Пишу про разработку вообще и в частности про: JavaScript, HTML5, CSS3, AngularJS, ReactJS, Agile, Bitcoins

Больше не назначаем сроки

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

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

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

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

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

is-no-estimation-for-real

Agile говорит о том, что нужно выработать подход, при котором мы можем работать в равном темпе над задачами. Однако, в тот момент, когда мы начинаем ставить сроки – темп нарушается. Эти два подхода противоречат друг-другу.

Даже если мы немного “сумничаем” и скажем, что сроки такие-то, но у них есть 20% шансов исполниться – это опять ничего не значит. Если дату мы как-то попытались угадать, то что с процентами? Это же тоже некая догадка. Чем же две догадки лучше чем одна? С тем же успехом можно играть в казино.

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

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

Как альтернативу с.п. можно предложить не оценку цифрами, а использовать более общие понятия: Trivial, Easy, Normal, Hard, Herculean, Don’t Know.

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

Мы так же можем сказать что планируется сделать в ближайшие пол года. Крупными мазками. Точно на 6 месяцев мы не можем запланировать.

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

А теперь самое главное – что же делать, если не оценивать? Ведь ты должен объявить сроки клиенту, есть выставки, конференции, к которым нужно успеть иначе в следующем году у компании может не быть заказчиков. Да, безусловно следовать срокам необходимо, только назначать их нужно не в момент расписывания стори, тут можно только примерно понять направление, а на 3-й, 4-й итерации. При таком подходе достаточно только считать количество стори, не назначая им стори-пойнтс вообще. В итоге дата релиза будет видна вот из такого графика:

no-estimates-flow-diagram

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

Тут может возникнуть вопрос – а как же поступать с большими задачами? Стори-пойнтс как раз и говорят о том, что задачу нужно разбить. Однако, дело же не в том сколько очков мы дали той или иной задаче, дело в том можем ли мы сами себя честно спросить “Нужно ли разбить эту задачу?” и так же честно ответить.

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

Ссылки по теме:

Поделиться:
comments powered by Disqus