Постигая Agile

Принцип № 11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд

Слишком сложные конструкции характерны для команд, которые уделяют чересчур много внимания планированию. Неудивительно, если задуматься об этом. Вернемся к главе 2 и рассмотрим картину водопадного процесса. В водопадной методологии выделяют целые этапы, посвященные разработке требований, дизайну и архитектуре. Наиболее тщательно выполненные работы на этапе дизайна и архитектуры предполагают создание самой удивительной структуры, которую команда только может придумать. Работающие таким образом интуитивно воспринимают небольшое количество требований и простой дизайн как недоработанный проект. Стоит ли удивляться, что они возвращаются с большим списком требований и сложной архитектурой? Конечно, нет, потому что это именно то, что они просят сделать. Ведь им известно: в водопадном подходе каждый этап должен быть подкреплен соответствующей документацией.

Но самоорганизующаяся команда не имеет явных требований или фаз разработки. Ее члены совместными усилиями планируют проект (вместо того чтобы полагаться на одного человека, «владельца» плана) и регулярно его пересматривают. Такие команды, как правило, разбивают проект на пользовательские истории или другие мелкие части и начинают работать с наиболее ценными для компании частями. Только после этого подходит очередь подробных требований, дизайна и архитектуры.

Это делает работу традиционного архитектора программного обеспечения сложнее, но и приятнее. Обычно программный архитектор сидит в кабинете с закрытой дверью и абстрактно рассуждает о проблемах, которые нужно решать. Конечно, бывают исключения, но для них типично отдаляться от повседневной работы остальной группы.

В agile-команде каждый несет свою долю ответственности за архитектуру. Старший архитектор программного обеспечения или дизайнер, как и прежде, играет важную роль, но при этом не может работать в изоляции. В самом деле, когда команда создает программное обеспечение по частям, начиная с наиболее ценных частей, работа архитектора становится сложнее (но часто и интереснее). Вместо формирования в начале проекта одной большой конструкции, охватывающей все требования, agile-архитекторы используют инкрементальный дизайн, включающий в себя методы разработки, позволяющие не только создавать полную систему, но и легко вносить в нее изменения.

Принцип № 12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы

Команда не может быть гибкой, если не совершенствует способы создания программного обеспечения. Agile-команды постоянно занимаются контролем и адаптацией – они следят за тем, как работают их проекты, и используют эти знания для улучшений в будущем. И делают это не только в конце проекта – на ежедневных встречах члены команды ищут пути изменения и меняют текущую работу, если в этом есть необходимость[25]. Вам не должно быть неловко признаваться себе и коллегам в том, что получается, а что нет. Это особенно важно для тех, кто только начинает заниматься гибкой разработкой. Единственный способ стать более квалифицированным специалистом – это постоянно оценивать уже сделанное, чтобы понять, насколько полезно ваше участие в команде, а также придумать план еще лучше.

Почти все согласны, что это полезное и нужное дело. Хотя анализ сделанного – это то, что многие команды планируют, но не все выполняют. Действительно, поначалу это не очень удобно, ведь нужно отслеживать ошибки других членов команды, а затем публично указать на них. Не все к этому готовы. Но со временем атмосфера в группе меняется, и людям все проще говорить на эти темы. Все начинают понимать, что это наиболее конструктивный путь.

Еще одна причина, по которой команды не анализируют случившееся, – в недостатке времени. Бывает, что оно запланировано, но желание думать о сделанном пропадает, как только появляется необходимость дать старт новому проекту. Команды, начинающие новый проект с резервирования времени для общей встречи в конце каждой итерации и проекта в целом, с большей вероятностью проведут обзор сделанного, оценят его и придумают план улучшения. Это помогает учиться на собственном опыте и становиться эффективнее.