Введение. Обзор

1.2 Принципы

Оставшаяся часть книги исходит из того, что следующие восемь принципов (три из которых являются частичными принципами) составляют agile канон.

Эти принципы следуют из пяти "общих предпосылок", рассмотренных в предыдущем параграфе, преобразуя предпосылки в фактические предписания.

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

1.2.1 Организационные принципы

Пять принципов руководят организацией и управлением agile проектов.

1. Разработка является ориентированной на потребителя^{7Ориентация на пользователя не является новинкой, придуманной agile. Этот совет можно найти у многих авторов. Тони Хоар в своей Тьюринговской лекции описывает неудачу в разработке второй версии компилятора из-за перегрузки ее избыточной функциональностью. Совет, который он дает – "Идите в люди!" (изучайте реальные потребности пользователей).}. Цель разработки – поставка потребителю продукта с наилучшим ROI. Представители потребителей должны включаться в проект, их роль одна из важных ролей в команде разработчиков.
2. Команда является самоорганизующейся. Решение зависит от специфики решаемых задач. Как следствие принципа важности команды – резкое ограничение прав менеджера проекта. Имеет место скрытая социологическая тенденция – увеличение значимости программистов и консультантов за счет уменьшения обязанностей менеджеров.
3. Развитие проекта идет устойчивым темпом. Благодаря жесткому графику отсутствуют так называемые "смертельные марши", когда для выдержки контрольного срока начинается авральная работа днем и ночью. "Устойчивость" требует, чтобы работе отводилось разумное время, сохраняя вечера и уикэнды для отдыха.
4. Разработка agile в трех отношениях является минималистской:
   • создаются только основные функции (минимальная функциональность);
   • строится только то, что запрашивается, исключая работы для будущего повторного использования и расширений (минимальный продукт);
   • создаются только два вида продуктов – программы и тесты, исключая все, что не поставляется потребителю, и избавляясь тем самым от излишних трат (минимальные артефакты).
5. Разработка должна допускать изменения. В программных проектах требования не могут быть определены в начале разработки. Потребности выявляются в процессе разработки. В ходе испытаний промежуточных версий как у потребителей, так и у самих разработчиков возникает понимание необходимости новых свойств или изменения существующих свойств системы. Такие изменения рассматриваются как нормальная часть процесса разработки.

1.2.2 Технические принципы

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

Первенство тестов представляет воплощение подхода к достижению качества. Этот принцип имеет два следствия. Поскольку оба следствия важны, их можно рассматривать как частичные принципы:

• Никакая новая разработка не может начаться, пока не пройдут все тесты. Это правило отражает строгое стремление к качеству и отказ от всяческих компромиссов при обнаружении ошибок (багов).
• Вначале тесты. Этот принцип, веденный в ХP (экс-тремальном программировании), предписывает, что никакой код не может быть написан до того, как для него не созданы тесты. При таком подходе тесты представляют замену спецификаций и требований. Глава об agile практиках описывает тест-ориентированный подход к разработке ПО.

Последний принцип – использование сценариев для определения функциональности – составляет еще одну часть замены требований. Сценарий представляет описание варианта взаимодействия пользователя с системой. Например, при проектировании системы для мобильных телефонов описание сценария разговора по телефону начинается от момента вызова абонента до момента разъединения. "Сценарий" не является общепринятым agile термином, но покрывает такие agile понятия, как варианты использования (use cases) и пользовательские истории (user stories), отличающиеся уровнем гранулярности. Вариант использования – это описание законченного взаимодействия, а пользовательская история – более мелкая единица по функциональности. Сценарии приходят от потребителей и определяют фундаментальную функциональность системы с их точки зрения. Собрание сценариев, в частности, пользовательских историй, отличается от традиционных требований по двум фундаментальным аспектам:

• Сценарий – это просто пример. В отличие от требований он не может претендовать на полноту. Даже большое множество сценариев не может достичь этой цели. Точно так же никакое множество тестов не может заменить спецификацию.
• В agile разработке требования не собираются в начале разработки, но появляются по ее ходу. Заметьте, это различие не столь абсолютно, как представляется в agile литературе, ссылающейся на модель "водопада", существующую лишь в воображении авторов подобной литературы. Фактически же традиционный подход программной инженерии предусматривает жизненный цикл для требований, предусматривающих возможность их изменений на каждом шаге цикла.

В "Принципы agile" организационные и технические принципы agile будут обсуждаться в деталях.

1.3 Роли

Методы agile определяют роли различных действующих лиц (actors) в программных проектах.

Первая и наиболее важная роль отводится команде – самоорганизующейся группе разработчиков и других членов команды (таких как представители потребителей). Команда ответственна за распределение задач между членами команды.

Scrum идет дальше в определении новых ролей с обязанностями традиционных менеджеров. Определение свойств программного продукта возлагается на владельца продукта (product owner). Он получает право изменять свойства продукта при одном важном ограничении, никакие изменения не допускаются во время итерации (спринт в Scrum). Менеджерские обязанности – консультанта, тренера, ментора, гуру, администратора – возлагаются на Scrum-мастера, который не может быть одновременно владельцем продукта.

Общим для всех agile методов является включение такой роли, как потребитель^{8Общий термин "потребитель" подразумевает как возможных заказчиков продукта, так и обычных пользователей, в интересах которых создается продукт. Если есть заказчики, то их представитель включается в команду. Если у проекта нет заказчиков, то всегда можно найти будущих клиентов, готовых принять участие в процессе разработки продукта.} продукта (customer). Появление этой роли является частью отрицания необходимости документа требований и общего недоверия к документам, характерного для agile. Как гласит Манифест, "сотрудничество с заказчиком важнее согласования условий контракта". Вместо фиксации требований на бумаге проект непосредственно включает представителей потребителей продукта.

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