Паттерны Скрама — применяя Скрам на практике

Перевод оригинальной статьи Сезарио Рамоса Scrum Patterns — putting Scrum into practice.

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

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

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

Табличный подход Аджайл-внедрения

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

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

Шаг 2. Создаются модель для измерения соответствия стандартному процессу или подходу.

Шаг 3. Создаются таблицы с вопросами и метриками, которые позволяют оценить, насколько команды, группы и подразделения соответствуют стандартному способу работы.

Шаг 4. Аджайл-коучи обучают команды, группы и подразделения работе согласно стандартному процессу.

Этот подход хорошо согласуется с идеями Фредерика Уинслоу Тейлора об эффективности производства: существует «наилучший способ» и нам необходимо отделить голову от рук».

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

Читать далее «Паттерны Скрама — применяя Скрам на практике»

Скрам-мастер паттерн**

Перевод паттерна Scrum Master**

В 1953 году участники британской экспедиции Эдмунд Хиллари и Шерпа Тенцинг Норгей, во главе с Джоном Хантом, впервые в истории взошли на Эверест. Признание получают те, кто достигает цели при поддержке фасилитаторов, играющих не такую заметную, но ключевую роль в миссии. Часто Скрам-Мастер работает незаметно.

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

✥ ✥ ✥

Без полного понимания Скрама и применения его принципов и ценностей Команды Разработки, Владельцы Продуктов и организации не смогут воспользоваться преимуществами, которые он дает.

Читать далее «Скрам-мастер паттерн**»

Скрам-паттерны для предсказуемости команд

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

Разработчики непрофессионалы или…?

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

“Злые” проблемы

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

Хорст Риттель и Мелвин Уэббер определили «злую» проблему как проблему, которая может быть четко определена только путем ее решения или решения ее части. Этот парадокс подразумевает, по сути, что вы должны «решить» проблему один раз, чтобы четко определить ее, а затем решить ее снова, чтобы создать работающее решение. (Стив Макконнелл)

Читать далее «Скрам-паттерны для предсказуемости команд»

Правильное ведение хозяйства

или ежедневный чистый продукт

https://sites.google.com/a/scrumplop.org/published-patterns/_/rsrc/1555448727626/value-stream/good-housekeeping/GoodHousekeeping_Head.jpg?height=317&width=320

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

Команда разработки двигается к Цели Спринта.

✥ ✥ ✥

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

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

Слишком большой объем информации на Доске информации путает сотрудников и мешает отделить главное от второстепенного. Это отнимает время.

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

Пустая трата времени возникает из-за работы в условиях неясного прогресса.

Поэтому:

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

Читать далее «Правильное ведение хозяйства»

Illegitimus Non Interruptus (без стука не входить)

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

✥ ✥ ✥

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

Скрам-команда — общий ресурс, который закрывает потребности многих стейкхолдеров. Трагедия общин — это дилемма, возникающая, когда множество людей, действуя независимо и рационально, руководствуясь своими личными интересами, в конечном итоге истощают общий ресурс, даже если очевидно, что такой результат не отвечает чьим-либо долгосрочным интересам. Впервые описал эту дилемму американский эколог и философ Гаррет Хардин в знаменитой статье «Трагедия общин» («The Tragedy of the Commons»), опубликованной в журнале Science в 1968 году.

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

Желательно, чтобы Скрам-команда отвечала за результаты своей работы (“eat your own dog food”). Если выявляется дефект, команде нужно его исправить как можно быстрее. Если создается специальная команда для исправления дефектов, Скрам-команда не будет обращать внимание на скрытые дефекты.

Это, а также другие причины постоянно мешают работе Скрам-команды.





 Читать далее «Illegitimus Non Interruptus (без стука не входить)»	

Аварийная процедура (Emergency Procedure)

Эд Аттербери, коллега Джеффа Сазерленда, сбит зенитной ракетой над Ханоем. На изображении видно, как он прыгает с парашютом!

…компании, команды и отдельные сотрудники часто обнаруживают, что не могут поставить продукт вовремя, и Sprint Burndown Chart свидетельствует о неизбежном провале. Для работы в Аджайл-стиле необходимы быстрое определение проблем и оперативная реакция.

✥ ✥ ✥

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

Есть много причин для срывов Спринта, в данном паттерне рассматриваются три основные из этих типичных проблем:

Для гибкости необходимо быстрое реагирование на изменения, а для этого проблемы должны выявляться как можно раньше. К сожалению, часто новые команды и среднестатистические команды не хотят, чтобы проблемы становились заметными. В частности, они не хотят останавливать работу, устранять проблемы и подвергаться критике. На первом заводе NUMMI (New United Motor Manufacturing, Inc) компании Тойота в Америке руководители из Японии посетили фабрику через шесть месяцев после открытия и увидели, что сотрудники боялись дергать шнур-андон — если дернуть этот шнур, срабатывает сигнальная лампа и начинается обратный отсчет, после которого конвейер останавливается. Рабочие не останавливали конвейер достаточно часто, чтобы разрешать свои проблемы. Руководство дернуло за шнур несколько раз, чтобы остановить конвейер и продемонстрировать рабочим, что самым главным препятствием было их нежелание останавливать конвейер. Остановка конвейера позволяет заметить проблемы и правильно их разрешить. «Отсутствие проблем — это проблема», как гласит мантра японских руководителей. Читать далее «Аварийная процедура (Emergency Procedure)»

Swarming: one-piece flow

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

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

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

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

Предположим, команда пытается увеличить выработку путем параллельной работы, когда каждый сотрудник работает над одним элементом Бэклога Продукта (PBI). Работая в одиночку, члены Команды разработки с большей вероятностью сосредоточатся на разработке элемента, а не на его тестировании, в частности, потому что специалистов, обладающих компетенциями и желанием проводить тестирование, намного меньше, чем специалистов для творческих задач проектирования и разработки. Если в ходе Спринта возникает задержка нескольких элементов, возрастает риск того, что к концу Спринта PBI не придут к статусу «Готово». Что еще хуже, некоторые разработчики из Кремниевой долины и Европы, работающие над сложным программным обеспечением, обнаружили, что если не выявить и не исправить ошибку в ходе Спринта, один час тестирования кода может превратиться в 24 часа тестирования три недели спустя. Если команда откладывает тестирование, а не применяет Сворминг, то элемент, который можно было бы поставить через месяц, будет поставлен через два года. Читать далее «Swarming: one-piece flow»