Белокаменцев Иван. Ускоряемся в 3 раза

Посмотрел интересный доклад Ивана (не смотри, что речь про #1С 😱 разработчиков) — разработчики в целом не сильно отличаются 👨‍💻 .
Доклад про то, как ускориться в 4 раза.
Что точно зацепило:
1. Начали со #scrum (который не в scrum guide, а в книге Сазерленда) и это позволило ускориться в 2️⃣раза ⚠️
2. Дальше, в книге заметили пункты про Сю-Ха-Ри (любимый пункт одного-из-подписантов-манифеста-Алистера 📖) и запустили эксперименты по #PDCA это позволило ускориться ещё в 2️⃣ раза
3. Что помогло: тотальная готовность (и доверие) команды пробовать и тут же внедрять 🏃 эти эксперименты 🧪

Ну и пару моментов из презентации, которые немного зацепили.
1. Управлять по срокам это зло. И для этого есть масса причин

2. Надо понять, чего хочет тот или иной сотрудник. Важно тут не топить за «цели компании», так как они сильно оторваны от человека (конкретного разработчика).

3. Страх, как и наличие выбора, парализует и народ «тупит». Надо это минимизировать


https://youtu.be/xeQe-TemEfI

Чтобы два раза не вставать 🤗, будет ещё 1️⃣ встреча, но уже по #eduScrum 16.12.2019 в 18:00.
Ведут 3 замечательных 🔋человека🧚‍♀️, которые двигают #scrum в школах👩‍🎓!

Присоединяйтесь 🎧!
https://m.facebook.com/groups/eduscrum/permalink/567197593855095/

Дорогие подписчики.

Пролетел 2️⃣0️⃣1️⃣9️⃣й и наступает 2️⃣0️⃣2️⃣0️⃣.
Придавать большого значения смене числа в календаре, на мой взгляд, не надо, делать сегодняшний день поводом для больших обещаний тоже 😜,
Но если сама жизнь (в лице рабочего календаря) даёт нам возможность остановиться от годового забега, я хочу пожелать всем хорошо отдохнуть 🏝 , поразмышлять над прошедшим 🧠 и простроить цели на следующий год 🎄

Я полагаю, что большинство читателей как-то связано с управлением изменением, поэтому желаю в 2020 с новыми силами 💪 продолжить менять себя 🧑‍💻, команду, в которой создаёшь ценность👬 и в целом мир вокруг себя 🌎.

Есть фреймворк, который позволяет в сложной среде создавать крутые результаты (в частности, изменения) — называется #scrum, у которого есть 5 ценностей, в разрезе которых мои пожелания ниже:

💎 Смелости в новом году
💎 Открытости к новому
💎 Честности с самим собой
💎 Приверженности на достижение результатов
💎 И фокуса на своём развитии

Статья о том, почему вам не подходит #scrum

https://blog.kaiten.ru/9-фактов-о-скраме-которые-стоит-знать

Если коротко:
✅ выкидываешь что-то из scrum получаешь что-то другое, но точно не scrum
✅ не scrum под организацию, а организация под scrum
✅ нужны кроссфункциональные команды с единой общей целью, а не отделы и матричная структура с параллельными проектами
✅ придётся нанять дорогого scrum master, с опытом и соответствующим образованием (и это не тренинг от scrum.org)

Ford vs Ferrari
Посмотрел отличный фильм 🎥 и из-за профессиональной деформации, кроме отличной истории про дружбу 👬 и достижения 🎯 , я увидел историю про внутренний стартап 🥚 в большой и сильно забюрократизированной корпорации 🏢.

Как живет стартап?
1️⃣ в отдельном юридическом лице
2️⃣ в месте, где можно максимально быстро производить тестирование с пользователем
3️⃣ с человеком, принимающим решения (РО и гендиректором) в непосредственной близости, работающий вместе с командой
4️⃣ Короткими итерациями, в конце каждой работающий продукт.
По сути по #scrum

Как выглядит жизнь корпорации?
🔸Внешне все хорошо 👌
🔸Много денег 💰 ,
🔸Выстроенная иерархическая лестница, где у секретарши 🧚есть курьер и секретарша🤦‍♂️,
🔸Заевшаяся и в то же время импотентная верхушка👨‍💼, неспособная на решительные действия 👎

И единственное, что дало страртапу путевку в жизнь — это падающие продажи📉,то есть возможная (ибо денег все ещё очень много 🏦) внешняя угроза существованию компании 💀

Собственно, все как и в жизни.

30 января пройдёт митам по несильно популярному, но очень мощному подходу работе с требованиями и тестированию: Specification by Example

Подробности

“Традиционная модель сбора требований и создания спецификации основана на большом количестве формальностей, передач и переводов “с одного языка на другой”. Бизнес-аналитики извлекают знания из заказчика, и делают по ним спецификацию, затем перекидывают их разработчикам и тестировщикам. Разработчики извлекают знания из спецификации и переводят их в исполняемый код, который потом передается тестировщикам. Затем тестировщики берут спецификации. извлекают знания из них и переводят их в проверочные скрипты которые исполняются над готовой системой, которая передается им от разработчиков.

В теории это должно замечательно работать и все должны быть счастливы. На практике этот процесс имеет существенные недостатки и обычно приводит к огромной разнице между изначально просил заказчик и что он на самом деле получает. Существуют огромные разрывы в коммуникации на каждом шаге. Важные идеи попадают в эти провалы и загадочным способом исчезают. После каждого “перевода” информация искажается и неправильно понимается, увеличивая степень отклонения от ожидаемого изначально поведения разрабатываемой системы. Независимая интерпретация может помочь исправить ошибочную интерпретацию разработчиков или может быть совершенно другой неправильной интерпретацией требований к системе.”

При помощи Agile-процессов разработки циклы обратной становятся значительно короче, поэтому проблемы обнаруживаются раньше. […] Однако, вместо обнаружения проблем нам в первую очередь нужно работать над тем как избавиться от их появления.”
Это выдержка из книги Gojko Adzic “Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing” вышедшей в свет в 2009 году. Прошло десятилетие, однако индустрия разработки ПО по-прежнему страдает старыми болячками. Давайте лечиться :)

На первом митапе в этом году мы начнем знакомиться с подходом Specification by Example(Spec.by Example, SbE). SbE - это когда все люди, участвующие в создании решения, совместно определяют требования. Подход помогает выявить пробелы и несоответствия в требованиях ещё до создания софта. При его помощи мы можем создать достаточный объем спецификаций, который потом превращается в “живую документацию” в виде автотестов и конечно же это сильно упрощает работу разработчиков и снижает риск создания “неправильного” ПО. Само название “Specification by Example” появилось на свет в 2004 году с легкой руки Мартина Фаулера, однако, сам подход “совместного анализа” уходит корнями в 90е (а может и ещё раньше) и имеет другие разные названия - Behavior Driven Development (BDD), Acceptance Test Driven Development (ATDD), Test-Driven Requirements и тд.

Нам предстоит поучаствовать в так называемом Specification Workshop, в ходе которого мы совместно создадим требования для настоящей IT-системы :)

https://www.meetup.com/ru-RU/Technical-Excellence/events/267932278/
#DevOps #Agile #Scrum

Cargo cult и user story
Кто-то умный 🧠 что-то придумал, рассказал второму, тот третьему, и так далее и уже через пару пересказов от первоначальной идеи осталась только механика, и почти полностью пропало содержание (смысл).

Сейчас уже у многих есть «бэклоги», внутри которых «пользовательские истории» (или просто «истории») и, если забить в google, как их писать, то первая страница поисковой выдачи будет про дебильный шаблон:

Я, как <РОЛЬ>, хочу <ПОТРЕБНОСТЬ>, чтобы <ЦЕЛЬ>.

У людей не так много потребностей и точно тяжело себе представить условного пользователя интернет банка, который хочет «заходить по логину и паролю в интернет банк», но это встречается сплошь и рядом.

Почему вдруг «потребности» заменились на «функциональные требования»⁉️
Полагаю, причина в том, что последние в индустрии больше 50 лет, а этим вашим историям — в лучшем случае со времён ХР (который такое себе получил распространение), и опять же пересказы не способствовали правильному внедрению подхода.

«Истории» получили своё название не из того, как мы их записываем, а из того, как используем.

Давайте использовать их правильно (3 ‘C’):
❇️ card (карточка ), на которой пользователь написал свои хотелки
❇️ conversation (обсуждение) этой хотелки, выявление потребностей, выяснение деталей
❇️ confirmation (подтверждение) наших договоренностей

Кстати,
1️⃣ В #scrum никаких историй нет, а только — «элементы бэклога».
2️⃣ Кому интересно, то есть и 5С https://www.pinterest.com/amp/pin/650840583620800007/

#userstory

Вкратце про #scrum

«Солнечный свет ☀️ – лучшая дезинфекция 🧼».

Луи Брандейс, американский судья 👨‍⚖️

Привал ⛺️ или причал ⚓️ , пока не решил, но точно пауза...

С 15.09.2020 на этом канале не выходят посты.
У этого есть ряд причин:
🔗 Смена работы и позиции
🔗 Огромная загрузка по приоритетам
🔗 Тема agile стала для меня слишком узкой

Однако интересные (возможно только мне 💆‍♂️) темы никуда не делались, и теперь они почти на 💯% никакого отношения к #agile #scrum не имеют (этим в моей команде занимаются другие люди, и они вроде справляются отлично;)), а крутятся вокруг данных🗄, их обработки и аналитики📈.

В более сжатом формате (иногда даже просто репост) я делюсь ими в другом канале https://t.me/VisualElephant
Сейчас там 66 постов, которые выходят с разной периодичности (ибо не может быть интересно ровно Х элементов в день 🧐), но в следующие пару лет я планирую его наполнить изрядно ♾

Если есть желание, присоединяйтесь.

Что будет с этим каналом я пока не знаю 🤷‍♂️
🤷🏻 возможно, у меня найдутся силы продолжить вести его (контента ещё много из неизданного),
🤷🏻 может появятся ребята, кто готов подхватить канал — будем посмотреть (контакты все есть — велкам).

Спасибо всем, кто был здесь все это время, комментировал 📝, писал в личку, всячески говорил спасибо и тем, кто просто читал 📚. Надеюсь, кроме моей личной прокачки, это ещё помогло кому-то в бизнесе 💰 или в работе с командами 🤗

Видео от Simon Wardly про его #WardlyMaps у некоторых особенно рьяных #agile коучей может вызвать приступ неприятия.

У адекватных людей, которые хорошо знаю модель Киневин, про отсутствие серебряных пуль и ошибочность желания притянуть #scrum/agile/что-угодно к решению всех проблем, получат истинное удовольствие, как от контента, так и от манеры подачи.

Саймон с юмором и троллингом приводит интересные примеры необоснованных #digital-трансформаций.

Рекомендую к просмотру

"Когда умирает #scrum остается daily»(с) Кривицкий

Мне одному кажется решение не сертифицировать россиян (и не давать делать бизнес в РФ местным PST) нарушением ценностей #scrum, например, честность?
А гаденькая формулировка, что они это делают не из-за того, что США сказала: мы всех прижмем, если попробуете сунуться — нет, что вы — все потому, что людей им жалко.
Такая себе «смелость».
Я молчу, что они кинули ребят, которые впахивали на PST (даже представить не могу себе, сколько им стоило трудов) - вот такая, понимаешь, открытость и приверженность.

Авторизация результата

Я всегда думал что авторизация результата непосредственно связана с наградой и казалось, что если хотя бы не похвалить (то есть не дать себе или другим оценку), то и достижения нет, но кажется я здесь сильно ошибался 🤦‍♂️

Почему нужно разносить авторизацию и награду?
Смотрим на цикл работы над задачей е2е:
1️⃣ контекст задачи и что требовалось сделать
2️⃣ что делалось для ее решения
3️⃣ какой результат в итоге получился
Казалось бы: начальная постановка и итоговый результат могут сильно отличаться друг от друга и хвалить не за что?

Смотрим на эти 3 пункта и задаём вопросы
➖можно было сделать лучше в указанном контексте?
➖достаточны ли были усилия, которые предпринимались для того, чтобы gap был минимальным?
➖ насколько приемлем для нас полученный gap между план-фактом?

Слушая восхитительную Аню Обухову я вспомнил одно выступление дедушки Woody Zuill о том, как у него получилась крутая команда благодаря ежедневной ретроспективе: они
подводили итоги дня формате

🤩«что нам сегодня помогало?»

Из этого вопроса родились
💎 mob programming
💎 #noEstimate
💎И другие прекрасные вещи (про #scrum скоромно умолчим)

Кстати, авторизовывать результат можно делать как про себя так и письменно

Нашёл у Макса Дорофеева одну статью, откуда процитирую отрывок про #waterfall:
1. Сначала мы напишем все-все требования учтем в них всё-всё
2. Потом по этим требованиям мы сделаем архитектуру. Хорошую-прехорошую, чтоб не переделывать. Это будет не сложно, у нас же будут все-все требования
3. Дальше мы все это закодируем. По понятной архитектуре это просто.
4. Потом протестируем. По идее ошибок много быть не должно. Ведь все будет описано в ТЗ, нам будет все понятно. Ну и архитектура будет продумана до мелочей
5. Потом мы исправим те незначительные баги, которые найдут тестировщики
6. Затем мы напишем пользовательскую документацию. По готовому софту оно же легко
7. Дальше мы всех пользователей обучим. Тем более, когда документация есть, какие тут сложности?
8. Внедрим систему. Это уже будет совсем просто, так как пользователи обучены, документация готовая, ошибки исправлены, архитектура понятна…
9. Получаем профит. Ну и редкие запросы на незначительные доработки. Мы же в самом начале всё учли…
#scrum #agile

Что такое #продукт?
Когда я работал в ЦК Agile довольно часто возникал холивар по поводу продуктового подхода в целом и продукта в частности.
На эту тему в новой версии scrum guide есть определение

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

1️⃣ Продукт — это средство для доставки ценности.
То есть подразумевается, что есть ценность.
Нигде не сказано, что за ценность за такая, но точно сказано, что она есть. О видах ценности было ранее.

2️⃣ Продукт — это, что имеет границы.
Можно подумать, что тут как бы идёт кивок в сторону проектов (у хороших РМ проекты имеют чёткие границы по фичам, чтобы вписаться в бюджет), но мне кажется тут про другое — про цели, с которой создаётся продукт, видение, которое есть у основателя/ РО и проч.
Важный момент: SG как бы само собой разумеющееся говорит, что продукт есть (хотя не понятно, по где по жизненному циклу он находится находится)

3️⃣ У продукта (для многих открытие) есть заинтересованные лица (условный «бизнес», спонсор, заказчик и проч)
То есть как бы РО максимизирует ценность, мини-СЕО, но и у СЕО есть Совет Директоров и Акционеры, которые в случае чего могут и устроить СЕО ☠️

4️⃣ У продукта есть пользователи или клиенты
То есть либо те, кто использует продукт в своей жизни/работе, либо есть те, кто заплатил за то, чтобы продукт появился в пользовании у них, в компании, у пользователей.

5️⃣ Продуктом может быть что угодно: физический продукт, услуга (сервис) или ещё что-то абстрактное, у которой есть перечисленные 4 свойства

Хочется обратить внимание на «настоящие» продукты и ненастоящие продукты.
SG в определении не проводит границы между ними, поэтому может хрестоматийная CRMка быть продуктом? Проверяем по чек-листу — да, может. Лучше было бы, если CRM входила как «компонент» в продукт «система продаж» — конечно, лучше (про компонентные команды Ларман лучше меня расскажет https://t.me/tw0_percent/8 — офигеть, это был 8й пост в этом канале), но хочется подсветить, что в компании может быть команда развития CRM и она даже может использовать #scrum для того, чтобы «помогать людям, командам … создавать ценность через адаптивные решения комплексных задач»

Видео на бранч

Короткое видео (00:17:33) про #UserStory vs #Requirements, в котором автор приводит определение того, что такое «Требования» от IEEE:

A condition or capability needed by a user to solve a problem or achieve an objective.
Что можно перевести как
«Условие/возможность, необходимое пользователю для решения проблемы или достижения цели»

И тут возникает неловкая пауза, так как из определения не следует, что «Требование» — это адский документ со спецификацией реализации.

Советую посмотреть видео самому и занять свою позицию по поводу работы аналитиков в команде, а то как бывает:
- Мы работаем по «#scrum»!
- Поставки хотя бы раз в 2 недели по задачам взятым на планировании?
- Не, у нас сначала спринт аналитики, потом спринт разработки, а в конце спринт тестирования, после которого спринт сборки и выкатки на ПРОМ/PROD. Так что да: поставка у нас раз в 2 недели, но по тем задачам, которые мы взяли в работу 3 спринта назад.
- У вас не scrum, а «scrum, но…»🤦

#ШколаAgile #ПерваяСтупень #Scrum
Всем привет!👋

Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о первом воркшопе про Scrum, в котором разбираются зоны ответственности (или роли, если ссылаться на SG'17) 👨‍🔬👷‍♀️👨‍🏭👩‍🔧

Данный воркшоп делался на базе scrum puzzle от AgileVerse, в которой работают 2 бывших agile-коуча из #СБЕР (Лева и Миша привет). Ребята большие молодцы, что сделали для community puzzle по #Scrum

Зачем мы проводим этот, казалось бы непрактичный воркшоп?
Ребята, завершившие первую ступень, либо участвуют в трансформации, либо могут способствовать трансформации работы своей команды, и им важно знать, что предлагает scrum (условно "революционный метод") и kanban (условно «эволюционный»).
C другой стороны, scrum легко прочитать, но тяжело понять, поэтому делать это нужно в растянутом формате и как можно раньше.

За деталями по вокршопа можно обратиться к документу, внутри которого есть:
🎯 цели этой встречи;
🎁 результаты, с которыми нужно с нее выйти;
📋 таблица с таймингом.

В настоящий момент пока еще доступна доска в miro
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке

✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.

🗣 А в комментах напишите, пожалуйста, что мы забыли включить в основы, то есть что нужно добавить, а что нам стоит выкинуть, так как тайминг не резиновый 🤦‍♂️?

🤙 Остаемся на связи
Канал 2%
____
Материалы подготовлены Натальей Варакиной в рамках запроса о помощи community.

#ШколаAgile #ПерваяСтупень #Scrum

Всем привет!👋

Мы продолжаем публиковать в открытом доступе материалы Школы Agile и сегодня поговорим о втором воркшопе про Scrum, в котором детально разбирается фреймворк Scrum: события, артефакты и углубленное понимание зон ответственности в команде.

Детальный разбор направлен на то, чтобы у участников воркшопа сформировалось понимание насколько сильно связаны между собой элементы и отказ от одного из них может привести к тому, что фреймворк распадется и потенциально может сделать элементы бесполезными.
Данный воркшоп делался на базе scrum puzzle от AgileVerse, в которой работают 2 бывших agile-коуча из сбера (Миши и Лева). Ребята большие молодцы, что сделали для community их puzzle.
Важное место в воркшопе занимает X-Team Silos Game, ведь это отличный способ через игру привести людей к сотрудничеству и развивать «T-образных специалистов» (T-shaped people).

За деталями по вокршопа можно обратится к документу, внутри которого есть:
🎯 цели этой встречи;
🎁 результаты, с которыми нужно с нее выйти;
📋 таблица с таймингом.

В настоящий момент пока еще доступна доска в miro
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.

✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.

🗣 А в комментах давайте немного похоливарим, от какого элемента Scrum активно отбивается ваша команда 😈 и что вы с этим делаете?

🤙 Остаемся на связи
Канал 2%
____
Материалы подготовлены Лобанова Елена в рамках запроса о помощи community.