Если вы занимались спортом, то знаете, как важен ритм и дыхание. В борьбе очень важно сбить дыхание соперника, а при беге сбивать свое дыхание ни в коем случае нельзя.
Планируя разработку программного продукта, мы задаем ритм, дыхание команды. Каждые 2 недели (длина нашей итерации) мы обязуемся выпускать новую версию продукта, которая продвинет заказчика вперед, принесет ему прибыль.
При планировании задач действуют простые правила. Вы не можете растягивать/укорачивать итерацию. Если все задачи на итерацию сделаны, а 2 недели еще не закончились, то можно заняться рефакторингом, оплатить свои технические долги, либо попросить заказчика добавить задач. Если мы ошиблись в оценках и запланированные задачи не могут быть выполнены в течение 2х недель, то их следует отложить на следующее планирование.
Первая ситуация возникает очень редко и разрешается довольно легко. Зато вторая бывает довольно часто. Чтобы выйти из ситуации, когда планирование было слишком оптимистичным, самым простым решением кажется не откладывать задачи, а доделать их за недельку и потом уже нормально запланировать следующую итерацию, так сказать «без хвостов». Здесь-то и лежит корень проблем, которые возникают после этого. А после этого получается «сбитое дыхание» как команды, так и заказчика.
Итак, через 2 недели у нас из 8 карточек осталось 2. Причем они практически готовы, но вот времени немного не хватило. Заказчик, видя, что всего 2 карточки не сделаны, предлагает их доделать и соглашается на приблизительные оценки (где-то 2-3 дня на доработку). Этого делать нельзя, потому что оставшиеся карточки изначально были неправильно оценены. Если попробовать установить срок «переделки», то можно наступить на те же грабли во второй раз.
Раз эти карточки остались, а 6 других сделаны, то получается они были последними в приоритетах итерации. Откладывать планирование - значит лишать заказчика возможности назначения важности задач. За то время пока разработчики «доделывают» последние карточки, они могли бы запланировать новые и начать с наиболее приоритетных для заказчика задач на данный момент. Практика показывает, что оставшиеся с прошлой итерации карточки не становятся первыми в следующей.
Во время «доделывания» задач, становиться непонятно кто и что делает и когда все это закончится. Происходящее в головах можно изобразить так:
На графике 2 оси: время и интегральный показатель. В данном случае он складывается из усталости команды, количества накопившихся ошибок в проекте, удовлетворенности/неудовлетворенности заказчика и т.д. Проще говоря, чем выше кривая, тем хуже дела с разработкой. После каждого планирования заказчик получает то, что просил 2 недели назад, разработчики с удовольствием показывают готовую работу, поэтому отношения между заказчиком и разработчиками улучшаются, становится более доверительными. Откладывание планирования ведет, как минимум, к ухудшению отношений заказчика и команды.
Не сбивайте дыхание, держите темп разработки!
Ссылки
Страх перед дедлайном - нормально ли это?
Отличная метафора про дыхание.
ОтветитьУдалитьНо все-таки что делать с незаконченными задачами? Сделать вид, что они и не начинались и включить их в планирование на следующий спринт, дабы они соответствовали своему приоритету? Эстимейтить только то, что не успели доделать в рамках этой задачи? Звучит неплохо, но вот только если задача "almost done", а программист переключается на более приоритетную (по результатам нового планирования), ему потом потребуется больше времени, чтобы вникнуть в задачу. Этот фактор тоже нужно учитывать.
@Idsa
ОтветитьУдалитьЕсли задача "почти завершена" то она пойдет первой в следующем спринте. Вообще в конце итерации остаются самые не приоритетные задачи. Если в следующем спринте незаконченная задача идет не первой, значит ее надо заново оценить. Если первой она не идет, то ничего страшного, что придется переключиться на более приоритетную. Практика показывает, что такие задачи в конце концов вообще вылетают из разработки :)
Правильно ли я понял, что основной посыл статьи заключается в том, что невыполненные задачи нужно переносить в новую итерацию, а не продлять текущую итерацию? А что если без этих фич мы не можем запустить новую версию в конце итерации?
ОтветитьУдалить@Idsa
ОтветитьУдалитьДа, точно.
> А что если без этих фич мы не можем запустить новую версию в конце итерации?
Заново оценить задачи и поставить в следующую итерацию первыми. Когда их сделаем, зальем новую версию.
>>Заново оценить задачи и поставить в следующую итерацию первыми. Когда их сделаем, зальем новую версию.
ОтветитьУдалитьИтого, если я правильно тебя понял, ты предлагаешь две стратегии доработки оставшихся задач:
1. Ставим их в следующей итерации первыми. Как только закрываем долги (например, в первой четверти итерации), заливаем новую версию. А затем продолжаем работать над текущей итерацией, и в ее конце релизим еще одну версию.
2. Не стремимся быстро доделать эти задачи, делаем их в порядке приоритета в новой итерации.
Первый вариант нежизнеспособен для средних и больших проектов, потому что проводить тестирование версии два раза за итерацию неэффективно.
Второй вариант обладает недостатком, который я отмечал выше. Но при коротких итерациях им, как ты правильно заметил, можно пренебречь.
Однако оба варианта вызывают у меня один и тот же вопрос: если в конце итерации мы не заливаем новую версию, разве можно говорить о не сбившемся дыхании?
P. S. Ты не подумай, что я придираюсь. Просто мне понравилась эта спортивная аналогия, и я хочу с ней лучше разобраться.
@Idsa
ОтветитьУдалить> 1. Ставим их в следующей итерации первыми
Нет, не так. Главное тут "ЕСЛИ". Т.е. если ЗАКАЗЧИК ставит эти задачи первыми.
> потому что проводить тестирование версии два раза за итерацию неэффективно
У нас весь код покрыт модульными тестами (проходят за 1-2 минуты) и все разработанные ранее задачи интеграционными тестами (проходят где-то за 15-20 минут), поэтому мы можем заниматься тестирование всегда.
> если в конце итерации мы не заливаем новую версию, разве можно говорить о не сбившемся дыхании?
Конец итерации != заливки. Итерации и заливки не синхронизированы.
>>У нас весь код покрыт модульными тестами (проходят за 1-2 минуты) и все разработанные ранее задачи интеграционными тестами (проходят где-то за 15-20 минут), поэтому мы можем заниматься тестирование всегда.
ОтветитьУдалитьЯ имел в виду ручное тестирование тестерами. Или оно у вас тоже автоматизировано? :)
>>Конец итерации != заливки. Итерации и заливки не синхронизированы.
Под заливкой ты понимаешь deployment? Ну хорошо, пусть не заливка, а просто новая версия (как учит agile). Перефразирую вопрос: разве можно говорить о не сбившемся дыхании, если к концу итерации мы не сделали задачи, а значит новая версия не готова.
@Idsa
ОтветитьУдалить> разве можно говорить о не сбившемся дыхании, если к концу итерации мы не сделали задачи, а значит новая версия не готова.
Мы сделали задачи. Причем самые важные и критичные. В конце итерации остаются менее приоритетные.