Как и какое техническое задание писать при работе по Agile

1. Техническое задание при работе по Agile

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

Об этом я подробно писал в статье 12 проблем при работе по техническому заданию в IT-продукте.

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

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

2. Метафора для инструмента планирования

Программное обеспечение абстрактное и легко меняется. Этим свойством софт отличается от производства вещей в реальном мире. Например, после постройки дома никому не придет в голову сказать: «Теперь давайте раздвинем 5-й и 6-й этажи и вставим между ними огромный аквариум с акулой». В мире материального производства так не бывает, а в разработке ПО такие изменения — норма. Поэтому подход к планированию работ должен соответствовать природе софта.

На мой взгляд, хорошо подходит метафора навигатора в автомобиле:

1. Навигатор знает где мы сейчас и куда хотим приехать.
2. Если по дороге домой, мы решили свернуть в магазин, то он перестроит первоначальный путь с учетом изменений.
3. Если мы передумали ехать домой, то ставим новую точку и нам сразу показывается новый оптимальный путь до новой цели.
4. Если на дороге случилось ДТП и путь закрыт, то навигатор перестраивает маршрут.

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

3. Реализация адаптивного плана работ

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

3.1. Визуальное и «многомерное» техническое задание

Люди хорошо работают с визуальными образами, mind map'ами и схемами. Поэтому в своей практике мы мало пишем «плоского» текста, зато активно используем карты и образы. Рисунки и карты легко перестроить в отличие от 300-страничного документа. К тому же эти карты быстро считываются и помогают людям на проекте эффективно коммуницировать.

Для построение карты целей и нахождения кратчайшего пути до цели мы рисуем Impact Map:

Взаимодействие всех частей IT-продукта, пользовательский опыт и сценарии работы пользователя описываются в Customer Journey Map и User Story Map.

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

Все три инструмента подробно описаны в Аналитике IT-продукта.

3.2. Циклы и пересмотры

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

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

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

3.3. Объем работ — не фиксированная величина

Для обеспечения гибкости в классическом проектном треугольнике нужно поменять две вещи: перестать фиксировать объем работ и начать фиксировать качество.

• Фиксация качества — т.к. направление разработки ПО всё время меняется, то архитектура и код не должны ломаться при внесении изменений. Код не должен быть хрупким. Для повышения качества кода используют практики Экстремального программирования и следят за уровнем технического долга.
• Плавающий объем работ — обычно для заказчика важны срок и цена, эти величины остаются зафиксированными. Но что конкретно мы сделаем в указанный срок? Сделаем то, что максимально приблизит заказчика к бизнес-цели, а это будет видно по картам и схемам, которые используются при планировании.
  Разработчикам хорошо известно, что одну и ту же задачу можно сделать бесконечным количеством способов. Например, если вывести красивый индикатор, то это займет два дня работы дизайнера, верстальщика и программиста, а если вместо него показать цифру, то это делается в пять раз быстрее. Поэтому мы часто «флексим», т.е. делаем меньше, но не ухудшаем достигаемость бизнес-цели.

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

3.4. Ориентация на бизнес-цель

Заказчик и исполнитель вместе ориентируются на бизнес-цель при прокладывании пути без формального технического задания:

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

4. Я бухгалтер, я так вижу

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

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

5. Повышаем качество работы

Основные тезисы:

1. Планирование работ — цикличный и постоянный процесс, поэтому нужно использовать гибкие инструменты;
2. Не заменяйте живую коммуникацию на ТЗ. Если ТЗ начинает занимать ведущую роль, то стоит насторожиться и проверить как устроена коммуникация в проекте между всеми участниками;
3. Пишите ТЗ, когда это необходимо. Делайте его как можно более полезным;
4. Контроль процесса разработки достигается за счет визуализации текущего состояния проекта и понимание дальнейших шагов.

Эта статья входит в цикл статей о техническом задании:

1. Когда надо прекратить писать Техническое задание и начать делать проект? Дана схема как балансировать между чрезмерно подробным, а значит дорогим, ТЗ и слишком абстрактным, что ведет к рискам и ошибкам.
2. 5 причин написать ТЗ, где перечислены причины, которые подталкивают подробно описывать весь план работ до начала проекта.
3. 12 проблем при работе по техническому заданию в IT-продукте. Описаны проблемы, которые превращают написание ТЗ в потери для бизнеса.
4. Откровенное общение с заказчиком, где решился спор о том, на сколько подробным должно быть ТЗ.
5. Техническое задание как база знаний о проекте, где описано, что написание ТЗ — это потери для бизнеса.
6. Как и какое техническое задание писать при работе по Agile, где описывается, как использовать подходящие инструменты планирования, прекратить фиксировать объем работ надолго в будущее и строить коммуникацию вокруг бизнес-целей.