6 – Как разрабатывать
Постоянная декомпозиция
При условии, что вы выбрали гибкую разработку и бэклог на релиз готов, требуется разделить каждую функциональность на более мелкие части и составить план на спринт. Для этого используйте одну из тех же методик, что и при планировании релиза:
– Use Case: детализация вариантов использования. (Например, описание возможных вариантов использования во время заполнения заявки на получение услуги).
– User Story: разбор отдельных историй на части. (Например, описание истории перехода от заполнения заявки к получению услуги).
– Job Story: дробление крупного контекста на мелкие контексты. (Например, описание переключения от контекста заполнения заявки к контексту получения услуги)
Как видите, степень свободы в реализации решений зависит от выбора фреймворка. Методика приоритизации задач на спринт – аналогичная той, что и для приоритизации функционала в релизе.
Стоит ли участвовать в декомпозиции задач внутри спринта, зависит от того, насколько глубоко хотите погрузиться в разработку и как договорились с подрядчиком.
Вертикальная декомпозиция. Источник – https://creativecommons.org
Я предпочитаю не углубляться в подробности реализации задач, если только разработчики сами этого не попросят.
Усмирение демонов
Допустим, план на спринт готов, критерии приемки чётко сформулированы и команда приступила к разработке. Обсудим несколько базовых правил, чтобы всё шло так, как должно.
Всегда давайте возможность разработчикам предложить вам несколько вариантов решения задачи. Ни в коем случае нельзя настаивать только на вашем конкретном варианте. Помните: пока продукт не запущен и нет возможности посмотреть на статистику его использования, все гипотезы равнозначны.
Если вы не можете избавиться от мысли, что ваше решение задачи самое лучшее и других вариантов быть не может, грамотный исполнитель предложит провести A/B-тест. Зафиксируйте ваше решение в отдельной таблице работы с гипотезами и двигайтесь дальше.
Старайтесь, чтобы у каждой задачи, которая идёт в спринт, был понятный результат, а не «провести исследование как провести исследование». Вообще, в гибкой разработке не принято выделять исследования в отдельные задачи, потому оценивать качество таких активностей и управлять ими затруднительно.
В гибкой методологии срок исполнения равен сроку завершения спринта. Если от спринта к спринту часть задач не выполняется – ничего страшного, это абсолютно нормальное явление. Зато после прохождения нескольких спринтов вы будете лучше понимать средний объём задач, который команда успевает «переварить», и в следующий раз не будете переживать о нескольких задачах, которые не успели решить. Просто держите приоритетность под контролем – и среди невыполненных задач окажутся не такие уж и важные.
Аппетит приходит во время еды
Возможно, у вас появится соблазн сказать: «Давайте пока закроем задачу, а потом немного доделаем!» Покорный исполнитель смирится и отправит задачу в колонку «готово». Но это неправильно. Так вы перестанете управлять сроками и качеством исполнения. Запомните: у задач не может быть статуса «почти сделана». Либо она готова полностью, либо не готова.