Есть такая замечательная техника как Planning Poker(http://goo.gl/Ek4kQF). К сожалению, из коробки она работает только в одном случае: вашему проекту всего несколько недель отроду, его разрабатывает три человека, и все знают написанный код как свои пять пальцев.
Покер позволяет каждому члену команды понять две важные вещи:
- Что в точности должно быть сделано, границы задачи, требуемое поведение и ограничения.
- Как в точности это должно быть сделано. Отсюда вытекает оценка объема задачи и сроков.
Теперь представим ситуацию: вашему проекту 10 лет, в нем 5 разработчиков, он состоит из сотен тысяч строк кода, некоторые куски этого кода не видел ни один ныне работающий в проекте разработчик, разные части кода ежедневно переписываются разными людьми.
Вчера вы прочитали про покер и решили попробовать его внедрить. Вы выбрали 10 фич среднего размера и решили их распланировать, собрали всех разработчиков в переговорке и начали обсуждать. Сначала вы пытались рассказать, что нужно сделать по первой задаче, но тут вас спросили, как реагировать на ошибки, и вы побежали за проектировщиком интерфейса и аналитиком, чтобы уточнить этот вопрос. Потом, кто-то из разработчиков понял, что часть из желаемого поведения реализовать невозможно, и вам снова потребовались аналитик с проектировщиком, чтобы налету перекроить решение. Через два часа вы переходите к оценке, но оценки расходятся, разработчики по-разному планируют решать поставленную задачу, кто-то включил в оценку подготовительный рефакторинг, написание функ.тестов, начинаются споры, кто-то забыл как выглядит часть кода, которая должна быть затронута, и вы идете за ноутбуком, чтобы была возможность освежить память. Договорившись о решении, вы начинаете декомпозировать задачу, не забывая записывать все подробности и границы подзадач. Спустя пять часов, вы переходите к оценке второй фичи. Команда измучена и голодна. Посередине вы решаете взять паузу и продолжить завтра.
После такого изнасилования, вы решаете, что «нужно готовиться к планированию». Вы рассылаете список задач разработчикам за день до планирования с просьбой ознакомиться и подготовиться, чтобы не было необходимости на планировании лазить в код и звать дизайнеров и аналитиков.
И на следующем планировании все проходит сильно лучше, и вы решаете, что так и нужно работать. Но что на самом деле происходит?
С одной стороны разработчики, помня изнасилование, действительно ко второму планированию прокапывают задачи. С другой стороны, чтобы не затягивать, стараются угадывать оценки коллег, чтобы не развязывать споры и обсуждения. Со временем мы получаем следующую ситуацию:
- Оценки даются интуитивно, никто не разбирается в задаче и коде до планирования. Все уже знают, как звучат сложные задачи, а как простые. Все уже чувствуют коллег и оценки всегда очень близки, но не потому, что все отлично понимают задачу.
- Решение всех непонятных вопросов откладывается до момента фактического начала работы над задачей, чтобы не затягивать планирование.
- Если же какие-то вопросы и решаются на планирование, то решение нигде не фиксируется. Все ведь и так всё запомнят. На итерации эти решения приходится восстанавливать заново.
В таких условиях покер превращается либо в формальность, либо в милые командные посиделки, в зависимости от вашего отношения. Команды, которые решают, что покер это формальность, оптимизируют свой процесс и исключают его. Такие команды, кстати, в итоге приходят к методологии «Programming, Motherfucker!» (http://programming-motherfucker.com/).
И это печально, ведь заставить покер работать очень просто. Все что нужно сделать это еще до планирования решить:
- Что в точности должно быть сделано.
- Как в точности это должно быть сделано.
К планированию задача должна быть полностью декомпозирована, вы должны в точности представлять каждую строчку кода, которая появится или изменится, у вас должен быть ответ на любой возникающий вопрос. Этот ответ должен быть немедленно зафиксирован в задаче. Если на вопрос не может быть получен ответ, то соответствующая задача должна быть незамедлительно снята с итерации.
Это необходимое и достаточное условие для эффективного планирования. Это требует ощутимого количества работы одного человека для проработки и декомпозиции задачи, но экономит огромное количество сил и времени всей команды при планировании и на итерации.
Возможно, вам будет сложно настолько глубоко владеть каждой задачей, которая должна быть взята в итерацию, но ведь у вас есть пять разработчиков! Они отлично справятся с этой работой, если каждому поручить проработать по задаче.
А есть ли в вашей команде Planning Poker? Как он работает? Какие задачи вы с помощью него решаете?
На самом деле оценка задачи разработчиком на планировании совершенно не говорит об объеме или сроках выполнения задачи. Она говорит о том, насколько точно программист понимает, что предстоит сделать.
- 1-2. Программист точно знает, какие строчки и как нужно поправить. 1 – мало строчек, 2 – много строчек.
- 2-3. Программист точно знает, где поставить брейкпоинт, если речь идет о баге, и в каком коде поковыряться, если речь идет о фиче, чтобы свести к предыдущему пункту.
- 5-8. Программист не знает, что нужно сделать, чувствует, подводные камни, но не теряет надежу, что решение может быть найдено за разумное время в пару днейJ
- 13 и выше. Песец. Задача будет сделана, только если вам сильно повезет.
Безусловно, понимание программистом задачи сильно коррелирует со сроком её выполнения, но спокойно вы себя можете чувствовать, только если все подзадачи имеют оценки не выше 3.
