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

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

Так вот, что по факту работает, а что нет и при каких условиях (взял иерархию принципов экстремального программирования из wiki):
1. Разработка через тестирование (Test driven development)
(сначала пишется тест, который изначально не проходит (так как логики, которую он должен проверять, ещё просто не существует), затем реализуется логика, необходимая для того, чтобы тест прошел)
Если рассматривать ситуацию, когда и тесты, и основной код пишет один и тот же человек, то это очень большая проблема, так как большинство разработчиков не только не обучена навыкам тестирования, но и категорически сопротивляется возложению на себя данных обязанностей. Если же брать под эти функции отдельную группу специалистов, то по мне, это уже выходит за рамки agile-концепции, и за счет размазывания принципов бюджетирования, взятых за основу разработки в DSDM, и за счет, по сути, распараллеливания процесса разработки (отдельно для разработчиков тестов, отдельно для основной команды), что замедляет разработку в целом.
Лично я старался все-таки возложить обязанности по тестированию (пусть не предварительному, но по факту окончания разработки отдельно взятого модуля) на разработчиков. А это уже переходный этап к написанию ими же предварительных unit-тестов для собственного кода.
Очевидный плюс во всем этом – команда избавляется от необходимости содержать (как в материальном, так и в моральном принципе) группу тестирования, а это и “+” к бюджету, и “+” к скорости разработки
Значимости минусов определяется аудиторией продукта: лично для меня несколько выросшее в релизах количество ошибок было допустимо, так как конечными пользователями были сотрудники банка, негатив со стороны которых не вредил бизнесу. Если же конечная аудитория – массовый публичный пользователей, то тут следует сто раз подумать, прежде чем отказываться от полноценного тестирования…

2. Игра в планирование (Planning game)
(основная цель игры в планирование — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими)
По сути, в той сфере (и той компании), в которой я работал, это был единственный выход из ситуации. И тарифы отдельных продуктов, и сами продукты в банках меняются так часто, что предусмотреть все заранее просто не возможно. Собственно, почему я понял, что мой процесс не полностью соответствовал DSDM-методологии, это потому что в DSDM есть очень полезный этап Исследования экономической целесообразности, который в отдельно взятой конкретной организации не работал. Задачи были целиком и полностью направлены на продажи и ставились в формате “я хочу”, при этом мнение даже коллег по бизнесу из смежных подразделений, например из рисков, редко учитывалось.
Однако если брать более адекватную ситуацию, то я бы обязательно включил в разработку этап, описанный в описанный в DSDM: (на данном этапе анализируются основные экономические и технологические характеристики. Происходит собрание экспертов, на котором обсуждаются наиболее важные стороны системы и принимается решение о приоритетах в разработке. На этом этапе разрабатываются список основных требований, описание сферы коммерческой деятельности, описание архитектуры системы и примерный план создания прототипов). Как минимум в 50% случаев это позволяет отсечь проекты, которые просто не будут использоваться в работе (а у нас были и те, которые разрабатывались 2-3 месяца, но также в последствие не использовались заказчиком).
+ я бы этот пункт дополнил собственным наблюдением: даже если в работы проводятся по приблизительному плану, то архитектуру системы необходимо делать максимально открытой в расчете на перспективные планы на 2-3 года вперед (как пример, если заранее известно, что через 2-3 года проект будет выводиться на международные рынки и/или расширять специализацию, например, начав продавать помимо чайников, еще и детскую одежду, то не стоит сообщения пользователям на русском языке прописывать непосредственно в коде, а в базе данных лучше изначально делить таблицы связей не просто на товары-> поставщики, а сразу на товары->типы товаров->поставщики)

3. Заказчик всегда рядом (Whole team, Onsite customer)
(XP: заказчик должен быть всё время на связи и доступен для вопросов
DSDM: вовлечение пользователя - это основа ведения эффективного проекта, где разработчики делят с пользователями рабочее пространство)

Тут дополнить нечего – абсолютно эффективный принцип.

4. Парное программирование (Pair programming)
(парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего. При необходимости клавиатура свободно передается от одного к другому)
Один большой минус – где взять столько сотрудников? (опять же в рамках ограниченного бюджета DSDM не применимо).
С другой стороны, если брать в пример спортивное программирование, то там зачастую участвуют команды не из 2-х, а даже из 3-х человек (больше – вредно). Так что если есть ресурсы, то данный принцип позволяет увеличить и скорость, и качество кода до максимально возможного.

5. Непрерывная интеграция (Continuous Integration), Частые небольшие релизы (Small Releases)
(XP: интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают… версии (releases) продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени. При этом каждая версия должна быть достаточно осмысленной с точки зрения полезности для бизнеса. Чем раньше мы выпустим первую рабочую версию продукта, тем раньше заказчик начнет получать за счёт неё дополнительную прибыль.
DSDM: частая поставка версий результата, с учётом такого правила, что «поставить что-то хорошее раньше - это всегда лучше, чем поставить всё идеально сделанное в конце»… Главный критерий как можно более быстрая поставка программного обеспечения, которая удовлетворяет текущим потребностям рынка. Но в то же время поставка продукта, который удовлетворяет потребностям рынка, менее важно, чем решение критических проблем в функционале продукта.)

Данный принцип - основа основ обеих методик. Его применение оправдано не только скоростью, но и рядом “побочных плюсов”:
- разработчики сразу получают обратную связь на свои ошибки и справляют их на порядок быстрее, так как “код еще держится в голове”
- незакрытые задачи не висели как дамоклов меч, и разработчик работал не в режиме опасения “закроется/не закроется”, а в режиме ожидания “дайте новую задачу, я ее сразу закрою и буду снова заниматься своими делами”
- бизнес сразу видит первичный результат и начинает не только тестировать его, но и запускать в работу, получая первые бизнес-результаты. Во многих случаях после первого прототипа бизнес просто прекращает разработку, так как видит, что бизнес-результаты не соответствуют первичной аналитике по продукту в целом. В иных методиках группа разработки потратила бы несколько месяцев пустую, а так они тратят всего от нескольких дней, до недели
Лично у нас было до 5-ти релизов в день и не меньше 10-ти в неделю, при этом за последние 3 месяца устойчивость системы составила 100%. Достигалось это за счет того, что любой критичный баг, если он и был, просто откатывался до предыдущей стабильной версии, тут же правился, и через 15 минут выкатывался в очередной релиз. При этом время реакции на появление бага составляло менее минуты (благодаря системе контроля версий), так что рядовой пользователь за это время даже страницу на сайте не успевал обновить и что либо заметить.

6. Рефакторинг (Design Improvement, Refactor), Стандарт кодирования (Coding standard or Coding conventions)
(однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан... необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, — вся команда работает унифицированно, как один человек)
Этим так или иначе занимается любой программист. Каждый всегда будет думать, что его код лучше и/или оптимальней. Так что лучше это “легализовать”, чем потом разбираться кто сколько времени потратил на “лишнюю работу”. Принятые стандарты кодирования позволяют экономить время именно на рефакторинге.
Отмечу, что в рамках нашего проекта это было не принципиально, так как по возможности каждый участник работал преимущественно со своим участком кода, при этом каждый случай доработки чужого кода доказывал этот принцип – каждый раз приходилось буквально “уговаривать” разработчика лезть в чужой код и не править его слишком сильно. Уже сейчас я понимаю, что потраченное время на “уговоры” компенсировало бы время на разработку стандартов кода.

7. Простота проектирования (Simple design)
(в каждый момент времени мы пытаемся использовать наиболее простой дизайн, который подходит для решения текущей задачи)
Доказано неоднократно, что для бизнеса дизайн важен только если он является продающим фактором, а во всех остальных случаях, например, когда автоматизируешь отчетность, делать программу красивее Excel, в котором раньше работал бизнес, смысла нет, так как первичная задача - это чтобы правильно считало цифры.
Более того, если уж брать задачи именно по дизайну, то они как никакие другие будут подвергаться изменениям на пост-релизном этапе, так что если и просят функциональный и хоть чуть-чуть красивый дизайн, то достаточно взять первую же версию, пришедшую в голову - это касается и цвета, и шрифтов, и всех подобных мелочей, ибо "мелочи" - это основное, к чему любит придираться заказчик. На моей памяти цвет(!) и название выводимых на экран статусов состояния заявки (одна из сущностей в системе) менялся раз 5, причем каждый раз это было коллективное многочасовое(!) обсуждение чуть ли не на уровне топ-менеджмента организации...

8. Метафора системы (System metaphor)
(метафора системы - это аналог того, что в большинстве методик называется архитектурой. Метафора системы дает команде представление о том, каким образом система работает в настоящее время, в каких местах добавляются новые компоненты и какую форму они должны принять)
Данный принцип я не рискнул отдать на откуп разработчикам и все архитектурные решения оставлял за собой, как за главным “архитектором” системы.
Сама логика - дополнять систему только в рамках ее архитектуры, более чем правильная, так как результат, когда система разрабатывалась без этого принципа мы получили в первой версии нашего продукта. Она работала, только спустя определенное время полностью перестала быть управляемой как с точки зрения разработки (просто потому что время разработки увеличилось на несколько порядков), так и с точки зрения понимания, а что еще эта система сможет или не сможет, т.е. где ее предел. Полностью переписанная архитектура позволила на том же этапе разработке (по времени – спустя 3-4 месяца) сохранить и скорость, и прозрачность характеристик системы.
Но как я уже сказал, отдавать этот функционал на откуп всей команде или отдельному человеку – этот вопрос я решил не в пользу команды.

9. Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
(коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы)
Очень важный пункт для понимания всех принципов в целом. Agile-разработка возможна, по моему мнению, только когда соблюдается этот пункт. В иных случаях все выстроенные процессы разбиваются о трудовой кодекс РФ, позволяющий сотрудникам ходить в отпуск, увольняться, болеть и т.п.
Другой важный момент – ответственность за весь код (в частности, необходимость искать и исправлять ошибки не только в своем, но ив чужом коде), исключает влияния личностных отношений в коллективе на разработку.
Однако есть проблемы, мешающие внедрению этого механизма, и в web-разработке, обычно разделенной на клиентскую и серверную часть, написанную, соответственно, на JS и PHP, это проявляется в большей мере. Универсализм, в данном случае, возможен, но многие разработчики не готовы становиться универсалами.
При этом если обходить данную проблему, например пытаясь писать и клиента и сервер на одном “родном” для разработчика языке, то надо быть очень аккуратным в выборе методов. Заменить сервер, например, на Node.js – это приемлемо, перенести валидацию данных с клиента на сервер, написанный на PHP - тоже, но вот переписать весь клиент на PHP – это чревато возникновением переписывания всей архитектуры в самое ближайшее время…

Из того что есть есть в DSDM, но нет я XP я бы отметил:
- разграничение на функциональный и конструктивный прототипы
Очень полезно для предотвращения лишней работы. По опыту в конкретной организации могу сказать, что разработку функционального прототипа может занимать 2-3 дня, разработка конструктивного прототипа – 2-3 месяца. За год разработки у меня было как минимум 2 случая, когда два конструктивных прототипа просто выбрасывались после 1-го дня использования – просто закрывался за неэффективностью бизнес-процесс как таковой. После второго случая я всю разработку перевел на обязательность создания функциональных прототипов.
- любые изменения во время разработки – обратимы
Не знаю, почему это не описано в XP, но обратимость в рамках agile-разработки – это явление штатное, так что к нему надо быть всегда готовым. Я лично всегда добивался этого делением проекта на модули, каждый новый из которых разрабатывается привязываясь к функционалу уже имеющихся, но не изменяя его (функционал). Тем самым появляется возможность отключить отдельный модуль, не отключая остальной функционал системы.
Если же что-то и требуется поменять, например, перевести разработку на другую базу данных, то я всегда категорически запрещал удалять старый код, либо просто комментируя его, либо вынося в конструкцию if(mysql==’enable’) then … else … По моей статистике вероятность обратимости изменений в agile разработки достигает 20-30%