Маленький проворный со вкусом XP

Сегодня я поделюсь секретным соусом того, как мы работаем и почему это работает - яркий пример нынешнего мышления об Agile внутри Armakuni.

Я ограничиваю объем этой статьи: я сосредоточусь на «построении правильного», а не на выяснении того, что «правильное».

Однако прежде чем я перейду к этому, я хочу, чтобы вы знали, что эта статья не похожа на модель SAFe или Spotify. Я описываю моментальный снимок во времени, и, как обучающаяся организация, мы, ну, всегда учимся, так что это изменится. Эта статья, вероятно, уже устарела.

Я постараюсь дать вам аргументы в пользу каждого действия в этом процессе, и если вы сможете найти что-то еще, что достигает тех же целей, или эти цели вас не беспокоят, дерзайте, отрежьте, измените , вырастите его и расскажите о своем опыте.

Многие в Armakuni (мы называем себя AKers) описывают наш стиль как маленький проворный со вкусом XP, на нас и по-прежнему сильно влияет мышление движения экстремального программирования. Но что это значит? Один из способов взглянуть на это - циклы обратной связи, которые помогают нам создавать правильные вещи.

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

В рамках начального цикла мы проводим множество встреч по планированию итераций (IPM). Это происходит еженедельно или раз в две недели. IPM предшествует демонстрация, а затем ретроспектива.

В рамках этого у нас есть ежедневная стендап, которую мы позиционируем как мини-сеанс планирования на день. Стендап - это возможность найти сотрудников и использовать то, что вы узнали накануне, для планирования сегодняшнего. Ежедневный, дальновидный цикл обратной связи.

Наконец, у нас есть парное программирование, которое дает посекундный цикл обратной связи. Мы верим в парное программирование не только как в инструмент, обеспечивающий качественную разработку программного обеспечения, но и как в метод создания совместной собственности. Я не буду здесь много говорить об этом, но мы более подробно рассмотрим парное программирование в нашем блоге.

Я сейчас углублюсь в каждый из этих циклов, но хочу, чтобы вы заметили здесь, что мы оптимизируем циклы обратной связи. Это потому, что мы стараемся учиться каждый день, каждую секунду, как команда и как сообщество. Мы делаем это, создавая частые возможности для безопасных пространств, чтобы поговорить о том, как идут дела, и о местах, где мы можем поднять проблемы, поделиться тем, что работает, узнать, что не работает, и постоянно вносить небольшие изменения с низким риском и низким трением на основе на этом обучении.

Начальный цикл

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

Прекрасной моделью для объяснения этого является модель Cynefin.

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

Мы решаем проблемы, на которые часто нет хороших ответов и на которые нам нужно искать путь на каждом шагу. Чтобы сделать это возможным, вам нужно создать цикл экспериментируйте, оценивайте, который приведет вас к месту, где вы можете более эффективно обслуживать клиента (который также будет узнавать о себе и постоянно меняться, мне нравится движение целевых столбов). Модель Cynefin называет это сложным пространством. В этом видео Cognitive Edge от Дэйва Сноудена есть отличное резюме Cynefin.

Начало - это признание этого факта.

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

Используя эту модель, вы всегда преследуете текущие бизнес-цели, вы всегда движетесь вперед и у вас есть способ переоценить ситуацию, когда этого не происходит.

Начальная петля - это рука направления © и выравнивания. Итак, мы ориентируемся и узнаем, в каком направлении мы движемся. Мы также договоримся о том, как мы будем работать в команде, и создадим начальный бэклог.

Начало начинается с определения целей, нецелей, действующих лиц и рисков. Как только мы вместе их обнаружим, мы можем взять их и передать в действие по картированию историй, чтобы сгенерировать наш Backlog.

Об одном из них я хочу подробнее остановиться: нецели. Нецели делятся на два типа; Во-первых, мы хотим четко указать, что работает против того, чего пытается достичь этот проект. Не все, что вам ясно, понятно всем остальным. Изложите свою ментальную модель. Вторая категория - это то, что мы знаем, что хотим делать, но пока не знаем. Мы могли бы внести их в еще одну будущую версию, но мы не собираемся делать их в эту секунду (начало работы над нецелевыми задачами - это способ сказать, что пора Reincept).

Сюжетная карта позволяет вам провести черту и попытаться набросать грубые эпосы, которые вы будете воплощать, и, что особенно важно, первые две итерации рассказов. Я не буду здесь слишком углубляться в картирование историй; вы можете прочитать об этом в User Story Mapping Джеффа Паттона.

Почему две итерации? Давать определения историям сложно. Если эти истории находятся в Backlog и когда-либо будут развиваться, вы потратите эти усилия; более того, вы оставляете себя уязвимым для того, чтобы быть заблокированным в их реализации (предвзятость плана-продолжения - это человеческое значение по умолчанию)

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

Другая часть начала - это согласование способов работы. Способы работы важны, потому что они определяют условия, при которых происходят переходы в предстоящем проекте, и определяют петли обратной связи, чтобы помочь разработчикам программного обеспечения соответствовать стандартам, и предлагают владельцам продуктов возможность получить обратную связь о качестве своих историй.

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

Этот процесс может показаться краткосрочным, но именно он позволяет команде быть гибкой и отзывчивой. Кроме того, при участии всех членов команды вы думаете со всей командой, а не с отдельным человеком в группе (например, отрывок из Power Rangers, где они объединяются, они становятся Мегазордом - эй, это подтверждено исследованиями!) .

Inception оставит вас с:

  • Цели, не цели
  • Актеры
  • Риски
  • Достаточно приоритетного отставания
  • Соглашение об определении готовности (DoR) и определения готовности (DoD)
  • Обязательства всей команды

На следующий день вы начинаете свою первую итерацию.

Как построить итерацию

В команде у нас есть несколько ключевых ролей. Эти роли могут меняться, они могут больше походить на головные уборы, которые вы носите, но в основном это мясистые и мягкие люди. Эти две роли - владелец продукта (PO) и технический руководитель (Tech Lead или TL).

Обе эти роли имеют разные обязанности и призваны отстаивать конкурирующие позиции. Владелец продукта несет ответственность за то, чтобы получатель работы был хорошо понят, получал то, что ему нужно, и постоянно узнавал о нем больше, а также приспосабливал нашу деятельность к их потребностям.

С другой стороны, технический руководитель отвечает за то, чтобы то, что попадает к клиенту, было хорошего технического качества, обеспечивая устойчивую итерацию и развитие в отдаленном будущем. Как вы увидите позже, мы наделяем эту роль разумной властью, чтобы уравновесить ее с владельцем продукта - неявно сильной позицией.

Чтобы прояснить эти роли, я хочу сформулировать их в терминах итерационной доски.

Наша доска спринтов по умолчанию выглядит так: Icebox, Backlog, In-progress, Delivered и Done. У нас есть типы карт: «Сюжет», «Работа по дому» и «Ошибка».

По умолчанию все эти типы карт попадают в Icebox. Icebox является бесплатным для всех. Кто угодно может положить туда вещи. Он называется Icebox, потому что заказчику и техническому руководителю необходимо проделать некоторую работу, чтобы разморозить существующие истории, чтобы их можно было использовать.

Владелец продукта создает истории, которые представляют функции (хотя иногда и крошечные) и работу, ориентированную на клиента. У них есть размеры, и они могут поступать из Icebox в Backlog по согласованию с владельцем продукта и техническим лидером.

История может переместиться из Icebox в Backlog только при условии, что технический руководитель или другой технический специалист, а также владельцы продукта и технические лидеры разработали достаточно дизайна. Нам необходимо согласие между этими двумя ролями, потому что мы гарантируем, что у нас есть представление о техническом качестве и направлении продукта. Кроме того, рассказ должен соответствовать требованиям «определения готового». Если история не готова, команда может сказать «нет». Это цикл обратной связи, который передает ментальную модель от заказа на поставку разработчику.

Рутинные работы - это техническая задача, которую необходимо выполнить, но она не оказывает видимого воздействия на клиента - например, создание базы данных или переформатирование базы кода с помощью инструмента контроля качества кода. У них нет оценок, и владелец продукта не должен просматривать их до или после. Однако они должны быть видимыми и присутствовать на доске.

Работы, выполняемые техническим руководителем, могут пропустить Icebox, вставляя их в бэклог без участия владельца продукта и позиционируя их так, как технический руководитель считает нужным (чтобы владелец продукта не мог постоянно помещать их в последнюю очередь). Владельцы продуктов почти всегда имеют гораздо больше возможностей, чем технические специалисты; рутинные работы позволили нам каким-то образом перебалансировать колоду, чтобы обеспечить встроенное техническое качество. Чем зрелее команда, тем меньше требуется хлопот. На раннем этапе они жизненно важны для выявления скрытой работы, которую выполняют многие технические специалисты, и о которой владелец продукта мог не подумать.

Хозяйственные работы позволяют нам испечь качественно. Тем не менее, они также учат технических специалистов не предполагать, что все знают все о том, что необходимо сделать, и дают владельцу продукта достаточно технических деталей, чтобы оценить скрытые усилия.

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

Отказ от истории предпочтительнее создания ошибки, но история готова, создайте ошибку.

Начало итерации

В начале итерации команда определяет размеры и фиксирует истории на КОРОТКОМ совещании по планированию итерации (IPM). Вступая в эту сессию, владелец продукта и технический руководитель должны были подготовить все истории, оставив невыполненной только разбивку историй на задачи (простой список дел внутри истории). Это сократит продолжительность сеанса и позволит убедиться, что исследование было проведено заранее.

Сеансу нужна эта подготовка заранее, и без нее он не пройдет. Поэтому я рекомендую product owner-у или техлиду тратить 15 минут каждый день на уточнение Backlog.

Когда история находится в Backlog, когда пара берет ее, она переходит в обработку. Разработчики втягивают работу в столбец из расчета 1 билет на пару. Ограничением в этой системе почти всегда являются разработчики. Оценить выполненную работу должны они, а не владелец продукта. Если они перестают работать над чем-то, это возвращается в начало Бэклога.

Если ваши разработчики не являются узким местом, переместите это поведение вытягивания на следующий шаг.

После того, как разработчики приносят соответствующие кровавые жертвы (вегетарианцы могут заменить свекольный сок) для реализации функции, эта функция перемещается в столбец «Доставлено», который владелец продукта может просмотреть.

Разработчики добавляют к рассказу, как продукт-владелец должен видеть, как эта история работает. Поставляемая колонка служит нескольким целям; во-первых, это служит подсказкой для пары, чтобы проверить, выполнили ли они критерии приемки, написав руководство «Как принять».

Во-вторых, мы упрощаем для владельца продукта возможность опробовать эту функцию и создаем подсказку для владельца продукта, чтобы он мог позвонить человеку, на которого эта функция влияет, и показать им крутые вещи, которые предоставили разработчики. Мгновенная обратная связь!

Если он не работает должным образом, владелец продукта помещает его обратно в верхнюю часть бэклога с пометкой, в которой запросы на покупку и ментальные модели разработчика не совпадают.

После этого вставьте билет в столбец «Готово» и приступайте к вечеринке.

Это отличная быстрая петля обратной связи, но это супер-хит дофамина, показывающий людям крутые новые вещи, которые сделали вы и ваша команда.

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

Теперь я хочу упомянуть, что общекомандные демонстрации по-прежнему являются жизненно важной частью процесса разработки. Демо - это инструмент согласования, первая возможность для спонсоров и тех, кто придерживается одной и той же ментальной модели. Позволить заинтересованным сторонам откликнуться, когда что-то не помогает им решить их проблемы или, может быть, упустили суть.

Итак, неделя выглядит так: IPM, состоящая из команды, быстро согласовывающей и оценивающей работу следующей итерации (менее чем за час, ваш Backlog должен быть готов из-за постоянной небольшой подготовки к планированию, выполняемой PO и техническим руководителем в течение недели), неделя ежедневных стендапов между парным программированием, демонстрацией и затем ретро (они вместе обычно занимают 1:30 минут) в конце недели, после чего снова следует IPM.

Петли обратной связи

Краеугольным камнем любой обучающейся организации является обучение себя и всех остальных, чтобы учиться, а не основывать свои действия на предположениях, которые вы сознательно или бессознательно оставили неизменными. Мы пытаемся решить эту сложную проблему, используя ту же технику, что и при непрерывном развертывании. Непрерывное развертывание решает сложную проблему развертывания, выполняя его много, поэтому мы хорошо с этим справляемся. Мы прерываем цикл предположений, создавая для себя петли обратной связи, которые могут во многом их нарушить.

Как правило, это следующие петли:

Ежедневные петли

  • Стендапы
  • Сопряжение
  • Обработка бэклога
  • Владелец продукта принимает истории

Еженедельные циклы

  • Ретроспективы
  • Планирование
  • Демо

Квартальные (Ish) циклы

  • Начальное планирование

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