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