SCRUM и архитектура
Yuriy Mayorov
Коллеги подскажите пожалуйста. Как должна рождаться архитектура ПО при
разработке методом SCRUM?
Должен ли существовать нулевой спринт, в котором она разрабатывается,
а в последующих спринтах усовершенствуется? Кто ее разрабатывает и
сколько времени на нее требуется?
В чем она заключается (документация, диаграмма классов, ядро
системы ...)? Должна ли она разрабатываться с нацеленностью расширения
в будущем и как быть если на 10 спринте выяснится, что в начале
команда что-то не заложила в архитектуру(дорогой рефакторинг)?
meowth
Я не смогу сказать, как должно быть, но я попробую рассказать, как у
нас, т.к. SCRUM.
Прежде всего, давайте отделим понятие архитектуры от дизайна. В моём
понимании, архитектура - это картина в целом: звенность, наличие/
отсутствие хранилища данных, связей/транспортов в системе и т.д. Такая
вещь действительно продумывается еще на этапе установки процесса. У
нас этим занимается вся команда, но на процесс очень сильно влияет
авторитетный архитектор (он опытный и знающий) и специалист-смежник,
знающий "бизнесовую часть" - он имеет обратную связь от того, как
работают те или иные решения. Это происходит на первом-втором спринте.
После этого начинается проработка дизайна и итерационное наращивание
функциональности приложения.
В каждой итерации ставится фокус на ту часть, которую необходимо
проработать-разработать. Смежные и ответные части других систем и
будущих модулей нашей системы в процессе прототипируются как-нибудь
легонько, но недалеко от истины, чтобы иметь возможность разрабатывать
фокус и потестировать будущее взаимодействие частей. (Ну, т.е. для
примера, если нам надо повзаимодействовать с подсистемой логистики, то
она у нас торчит какими-нибудь интерфейсами, которые пока окей, а в
процессе собирают к себе требования и стабилизируются).
В качестве документации используются постановка от бизнеса, которая
потом трансформируется в модель предметной области (у нас DDD и жЫрные
[rich] модели, в основном) и sequence-диаграммы, которые потом ложатся
в код. Код покрывается тестами, типичное покрытие у нас высокое -
70-80%, и выше. Зато потом в продакшене багов очень и очень мало, что
приятно.
Естественно, всё предусмотреть невозможно, поэтому что-то додумывается
в процессе. Именно поэтому доки у нас ведутся в основном в текстовом
виде в wiki (их переделывать проще, чем графику), а диаграммами
классов никто не заморачивается - при желании они генерятся достаточно
просто из исходников системы (тулов полно).
Однако, лучшая архитектура - это простая архитектура, лучший код - это
ненаписанный. Поэтому закладываться на будущее и писать код в надежде
на расширяемость не стоит, если это требует дополнительных усилий.
Кроме того, нужно прикидывать вектор, куда ваши требования скорее
всего поменяются, и в этом направлении проектировать гибче, чем в
других.
>> ..как быть если на 10 спринте выяснится... <<
Очень странный у вас процесс, если в течение 9 спринтов вы ничего не
замечаете, а потом оказывается, что вы "попали". Значит, команда
профакапила предыдущие 9 итераций и не разбиралась с внутренними/
внешними рисками и техническими долгами по ходу проекта, и жила в
пещере/на необитаемом острове. В жизни ничего не бывает просто так,
если требования поменялись "ВНЕЗАПНО", значит, вы что-то недопоняли в
бизнесе/предметной области, неэффективно общаетесь с заказчиком,
просто приятно проводите время вместо того, чтобы двигаться к цели
"реализовать систему как её хочет видеть снаружи заказчик, внутри -
разработчик" (нужное подчеркнуть)
Жалко, но ничего не поделаешь. Не стоит выяснять, кто виноват -
виноваты все сразу. Надо быстро покаяться и:
- волевым усилием признать, что "лошадь сдохла, пора с неё слезть";
- "вломить" Product Owner-у и аналитикам;
- устроить ретро и ПОНЯТЬ, почему ситуация рулит вами, а не вы ею.
Расстроиться, уйти в запой, потом собраться и назначить
стабилизационный спринт с высоким уровнем внутренних задач. Внутренние
задачи - переделать архитектуру.
- устроить повторный анализ требований, чтобы выяснить, что же было
понято не так в прошлый раз.
Аналитикам К. Вигерса перед сном читать, как псалмы, разработчикам -
M. Fowler "Refactoring", M. Feathers "Working Effectively with legacy
code" в руки и вперед. и голову не забыть, чтобы не вышло опять
такого, как было.
Сделаете всё так - будет вам счастье.