Болезнь роста

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

Когда продукт или сервис только появляется, у него есть одна единственная версия. Код, как правило, пишется по тикетам средних начальников, которые становятся одновременно и мудрецами-носителями сакральных знаний (для верхнего менеджмента -- о работе программного кода, для исполнителей -- о бизнес-задачах, пользователях, ресурсах, ограничениях, ...). Поначалу всё хорошо: коллектив небольшой, продукт умопостижим, если кому-то что-то не понятно, ответственный человек известен и доступен для непосредственного общения.

В дальнейшем верхний менеджмент начинает получать обратную связь от пользователей и владельцев, так что возникают новые бизнес задачи, спускаемые на средних начальников. Продукт обрастает новыми возможностями, коллектив развивается и растёт: кто-то уходит, кто-то приходит.

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

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

Формализация требований

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

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

Менеджеры среднего звена уже не выдумывают тикеты на изменения: тикеты становятся следствием изменений требований, то есть разницы между версиями (бейз-лайнами) требований. Это в идеале, но предположим.

А что с кодом и программистами? Их ад никуда не девается. Воля верхнего менеджмента доходит до эмпирея средних менеджеров и аналитиков и ... теряется в пропасти между средством разработки требований и системой тикетов с одной стороны, и ада хранилища кода с другой.

Ад программиста

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

Почему нельзя просто взять и скопировать требование в комментарий, почему нужно ставить ссылку? Потому что требование может измениться при переходе от одной версии требований, одной версии ПО, к следующей. Анализ влияния изменения требований (импакт анализ) становится проще: нужно найти все участки кода, ссылающиеся на изменённое требование.

Как оформлять ссылку? Современные средства разработки для каждого требования предоставляют веб-ссылку (URL). Казалось бы, программисту достаточно сделать Ctrl-клик на ссылку в его интегрированном окружении (IDE), и, вот оно, требование, в окошке браузера.

Но требования имеют версии. Код тоже имеет версии. Должна ли меняться ссылка при смене версии требования?

Если ссылка (URL) обязательно меняется от версии к версии требований, то переход от версии к версии в коде означает внесение изменений везде, где стоят ссылки на требования. Маленькое исправление ошибки в минорной версии приведёт к изменениям во всём коде.

Если ссылка меняется только при изменении самого требования, то возможны два варианта. Первый вариант: разные места кода будут ссылаться на разные версии одного и того же требования, что не вариант. Второй вариант: если проверять единство версии требований, например скриптом в системе контроля версий кода (git hook), то изменять ссылку придётся не только в месте кода, действительно подлежащем изменению, но и в каждом месте, затронутом данным требованием. Лучше, но всё равно филиал того же ада.

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

Так не пойдёт. Нет ли способа лучше? Нельзя ли вообще без пропасти, без эмпирея и ада? Так, чтобы воля менеджмента доходила до самого низа, а внизу не чувствовали пустоту и отчаяние.

Без пропасти

Дорогой читатель, спасибо, что дочитали. Надеюсь, несколько моих советов не испортят Вам настроение окончательно, а вселят надежду.

1. Пишите каждое требование в отдельном файле. Начните с формата Markdown, дальше возможны усложнения.

2. Ставьте ссылки в комментариях в коде в виде кратчайших относительных путей от файла кода к файлам требований.

3. Markdown поддерживается Doxygen, так что пишите ссылки в комментариях в формате Markdown, и переход на требования будет возможен и в браузере со сгенерированным HTML-ем.

4. Храните эти файлы требований в git вместе с кодом. Можно сделать аналитикам отдельный репозиторий со своими правами доступа, который будет подключаться к репозиторию кода как подмодуль git. Да, аналитикам придётся учить git и писать требования в IDE.

Приятной трассировки.