Вы пробуете строить Scrum?

Мы в компании тоже, и получалось на первых парах не очень. Не то что бы Scrum это плохо, скорее хорошо! Не зря же пишут столько книжек с восторженными отзывами?! У меня представление о этой методологии разработки ПО сложилось как о идеальной методологии, где люди хотят создать качественный продукт, где инженеры получают удовольствие от своей работы, где царит гармония, равенство и коллективная ответственность за результат и лучи света в купе с божьей благодатью осеняют проект и всех его участников=) 

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

Дальше в этой заметке представлены мои мысли о Scrum, процессе в целом и планировании в первом приближении к теме.

Про артефакты будет упомянуто ниже, а роли описаны тут.

Проектные роли в Scrum

• Product Owner. Представитель заказчика или заказчик сам по себе. Отвечает за формулирование бизнес требований к функциональности, объем работ и приоритеты задач. Этот человек формирует Product Backlog.
• ScrumMaster. Фактически это лидер команды, в отличии от менеджера он делает упор на мотивацию и самоуправление команды в отличии от контроля и диктаторнского стиля управления "я сказал - ты делаешь". В обязанности входит устранять все преграды на пути команды к поставленым целям. Отвечает обустройство рабочего пространства, решение организационных вопросов, занимается дисцеплиной и отслеживает прогресс в работе, следит, что команда не сбилась на намеченного пути. 
• Команда. Самоорганизованный и замотивированный коллектив разработчиков, воплощающих желание заказчика(ProductOwner'а).

Наибольший интерес для меня представляла фаза планирования, поэтому на ней остановился подробнее.

Работа с заказчиком и выявление требований.

По средством всевозможных игр по анализу требований заказчика формируется документ - "ProductBacklog".

ProductBacklog

Product Backlog - список задач(Историй пользователя/ Историй / UserStory), описанных на языке бизнеса, выступает в роли требований к разрабатываемой функциональности. 

Фактически – это документация требований.

У каждой UserStory есть: 

• Название 
• Описание 
• Важность/Приоритет 
• Предварительная оценка сложности
• Критерий достижимости/ Как продемонстрировать (описание как можно подтвердить, что результат достигнут, действия для верификации результата).
• какие либо примечания. 

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

Нет фазы elaboration? О.О

В Scrum не принято планировать все сразу и наперед. Если не прав – поправьте меня в комментариях. Мы планируем только на одну итерацию и святая обязанность ProductOwner’а и ScrumMaster’a следить за процессом разработки и рассчитывать когда может быть релиз и поставка. Поясню, что я имею ввиду. В Стандартной Waterfall модели команда разработчиков заранее накидывает себе времени, чтоб предохраниться от рисков. В Scrum команда оценивает честно, только ту работу, которая перед ней поставлена, она не думает о том, что изменятся требования, кто-то заболеет или реализация окажется сложнее, чем предполагалось. Заказчик согласен, что ситуация может поменяться, как в его планах, так и в реалиях разработчиков и может сдвинуть дату релиза или урезать объем работ. И тем не менее только ProductOwner управляет датой релиза и его содержанием.

Планирование спринта (Итерация/Sprint)

Попробуйте включить фантазию. Представьте что вы находитесь в третьем классе и перед вами задача на формулу прохождения пути за время. S = V * T.

Дано:

• ProductOwner - персона которая ставит путь.
• ProductBacklog – как карта указывающая маршрут всего вашего пути.
• Длина итерации(T) – это время, которое определяет темп вашего движения по пути беклога.
• Примерная скорость команды(V). Так или иначе, для одной и той же команды эта цифра стабильна и статистически верна, но в то же время есть факты, которые помогают увеличить скорость, а могут ее и снизить. Если в вашей команде новичек, то представите, что вам нужно пройти трассу с дополнительной нагрузкой в 20кг. Вряд ли вы побежите с той же скоростью, что и налегке. Или другой вариант, вам дали велосипед – сразу ясно, что вы трассу пройдете быстрее. Или еще лучше метафора, вам дали лыжи.. и тут уже дело зависит от трассы, если это заснеженный склон горы – вам это в помощь, если пустыня – нагрузка.

Цель:

• Цель планирования – подобрать путь и скорость так, чтоб прибыть вовремя. Тут две переменные, но люди с диаметрально противоположными интересами отвечают каждый за свою.
• Определить SprintBacklog - какие UserStory будут реализовываться в данной итерации и в каком объеме. Метафорически это значит определить своеобразный путь(S), который команда может пройти за заданное, фиксированное время, с учетом скорости работы команды. Это не простая дорога по прямой или кольцевая трасса, это бег по пересеченной местности, временами похожий на челночный бег, где на пути много поворотов, часто делается лишний крюк и прочие логистические проблемы. Путь выбирает ProductOwner и максимум, что команда может сделать - это подсказать, где не делать крюк или, где можно срезать.

Решение:

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

Главная мысль в следующем. В идеале тут только две переменные(S и V) и скорее всего послабления со стороны заказчика в необходимом объеме работ на заданном времени у вас не будет. Думайте над тем как вы можете добраться до цели с учетом вашей скорости и как скорость можно увеличить. 

Cheating 

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

Fair play

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

Торги. Сколько команда успеет реализовать за время итерации? 

Зависит от сложности каждой истории и скорости, с которой команда решает подобные задачи.

Как определить, сколько команда успеет сделать - тема обширная. 

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

Если ближе к терминам Scrum - у каждой истории команда определяет примерную сложность истории (измеряется в штуках, StoryPoint), где 1 StoryPoint = одному идеальному дню, когда человек все знает про предметную область, обладает всей необходимой технической экспертизой, когда его никто не отвлекает, когда сыт, выспался и не хочет в туалет. Сразу можно сказать, что идеальных дней в команде размером больше чем 1н человек не существует. 

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

Пример торгов. 

ProductOwner управляет приоритетом задач из ProductBacklog, а так же объемом работ, например он может указать, что часть UI для UserStory не требуется. В то же время команда в зависимости от объема работ дает оценки по времени, за сколько они реализуют указанный объем работ. Если ProductOwner'у не нравятся оценки, он может либо уменьшить объем работ отказавшись от части функциональности или разделив одну функциональность из UserStory на две поменьше и расставить соответствующие приоритеты или может изменить приоритет задачи и тем самым убрать историю из кандидатов в текущую итерацию. Путем переговоров команда и ProductOwner договариваются, какие истории попадут в текущую итерацию. Команда не влияет на объем работ и приоритет, а ProductOwner на оценки по времени. Это табу. 

Draft design and Sprint Tasks.

UserStory отобранные для Sprint'а бьются на задачи для достижения более точных оценок и для более детального описания, что именно и как будет реализовывать команда. Задачи это тот уровень детализации, в который ProductOwner вдаваться не станет, поэтому задачи это часть SprintBacklog, а не ProductBacklog. В основном задачи или не продемонстрировать или они не представляют ценности для заказчика. Каждая задача это единица работы понятная каждому участнику команды. Воплощение идей как реализовывать бизнес требование заказчика в технических деталях. Описываются на языке понятном команде, но не обязательно понятном заказчику. Задачи могут меняться в течение спринта.

Итог планирования.

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

• [Обязательно] Цель спринта. (например, удивить заказчика)
• [Обязательно] Дата демонстрации/презентации реализованной функциональности/UserStory
• SprintBacklog - список задач отобранных для итерации.
• Временные оценки задач попавших в SprintBacklog.
• Описание как задача будет продемонстрирована для всех задач из SprintBacklog.
• Расчеты производительности и список членов команды на Sprint и их соответствующая занятость.
• Время и место StandUp'а
• Истории, разбитые на задачи.

Технические истории.

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

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

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

Ниже несколько идей из книги Scrum и XP: Заметки с передовой, о том как совмещать желания заказчика с нуждами команды:

• Попробуйте превратить техническую историю в нормальную историю с прямой ценностью для бизнеса.
• Попробуйте включить техническую историю как часть обычной истории.
• Если оба варианта провалились - добавить в ProductBacklog и объяснять ProductOwner'у, что эта история поможет команде приблизится к идеальному дню за счет увеличения фокус фактора.

Жизнь во время спринта

BurnDownChart, отслеживание изменений, незапланированные задачи

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

Формат, предложенный автором книги ниже.

Daily StandUP.

Каждый день команда собирается, чтоб обновить свой статус и каждый отвечает на 3 вопроса: 

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

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

Подводим итоги работы

Demo

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

Ретроспектива

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

Вопросы на повестке:

• Что было хорошо?
• Что было плохо?
• Что стоит улучшить?

Без чего не обойтись: 

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

Следите, чтоб скорость команды и фокус фактор не уменьшался.

Идеи о том, как увеличить скорость команды

• Continuos Integration
• TDD
• Эволюционный дизайн
• Парное программирование или не "self driven пассажир"
• Совместное владение кодом.
• Стандарты кодирования
• Ритмичная работа без переработок. Все по планам.
• Continuos Testing

ToDo

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

1. Где учитываются риски в Scrum?
2. Где Место для Elaboration?
3. Правда ли что в Scrum мы ориентируемся по состоянию и непредвиденные проблемы и ошибки в оценка – само собой разумеющееся?
4. Дата релиза больше одной итерации не планируется?
5. Как большие фичи укладывать в маленькие истории?

Agile, Scrum