Оказывается, история с Циклом PDCA разворачивалась не шуточная, примерно как с пониманием SCRUM в наши дни. Деминг переживал, что слово «check» в английском значении будет «to hold back», поэтому хотел явно выделить этап Обучения, получения опыта из данных.

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

Для тех, кто хочет копнуть глубже в оригинал.

Дано: провести мини тренинг по канбан, для небольшой команды (ситуационной), которая состоит из представителей разных команд, но у которых есть общие инициативы над которыми они работают.

Решение: для этих целей взять Changeban из папки с полезностями (https://yadi.sk/d/IHOIBnS59-ZxLg) нашего Канбан.клуба и заодно обкатать русскую версию.

Что получилось:

1. Для команды нужен был легкий формат, без графиков и метрик, показать как работают WIP-лимиты, поэтому сразу теорию про Lean Startup, тот что лежит под капотом этой симуляции, я пропустил — это оказалось правильным решением
2. Колода карт, в отличии от монетки, мне понравилась больше. Каждый раунд — у тебя одинаковый набор, но раздается случайно и стендапы команды проходят динамично. Монетки, нужно подкидывать, они падают и теряется время и динамика.
3. Очень здорово, что можно ставить цель, набрать 20 очков (включая бонусные).
4. Использовать большие стикеры и маркерно-магнитную доску — то, что надо. Меньший формат требует уменьшения размера стикеров

Что можно улучшить:

1. Брать колоду карт полную, у меня была от 6 до Туза, а нужно от 2 до Туза. Из-за этого команда из четырех человек сыграла только 9 раундов и не получила возможности выбить все 20 очков. Из-за этого, в первом раунде было 7 очков, а во втором только 10
2. Я наклеил по 4-ре стикера, каждого цвета, а нужно все. Из-за этого я сделал «бесконечный бэклог», что было неправильно. Об этом я узнал, когда дошел до слайда дебрифа, а там был вопрос «что было бы, если ваш бэклог был бы бесконечным?». А он у них такой и был, по факту, и на фото можно увидеть, что было бы :))
3. Не брать готовые презентации, а готовить, или свою презу, или свои флипы (рассказывать по слайду, а точнее читать с него — не удобно)

Итог: результат мне понравился. Ребята смогли увидеть момент, что во втором раунде они стали друг другу помогать, только за счет того, что появились лимиты. Данную практику они решили взять себе на вооружение, посмотрю что у них приживется со временем.

Что было выявлено по итогу присутствия на ретроспективе, у команды, которая уже около 3 месяцев работает по Scrum. Команда из 7 человек, причем ВП и СМ находятся в одной локации, а вся остальная команда в другой.

Что имеем из фактуры, над которой можно поработать:

1. Цель спринта состоит из 8 пунктов, в формате что надо сделать. (причина — задачи не связаны друг с другом, а раз так, то и разные цели)
2. Запланированный на спринт объем работы, команда не выполняет (команда хочет лучше оценивать задачи в человеко-часах и просит СМ дать им инструменты, чтобы трекать это Jira)
3. Команда не довольна оценкой результативности от ВП по результатам обзора, в прошлый раз было 4.5 из 10, в этот раз 3.5 из 10, команда не довольна и хочет лучше планировать
4. На ревью пользователи не приходят, так как им нечего показывать

Варианты, что можно улучшить Скрам-мастеру в его команде:

1. Сейчас ВП и команда по разные стороны баррикад, так как на обзоре никого кроме ВП и команды нету, то это походит на отчетную встречу. По этому команда спрашивает у ВП, как хорошо она поработала, на что получает низкую оценку, так как ВП смотрит на разницу между что планировали и что сделали. Поэтому команда хочет защититься от этого, хочет начать мерить свое время, чтобы узнать что она молодец, но реальная причина не в этом. Результат — демотивация команды. СМ нужно вернуть команду и ВП на одну сторону и направить их к единой цели. Еще раз сформировать общее видение того, что делает команда (см. цель спринта). Цель сформулировать по SMART.

2. Обратную связь получать от Пользователей, так она будет объективной и команда должна мочь сама оценить свою результативность без интерпретации ВП. Объективность можно достичь тем, что это будет какая-то измеримая цель: количество денег, пользователей и т. д.

3. Признаться, что ниодна задача не сделана до конца и поставить самим себе за результат 0. Еще раз вернуться к теме, что такое DoD и чем он отличается от AC. СМ нужно запустить активность с командой по генерации DoD и посмотреть на свой бэклог спринта с тем, что вся команда уверена, что сможет сделать все запланированное с учетом согласованного DoD

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

5. Еще раз с командой проговорить цикл, что когда мы берем задачу в спринт, то обсуждаем АС (критерии приемки), все задачи обязательно проходят DoD. АС — для каждой задачи свой, DoD общий и его можно менять на ретроспективе. Команда получает ОС от пользователей напрямую, и это являются экологичным источником положительных или отрицательных эмоций, где ВП может подбодрить команду и прийти на планирование с новым задором.

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

После такого разбора, за такой период, СМ сказал: «Ааа.... я все сломал, ничего не работает, я почти убил команду» :)

И здесь лежит ловушка в том, что Scrum всегда не работает — и в этом и была задумка. В этом и есть источник улучшений команды для СМ. Включайте режим Коломбо, экспериментируйте, сначала сделайте все события скрам, потом улучшайтесь.

Реально убить команду СМ может только специально и это тоже надо уметь. Нельзя все сразу предусмотреть, каждая команда идет своим путем, ему нужно только помогать.

Автор Роман Петров

Рубрика Микрокейсы.

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

Что поменяли:

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

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

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

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

Продолжение следует.

Автор Роман Петров

Порой Scrum-мастер задаётся вопросом: «Хорошо ли у нас проходят события Scrum?» однако, не может найти подходящий инструмент.

Инструмент «Паутинка» позволит команде на ретроспективе оценить события и совместно разработать план по улучшению.

Инструмент состоит из 3-х частей:
I часть — выравнивание критериев оценки с командой, что для команды 1, а что 5
II часть — совместная оценка событий участниками команды
III часть — сведение полученных оценок и разработка плана по улучшению

I. Выравнивание критериев оценки с командой

Подготовка: флипчарт с нарисованной шкалой оценки от 1 до 5

Команда и Scrum-мастер пишут на стикерах, что для них оценка «1», а что оценка «5».
Например:
«1» — нет цели/регулярное опоздание участников/плавающие события (в разное время)/отсутствие участников без уважительной причины;
«2» — тайминг не соблюдён/цель не досигнута/отсутствие участников без уважительной причины;
«3» — тайминг соблюдён/цель достигнута;
«4» — всё хорошо, фасилитирует Scrum-мастер;
«5» — команда всё делает сама, Scrum-мастер фасилитирует только ретроспективу

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

II. Совместная оценка событий участниками команды

Подготовка: флипчарт с матрицей событий

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

• DSM (или Stand-up);
• Планирование;
• PBR (согласно Scrum guide не является отдельным событием, однако эта активность крайне важна для команды)
• Обзор спринта
• Ретроспектива
• Спринт (как в целом команда оценивает достижение цели спринта, дополнительно можно включить оценку выполнения роли Владелец продукта и Scrum-мастер)

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

III часть — сведение полученных оценок и разработка плана по улучшению

Подготовка: флипчарт с паутинкой

На соответствующие оси «Паутинки» наносим разными цветами оценку команды и Scrum-мастера (см. картинку)

Расхождение линий оценки Scrum-мастера и команды — это фокус внимания для Scrum-мастера по тому, как он видит работу внутри команды.

Scrum-мастер фокусирует внимание команды на события, которые получили наименьшую оценку от команды и просит их написать на стикерах ответ на вопрос: «Что нам нужно сделать, чтобы данное событие улучшилось?»

Далее команда голосует точками за улучшение, выбирает ТОП3 для реализации и создаёт «план действий» 

В своей статье Брэнан Уовчко эксперт в Kanban и Scrum выделяет 5 условий, при которых Kanban подходит команде лучше, чем Scrum.

1. Низкая терпимость к изменениям

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

2. Очевидный на всех уровнях

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

3. Быстро меняющиеся приоритеты

Scrum дает наилучшие результаты, когда команда берет на себя пул задач и остаётся сфокусированной на них на протяжении всей итерации (спринта). Чтобы Scrum был успешным, необходимо чтобы заинтересованные стороны были информированными и эмпатичными, стремились быть agile (гибкими).

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

4. Маленькие команды

Идеальный размер Scrum команды, это команда, которую можно накормить двумя пиццами (two pizza team). Это гарантирует, что команда достаточно маленькая, чтобы быть эффективной и достаточно большая, когда имеет смысл вкладывать временнЫе инвестиции во встречи. Если ваша команда меньше, чем two pizza team, вам больше подойдёт Kanban.

5. Сложное взаимодействие

Scrum изменил взгляд мира на работу — появились кросс-функциональные команды. Идея, что команда состоит из людей из разных отделов и дисциплин, меняет правила игры.

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

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

Kanban не использует временные рамки для создания предсказуемости, он использует время выполнения заказа (lead time), поэтому он способен устойчиво поддерживать неограниченное количество действий и взаимодействий.

Scrum и Kanban не являются конкурентами или врагами. Оба являются средством, помогающим командам и их заинтересованным сторонам достичь устойчивого успеха. Не думайте, что лучше всего подойдет то, что вы лучше понимаете или чаще используете. Будьте agile и экспериментируйте с обоими!

Текст адаптирован с оригинальной статьи:

https://www.mountaingoatsoftware.com/blog/when-kanban-is-the-better-choice

Инструмент «5 пороков команды» П. Ленсиони отлично помогает командам посмотреть как у них идут дела внутри, провести самодиагностику и выработать шаги по повышению эффективности командной работы.

ВАЖНО:

1. Проводится опытным Scrum-мастером/Agile-коучем, который знает и понимает как работать с командной динамикой и умеет управлять конфликтами.
2. Рассчитана на зрелую Agile-команду численностью не более 12 человек.
3. Первая встреча выездная на 1 день, далее уже в формате ретроспектив

Шаги до встречи:

Чтобы эффективно провести сессию до её начала вам необходимо:

1. «Продать» данный инструмент команде, в которой вы планируете это сделать, чтобы они понимали цель;
2. Получить согласие от всех участников команды на проведение данной сессии. Этот аспект очень важен, так как в течение всего мероприятия участники будут выходить из зоны комфорта, они должны быть к этому готовы и согласны;
3. Направить всем участникам команды тест, который им необходимо заполнить до сессии и принести с собой (тест вы можете найти здесь: https://yadi.sk/i/4tTXFTnY3G9tuQ );

На командной сессии:
Первая часть: открытие продолжительность ~1 ч.

1. Как и в начале ретроспективы необходимо создать атмосферу. Для этого можно использовать любой дизайн, например с сайта https://retromat.org/

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

3. Подготовьте заранее заготовки флипчартов с правилами и расписание сессии.
   Перед тем как перейти к цели встречи с участниками команды необходимо договорится о правилах (например, правило поднятой руки, одного микрофона, парковка, не отвлекаемся на девайсы и т. п.) и о расписании (лучше делать сессию 50 мин. работы и 10 мин. отдыха).
   ВАЖНО: Обязательно получите «ОК» от команды на правила и расписание, в течение встречи, вы не раз будете возвращать команду к правилам. «ОК» также важно получить, чтобы не было сопротивления от команды, так как это их встреча, если им что-то не нравится или они хотят что-то добавить, измените написанное или создайте новый флипчарт.

4. Перейдите к цели. Озвучьте цель и спросите команду согласны ли они с данной целью (цель следует написать на флипчарте, чтобы команда видела)
   Пример цели: Остановиться, выдохнуть и посмотреть как у нас идут дела внутри, провести самодиагностику и выработать шаги по повышению эффективности нашей командной работы.
   ВАЖНО: если команда не согласна с целью, то совместно создайте новую, удовлетворяющей всех цель сессии.

Вторая часть: общее понимания и диагностика продолжительность ~3 ч.

1. Ещё раз познакомьте команду с инструментом, расскажите кто его создатель (Патрик Ленсиони) и где можно в интересной форме о нём прочитать (одноименный бизнес-роман «5 пороков команды»). Покажите команде треугольник, но пустой :)

2. Скажите команде: «Перед тем как приступить к работе с треугольником давайте сведём результаты ваших тестов в единое»
   Это можно сделать на флипчарте, но для скорости и удобства лучше сделать в Excel. Не показывайте команде результаты, вы вернётесь к ним немного позже — сохраните интригу.
   (Excel вы можете найти здесь: https://yadi.sk/i/_9ceVJDVptQmTA )

3. Верните команду к флипчарту с пустым треугольником и начните совместно с ними заполнять и прорабатывать уровни. Так как вы уже ранее встречались с командой и рассказывали про данный треугольник, здесь важно включить участников в совместное «вспоминание»
   Спросите: «Помнит ли кто-то, что у нас на первом уровне?» После того, как назвали, запишите в треугольник. Далее спросите: «Есть ли кто-то кто считает, что доверие не важно в команде?» Если такие есть спросите: «Можешь, пожалуйста, рассказать почему?» Не критикуйте и не переубеждайте, просто выслушайте и посмотрите на реакцию других участников. Если участник не готов сказать — это его право. Если вдруг начинается дискуссия аккуратно остановите её и верните команду к цели сессии.

4. Попросите участников команды на стикерах (1 стикер = 1 мысль) написать, что они понимают под фразой «Взаимное недоверие», далее каждый из участников выходит и, озвучивая, клеит свои стикеры. Когда все наклеили свои стикеры, уточните не хотят ли они ещё что-то добавить и если у кого-то возник инсайт, обязательно запишите. Это упражнение повторяем для всех уровней, однако, с небольшим дополнением: уточните не хотят ли участники переместить свои стикеры на другой уровень.

5. Вернитесь с командой к тесту и посмотрите на результаты, которые получились. В первую очередь посмотрите на те пороки, которые набрали 3-5 баллов. Если у команды получилось более одного порока в данном диапазоне начните с самого первого, например, тест показал, что у команды Порок#1 и Порок#3 попали в диапазон 3-5 баллов, начните с Порока#1 и проработайте его до конкретных шагов и первых результатов и только потом переходим к следующему пороку

6. Для этого шага у вас заранее должен быть подготовлен флипчарт с вопросом «А как это у нас?».
   Попросите участников команды на стикерах (в данном случае можно использовать длинные стикеры) написать ответ на вопрос «А как это у нас?». На этом шаге важно понять как этот порок проявляется у команды. После того как участники команды написали, попросите наклеить, озвучивая написанное.

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

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

ВНИМАНИЕ: остальные кластеры не выкидываются, а остаются для рассмотрения на будущих ретро команды, желательно не раньше получения первых результатов по первому кластеру.

После данного блока команду желательно отпустить на обед.

Третья часть: разработка плана действий продолжительность ~2 ч.

1. Для данного шага необходимо подготовить флипчарт с вопросом «Как улучшим ситуацию?»
   Итак, команда выбрала для себя первый кластер, с которым будет работать. Попросите команду на стикерах написать решения (1 стикер = 1 решение). Далее каждый участник озвучивая, клеит свои стикеры на флипчарт.

2. После того, как все участники наклеили свои предложения проверьте их на адекватность по матрице («решает/не решает» проблематику и сможем «сами/нужна помощь»). Зачитайте каждый стикер и совместно с командой отнесите стикер в соответствующую ячейку. После того как все стикеры распределены фокусируйте внимание команды на ячейки «решает/сами» и «решает/нужна помощь».
   Стикеры, которые по мнению команды попали в «решает/нужна помощь» — это область работы Владельца продукта и Scrum-мастера/Agile-коуча. Уточните у команды чья по их мнению им нужна помощь.
   Далее переходите к стикерам в ячейке «решает/сами» и разрабатываем план действий (см. http://kanban.club/all/do-action-plan/)

ВАЖНО:

1. В течение данного сессии не переходите на работу в малых группах, здесь важна динамика целой команды и ощущение их самих себя как единого целого. Важна динамика их всех целиком
2. Если команда начинает позитивно что-то обсуждать и хихикать, не вмешивайтесь, просто молча подождите, когда команда вернётся — это важный командообразующий момент;
3. Если команда начинает что-то конструктивно обсуждать, не вмешивайтесь, это их встреча и, возможно, им надо выговориться, подождите, когда команда к вам вернётся.
4. Как только чувствуете, что команда «накалена» или «устала» — сделайте перерыв. Возвращая команду с перерывов сделайте краткий обзор того, что было сделано до ухода на перерыв (recap).

Мы будем рады вашим комментариям. Удачной вам сессии.

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

Так как же Команде разработчиков договориться с Владельцем продукта о том, что же такое сделано? И тут, на помощь нам приходит Критерии Готовности (DoD или Definition of Done) — это чек-лист работ, которые проходит каждая из задач команды, после чего она может на каждую из них свою печать «Готово». Этим команда заверяет, что продукт сделан правильно.

Владелец продукта, принимая задачу от команды, уже знает, что все очевидное и ожидаемое, по умолчанию от команды, сделано. А чтобы, это действительно было так, то стоит, этот список действий, записать в явном виде и согласовать с двух сторон. Цель в том, чтобы не было разночтений, все четкой ИЛИ работа СДЕЛАНА, ИЛИ НЕ СДЕЛАНА, только в этом случае, будет доверие к команде от Владельца Продукта и Заинтересованных лиц.

Кто составляет этот список?

Команда. Это именно команда, говорит, что для нее значит, что задача сделана, это общий список без привязки к контексту. Это может быть для ИТ проекта: «Прошли автотесты, Сделан регресс, Написана пользовательская документация, и т. д.», для доставки: «заказ собран в коробку, упакован в пакет, зарегистрирован в систему, наклеен штрих-код, положен на полку на складе».

Достаточно ли это для Владельца продукта?

Очевидно, нет! То, что код прошел все технические процедуры, а коробка лежит в красивом виде на правильной полке, не говорит ничего о содержимом. Для содержимого, есть дополнительный критерий, называемый Критерий Приемки (Acceptance Criteria). Он уже составляется Владельцем продукта, для того чтобы понимать, что сделали вещь правильную.

Соединение DoD и AC, дает нам прозрачность в том, что была сделана правильная вещь правильным способом.

Давайте посмотрим на это, на примере метафоры нашего любимого аэропорта.

Мы приходим в аэропорт и сдаем багаж. Каждый багаж проходит необходимые проверки: по размеру, весу и содержимому. Если в самолет загрузили багаж, то команда самолета уверена, что все, что загружено правильной формы, безопасно и т. д. Эти все процедуры — это критерии готовности (DoD), в которых вам можно, что сдав свой багаж, вы получите его целым по прилету. И тут-то содержимое чемоданов — это критерий приемки (AC), он то и важен для вас, в соответствии с ним, вы смотрите, что все что вы положили в чемодан, прилетело в целости и сохранности.

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

В пиццерии

DoD: пицца приготовлена, пожарена, нарезана, упакована в коробку / подана на стол и нигде в процессе не испорчена

Acceptance Criteria: пицца именно того размера и вида (состав ингредиентов), какого заказал клиент.

Говоря математическим языком: DoD — это необходимое условие, а AC — это достаточное условие. Они всегда идут рука об руку, но путать их не надо.

Еще, для больших команд, применяется критерий готовности Релиза (Definition of Done for a Release).

Если вам не нравится слово Критерий приемки, то можете взять вариант Хенрика Книберга «Как продемонстрировать» (How to demo) или Майка Кона «Условия удовлетворения ожиданий» (Conditions of Satisfaction). Эти варианты больше подходят для задач без ИТ, например, в высокоуровневых бизнес-целях.

Что такое идеальный DoD?

DoD — это те работы, которые мы делаем с каждым элементом бэклога, каждый спринт. И в идеале, у вас в результате есть то, что сразу можно поставить \ отдать пользователю. Но что делать, если для этого нужно сделать что-то еще? Например, провести сборку, сделать нагрузочное тестирование, подготовить документацию, получить согласования от юристов, бухгалтерии, безопасников и т. д. Быть честным!

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

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

Сокращенно, AC — называть не удобно и можно путать с Agile Coach, Автоматизированная Система и т. д. Поэтому, давайте пользоваться термином CoS (Conditions of Satisfaction) Условия удовлетворения ожиданий

Автор: Роман Петров

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

Почему именно такой порядок?

1. Визуализация — мы начинаем с того, что осознаем, как мы сейчас работаем, какой у нас процесс. Это первый очень большой стресс. На этом этапе, команда такой низкой зрелости, что спрашивать ее о том, какие у нее цели изменений и как они будут их мерить, или банальные (выпускать как можно быстрее) или общие (сократить time-to-market)

2. Явные правила — следующий шаг, это описать свои правила для внешнего заказчика, либо договориться внутри себя (если команд несколько и они делают один продукт). Тут тоже возникает ряд сложностей, раньше такого не делали и все устные договоренности и то, что само собой подразумевалось, нужно описать в явном и общедоступном месте

3. Циклы обратной связи — теперь, чтобы закрепить полученный результат, прописываем обязательно получение обратной связи от заказчика для каждого элемента работ (обычно это значительно чаще, чем раз в квартал), а так же ретро для команды. Первая такая ретроспектива проводится на при проведении STATIK. Этот шаг, позволяет не усугублять текущее положение и уже начать работу над совершенствование визуализации и явных правил работы, так как обычное дело, что то что было создано в первой попытке нуждается в улучшении

4. Измеряй время выполнения работ, после того, как наш процесс стабилизировался, можно начинать собирать метрики и смотреть, как мы работаем сейчас. Для нас это является первой доказательной точкой того, что происходит в действительности в работе команды/сервиса

5. Ограничивай незавершенную работу — наконец, мы сможем увидеть явное влияние того, как помогает нам оптимизировать поток, за счет установики WIP-лимитов с использованием Закона Литтла. Эта точка, дает сильный заряд гордости за полученный результат от проделанной работы и мотивации на новые улучшения на основе метрик.

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

Автор: Роман Петров

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

Но что же такое продукт?

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

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

Что является продуктом авиакомпании?

Взять к примеру авиакомпанию. Некоторые сотрудники компании утверждают, что авиакомпания осуществляет только одну вещь (или услугу): перемещает людей из одной точки в другую. Эти же сотрудники утверждают, что несмотря на то, что в компании может работать более 40 тыс. человек, у компании только один продукт.

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

Всё ли перечисленное — продукты?

Определение продукта и примеры

Майк Кон определяет продукт как что-то (физическое или нет) созданное в процессе и предоставляющее ценность рынку.

Исходя из этого определения, стул будет продуктом, Microsoft Office тоже, услуги по Agile консультированию тоже продукт, картина тоже будет продуктом.

Таким образом, продуктом может быть что-то физическое (например, стул) или что-то цифровое (например, Microsoft Office, электронная книга, телевещание), также продуктом может быть услуга (например, Agile консультирование).

Продуктом может быть даже идея (например, запатентованный алгоритм).

Каждый из этих видов продуктов создаётся в процессе или, говоря проще, посредством одного или нескольких действий. Кто-то изготавливает и собирает стулья. Для Microsoft Office был создан дизайн, написан и протестирован код. Процесс, который создаёт продукт не обязательно формальный и определённый. Некоторые создатели могут даже и не знать о существовании процесса. Однако некоторая форма деятельности входит в создание каждого продукта.

Продукты могут быть определены рекурсивно

Продукт может существовать с другим продуктом. Например, у пишущей ручки есть стержень с чернилами. Ручка — продукт, однако и стержень с чернилами — продукт.

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

Продукты могут быть определены рекурсивно. Лесозаготовительная компания срубает деревья для изготовления древесины, древесина — это самостоятельный продукт. Затем, мебельная фабрика изготавливает из данного дерева ножки для стула, а другая компания использует данные ножки для изготовления стульев собственного дизайна. Таким образом продукты могут существовать внутри других продуктов.

Продукты приносят ценность рынку

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

Это применимо и к ножкам для стула и к сменному стержню для ручки. При определении продуктов — и, следовательно, владельцев продуктов и бэклогов продуктов в Scrum — крайне важно чтобы они приносили ценность рынку.

Применим определение продукта к примеру с авиакомпанией

Итак, если продукты создаются в процессе и приносят ценность рынку, является ли программные компоненты продуктами?

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

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

А что насчет системы мониторинга и планирования технического обслуживания самолётов? И это тоже продукт.
Она создана в процессе и также приносит ценность рынку. Какому рынку?

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

Тоже самое может быть сказано и о сайте авиакомпании, который позволяет пассажирам бронировать авиабилеты. Для сайта существует рынок.

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

Применение определения продукта к программным компонентам

Держа в голове вышесказанное, перейдём к программным компонентам. Если одна команда создаёт программу, которой пользуются другие команды, можем ли мы сказать, что программа — продукт?

Для примера рассмотрим команду, которая создаёт календарь. Календарь приносит ценность рынку — другим командам, которые будут его использовать. В таком случае, компонента, которая создаётся для нескольких команд, — продукт.

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

Избегание субоптимизирующих продуктов

Согласно профессору Таер Воткинсу из  государственного университета экономики Сан Хосе (San Jose State University Economics) субоптимизация «относится к практике сосредоточения внимания на одном компоненте из всех и внесении изменений для улучшения только в один компонент... игнорируя эффект изменений на другие компоненты»

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

Как было сказано ранее в примере с авиакомпанией, бывает, что продукт настолько велик, что обслуживает несколько рынков, и лучше выделить в нём несколько продуктов, которые обслуживают свои рынки.

Например, довольно легко представить Microsoft Office как один продукт, однако, он является набором нескольких продуктов и каждый продукт предоставляет различные функции и обслуживает разные (но частично совпадающие) рынки.

Word, Excel, PowerPoint и тд. — это отдельные продукты. У каждого из них свой владелец продукта и свой продуктовый бэклог.

С таким большим продуктом как Office, легко представить, что есть и продукты, которые представляют собой общую функциональность для Word, Excel и PowerPoint. Если говорить о проверке грамматики, то да, выделение компоненты как отдельного продукта имеет смысл. Функциональность по проверке грамматики ценна для рынка (другим команда нет необходимости создавать свою отдельную такую же компоненту с нуля).

Тем не менее, функции Excel {=СУММА; =СРЗНАЧ и прочее} нельзя выделять как продукт, так как эта функциональность уникальна для Excel, таким образом функциональность служит только одному клиенту. Слишком рискованно для данной функции выделять отдельного от Excel владельца продукта и отдельный продуктовый бэклог.

В дополнение к тому, что следует избегать продуктов для одного клиента, еще одним способом снижения неоптимального мышления при работе с несколькими продуктами является назначение главного владельца продукта (chief product owner).

Главный владелец продукта (chief product owner) — это стратегическая роль, он отвечает за формирование видения по всем подпродуктам. Например, для продукта Office главный владелец продукта (chief product owner) будет следить за тем, как каждый отдельный продукт влияет на весь пакет.

P.S.

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

Текст адаптирован с оригинальной статьи:
https://www.mountaingoatsoftware.com/blog/what-is-a-product