Планирование на перспективу в Agile
Для каждого уровня планирования, описанных ранее, жизненно необходимо, чтобы эти усилия не были единичными событиями, а, скорее, постоянной работой, такой же частью проекта, как написание кода и тестирование. Мы должны постоянно смотреть вперед, систематизировать полученные знания и быть готовыми максимизировать ценность, которую хотим реализовать. Каждый тип планирования, описанный ранее, должен выполняться на постоянной основе теми, кто отвечает за каждый уровень планирования. К примеру, во время каждой итерации, в ответственность некоторых членов команды (обычно аналитиков и скрам-мастеров) входит определить, в достаточной ли степени детализирована работа, которая должна быть проделана в следующей итерации. Здесь мы не расставляем приоритеты среди историй; мы, скорее, решаем, достаточно ли знает команда, чтобы начать работу над данной историей или нужна дополнительная аналитическая работа. Тут нужен тот же подход, что и при написании историй на этапе планирования релиза: написать историю, расставить приоритеты, оценить и т.д. Но нам также необходимо убедиться, что для каждой истории разработаны критерии приемки. Я часто вижу, что очень полезно, чтобы аналитик работал в плотном контакте с тестировщиком при разработке критериев приемки - они помогают друг другу, и, кроме того, это дает контролеру качества представление, что именно предстоит, позволяя начать разработку - или, по крайней мере, продумывание - планов и методов тестирования для новых историй. Такое планирование должно происходить на каждой итерации в качестве нормальной части повседневной работы. Таким же образом во время каждого релиза некая группа людей должна заглядывать наперед на следующий релиз, выявляя новые требования, изменения курса и технологии и расставляя приоритеты среди вновь обнаруженного, чтобы максимизировать ценность продукта. И, наконец, пока проект еще в разработке, мы должны рассмотреть, какие возможности открываются для бизнеса (или какие недостатки бизнеса он выявляет). Мы должны начать планирование следующего проекта, пока этот проект еще в процессе. Ежедневные летучки - это возможность для всей команды собраться вместе и убедиться, что все хорошо (или обнаружить проблемы). Вместо того, чтобы фокусироваться на сделанном вчера (один из трех вопросов типичной «летучки»), я предпочитаю, чтобы члены команды рассказали остальным, что собираются сегодня сделать и попросили помощи, если это необходимо. Это позволяет всем остальным быстро определить, нет ли у них препятствий в работе и решить, могут ли они внести какую-то лепту в усилия других членов команды. Вы можете использовать тот же подход, чтобы масштабировать Agile применительно к крупным задачам с несколькими командами, множеством проектов (или рабочих потоков) и, возможно, даже разными часовыми поясами. Без планирования вы не сможете масштабировать. К несчастью, многие считают, что если вы масштабируете, то планировать не можете. Звучит так, как будто придется проделать кучу работы. Ну да, так и есть. Планирование требует дисциплины, и это показатель успешности проекта - не единственный показатель, но существенный. Вам нужно иметь способность фокусироваться на малом количестве задач и делать их хорошо, нежели применять более традиционный подход - планировать все подряд и быть рабом плана. Балансировать между потребностью знать лишь необходимое и желанием знать все (чего никогда не бывает) сложно, но если вы следуете принципам, описанным выше, то я знаю, что вы готовы к хорошему старту. -- Об авторе: Пол является экспертом и в гибких, и в традиционных методах разработки, а также в их влиянии на организационную структуру, но его главный приоритет - это создание высокоценного ПО, решающего проблемы бизнеса или имеющего преимущества на рынке. Это позволило ему стать лидером во внедрении новых подходов в разработке ПО, не теряя при этом из вида настоящих причин и потребностей этого внедрения - того, что устаревшие методы больше не работают, а более эффективные принципы и практики жизненно необходимы бизнесу в долгосрочной перспективе. Этот прагматичный и эффективный подход привел к тому, что Пол постоянно востребован большими и малыми IT-компаниями и в США, и в Европе, где он возглавляет формирование и тренинг команд разработки ПО, работая с руководителями над пониманием их перехода к более гибкой модели руководства и позволяя географически разрозненным командам укрепить сотрудничество и качество работы. Оригинал: http://www.agileconnection.com/print/article/five-levels-agile-planning Перевод: Александра Родсет |
Сертифицированные курсыАндрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.
Еще интересные статьи на эту тему:
|
