Книга: Постигая Agile

Постоянное совершенствование проекта и команды

Постоянное совершенствование проекта и команды

Один из основных принципов проектирования не только программного обеспечения, но и во всем инженерном деле – это KISS[23] («чем проще, тем лучше»). Agile-команда живет по этому принципу, когда планирует проект, разрабатывает программное обеспечение и движется вперед.

Часто бывает довольно сложно добавить код в существующий проект, особенно если дописываемый код зависит от уже существующего. Зависимости между системами, объектами, услугами и прочим делают код более сложным и трудно изменяемым: зависимости повышают вероятность того, что одно изменение может привести к каскадным изменениям в другой части системы, которые, в свою очередь, вызовут изменения в третьей, создавая эффект домино с возрастающей сложностью для каждого изменения. При помощи итераций и создания минимальной документации в начале проекта команда может избежать поставки ненужного программного обеспечения.

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

Это понятная реакция, ведь для многих проектов вне сферы разработки программного обеспечения такой подход не имеет смысла. Нередко программисты, только что вступившие в сферу agile-разработки, выдвигают возражения такого рода: «Если подрядчик ремонтирует мой дом, то первым делом я хочу видеть подробные чертежи. Я не допущу, чтобы, второпях поговорив со мной, он начал ломать стены».

Этот аргумент имеет смысл в ситуации с ремонтом дома. Дело в том, что в этом случае нет ничего более разрушительного, чем взять кувалду и сломать стену. Но программные проекты отличаются от домов и прочих физических объектов. Удаление кода не несет глобальных разрушений, потому что вы легко можете восстановить его из системы управления версиями. Самая разрушительная вещь для вашего проекта – это создать новый код, а затем другой, зависимый от первого, и так далее, как выстраивают костяшки домино. Получится до боли знакомый эффект каскадных изменений… И в итоге вы останетесь с неремонтопригодным, запутанным спагетти-кодом.

Максимальное увеличение объема работы не поможет избежать этой путаницы. Лучше создавать систему без большого количества зависимостей и ненужного кода. Наиболее эффективный способ создания максимально полезного и ценного программного обеспечения – это работа с клиентами и заинтересованными сторонами. Если функция не является ценной, то в долгосрочной перспективе для компании дешевле не создавать ее вовсе. Потому что расходы на содержание дополнительного кода выше, чем стоимость самой разработки. Когда команды пишут код, они могут хранить свои несложные проекты программного обеспечения, создавая дизайн ПО на базе небольших автономных единиц (например, классов, модулей, сервисов и т. д.), которые делают только одну вещь – помогают избежать эффекта домино[24].

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

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

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

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

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

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

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

Оглавление книги