Agile – Иллюзии и Реальность
May 10, 2008 | Posted by Denis under Методологии, Статьи |
В понимании и применении ключевых принципов гибкой разработки существуют серьезные проблемные зоны. Мы их рассмотрим и увидим, что реалистичное видение принципов позволяет получить действительные преимущества гибкой разработки. Мы обсудим, как избежать риска погони за невозможным и направить усилия в направление реальных результатов.
1. Самоорганизованная команда. Буквальное понимание этого принципа – верный путь к нервному расстройству. Любая команда нуждается в лидерстве и управлении. Это необходимо для реализации двух основных целей: эффективного решения локальных проблем сегодня и успешного достижения глобальной задачи в широком масштабе.
- Почти все члены команды являются носителями адекватного видения того, что они делают;
- Почти все хорошо мотивированны;
- Почти все возможные управленческие функции (управление другими и собой) по максимуму делегированы членам команды;
- Хотя бы раз в месяц они добиваются успеха вместе;
- Посидеть с кем-то в паре и помочь ему с решением задачи почти так же важно, как и решать свою задачу.
2. Бизнес и Инжиниринг работают как одно целое. Это случается очень редко. Часто между Бизнесом и Разработчиками царит непонимание, недоверие, дефенсивность. Опять-таки, “одно целое” следует понимать как иллюзию. Но, как и в предыдущем случае, имеет огромный смысл к этому идеалу приблизиться. Это с позиции Инжиниринга возможно, если:
- Если у команды нет видения, то она добивается его у Бизнеса. Часто Бизнес сам страдает близорукостью и не может или не считает нужным четко определять, к каким глобальным целям двигаться. Тогда Инжиниринг не просто требует видения, но принимает участие в его формировании, предлагая к рассмотрению не только вопросы, но и решения.
- Инжиниринг исходит из того, что существует только Win-Win исход для них и Бизнеса. Даже когда Бизнес, по мнению разработчиков, ведет себя похабно, поведение команды стабильно конструктивное.
- Инжиниринг делает все, чтобы идеи Бизнеса сработали в разрабатываемом продукте/сервисе и из этого постепенно зарождается доверие между Бизнесом и командой по Разработке.
3. Приветствуются любые изменения требований, в частности самые поздние. Вот это “самые поздние” – неприятный и опасный момент. Правильное понимание этого принципа покоится в одном склепе с видением различия между исходом итерации и релиза. Да, действительно, при гибкой разработке команда способна делать частые релизы с продакшн-качеством.
Также правильно и то, что каждая итерация заканчивается рабочим билдом продукта, а не спецификациями, дизайном или еще чем-то. Но “рабочий билд” и “релиз-версия” – это разные вещи. Вкратце, отличает их качество. Для того, чтобы последний релиз-кандидат стал полноценной релиз-версией, необходимо время на стабилизацию. К примеру, вся однонедельная итерация посвящена стабилизации версии – фиксание багов, дополнительное ручное тестирование, финальное тестирование конфигураций и деплоймента и т д.
Если времени на это не будет, то на выходе получится просто “рабочий билд” и ваши пользователи найдут много дефектов. Правильное понимание принципа таково – изменение требований является необходимой реальностью, при которой обе стороны (Бизнес и Разработка) имеют возможность вносить изменения на протяжении всего релиза, кроме периода стабилизации (последние 10%-15% графика релиза). Речь идет не только о серьезных изменениях логики системы – жизнь изобилует примерами, когда за несколько дней до релиза Бизнес присылает 50-70 безобидных изменений (там текст поменять, там выравнивание переорганизовать и т.д.) и полностью съедает время на стабилизацию.
Примеры и обсуждение:
– Видение, необходимо для “самоорганизации” как воздух. Организовать можно только для достижения очевидной цели. В противном случае вся автономная активность членов команды будет бессмысленной. Под видением я понимаю общую картину всех релевантных фактов связанных с разрабатываемым продуктом, компанией, стейкхолдерами. Важно понимать, что это видение само по себе у команды не появится. Нужно проводить достаточно времени, общаясь со стейкхолдерами, чтобы понимать ситуацию достаточно глубоко. Особенно важно для случая, когда Продуктовая команда и команда Разработчиков разделены географически (тем более, при различных временных поясах). Когда следующий релиз? Какое значение для компании имеют определенные фичи? Откуда берутся приоритеты? Как они соотносятся с миссией компании? Подобные вопросы очень важны и их понимание критично для успешной разработки и развития команды. Но стандартным вопросником вроде этого ситуацию не опишешь.
Нужен неформальный подход. На одном из проектов мы очень долго и безуспешно работали с продуктовой командой в Америке по определению UI-части следующей версии продукта, которая должна была кардинально отличаться от текущей. Планирование релиза непонятно затягивалось и изрядно нервировало. В конце концов оказалось, что Продуктовая команда и не собиралась в ближайшее время финализировать этот план, так как разработкой UI-концепции должен был заняться новый человек, естественно, только после выхода на работу.
– Делегация управления – одно из самых серьезных испытаний для менеджера проекта. Делегировать работу вообще – это одно. Делегировать управление значительно сложнее. Но это: делает управление намного эффективнее – больше точек зрения и углов, а проект один. А также служит серьезным мотивационным моментом. Не стоит бояться экспериментировать и нужно культивировать неформальное лидерство в команде. Причем, при ситуативном проявлении лидерства следует его всячески поддерживать, развивать и корректировать в нужном направлении. Пример из жизни: человек проявляет сильное лидерство в плане бизнес-анализа – видит “насквозь” требования, эффективно шлифует их с продуктовой командой, очень хорошо эстимирует разработку. Но никогда не хотел браться за полновесное управление проектом, поскольку не видит себя эффективным менеджером именно в плане управления людьми. Когда в команде много неформальных лидеров: бизнес-аналитиков, тестировщиков, архитекторов, конфиг-менеджеров и т д – это очень близко к идеалу “самоорганизации”.
– Много воды утекло с того момента, когда я познакомился с Дином Леффингуэлом и начал работать на его проекте. Он решил поэкспериментировать с однонедельными итерациями, поскольку видел в этом потенциальные плюсы. Подход оказался удивительно эффективным. Много точек для принятия решений, изменения тактических целей и т д. Но в отношении развития команды – просто супер! Каждую неделю (в случае успеха) команда выкатывает функционирующий билд с новым функционалом. Каждую неделю – маленькая победа, достигнутая вместе. Через определенное количество итераций это входит в привычку. Кстати, на основных проектных задачах ограничиваться не стоит – можно играть в футбол, Unreal Tournament – вообще что угодно. Важно только чувствовать как все вместе добиваются результата.
– “Изменения последнего дня”. Это когда в течении последней итерации перед релизом приходит длинный экселевский чек-лист с необходимыми изменениями. Все нужно немножко подправить во многих местах. Или прямо перед релизом оказывается, что запланированный UI не является интуитивно понятным (как может показать запоздалый user testing) и все откладывается на две недели. Есть много примеров, о которых я знаю и от коллег. Общая черта – как ни крути, а Продакт тим живет своей жизнью, а Инжиниринг – своей. В этом ничего фатального нет, важно только это хорошо понимать и стараться максимально сблизить такт тех и других.
Подведем итог.
Гибкая разработка очень эффективна и способна принести большие преимущества компаниям, которые ее внедряют, а также в частности разработчикам, продуктовой команде и маркетингу. Но эффективность реальна только в случае, если ставятся адекватные цели и за основу берутся реалистичные предпосылки:
– Члены команды хорошо мотивированы и обладают максимально возможными и применимыми полномочиями;
– Бизнес и Инжиниринг постоянно активно синхронизируют планы, прилагая усилия для лучшего взаимопонимания и доверия на ежедневной основе;
– Изменения требований неизбежны, но во время финального аккорда в симфонии дирижер уже ничего не делает – весь оркестр готовится принять овации.