Украинский портал по SCRUM

Agile Podcast: Роли в Agile команде

noreply@blogger.com (Alexey Krivitsky) — Tue, 07 Jul 2009 12:48:37 PDT

Подкаст на тему "Роли в Agile команде"

Участники:
Алексей Кривицкий, Асхат Уразбаев, Денис Миллер, Кирилл Медведев

Обсуждалось:

Scrum-команда
Понятие ролей, соотношение с должностями
Кроссфункциональность и узкая специализация
Синергия команды: 1 + 1 = 11
Тестировщик и разработчик в Team
Менеджер проекта
Product Owner
Мотивация, индивидуальные поощрения
Scrum Master – вымирающий динозавр

Слушать!

Тяжелые последствия fixed-price проектов IT

noreply@blogger.com (Alexey Krivitsky) — Tue, 07 Jul 2009 02:29:31 PDT

"Fixed-price" проекты являются обычной практикой в IT или как результат фиксированной стоимости конкурсной предлагаемой цены, или как результат бюджетных давлений внутренних проектов разработки ПО.

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

По-видимому, все об этом знают, но почему-то мы не можем выбраться из этой канавы. В этом месяце я обсуждаю вопросы, окружающие fixed-price проекты IT, в надежде мотивировать вас удалиться от этой сомнительной практики.

Из Dr Dobb's, автор Скотт Амблер.

Фундаментальной проблемой fixed-price проектов является то, что они побуждают вас выполнять очень сомнительные вещи, которые неизменно приводят к убыткам. Чтобы разработать точную смету, вам надо понимать требования, которые вам следует учитывать, и архитектуру, которую вы собираетесь строить. Чем больше потребность в точности в вашей смете, тем больше потребность в максимально подробной информации. Как результат давления разработать точную изначальную смету, типично вы вынуждены принимать следующее:

Подход предварительных больших требований (Big Requirements Up From - "BRUF"), где вы создаете подробную спецификацию требований в самом начале жизненного цикла.
Процесс управления изменениями, который старается избежать «ползанья границ» ("scope creep") по всему проекту.
Подход предварительного большого дизайна (Big Design Up Front - "BDUF"), где вы пытаетесь детализировано указать свою архитектуру до того, как начнется кодирование.
Жизненный цикл разработки ПО, который обычно последователен по своей природе.

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

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

В-третьих, BDUF также оказывается сомнительным на практике. При детальной разработке дизайна на ранней стадии проекта вам приходиться принимать серьезные решения, тогда как владеете наименьшим количеством информации. К примеру, в течение первого месяца проекта вы знаете намного меньше, чем на 10-й месяц проекта. И как только эти решения приняты, вы вынуждены придерживаться их из-за всей той тяжелой работы, которая уже проделана. Еще хуже то, что если вы неправильно поняли требования, с которых надо начать (а это часто случается), то не имеет значения, насколько хорошо разрабатывается дизайн, так как он по-прежнему неправильный, потому что основан на неправильных требованиях.

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

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

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

Альтернативой fixed-price проектам, конечно же, являются variable-priced проекты. На практике гораздо легче уменьшить финансовый риск на variable-priced проектах со стробированным инвестированием, основанном на промежуточных поставках (идеально работающее ПО). Этот подход предусматривает хорошее взаимоотношение между организаторами дела и IT так же, как и активное участие организатора в проекте. Если вы хотите гарантировать ценность вашей инвестиции в IT, то вам следует управлять вашей инвестицией в IT вплотную.

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

Из Dr Dobb's, автор Скотт Амблер.
Перевел Павел Юров для scrum.com.ua под редакцией Алексея Кривицкого.

Ежедневный митинг у доски

noreply@blogger.com (Alexey Krivitsky) — Sat, 13 Jun 2009 01:36:45 PDT

Хороший способ проверить, использует ли ваша команда доску для того, чтобы по настоящему управлять своей работой - это посмотреть на их ежедневный митинг (daily standup).

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

Оно выглядит так:

или так?

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

Существует очень простое указание для того, чтобы убедиться, что вы не забудете поговорить о чем-то важном каждый день: проводите ежедневное собрание стоя напротив доски и проверяйте, чтобы все задания в средней колонке ("выполняется", "in progress") были обсуждены.

Из Visual management, автор Xavier Quesada Allue.
Перевел Павел Юров для scrum.com.ua под редакцией Алексея Кривицкого.

Ярлык "DONE"

noreply@blogger.com (Alexey Krivitsky) — Sat, 13 Jun 2009 01:36:13 PDT

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

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

Концепция проста. В течение дня члены команды работают над задачами, которые находятся в колонке "in progress" (выполняется) на доске задач. Когда они заканчивают задачу, вместо того, чтобы немедленно перенести ее в колонку "Finished" (Закончено), они клеят на нее ярлык DONE. И там он остается до конца дня, провозглашая на весь мир, что команда завершила некоторую работу. Это часть о потоке: бросив быстрый взгляд в конце дня на доску вы можете "видеть поток", поискав глазами ярлыки DONE. Чем больше голубого, тем больше поток. Это нравится менеджерам и Product Owners.

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

Что насчет выравнивания и общения? Перенося все ярлыки DONE на ежедневном собрании вы, по существу, обеспечиваете то, что все в команде осведомлены о том, кто и что заканчивает. Фактически, так появилась эта идея. Члены команды переносили задачи в колонку Закончено в течение дня, и потом на ежедневном собрании они могли забыть рассказать об этом. Имея много задач в колонке "Закончено" становилось тяжело запомнить, которые из них были новыми, а не вчерашними. И поверьте мне, если у вас много однодневных задач, то это случится, особенно с наиболее производительными девелоперами, которые делают много вещей.

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

Итак, основное указание для использования ярлыка DONE следующее:

Вам следует перемещать задачи в колонку "Закончено" только во время ежедневного собрания.
Вам следует перемещать только те задачи, на которых есть ярлык DONE и которые вы сделали сами.
Как только вы перемещаете их в колонку "Закончено", снимите ярлык DONE.

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

Можете ли вы быстро обнаружить ярлыки DONE?

Почему ярлык голубого цвета?

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

(Для интереса: я узнал это в очень длинной беседе с Кошуке Кавагучи, автором Hudson CI engine. Хадсон показывает голубой экран вместо зеленого экрана, когда конструкция в порядке.)

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

Экспериментируйте!

Из Visual management, автор Xavier Quesada Allue.
Перевел Павел Юров для scrum.com.ua под редакцией Алексея Кривицкого.

Дао Скрам

noreply@blogger.com (Alexey Krivitsky) — Mon, 25 May 2009 13:10:41 PDT

Автор: Игорь Тамащук

Много бумаги исписано и и мегабайтов перекачано в процессе, когда одни пытаются понять, что же такое Scrum, а другие пытаются это объяснить. Главное достоинство Scrum в этом смысле заключается в том, что для того, чтобы начать его применять не нужно многого – бери готовые несложные правила, минимум артефактов, и колесики закрутились. Но понимание глубокой сути этого процесса наступает далеко не сразу.

Как известно, центром любого scrum-проекта является product backlog. Это место, куда product owner записывает свои пожелания, оценивая их значимость и вместе с командой планирует итерации. Казалось бы, что может быть проще? Но чем же этот подход оказался лучше других? Чем он отличается, скажем, от случая, когда заказчик просто заводит тикеты, например, в JIRA? Что делает этот проект столь эффективным?

Читать дальше...

CSM

noreply@blogger.com (Alexey Krivitsky) — Wed, 04 Mar 2009 11:20:45 PST

В Киеве в апреле состоится очередной класс Certified ScrumMaster: детали.

Extended SCRUM simulation with LEGO

noreply@blogger.com (Alexey Krivitsky) — Mon, 23 Feb 2009 11:02:48 PST

Author: Alexey Krivitsky

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

Over the last couple of years I’ve participated in and facilitated several CSM classes run by different trainers. All of those classes had (what they used to call it) an “XP game” done during the second part of the second day. During this game people blew balloons, sorted decks of cards, built card houses, and other funny stuff like that.

Though it was nice and entertaining activity, I think there should be other games that illustrate better the things we try to teach.

So I started to think of better simulations and have come across the idea of using LEGO bricks (thanks to William Wake, Jurgen De Smet, Yves Hanoulle, Mykola Gurov and other folks for opening my eyes).

Lego For Extended Scrum Simulation - DOWNLOAD

View more documents from krivitsky. (tags: scrum games)

Планирование спринтов

noreply@blogger.com (Alexey Krivitsky) — Tue, 10 Feb 2009 09:38:31 PST

Автор: Алексей Кривицкий

"Скажите, как вы планируете спринты,
и я скажу, на сколько успешен ваш проект."

(древнее высказывание)

Шутка, конечно. Но на самом деле планирование спринта - это сердце Скрама.

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

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

Давайте начнём с цели спринт планирования:

Определиться со списком историй (от англ. "user stories"), которые команда верит, что может реализовать (в полном объёме и ожидаемом качестве), которые временно удовлетворят жажду заказчика по новой функциональности.

Другими словами мы пытаемся найти компромисс между желаниями заказчика и возможностями команды (при чём компромисс, который бы не компрометировал наш профессионализм!).

Существуют следующие основные варианты проведения спринт планирования:

Планирование на основании велосити.

В ходе такого планирования команда набирает истории на новый спринт в соответствии со своим ожидаемым велосити (velocity - скорость работы команды, измеряемая в единицах функционала, которые команда реализовывает за спринт).

То есть, если за прошлый спринт команда выполнила историй на сумму 20 единиц, то можно смело предположить, что и в этот раз команда выполнит столько же (при условии равной длины спринтов и той же доступности членов команды).

В eXtreme Programming этот подход называется "вчерашняя погода" (yesterday's weather).
Планирование, базируемое на обещаниях.

Другой (более скрупулёзный) вариант планирования - пройтись детально по историям беклога (начиная с наиболее приоритетных и идя вниз).

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

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

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

Какой же подход выбрать?

Молодым командам я бы однозначно посоветовал комбинированных подход.

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

Будьте бдительны!

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

В этом случае варианты у вас следующие:

переговорить размер историй - упростить что-то;
заменить одну историю другой - заменить что-то на что-то;
разбить историю на более простые - оставить что-то на потом.

В любом случае ответ у вас должен быть один: уменьшить объём работы за счёт чего сделать большее количество более простых историй.

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

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

Удач!

Скрам тренинги

noreply@blogger.com (Alexey Krivitsky) — Fri, 06 Feb 2009 04:07:10 PST

Автор: Алексей Кривицкий

13 и 14 февраля в Киеве пройдёт серия Scrum-тренингов:

На 6 февраля к каждом классе есть по 5 мест.

Будем рады видеть всех желающих.

Время переосмысления

noreply@blogger.com (Alexey Krivitsky) — Fri, 06 Feb 2009 04:13:00 PST

Автор: Алексей Кривицкий

Сегодня многие говорят и пишут об особенностях работы (и её поиске) в кризисное время. Мне не нравится слово "кризис", поэтому я его использую только в начале этого поста, и только ради индексации в поисковиках по этому ключу :)

Больше ни слова про слово на "К" ;) Дальше только про новые возможности!

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

Все что-то переваривают, о чём-то усиленно думают. Сегодня появился повод сослаться на "К" и под этим предлогом сменить условия сотрудничества.

Мне хочется назвать это время "временем переосмысления". Что за прекрасное время! Давайте же использовать его потенциал!

Основная часть

Сегодня как никогда важно быть эффективным. Продуктивным быть уже недостаточно. Недостаточно писать много кода. Недостаточно повышать метрики производительности команд. Недостаточно часто выпускать релизы.

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

Давайте рассмотрим суть происходящего по порядку.

Удовлетворение найценнейших потребностей бизнеса

Отчёт Standish Group за 2002 год (так называемый"Chaos Report") утверждает, что в любом программном продукте общего пользования порядка 2/3 функционала не используется либо используется редко и лишь 1/5 используется всегда или часто.

С трудом верится. Но если вы подумаете о своих продуктах (если вам приходилось участвовать в разработке ПО), то вы легко сможете идентифицировать ряд фич, без которых ваш продукт остался практически таким же полезным как и с ними...

Я проводил на тренингах подобное упражнение с участниками, большинство с лёгкостью в течение 7 минут выписывает 5-10 относительно больших фич, которые можно было не реализовывать. На вопрос, почему они говорили об этом заказчикам, половина отвечала: "а зачем?"...

Если верить этому же отчёту, более половины проектов в 2004 году переиспользовала свой бюджет и при этом более 80% проектов не уложились в срок. И всё это при том, что в этих проектах было в среднем 2/3 неиспользуемых фич.

(пауза)

...В наикратчайшие сроки

Это не означает выпустить полную версию уже завтра или послезавтра. Нет. На столько быстро мы писать вряд ли сможем писать код (there is not silver bullet...).

Но посмотрите на эту иллюстрацию:
Производительность обоих проектов одинакова: обе команды за одинаковое время выпускают 100 единиц ценностей (business value, BV).

Но при каком из этих подходах выпуска BV заказчик более спокоен? Что заказчик понимает под найкратчайшими сроками? Выход финальной версии (когда-нибудь) или выход ранних рабочих версий (уже сейчас)?

При каком подходе заказчик раньше начинает получать (видеть) выгоду от вложений?

Так уж важны ли заказчику финальные сроки, если он каждые две недели может получать готовую к поставке версию продукта?

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

Выпускать в найкратчайшие сроки не означает отгружать рабочий продукт быстро. Это означает возвращать инвестиции заказчика постоянно.

С наивысшей адаптивностью

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

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

Итог

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

Не бойтесь! Вперёд!

Удач

Харьков, тренинг "Базовые концепции Agile и SCRUM"

noreply@blogger.com (Alexey Krivitsky) — Tue, 23 Dec 2008 12:01:31 PST

Автор: Алексей Кривицкий

С субботу 10 января 2009 в Харькове пройдёт полнодневный тренинг по программе "Базовые концепции Agile и SCRUM".

Вопросы, рассматриваемые на тренинге:

Что значит Agile? Что такое SCRUM?
Что нужно для внедрения Agile подходов? С чего начать?
Как объяснить своим заказчикам и руководителям выгоды от применения этих подходов?
Как подготовить проектную среду для запуска проекта?
Как запустить SCRUM?
Как построить эффективную комманду?
Что нужно для перевода запущенного проекта на SCRUM?
Как собрать и подготовить требования для SCRUM проекта?
Как планировать и отслеживать релизы и итерации?
Как построить свой Agile процесс?
У вас будет возможность задать любые интересующие вас вопросы.

Детали тренинга и регистрация.

A tool for time boxing

noreply@blogger.com (Alexey Krivitsky) — Fri, 07 Nov 2008 15:07:32 PST

Автор: Алексей Кривицкий.

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

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

Есть online версия, есть версия для выкачивания:
http://www.online-stopwatch.com/

Энджойте!

Чеклист СкрамМастера

noreply@blogger.com (Alexey Krivitsky) — Mon, 25 Aug 2008 10:33:09 PDT

Переводчик: Кривицкий Алексей

От переводчика:

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

Я решил перевести статью "A ScrumMaster's Checklist", опубликованную на сайте Danube, Майкла Джеймса (Michael James), так как по-моему мнению, она может помочь СкрамМастерам (начинающим и не только) разобраться в том, что же входит в сферу их обязанностей.

И так, далее я привожу мой непрофессиональный перевод первой части статьи. При наличии вдохновения продолжу позже... :)

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

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

Великий СкрамМастеру под силу справиться только с одной командой.

Мы рекомендуем одного выделенного СкрамМастера на команду (из семи человек), особенно на начальной фазе.

Для того, чтобы найти весь спектр работ, которыми стоит заниматься СкрамМастеру, попробуйте взглянуть на работу вашего Product Owner, вашей команды, на их инженерные практики и также на вашу компанию вне команды и проекта. Нельзя точно описать роли и задачи СкрамМастера, но я выписал вещи, которые на моём опыте СкрамМастеры по ошибке упускают из вида:

Как поживает мой Product Owner?
Вы можете повысить эффективность работы вашего Product Owner’а, помогаю ему управлять Product Backlog и планом релиза. (Помните, что только Product Owner может приоритезировать беклог)
- Приоритезирован ли беклог в соответствии с последними пожеланиями Product Owner’а?
- Все ли требования и пожелания от всех заинтересованных в продукте сторон записаны в беклоге? Помните, что беклог обновляется постоянно.
- Управляемого ли размера беклог? Для поддержания управляемого количества элементов в беклоге, храните его элементы более гранулярными кверху, с более крупными (эпическими) элементами книзу. Зачастую непродуктивно детально анализировать беклог, делаю это далеко вниз от его верха. Требования будут часто изменяться во время обсуждений между разработчиками и заказчиками.
- Могут ли элементы беклога (особенно те, что ближе к верхушке) быть выражены как независимые, обсуждаемые, полезные, оцениваемые, мелкие и тестируемые истории?
- Объяснили ли вы вашему Product Owner суть технической задолженности и то, как её избегать? Одним из решений этой головоломки может быть добавление автоматизации тестов и рефакторинга в определение готовности элементов вашего беклога.
- Является ли беклог радиатором информации, который доступен и виден всем заинтересованным сторонам проекта?
- Если вы используете автоматические средства для управления беклогом, все ли знают, как ими эффективно и просто можно пользоваться? Средства автоматического управления беклогом могут стать информационными холодильниками (information refrigerators), если СкрамМастер не пытается превратить беклог в коллективный легкодоступный инструмент.
- Можете ли вы помочь коммуницировать беклог, раздавая распечатки?
- Можете ли вы помочь коммуницировать беклог, создавая большие видимые настенные диаграммы?
- Можете ли вы помочь вы вашему Product Owner'у организовать элементы беклога по релизам, адекватного размера?
- Все ли стороны проекта (включая команду) знают, отвечает ли план релиза текушему прогрессу проекта, основан ли он на текущей велосити (сумме оценок завершаемых историй за спринт)?
- Обновил ли Product Owner план релиза после последней демонстрации результатов спринта? Вы можете показать всем Product/Release Burndown Charts, которые рекомендует Mike Cohn, это может помочь выявить отставания о на ранних фазах."

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

C чего начать изучение SCRUM?

noreply@blogger.com (Alexey Krivitsky) — Mon, 25 Aug 2008 10:37:49 PDT

Терминология и базовые принципы SCRUM

Неплохие статьи-обзоры:

Видео

Часовое видео от Кена Швабера

Материалы Кена Швабера

Материалы с тренинга Certified ScrumMaster:
http://www.controlchaos.com/quickstart.pdf

Другие материалы на сайте
http://www.controlchaos.com/about/index.php)

Выжимки из первой книги Кена:
http://www.controlchaos.com/download/Book%20Excerpt.pdf

wiki о Scrum:

http://c2.com/cgi/wiki?ScrumOverview

Бесплатные книги

Хенрик Книберг и его практические советы в книге
"Scrum and XP from the Trenches"

Гибкий подход разработки ПО – Scrum

noreply@blogger.com (Alexey Krivitsky) — Fri, 18 Jul 2008 02:11:18 PDT

Автор: Кривицкий Алексей

И как всё это касается меня – разработчика?

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

Я пишу это для тех, кто отрицательно ответил на перечисленные вопросы.

Читать дальше...

Certified ScrumMaster video

noreply@blogger.com (Alexey Krivitsky) — Thu, 02 Oct 2008 13:48:37 PDT

Видео с CSM классов, которые провёл Mark Pushinsky и его коллеги из компании Innovel в Украине и Бразилии.

У вас есть шанс попасть в CSM, который будет проведён в Киеве в сентябре.

SCRUM митинг и культ карго. С чего не стоит начинать внедрение SCRUM

noreply@blogger.com (Alexey Krivitsky) — Mon, 09 Jun 2008 16:21:17 PDT

Автор: Кривицкий Алексей.

Ежедневные SCRUM (или Standup) митинги - одна из практик SCRUM. Многим кажется, что это самая простая практика, и следовательно, с неё, стоит начинать внедрение Agile и SCRUM.

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

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

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

Вот примеры условия, когда Daily SCRUM митинг, внедрённый в команду, может не принести ожидаемого результата:

Члены команды работают над более-менее изолированной функциональностью.
Задачи ставятся в индивидуальном порядке менеджером проекта или заказчиком.
В команде не создана безопасная среда, когда каждый член команды может свободно высказывать свои мысли. Люди предпочитают не идти на конфликт.
Членам команды было "велено" проводить SCRUM митинг. В итоге никто не понимает зачем же нужен этот митинг. Он вырождается в репортинг менеджеру.

Подобные ситуации можно перечислять ещё долго... Не суть.

Я хочу лишь показать, что без решения корневых проблем (построение общей цели, налаживания безопасной и доверительной среды, устранение пороков команд) Daily SCRUM если и будет полезен, то далеко не на 100%.

Хуже, если после подобных проб команда и её менеджер скажут: "Мы использовали SCRUM и он нам не подошёл". Или ещё что-то в этом роде. Такое к сожалению случается.

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

Время от времени устраивайте открытые дискуссии на эту тему.

Пытайтесь всей командой понять, когда ваш недавний ежедневный митинг был полезен, чем именно, и как этот успех можно перенести на все подобные митинги. Хорошее групповое упражнение.
Если вы ScrumMaster, время от времени не приходите на Daily SCRUM - если команда видит необходимость в этом митинге - она его проведёт и без вас.

Этот приём я почерпнул от Марка Пушински на тренинге Certified ScrumMaster. Как по мне - отличный инструмент SCRUM мастера.
Экспериментируйте и пересматривайте формат митинга. Иногда переформулирование одного из трёх вопросов ("что я сделал? что я буду делать? что мне мешает?") или добавления нового может помочь вашей команде по-другому взглянуть на митинг.

К примеру вместо вопроса "что я сделал?" можно ввести "что я делал?". Разница на первый взгляд незначительна, но как показывает опыт Асхата Уразбаева такая постановка вопроса открывает дополнительный источник информации.

Удач! И следите за признаками возникновения культов карго в вашей команде.

Unfinished work in sprints

noreply@blogger.com (Alexey Krivitsky) — Sat, 24 May 2008 01:41:11 PDT

Автор: Алексей Кривицкий.

Я когда-то написал об использовании user stories. До сих пор время от времени получаю отзывы и вопросы.

Вот к примеру вопрос, который я слышу довольно часто:
"Что делать с историями, которые не полностью сделаны за итерацию?"

На мой взгляд есть такие варианты:

1. История не полностью сделана, и сделанная часть НЕ несет выгоды для заказчика
= Business value not delivered

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

2. История не полностью сделана, но сделанная часть несёт выгоду для заказчика
= Business value delivered (but partially)

В этом случае, как мне кажется:
а) можно зачесть историю как сделанную (при этом обновить описание истории, указав что именно сделано, какие тесты проходят);
б) создать новую историю (или ряд историй), описывающих недостающие требования;
в) при необходимости переоценить историю и учесть её при подсчёте velocity текущего спринта.

3. История сделана, но после найдены дефекты
= Business value delivered (but the quality/level of details is not acceptable)

В этом случае вопрос чаще стоит так - "как трекать баги, найденные после сдачи истории, и что делать с историей - переоткрывать ли или нет"?

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

Обсудить в группе дискуссий Agile Ukraine?

Следующий класс Certified ScrumMaster

noreply@blogger.com (Alexey Krivitsky) — Wed, 21 May 2008 07:51:51 PDT

С апреля 2007 мы регулярно проводим классы сертификации по программе "Certified ScrumMaster".

Два класса было проведено в 2007 году в Киеве. Минимум два класса мы планируем на текущий год. Первый уже был проведён в апреле. Второй планируется на осень.

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

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

CSM class Kyiv, April 2008

noreply@blogger.com (Alexey Krivitsky) — Mon, 09 Jun 2008 17:55:52 PDT

В апреле в Киеве прошёл очередной класс сертификации СкрамМастеров.

16 человек пополнили ряды украинских CSM.

Тренер Марк Пушинский (Mark Pushinsky) провёл класс на очень высоком уровне. Не менее половины времени тренинга было посвящено дискуссиям, симуляциям, упражнениям.

Наш веб-альбом

Видео из классов

Регистрация на следующий класс.

О совмещении ролей ScrumMaster (SM) и Product Owner (PO)

noreply@blogger.com (Alexey Krivitsky) — Mon, 05 May 2008 08:53:39 PDT

Часто слышу вопрос о совмещении ролей ScrumMaster (SM) и Product Owner (PO).

Как по мне, то это крайне нежелательно.

Причины:

Одной из задач SM является следить за правилами выполнения "игры Scrum" и помогать команде и заказчику (в частности PO) эффективно работать. То есть выполнять наибольшее количество business-value за единицу времени, но при условии поддержки определенного уровня качества (!)

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

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

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

Еже ли SM и PO - одно и то же лицо, то у этого человека будет явный внутренний конфликт, и этот баланс скорее всего очень быстро закончится, и перевесит сторона PO (читать "сиюминутная прибыль").

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

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

Удач!
Кривицкий А.

Ретроспективы. Рекоммендуемая структура

noreply@blogger.com (Alexey Krivitsky) — Tue, 26 Feb 2008 05:38:26 PST

Проблемы, проблемы, проблемы

Прошлый пост на тему ретроспектив (или вернее того, чего не хватает чаще всего для их эффективного проведения), поднял активность дискуссий группы Agile Ukraine.

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

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

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

Схема ретроспектив

И так. Для решения ряда проблем, которые были озвучены ранее, я предлагаю следующую схему проведения ретроспектив. Это не моё личное «ноу-хау», это наработки многих экспертов в области фасилитаций общения, генерации коллективного знания и прочих групповых методик (см. ссылки на ресурсы внизу поста):

Подготовка – 7 мин.
Сбор информации – 30 мин.
Выработка плана действий – 20 мин.
Завершение ретроспективы - 3 мин.

Звучит просто? Ничего нового? В этом и следующих постах я опишу в деталях рекомендации по проведению каждой из этих частей.

Длительность ретроспективы и её частей

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

Рекомендуемая длительность ретроспектив – один час на каждую неделю работы команды в 5-9 человек. Таким образом для двухнедельных спринтов стоит уделить около двух часов.

Подготовка

В зависимости от зрелости вашей команды и аудитории во время подготовки следует уделить внимание как минимум следующим моментам:

Приветствия и опрос настроений.
Напоминание цели ретроспективы.
Настройка на конструктивизм.
Гарантия личной безопасности.
Представление структуры ретроспективы.
Выработка (либо напоминание) этики общения и правил принятия решений.

Приветствия и опрос настроений

Поприветствуйте всех.

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

Плавно перейдите к цели.

Напоминание цели ретроспективы

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

Цель ретроспективы может звучать так:

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

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

Настройка на конструктивизм

Исходя из цели очевидно, что задачей ретроспективы ни в коем случае не является поиск виновных или прочие действия, явно не улучшающие процесс разработки. Но в командах, которые ещё не сработались стОит явно об этом напомнить. Работает следующая формулировка, предложенная Норманом Кёртом, которую он назвал «первичной директивой» или «prime directive» (см. список ссылок внизу):

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

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

Гарантия личной безопасности

Как фасилитатор объясните всем вашу роль – вы помощник команды, фасилитатор. Во время ретроспективы вы соберёте мнения и сделаете их доступными, с тем, чтобы команда смогла принять адекватные решения.

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

Объясните всем, что если кто-то предпочитает молчать, то это его дело, но он должен понимать, что тем самым лишаем команду своего мнения. Пару раз за время ретроспективы между прочим спросите у «молчунов», есть ли им что добавить. Убедившись, что на них никто не давит, они ещё могут разговориться.

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

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

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

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

Выработка (либо напоминание) этики общения и правил принятия решений

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

Если у вас нет формально выписанных правил, стоит посвятить 10-15 минут на их генерацию. Эти правила команда потом будет использовать на последующих ретроспективах и других групповых сессиях.

Как ведущий помните, что эти правила определяет команда, и она 100% владеет ими. Ваша же задача напоминать во время ретроспективы (когда страсти накаляются) о соблюдении этих правил. Либо же инициировать их пересмотр: «Мне кажется наши правила не работают, мы хотим их пересмотреть?»

Итог подготовки

Во время подготовки можно использовать и другие техники. Экспериментируйте. Но не вырождайте эту часть в пустое приветствие!

Чем лучше вы подготовите команду и настроите на работу, тем плодотворнее будет ретроспектива.

Дальше...

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

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

Комментарии как всегда приветствуются. Присоединяйтесь к дискуссиям Agile Ukraine.

Материалы по ретроспективам

Статья Rachel Davies
“How To: Live and Learn with Retrospectives”
Статья Boris Gloger’s blog and presentation
“Heartbeat Retrospectives”
Книга Norman Kerth
”Project Retrospectives: a handbook for team reviews”
Книга Esther Derby, Diana Larsen
”Agile Retrospectives: Making Good Teams Great”
Книга Jean Tabaka
“Collaboration Explained”

Алексей Кривицкий

Что не так с нашими ретроспективами?

noreply@blogger.com (Alexey Krivitsky) — Wed, 20 Feb 2008 13:18:55 PST

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

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

И так. Как же проводить ретроспективы?

Базовые материалы по СКРАМ говорят, что после спринт ревью митинга (или проще говоря демонстрации результатов спринта) команда собирается на ретроспективный митинг, где обсуждаются следующие вопросы:

Что в ходе спринта было хорошего?
Что было не очень хорошо?
Что можно улучшить в следующем спринте?

Это же касается ретроспективы по окончанию релиза или другой фазы проекта. Для простоты я рассматриваю ретроспективы, привязанные к окончанию спринта.

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

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

А что если ничего не будет сделано? В следующий раз команда cгенерирует очередной список, и так до тех пор, пока практика ретроспектив справедливо (для такого типа ретроспектив) не будет объявлена бесполезной.

Что же здесь не так?

Я думаю (и надеюсь это уже стало очевидно), что при таком подходе явно не хватает как минимум следующих вещей:

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

А что не так в ваших ретроспективах?

Обсуждения ретроспектив в группе дискуссий Agile Ukraine.

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

Что если не всем членам команды комфортно на ретроспективе?
Есть ли рекомендуемая структура ретроспектив, с которой стоит начать?
Наши ретроспективы заканчиваются ничем, есть ли подходы получить план действий на выходе?
Стоит ли привлекать представителей заказчиков на ретроспективы?
Похоже нашему СкрамМастеру самому есть что сказать как участнику проекта. Кто в этом случае должен проводить ретроспективы?

Алексей Кривицкий

Материалы по ретроспективам:

Статья Rachel Davies
“How To: Live and Learn with Retrospectives”
Статья Boris Gloger’s blog and presentation
“Heartbeat Retrospectives”
Книга Norman Kerth
”Project Retrospectives: a handbook for team reviews”
Книга Esther Derby, Diana Larsen
”Agile Retrospectives: Making Good Teams Great”
Книга Jean Tabaka
“Collaboration Explained”

Ретроспективы. Формальность или польза?

noreply@blogger.com (Alexey Krivitsky) — Wed, 20 Feb 2008 12:51:20 PST

Ретроспективы – как известно, являются обязательной практикой многих гибких методологий. В частности таких как XP, семейства Crystal, SCRUM.

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

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

Многие сторонники гибких подходов (я в том числе) верят, что целенаправленные и регулярные ретроспективы могут природно улучшить любой процесс, повысив эффективность работы команды.

Почему же это так?

Давайте начнём с начала.

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

Одно но: завершённому проекту от этого уже было ни холодно ни жарко. Его команде тоже. Вскрытие же, как никак!

Прелесть итеративных-инкрементальных подходов (к которым относятся все Agile подходы) состоит как раз в том, что подобные ревью можно проводить по ходу проекта (и не раз), так как имеется объективная информация о статусе проекта и готовности продукта. Почему? Да просто потому, что каждая итерации такого проекта является сама мини-проектом, на выходе которой должен быть ощутимый результат. На основании которого можно сделать определённые выводы и таким образом повлиять на процесс разработки следующей итерации и, как следствие, на процесс всего проекта.

Звучит просто и логично.

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

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

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

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

Кто и как должен с ними бороться?

Кто - конечно команда. Как – при помощи грамотного лидера-фасилитатора!

Читать следующий пост на тему ретроспектив.

Ссылки:

Статья Rachel Davies
“How To: Live and Learn with Retrospectives”
Статья Boris Gloger’s blog and presentation
“Heartbeat Retrospectives”
Книга Norman Kerth
”Project Retrospectives: a handbook for team reviews”
Книга Esther Derby, Diana Larsen
”Agile Retrospectives: Making Good Teams Great”
Книга Jean Tabaka
“Collaboration Explained”

Just in time backlog population

noreply@blogger.com (Alexey Krivitsky) — Mon, 25 Aug 2008 10:15:21 PDT

В Харькове на втором тренинге нас долго мучили вопросами типа:
"Так кто же и когда уточняет и пережёвывает элементы беклога?".

Есть две стратегии:

Стратегия 1. Уточнять верхнюю часть беклога во время планирования очередного спринта.

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

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

В худшем же (к несчастью приходилось видеть такое на проектах) - планирование останавливается на фразе: "всё, пора. там посмотрим" и начинается спринт. Спринт, в котором нет ни чётких обещаний (заказчику и членов команды друг другу), ни детального спринт беклога с оценками времени (ибо какие там оценки если ещё 10 фич висит в воздухе!). В итоге такой ситуации не представляется возможным построить burndown, и таким образом теряется предсказуемость и адаптивность процесса.

Результат - естественно, куча недоделанных фич ибо не было чётко понятно попадают ли они в спринт или нет. Такие спринты демотивируют и заказчиков и команды.

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

Стратегия 2. Распараллеливать разработку беклога и проработку его будущих частей.

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

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

уточнить фичу А, потратив не более 4 часов, ответственный Миша

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

Майк Кон (Mike Cohn) в своей последней статье разъясняет эту же задачу - задачу постепенного уточнения элементов беклога.

Обсуждение этой темы