English Version

Agile R&D Seminar

В среду прошел семинар по Agile Research & Development в G-клубе для GlobalLogic. Мы рассмотрели вопросы быстрого построения функциональных прототипов, эффективной "продуктизации" - превращения прототипа в полноценный продукт, и поддержку высокого ритма внедрения инноваций, когда продукт уже в продакшн-режиме...

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



Осторожно: Burndown Chart!

Автор: Александр Якима (www.enter-agile.com)

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

Рассмотрим два примера, в каждом из которых команда не выполняет план согласно Burndown chart. В первом случае невыполнение минимально:



Как видим, тэмп выполнения только незначительно отстает от "идеального". Но в скоупе спринта три больших пользовательских истории и в итоге не выполняется ни одна из них, хотя "выжгли" около 75% запланированных усилий. Результат равен 0, показывать нечего.

Рассмотрим теперь сценарий №2:



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

Как такое случилось? Очень просто. Первое, что нужно всегда помнить:

burndown chart показывает прогресс "выжигания" всего лишь единиц измерения пользовательской ценности, а не самой этой ценности.

Итак, если пользовательская история "стоит" нам 8 пунктов, то только все 8 пунктов и обеспечат запланированную ценность (полный пакет: реализованный скоуп истории, тестирование, конфигурирование, и т. д.). Из этого правила могут быть исключения - о них позже. Поэтому, 6 пунктов из 8 для конечного пользователя пустой звук. Другое дело в случае 2, где истории значительно мельче и их, соответсвенно, больше. Тогда в процессе "сгорания" пунктов с болшей вероятностью "целиком сгорают" и истории, т. е. приносится ценность. Отсюда следствие:

Чем мельче пользовательские истории, тем адекватнее burndown chart.

Откуда вобще берутся компактные пользовательские истории? Очень просто: команда сама должна об этом позаботиться во время планирования/коммитмента. Пользовательские истории очень полезно просто разбивать. Существует много приемов того, как это делать и мы о них в последующих постах обязательно поговорим. Пока что приведу один из примеров: история А = история А1 ("основной, примитивный сценарий") + история А2 ("все остальное"). Умение дробить и желание дробить - это часть культуры хорошей гибкой команды, что, к сожалению, часто не встретишь...

Наконец задаимся вопросом: а можно ли было что-то лучше сделать в случае №1? Да, точно: не имплементировать истории в параллели. Многие скрам-команды забывают сам дух скрама, саму суть "ведения мяча всей командой". И это опять таки элемент командной культуры. Поэтому, можно говорить о том, что эффективность burndown chart является также и индикатором гибкости команды.

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

Fixed Price: Как НЕ нужно эстимировать

Автор: Александр Якима (www.enter-agile.com)

Fixed-Price контракт - неидеальная среда для agile-разработки. Говоря более точно: просто для разработки. Мы не всегда можем более-менее точно оценить, сколько времени у нас уйдет на приготовление завтрака или на поход на работу, хотя делаем эту рутину регулярно. Что уж говорить о разработке ПО, где элемент уникальности - наиболее характерная черта...

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

Как эстимировать Fixed-Price проект?

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

Таблица 1. Традиционная разбивка при оценивании Fixed-price проекта.

Более или менее детализировано, но идея одна и та же - декомпонируем по задачам. Грубо говоря, вот вам время на разработку, вот на работу с требованиями и т д. При большей детализации выяснится, что мы рассчитываем столько-то времени на разработку схемы базы данных, столько на написание хранимых процедур и триггеров, столько на ORM-уровень, бизнес-логику мы напишем за столько, а вот столько-то у нас займет UI. Конечно, при этом (в частвности при самом процессе эстимирования) особой уверенности нам добавляет часто то, что мы комбинируем "лэйерную" декомпозицию с разбивкой "модульной", получается что-то вроде матрицы. Ну как тут можно ошибиться???

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

Не делать декомпозицию по задачам / модулям / лэйерам!

А как же делать? Отвечу вопросом: а как вы собираетесь имплементировать этот agile-проект? Ясно ведь как: закоммитимся на определенный объем пользовательских историй в первой итерации, потом так же во второй и т. д. Прекрасно, значит так нужно и эстимировать. Отсюда правило:

Декомпонируйте исходя из ценности для пользователя - разбивайте проект на фичи или пользовательские истории.

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

Таблица 2. Agile-оценка.


Таким образом достигается несколько принципиально важных целей:

1. При разбиении по пользовательским историям или фичам "анализ требований" получается более полным и адекватным, так как служит критической цели - оченке проекта. В случае №1 это не так, четкой внутренней необходимости для команды в адекватном анализе требований нет.

2. Заказчик и команда получают дполнительную степень свободы в планировании и выполнении: теперь заказчику понятно, что он может отложить на будущее, а что важно делать в первую очередь. Когда перед тобой список задач (напр., разработка, тестирование...) то как увидеть, чем можно пожертвовать? Тестированием модуля А или разработкой модуля Б?

3. Вероятность "вписаться" в рамки обещаний значительно выше, так как планироание иммитирует ход разработки, а не является иным по природе. Более того, если оценку дает команда уже работвашая совместно и если (при некоторых допущениях) можно говорить, что проект "типичен" или хотя бы не экзотичен, то априори команда уже имеет полезную для этого случая способность оченивать пользовательские истории ( напр., в стори-поинтах). Стори-поинт - это ни что иное, как единица измерения трудозатрат команды по разработке полностью всей истории, всех 100% - от анализа требований до разработки и тестирования. Этот факт обуслалвливает большую надежность оценки.

Точных оценок вам!

КАНБАН: пример естественного применения

Автор: Александр Якима (www.enter-agile.com)


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

Итак, описание кейса:

- Стадии (фазы, этапы) работы объективно существуют как часть формализованного процесса - диктуются заказчиком.

- Процесс почти строго последовательный

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

- Эстимирование объективно осложнено: система очень большая, каждый второй work item несет в себе много нового и неизвестного

- План работы может меняться произвольно - новые важные work items могут появляться в любое время

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

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

А как это лучше всего сделать? Точно! Ограничить работу в прогрессе и аккуратно следить за "проседанием" задач на индивидуальном уровне.

Поток ценности выглядит приблизительно так:


Соответственно, вот пример Канбан-доски для этого процесса:

И стало действительно лучше жить. Разработчик не берет больше одного айтема в разработку (за исключением, когда предыдущий ушел в приемочное тестирование, которое делается удаленной командой) - тоесть формулировка WIP Limit для этого случая звучит немножко нетривиально: "Не более одной задачи в строке таблицы, за исключением 2-х задач, одна из которых на этапе приемочного тестирования". Стало реально трэкать, что и как происходит. При этом, когда новый work item приходит под высочайшим приоритетом с легким движением руки Продакт-оунера, команда убирает одну из текущих задач в "отстойник" и высвобождает слот в пользу новой задачи. Естественно, лечге трэкать потери при постоянном изменении плана и Продакт-оунер принимает более осмысленные решения.

Патчи идут на продакшн-среду каждую неделю и каждую же неделю проводиться то, что команда называет "Kanban status meeting" - что-то похожее на демо + план новых задач (которые можно планировать) вместе с Продкат-оунером. Ежедневный утренний стэнд-ап для определения внутреннего статуса работы команды тоже никуда не исчез. Только проводит его теперь Kanban-мастер.

Наконец, очень важно отметить, что модель хорошо сработала именно потому, что процесс "сторго поэтапный" - данность в связи со спецификой и стилем работы заказчика. Однако, значительно эффективнее (даже в этом самом случае) было бы применять модель D-B-T (Define-Build-Test), в которой нет строгих фаз и "водопадоподобности", а наоборот - микроциклы D-B-T много раз прокручиваются, пока не получается то, что нужно. Но об этом в последующих постах...

Продакт-оунер в аутсорсинге

Автор: Александр Якима (www.enter-agile.com)


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


В аутсорсинге отношение "Команда - Продакт-оунер" накладываются на отношение "Поставщик - Заказчик" и эти форматы отношений во многом сущесвенно влияют друг на друга.

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

Здесь сразу хочу упредить душевное расстройство всех аутсорсинг-менеджеров и в особенности сейлов: мы не говорим здесь о модели staff extension (или как ее еще называют - staff augmentation). Эта модель лишена смысла с точки зрения Agile. Речь не идет о том, чтобы возвращаться к ненавистному "бади-шопу", от которого только-вот придумали как уйти с помощью новомодных (хотя и весьма порочных) парадигм, нет... Успешный Agile-аутсорсинг может работать только если agile-команды будут целостны и самодостаточны на стороне вендора, за исключением П-О. Вот это "маленькое исключение" как раз и определяет характер сервиса.

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

1. Доверия априори нет, заслужить всегда сложно. Именно потому, что Agile не может жить без доверия между Продакт-оунером и Командой этот пункт мы выносим на первое место. При этом часто и заказчик и вендор делают все против правил, удаляясь от желаемого результата. В основном либо потому, что заказчик пытается предохраняться где нужно и где нет - фиксировать скоуп, требовать четких коммитментов, там где это не представляется возможным, обложиться метриками и SLA-соглашениями, полагая, наверное, что юридически весомые документы умеют сами анализировать требования, писать и тестировать код... С другой стороны вендоры - вместо того, чтобы убирать барьеры, очень часто их создают под сладким соусом самоуправляемости, независимости и соблазнительной идеи маркетировать себя как поставщика black-box сервиса, где заказчику неочем беспокоиться на ежедневном уровне, а только перебросить через кирпичную стенку требования, а оттуда со временем назад вылетит "потенциально доставляемый инкремент" (сложно, наверное, подыскать более ироничное применение акронима PSI)...

2. Продакт-оунершип как хобби. Это встречается в аутсорсинге весьма часто... к сожалению. Продакт-оунер - это ключевая роль в гибкой разработке. Самая важная! Неправильно полагать, что: была бы хоть команда разработчиков - и уже можно что-то делать... Без хорошего продакт-оунера проектная работа обречена (либо на коллапс, либо на влачение жалкого существования). То, что часто происходит в действительности, не перестает удивлять - в качестве промоушена самому выдающемуся разработчику со стороны заказчика вверяют аутсорсинговую команду... при этом он остается занят разработкой и не имея малейших подозрений о том, почему важно в первую очередь выполнять роль П-О, переносит на два дня демо итерации, потому что он должен что-то там доразработать, дофиксать, а потом наступит и черед вернуться к agile-каденции ввереной ему команды...

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

Теперь несколько фраз о способах решения этих сложностей.

Что касается №1, то тут вопрос скорее отношения к собственному бизнесу, чем объективная проблематика. Иными словами, аутсорсинг-компаниям, конечно необходимо как-то обосновывать высокие рейты (по сравнению с другими), однако делать это можно по-разному. По крайней мере без резких противоречий с ключевыми принципами и ценностями Agile. Это становится особенно четко видно, когда "продается" услуга заманчиво называемая "Agile Fixed Price" или "Agile Managed Delivery" или как-то еще с одним и тем же подтекстом - Agile с минимальной тратой времени Продакт-оунера - но это нонсенс. Наоборот, разумный аутсорсинг-вендор увидит тут конкуррентное преимущетво по сравнению с "недоучками", предлагая то, что на самом деле будет работать и послужит хорошим бизнес-кейсом, подспорьем для приобретения новых клиентов в будущем - модель которая максимально сближает П-О и Команду, не ставит лишних барьеров. Это отдельная большая тема, в текущем посте же только скажу, что в какие бы юридические и маркетинговые обертки не был облачен проект, если П-О не будет "знать всех своих разработчиков в лицо" в полном смысле фразы, то надо помнить, что тогда не только Agile невозможен, но и отказаться от такого "черного ящика" П-О будет всегда очень легко. Подумайте на секунду, слышали ли вы много случаев противоположных, чтобы в продуктовой компании П-О уволил всю (!) свою команду? В аутсорсинге это случается сравнительно часто. Повод для раздумий, не так ли?..

№2 решается всегда непросто. Если удастся (и если есть кому), то нужно такого П-О постепенно "обучать". Не нужно сильно комплексовать из-за того, что это заказчик. Если делать все аккуратно, никто не заметит, что это по сути образовательный процесс. Хуже, если П-О страдает существенной упертостью, бывает и такое. Придется тогда тратить больше времени на "логирование проблем и сбор фактажа", которые время от времени в ходе ретроспектив необходимо будет своему П-О в очень корректной форме предоставлять. Вода камень точит...

№3 - исходит полностью из культуры компании, поэтому тут совет двоякий. Во-первых, тем, кто на эту культуру сильно влияет исходя из своего заоблачного служебного положения - помнить всегда о том, что именно мега-успешные Agile проекты приносят дивиденды в виде лояльных заказчиков, творчески заряженных сотрудников, и много buzz'а вокруг компании о том, как здесь умеют делать software. Тем же от кого зависит хотя бы ситуация на проекте и кто хочет эту проблему разрешить - наберитесь терпения и все-таки постепенно добивайтесь процессных изменений. Каждый успешный шажок - аргумент для вашего менеджмента, что вы поступаете правильно. Ваша мотивация - шанс стать проводником изменений во всей компании по уже известному вам паттерну, когда наступит время. Поверьте, у вас в этом почти не будет конкуррентов...

OSDN.org.ua - My Conference Speech

Last Saturday I had a speech at pretty interesting conference of developers and users of free open source software - OSDN. I was speaking about FOSS tools for Agile teams. Here're few pics:




...and the presentation:

Agile foss tools
View more presentations from alexyakima.

Дефекты в обнаружении дефектов

Автор: Александр Якима (www.enter-agile.com)

Очень коротко хочется до самой глубины раскрыть такой важный ньюанс:

Тестировать софтверный продукт, не представляя перед глазами четкого профиля конечного пользователя ущербно!

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

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

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

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

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

Основы пользовательских историй. Часть 5.

Дин Лэффингуэл (Dean Leffingwell, blog), Пит Беренс (Pete Behrence)

Перевод: Александр Якима (www.enter-agile.com)

Спайки

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

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


Технические и функциональные спайки

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

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


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


В этом случае команда может создать два спайка:

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




Рекоммендации по спайкам


Эстимируемость, демонстрируемость и возможность приемки

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

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

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


Исключение, а не правило

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

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


Реализация спайка в одном спринте, а результирующих пользовательских историй в другом

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


Моделирование стори с помощью карточек

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

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

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

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


Подводим итог

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

--------------------------------

Литература

Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.
Martin, Robert. 2009. Clean Code: A Handbook of Agile Software Craftsmanship. Boston: MA: Pearson Education.
Poppendieck, Mary, and Tom Poppendieck. 2007. Implementing Lean Software Development: From Concept to Cash. Boston, MA: Addison-Wesley.
Jeffries, Ron. 2001, August. “Essential XP: Card, Conversation, and Confirmation.” XP Magazine.

Agile в неравенствах

Автор: Александр Якима (www.enter-agile.com)

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

трудозатраты != результаты != ценность

Выглядит очень просто. Попробуем посмотреть, что стоит за этой формулой... по частям:

1. трудозатраты != результаты. Это неравенство в первую очередь относится к команде разработчиков. Тем более оно как раз особо важно для заказной разработки, или даже лучше будет сказать: контекст этого неравенства является в области контроля команды разработчиков, в отличие от неравентсва №2 (см. ниже). Это неравенство оипсывает правильную психологию гибкой команды, для которой важен только результат - они его регулярно достигают посредством инкрементов итераций и соответсвенно с практической позиции знают, что методы и трудозатраты, необходимые для достижения результата, чаще всего оказываются совсем не такими как казалось по-началу.
Несколько типичных иллюстраций:

Технический аванс vs. технический долг. Есть у многих разработчиков такая слабость: при имплементации фичи дойдя до определенного слоя системы начать "закладываться" под другие гипотетические фичи: "раз уж я здесь, то сделаю больше... а то что это за слой такой - всего два класса...". Эффективным будет на самом деле оставить минимальное минимальным, а с точки зрения того, насколько нужно "закладываться" под кое-какую общность - исходить из простого правила: всегда лучше сделать, получив на выходе результат, имеющий ценность для конечного пользователя (читай - работающий продукт) и таким образом взять технический долг, который потом "отдается" в форме рефакторинга, чем брать технический аванс и не знать, что с ним потом делать по отношению к пользователю. Так вот, реализованные фичи - это уже результат независимо от того, сколько трудозатрат на нее потрачено, а слой системы - это слой системы и не более, его пользователь не то что применить не сможет, но даже объяснить ему не сможете, что это такое. Итак, сделав слой "наугад" команда а) на 90% рискует ошибиться и б) лишает себя дополнительных опций в принятии технических решений в будущем - а это даже хуже. Итак, добиваемся результата любой ценой, оставляя, возможно, за собой технический долг, который в последствии отдаем в форме рефакторинга.

Перфекционизм. Почему-то часто принято считать, что перфекционизм как-то положительно связан с профессионализмом. Нет, есть конечно несколько форм положительного проявления перфекционизма, например: например, в постоянной поддержке бэклога, или в том, чтобы не давать дефектам переходить в следующую итерацию и т. д. Но что на самом деле обычно является предметом усердствований перфекциониста? Именно так: как писать юнит-тесты, как писать код, что выносить, а что нет в конфигурационные файлы и т. д. У всего этого есть одно общее свойство - акцент на низкоприоритетных вещах. Вроде бы и лишних "движений" по слоям не делается, как в предыдущем случае, вроде бы появился только нужный код, но увы, на его "полировку" уходит уйма усилий в то время, когда нужно всего лишь грубо отшлифовать. Тут нельзя не вспомнить советскую 34-ку, грубую, везде похабно подвареную, но достаточно надежную и, самое главное - дешевую в производстве, по сравнению со сверхкачественными Тиграми, которые требовали много дорогих как сырьевых, так и человеческих ресурсов. Советский танк тогда выиграл войну своей легкостью в производстве и поддержке, это прекрасный исторический пример, свидетельствующий о здоровом расчете: место танка - на поле боя, а не на автошоу.

2. результаты != ценность. Допустим теперь для простоты, что мы имеем дело с идеальной командой разработчиков, всецело понимающей и на практике руководствующейся неравнеством №1. И все же, несмотря на нацеленность на результат, результат этот может не нести должной ценности конечному пользователю - и действительно существует немало примеров прекрасной реализации релизов продукта, никому не нужного, как оказывается в последствии. "Это не проблема разработчиков", - скажут разработчики и будут почти правы, так как этот пункт почти полностью относится к обязанностям продакт-оунера. Это неравенство какраз выражает ту простую мысль, что правильное задание приоритетов - кардинально сложная задача. Если неравенство №1 "срабатывает" на уровне итерации, то неравенство №2 - это уровень релиза, так как нет иного эффективного способа эффективно валидировать свои гипотезы о приоритности фич, как посредством частых релизов и активного сбора фидбеков от пользователей. Тут и становится понятным использованное нами наречие "почти": команда должна научиться релизить часто. Часто - понятие относительное, но если разработка производится командой из 5 - 30 человек, полностью покрывающих разработку системы, то 6-8 недель - абсолютно достижимый и даже весьма рекомендуемый таймбокс для релиза.

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

Одним слайдом: Анатомия гибкой итерации

Автор: Александр Якима (www.enter-agile.com)

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

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

Agile-Стоматолог

Автор: Александр Якима (www.enter-agile.com)

В 2007 году один из разработчиков на моем проекте посоветовал стоматолога. С тех пор я стоматолога не менял. И не собираюсь. Почему? Потому что этот стоматолог 100% ориентирован на качественное удовлетворение потребности "пользователя". Расскажу подробнее и мы увидим явные параллели с гибкой разработкой.


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

Комментарий. Это мечта любого продакт-оунера. Команда исправно доставляет инкременты итераций, действительно работающие, и каждый раз ожидает от него простого "ДА" (принято) или "НЕТ" (не принято). Квинтэссенция всего - приемка релиза. Однако типичная расхлябаность и отсутствие элементарной дисциплины оставляют от гибкой команды одно название (см. У Вас Agile? Проверим?..). Очень часто ситуация усугубляется тем, что на проекте нет выделеной роли "продакт-оунер". Тогда следует кому-то в команде это бремя на себя принять, а именно - роль прокси продакт-оунера. Тема проксирования заслуживает целой книги, мы к ней обязательно вернемся в последующих постах. Однако важно помнить следуюющее простое правило: без продакт-оунера, делающего систематическую приемку выхлопа каждой итерации, это не Agile.

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

Комментарий. Команда должна не просто выкатывать комок софта на демо и на этом все. Нет. Так команда получит только поверхностный фидбэк от продакт-оунера. Чтобы основательно понять, в каком состоянии предлагаемый билд итерации, команда должна предоставить продакт-оунеру следующие две вещи:
1) "Алгоритм" полноценной приемки. Обяснить как "локализовать нервные окончания".
2) Время, достаточное для выполнения офф-лафн приемки.
Последнее означает в оптимальном случае (и это действительно хороший стиль работы), что до следующего демо у продакт-оунера будет свободный доступ к текущему билду; иными словами - держать инкремент предыдущей итерации доступным всю текущюю итерацию, пока не появится новый инкремент.

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

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

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

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

Берегите зубы!

Основы пользовательских историй. Часть 4.


Дин Лэффингуэл (Dean Leffingwell, blog), Пит Беренс (Pete Behrence)

Перевод: Александр Якима (www.enter-agile.com)

Разбиение пользовательских историй

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

Не существует какой-либо установленной процедуры разбиения пользовательских историй на куски, вместимые в рамки итерации, кроме как общих положений о том, чтобы стори предоставляла вертикальный срез, определенный кусок, ценный для пользователя, проходящий систему насквозь. Однако, базируясь на недавней работе Ричарда Лоренца (Richard Lawrence), мы рекомендуем применять соответствующий набор из десяти общих паттернов разбиения пользовательской истории, как это показано в Таблице 1[11]:










































































1. По последовательностям действий. 

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

Как энергокомпания я хочу изменять и публиковать тарифные планы потребителю

...Я могу публиковать тарифные планы на домашний дисплей

...Я могу послать сообщение на Интернет-портал потребителя

...Я могу опубликовать таблицу тарифов на смарт-термостате потребителя


2. По вариации бизнес правил. 

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

Как энергокомпания я могу упорядочивать потребителей по демографическому признаку

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

...упорядочивать по домашней демографии

...упорядочивать по уровню потребления энергии


3. По основным трудозатратам. 

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

Как пользователь я хочу иметь возможность выбрать/изменить мой тарифный план с помощью энергокомпании через Интернет-портал

...Я хочу использовать Временной тариф [12]

...Я хочу использовать Предоплатный тариф

...Я хочу подписаться на Пиковый тариф [13]


4. По простоте / сложности. 

Когда команда обсуждает пользовательскую историю и она, кажется, становится все объемней и объемней (“А как насчет x? А думали ли вы об y?”), следует остановиться и спросить себя “какой наипростейший вариант мог бы сработать?” Зафиксируйте эту простейшую версию в качестве первой стори, и тогда уже сможете разбить все вариации и сложные детали в отдельные пользовательские истории.

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

...реагировать на время и продолжительность пиковых цен

...реагировать на непредвиденные изменения


5. По вариациям данных. 

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

Как энергокомпания я могу отсылать сообщения потребителям

...на английском

...испанском

...арабском и т. д.


6. По методам ввода данных. 

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

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

...используя гистограммы по однонедельным промежуткам

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


7. Отсрочка качеств системы. 

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

Как пользователь я хочу видеть потребление на моем счетчике в реальном времени

...интерполировать данные из последней вычитки данных

...показать настоящие данные счетчика в реальном времени


8. По операциям (пример: CRUD [14]). 

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

Как пользователь я могу управлять своей учетной записью

...Я могу создать учетную запись

...Я могу редактировать установки учетной записи

...Я могу приостановить учетную запись

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


9. По сценариям использования. 

Если сценарии разрабатывались для представления сложных взаимодействий вида “пользователь-система” или “система-система”, то стори часто можно разделить соответственно отдельным под-сценариям.

Я хочу подписаться на программу энергосбережения через розничного дистрибьютора.

Сценарий / Стори №1 (оптимистичный сценарий): Сообщить энергокомпании, что у пользователя есть оборудование


Сценарий / Стори №2: Энергокомпания обеспечивает оборудование и данные и уведомляет потребителя.


Сценарий / Стори №3 (альтернативный сценарий): Обработать ошибки при валидации данных.


10. Запустить спайк. 

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



Таблица 1. Десять паттернов разбиения пользовательской истории

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


ПРОДОЛЖЕНИЕ СЛЕДУЕТ...


----------------------------------------

Литература

Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.
Martin, Robert. 2009. Clean Code: A Handbook of Agile Software Craftsmanship. Boston: MA: Pearson Education.
Poppendieck, Mary, and Tom Poppendieck. 2007. Implementing Lean Software Development: From Concept to Cash. Boston, MA: Addison-Wesley.
Jeffries, Ron. 2001, August. “Essential XP: Card, Conversation, and Confirmation.” XP Magazine.

----------------------------------------

11. Адаптировано из статьи Ричарда Лоренца: http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/

12. Примечание автора перевода: в США потребители электроэнергии могут воспользоваться временным тарифом (time-of-use pricing), который предполагает разные тарифы в разные периоды времени (обычно года; тарифы заранее известны потребителю) и, таким образом, позволяет оптимизировать объем платы за энергию.

13. Примечание автора перевода: Пиковый тариф (Critical Peak Pricing) отражает отношение к себестоимости энергии и позволяет потреблять по “оптовым” тарифам в момент высокой загруженности сети.

14. Примечание автора перевода: Create Read Update Delete – Создание Чтение Обновление Удаление, - сокращенное название базовых функций управления данными.

Основы пользовательских историй. Часть 3.

Дин Лэффингуэл (Dean Leffingwell, blog), Пит Беренс (Pete Behrence)

Перевод: Александр Якима (www.enter-agile.com)


Инвестируйте в качественные пользовательские истории


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

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

Поэтому,
инвестировать усилия в качественные стори, хоть и в последний ответственный момент, является стоящим занятием для команды. Билл Вейк (Bill Wake), ввел в оборот аббревиатуру INVEST[7], чтобы описать атрибуты хорошей пользовательской истории[8]:

Independent (Независимая)
Negotiable (Обсуждаемая)
Valuable (Полезная)
Estimable (Эстимируемая)
Small (Компактная)
Testable (Тестируемая)

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


Независимость

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

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

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


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


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

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


1') Как администратор я могу установить период истечения действия пароля, таким образом пользователи будут обязаны периодически менять пароли.
2') Как администратор я могу установить характеристики сложности пароля, так что пользователи будут обязаны создавать пароли, которые сложно подобрать.


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



Обсуджаемость

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

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

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


Польза

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

Типичный вызов, с которым сталкиваются команды – научиться писать небольшие, инкрементальные пользовательские истории, подходящие для эффективной доставки ценности. Традиционные подходы запечатлели в нас алгоритм функциональной разбивки требований на технические компоненты. Этот подход “технического наслоения” при разработке систем замедляет доставку до тех пор, пока все слои не будут соединены воедино в результате многочисленных итераций. Вейк[9] (Wake) предлагает свое видение скорее вертикального, чем технического (горизонтального), наслоения:


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


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

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


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


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


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


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


Произвести рефакторинг системы логирования ошибок.


Формулируя ценность технического решения как пользовательской истории помогает донести бизнесу ее полезность. Например:


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


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


Эстимируемость

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

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

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


Компактность

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


Увеличение пропускной способности

Как известно из теории массового обслуживания, более компактные пакеты проходят сквозь систему быстрее. Это один из ключевых принципов бережливого производства и отражен в законе Литтла (Little):



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

Более того, когда система загружена полностью, она может стать нестабильной и проблема может нагромождаться. В сильно перегруженных системах большие пакеты двигаются сквозь систему непропорционально медленно, так как пропускная способность падает. (Представьте себе шоссе в час пик. У мотоцикла шансов нормально передвигаться значительно больше, чем у легковых автомобилей и грузовиков – значительно легче маневрировать компактными объектами при движении в нагруженной системе.) Поскольку команды разработчиков обычно заняты почти на полную нагрузку, а то и выше (80-120%), они также попадают в “час пик”.

Когда загрузка достигает порядка 80% и выше, большие объекты увеличивают продолжительность цикла (замедляют) в значительно большей степени, чем меньшие объекты. Более того, вариация продолжительности цикла увеличивается, то есть становится труднее предсказать, когда пакет сможет на самом деле покинуть систему – иллюстрация этому представлена на Рисунке 1 ниже[10]. В свою очередь, эта низкая предсказуемость разрушает планы, обязательства и доверие к команде.



Рисунок 1. У больших пакетов больше продолжительность цикла и выше вариация.



Уменьшение сложности

Более компактные пользовательские истории проходят сквозь процесс разработки быстрее не только из-за их пропорционального объема, но и из-за меньшей сложности, а сложность нелинейно зависит от объема. Это лучше всего наблюдается в тестировании, где разветвленность системы тестов, необходимых для валидации функциональности, растет экспоненциально по отношению к объему самой функциональности. Это соответствует рекомендации по разработке чистого кода, а именно, Роберт Мартин [Martin 2009] предлагает следующие правила для функций системы:

Правило 1: Реализуйте что-то одно

Правило 2: Следите, чтобы объем задачи был небольшим

Правило 3: Сделайте ее еще меньшей


Это одна из основных причин, почему последовательность Фибоначчи (то есть 1, 2, 3, 5, 8, 13, 21, ...) столь эффективна при эстимировании пользовательских историй – оценка трудозатрат растет нелинейно с ростом объема задачи.


О соотношении объема и независимости

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


Тестируемость

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

Чтобы удостовериться в том, что стори не попадут в итерацию, если они не способны из нее выбраться (то есть быть успешно оттестированными), много гибких команд на сегодняшний день применяет подход: “сначала тесты”. Это берет начало в XP-сообществах, использующих Разработку через тестирование (TDD) – практику написания автоматизированных юнит тестов перед написанием кода, который должен этим тестам удовлетворять.

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

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


ПРОДОЛЖЕНИЕ СЛЕДУЕТ...

--------------------------
Литература

Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.
Martin, Robert. 2009. Clean Code: A Handbook of Agile Software Craftsmanship. Boston: MA: Pearson Education.
Poppendieck, Mary, and Tom Poppendieck. 2007. Implementing Lean Software Development: From Concept to Cash. Boston, MA: Addison-Wesley.
Jeffries, Ron. 2001, August. “Essential XP: Card, Conversation, and Confirmation.” XP Magazine.

---------------------------

7. Bill Wake. www.XP123.com.

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

9. Там же

10. Источник: [Poppendieck 2007].

У Вас Agile? Проверим?..

Автор: Александр Якима (www.enter-agile.com)

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

Вопрос №1: У вас итерационная разработка? Иными словами, работает ли ваша команда четкими короткими (одно-, двух- или нескольконедельными) таймбоксами?

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

Вопрос №2: Является ли основной целью и результатом каждой итерации работающая версия продукта?

Если это не так - у вас точно не Agile. Тут все просто. Если под конец итерации у вас что угодно, только не запускающийся и нормально работающий продукт (много несинхронизированного кода в разных ветках, скриптов, отчетов о прогрессе в excel-документах, планов, диаграм архитектуры системы и т. д.), то это не Agile. Вам попросту нечем измерять действительный прогрес разработки, нет средства получения фидбека, нет осязаемого результата.

Вопрос №3: Является ли для команды принятие/непринятие итерации продакт оунером существенным и действенным показателем успешности их работы?

Если команда просто работает, даже итерационно, но команда не ставит перед собой постоянной целью получение фидбека от продакт оунера (да или нет; принята итерация или нет...) - это не Agile. Очень важно понимать, что в этом пункте не может быть исключений, например: "а у нас заказчик такой... - ему все равно". Иногда выходом является проксирование функции продакт оунера менеджером продукта, есть и другие варианты. Однако суть такова - без авторитетной приемочной роли п/о это работа на холостых оборотах, а не Agile.

Вопрос №4: Сдает ли ваша команда релиз всегда вовремя и качественно?

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

Вопрос №5: Знает ли и понимает ли ваша команда в каждый момент времени цели продукта в целом, текущего релиза в частности и, наконец, итерации?

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

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

Основы пользовательских историй. Часть 2: Форма

Дин Лэффингуэл (Dean Leffingwell, blog), Пит Беренс (Pete Behrence)

Перевод: Александр Якима (www.enter-agile.com)


Карточка, диалог и подтверждение


Рон Джеффрис (Ron Jeffries), другой среди создателей XP, дал описание, ставшее для нас наиболее предпочтительным представлением о пользовательских историях. Он воспользовался словосочетанием: Карточка, Диалог и Подтверждение [4], для описания трех элементов стори, где:

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

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

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

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

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


Шаблон пользовательской истории

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

Как <роль> я могу <действие>, так что <бизнес-ценность>

где:

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

Мы называем эту конструкцию [5] “голосом пользователя” и находим ее крайне полезной, поскольку она охватывает проблемную область (доставляемую <бизнес ценность>) и область решения (<действие>, производимое пользователем с помощью системы). Она также выдвигает пользователя (<роль>) на приоритетное место для команды, фокусируя таким образом команду на бизнес ценностях и решении настоящих проблем для настоящих людей.

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

Например, пользователь бытовой системы управления энергопотреблением желал бы следующего [6]:


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


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


Детали пользовательских историй

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


Критерий принятия стори


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

Например,


Как пользователь, я хочу иметь возможность видеть мое ежедневное потребление электроэнергии, чтобы обрести представление о том, как уменьшить финансовые затраты с течением времени.
Критерий принятия:
• Считывать показатели счетчика Декаватт каждые 10 сек. и показывать на портале в виде 15-минутных инкрементов и отображать на бытовом дисплее каждую вычитку
• Считывать показатели в Киловаттах, как только появляются новые данные и показывать на портале каждый час, а на домашнем дисплее после каждой вычитки
• Никакого многодневного трендинга пока что (попадет в другую стори)
• И т. д. ...


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

ПРОДОЛЖЕНИЕ СЛЕДУЕТ...

--------------------------------------------
4. http://xprogramming.com/xpmag/expcardconversationconfirmation/

5. В поисках происхождения этой конструкции я получил комментарий от Майка Кона (Mike Cohn): “Я начинал работу с командой в компании Connextra в Лондоне и это было упомянуто на XP2003. Я стал использовать это и в дальнейшем и написал об это м в моей книге, изданной в 2004 году, User Stories Applied.”

6. Автор приносит благодарность Дженнифер Фосетт (Jennifer Fawcett), сотруднику компании Tendril Networks, за предоставление примеров
Newer Posts Older Posts Home
Powered by Blogger