Существует старое правило управления проектами, которое гласит: «план работы – рабочий план». Если вы работаете по неправильному плану, то создадите неправильный продукт. Именно поэтому командам нужно постоянно следить за изменениями и быть уверенными, что они четко реагируют на них, если эти изменения нужны пользователям или процессу создания ПО. Когда ситуация меняется, проекту нужен новый план.
Сопротивление переменам – не редкость среди тех, кто создает план, потому что изменение плана требует дополнительных усилий. Возможно, было вложено много усилий в разбивку проекта на пакеты работ и оценку каждого этапа. Изменение в этом случае может потребовать от менеджера проекта переделки всей работы. И если для него следование первоначальному плану превыше готовности меняться, то ему придется и дальше проявлять упорство. Это делает работу над проектом более гладкой, но если изменения действительно необходимы, то это будет гораздо труднее сделать позднее, когда работа над кодом будет в самом разгаре.
Доска задач – хороший метод, помогающий команде правильно реагировать на изменения. Каждый элемент работы (как правило, пользовательская история) написан на карточке и прикреплен к доске – вроде той, которую Джоанна использовала для проекта «Музыкальный автомат». Все задачи обычно распределяют по трем столбцам, размещая их в том порядке, который показывает состояние каждой из них. Доска задач может управляться при помощи компьютерной программы. Но многие команды считают наиболее эффективным использование настенной доски, потому что, стоя перед ней, можно дискутировать и перемещать истории. Такая форма общения намного продуктивнее простого разговора. Доска создана так, что любой может изменить порядок задач, и даже рекомендуется это делать. Если происходят изменения, то любой может добавить учетные карточки на доску задач, а не удалять каждое изменение при помощи единого центра управления проектом. Это помогает держать всех в курсе дела, поэтому план не устаревает.
Рис. 2.3. Agile-команды часто используют доски задач, чтобы размещать на них задачи и отслеживать прогресс. Они будут писать задачи или пользовательские истории на карточках и перемещать их по доске, отмечая прогресс. Многие команды также рисуют диаграммы на своих досках, чтобы демонстрировать прогресс
Наша команда музыкального автомата получила хорошие результаты, потому что воспользовалась некоторыми прекрасными методами и благодаря им смогла улучшить проект. Но из-за раздробленного видения члены команды не получили полной отдачи от совместной работы над усовершенствованием способа создания ПО. Существует agile-мышление, которое выходит за рамки практик, и команды, ищущие свой путь к ключевым идеям Agile, найдут лучший способ сотрудничества и взаимодействия.
Другими словами, команда, использующая agile-практики, чтобы построить рабочее программное обеспечение, и находящая ценность работы с клиентами во взаимодействии и сотрудничестве с ними, в ответ на собственные изменения получит больше от своих проектов, чем те, кто просто применяет лучшие методы планирования, программирования и ведения документации.
Джим Хайсмит удачно обобщил эту идею в своей книге Agile Project Management: Creating Innovative Projects:
Без конкретных практик принципы бесплодны, но без принципов в практиках нет жизни, нет характера, нет сердца. Великие продукты возникают у великих команд – принципиальных, которые имеют характер, у кого есть сердце, упорство и мужество[13].
Так как команды выходят за рамки простого принятия методов и становятся «принципиальными», могут ли они создавать отличные продукты?
Agile-манифест содержит общие ценности и идеи, которые делают команды эффективными.
«Люди и взаимодействие важнее процессов и инструментов» означает, что команда должна сосредоточиться на людях и прежде всего на том, как они общаются, а затем уже на инструментах и методах, которые они используют.
«Работающий программный продукт важнее исчерпывающей документации» означает, что поставка программного обеспечения, которое делает именно то, что от него нужно пользователю, значительно ценнее, чем поставка спецификации, описывающей это ПО.
«Работающий программный продукт» означает такое ПО, которое обеспечивает ценность компании.
«Сотрудничество с заказчиком важнее согласования условий контракта» означает уважительное отношение ко всем, как будто они в одной команде.
Многие эффективные agile-команды рассматривают владельца продукта в качестве члена проектной группы, с которым нужно сотрудничать, а не только вести переговоры как с клиентом или заказчиком.
«Готовность к изменениям важнее следования первоначальному плану» означает признание того, что планы становятся неточными, и поэтому главное – поставить программное обеспечение, а не только разработать план работы.
Доска задач – это инструмент agile-планирования, в котором пользовательские истории крепятся к доске и делятся на столбцы в зависимости от своего статуса в текущем проекте или итерации.
Понимание слона
Лисса Адкинс в своей книге Coaching Agile Teams[14] объясняет, как метафора может стать ценным инструментом для понимания концепции.
Метафора – это мощная вещь. Профессиональные коучи знают об этом уже давно. В самом деле, «метафора» – это основной навык, которому учат на профессиональных коуч-курсах… Коучи задают вопросы, помогающие клиентам создавать свою собственную метафору, которая одновременно должна быть глубокой и яркой. Клиенты используют метафору, чтобы прокладывать свой путь через события, происходящие в их жизни[15].
Существует полезная метафора, которая поможет получить представление о том, что значит сломанная перспектива и почему она ведет команду по наименее эффективному пути. Это история о слепых и слоне.
Чтобы определить, как выглядит слон, шестерых слепых попросили ощупать разные части тела слона и описать свои ощущения. Слепец, ощупывающий ногу, сказал, что слон похож на столб. Тот, кто ощупывал хвост, утверждал, что слон похож на веревку. Ощупывавший хобот предположил, что слон похож на дерево. А тот, кто трогал ухо, был уверен, что слон шершавый, как веер. Слепец, который трогал живот, сказал, что слон похож на стену. Трогавший бивень утверждал, что слон похож на твердую трубу.
Король объяснил им: «Все вы правы. Причина, по которой ваши мнения не совпадают, в том, что каждый ощупывал разные части слона. На самом деле слон имеет все свойства, которые вы описали»[16].
Команды, добивающиеся от гибких методологий результата «лучше-чем-ничего», зачастую способны получить достаточно хорошее программное обеспечение еще до начала применения Agile. Они надеются, что Agile поможет им сделать проект еще лучше. Суть в том, что до начала внедрения agile-методов команды уже испытывают проблемы (хотя это еще нельзя назвать серьезным кризисом программного обеспечения), которые причиняют вред проектам не сразу, но вызывают трения в команде. Это и есть «раздробленное видение»: разработчики думают только о разработке, проектные менеджеры – лишь об управлении проектом, они пишут код и не стараются разрушить стену непонимания, отделяющую их от клиента, который думает только о бизнесе.
Все заняты мыслями о собственной работе над проектом настолько сильно, что используют такую фразу, как «перебросить соседу через забор», которая явно разделяет команду и уничтожает сотрудничество. Если каждый думает исключительно о собственной задаче и мало коммуницирует с другими членами команды, то все работают по отдельности, а не как единое целое.
В этой ситуации очень подходит история «Слепые и слон». В раздробленном agile-видении человек использует только те методы, которые влияют на его работу (так же как каждый из слепых ощущает только одну часть слона). Например, разработчики концентрируются на разработке через тестирование, рефакторинге и автоматической сборке. Руководители проекта – на доске задач, скорости реализации проектов и выполнении графика. Бизнес-пользователи применяют планирование выпуска и пользовательские истории, чтобы получить более точное представление о том, что делает команда. Руководители используют ежедневные встречи и ретроспективы для управления и улучшения команды. Каждый хочет чем-то отличиться в проекте и видит несколько методов, позволяющих делать что-то конкретное, чтобы помочь ему в работе. (Мы рассмотрим каждый из этих методов чуть позже, так что не беспокойтесь, если вы еще не знакомы с ними.)
Внедряя эти методы по отдельности, вы, безусловно, улучшите положение вещей, потому что agile-практики действительно очень полезны. Проблема в том, что все – разработчики, менеджеры проектов, бизнес-пользователи и лидеры команды – видят проект с разных точек зрения и концентрируются только на тех методах, с которыми непосредственно связаны. Существует парадоксальный эффект («Именно я был прав!»), когда каждый человек видит лишь ту часть agile-методологий, которая влияет на его непосредственную задачу, и приходит к выводу, что Agile нужен для того, чтобы остальные придерживались его точки зрения.
Таким образом, хотя agile-«слон» и состоит из множества потрясающих практик, все же он существенно больше, чем простая сумма всех частей. И если вы отмечаете лишь отдельные методы – особенно те, которые влияют исключительно на вашу работу в проекте, – то будете видеть только небольшой кусок Agile. «Слон» Agile состоит из повседневных практик, но это гораздо больше, чем просто agile-практики.