Усмирение демонов
Допустим, план на спринт готов, критерии приемки чётко сформулированы и команда приступила к разработке. Обсудим несколько базовых правил, чтобы всё шло так, как должно.
Всегда давайте возможность разработчикам предложить вам несколько вариантов решения задачи. Ни в коем случае нельзя настаивать только на вашем конкретном варианте. Помните: пока продукт не запущен и нет возможности посмотреть на статистику его использования, все гипотезы равнозначны.
Если вы не можете избавиться от мысли, что ваше решение задачи самое лучшее и других вариантов быть не может, грамотный исполнитель предложит провести A/B-тест. Зафиксируйте ваше решение в отдельной таблице работы с гипотезами и двигайтесь дальше.
Старайтесь, чтобы у каждой задачи, которая идёт в спринт, был понятный результат, а не «провести исследование как провести исследование». Вообще, в гибкой разработке не принято выделять исследования в отдельные задачи, потому оценивать качество таких активностей и управлять ими затруднительно.
В гибкой методологии срок исполнения равен сроку завершения спринта. Если от спринта к спринту часть задач не выполняется – ничего страшного, это абсолютно нормальное явление. Зато после прохождения нескольких спринтов вы будете лучше понимать средний объём задач, который команда успевает «переварить», и в следующий раз не будете переживать о нескольких задачах, которые не успели решить. Просто держите приоритетность под контролем – и среди невыполненных задач окажутся не такие уж и важные.
