История тяжелого проекта: немного о бюрократии, инфраструктуре и процессе разработки ПО

Любой маленький проект мечтает вырасти в Facebook во что-то значительное. Далеко не всегда это происходит, но если все же случается, то возникает целый сонм проблем и задач, которых казалось бы не существовало, когда в проекте было пять разработчиков, но которые требуют значительного внимания после становления проекта на ноги. Ниже изложение истории сравнительно большого проекта, мысли о бюрократии а также описание инфраструктуры и процесса разработки — думаю этот опыт кому то будет полезен.

Заказчик — довольно крупный инвестиционный банк. Число конечных пользователей: более 10 тыс.

Команда проекта

• более 200 разработчиков (из них 31 тим лид, 7 мастер тимлидов)
• 3 архитектора, один из них главный
• 19 тестировщиков (1 лид, 2 на нагрузочных испытаниях, остальные на функциональном тестировании)
• 5 системных администраторов, в зоне ответственности которых управление СУБД и выше. Администрирование ОС и аппаратной части в зоне ответственности специальной HW team
• переменное число (от 2 до 16) аналитиков, работающих на part time
• 12 технических писателей и переводчиков
• 3 руководителя проекта, постоянно руководит один — второй и третий на подмене во время отпуска, болезни или выступают в качестве ассистента руководителя проекта когда активны и доступны.

Все сотрудники работаю в географически разнесенных офисах. Аналитики в Лондоне, Нью-Йорке и Франкфурте-на-Майне. Центры разработки в Восточной Европе, но значительная часть разработчиков де-факто работает удаленно, так что в проекте помимо венгров есть болгары, русские, а также украинцы и белорусы.

Что из себя представляет разрабатываемая система и краткая история

По сути это некая смесь CRM, OSS для финансовых организаций и специализированного ПО для инвестиционного банкинга. Проект начинался более 15 лет назад, первоначально разрабатывался на Perl, остатки кода на котором все еще (на 2013 год) присутствуют в системе. Когда стало понятно, что на Perl далеко не уедешь, была сформирована команда внутри ИТ блока, которая стала неспешно переписывать существующих функционал на новую платформу (Java). Спокойная работа длилась не долго — в результате поглощения заказчиком финансового института помельче, к системе «органически» была присоединена система на PHP, которая представляла из себя, упрощенно, веб-интерфейс конечных пользователей, тогда как back-end представлял из себя брокеров, вручную обрабатывающих поданные заявки. Первоначально планировалось полностью переписать PHP часть, благо она была сравнительно небольшой.

К сожалению по такому критически важному фактору, как время вывода функционала в продуктив (go to market), Java команда наголову проигрывала PHP команде, несмотря на почти двукратное преимуществу первых в численности, и почти 3-х кратному преимуществу в фонде оплаты труда. В результате все новые продукты сначала появлялись на PHP, и лишь спустя определенное время Java команда воспроизводила, иногда лишь частично, данный функционал на J2EE. Оставим в стороне причины такого явления, но пользуясь случаем скажу, что на мой субъективный взгляд такое положение дел полностью устраивало Java команду, которая была лишена «счастья» общения с конечным заказчиком, требования до команды доходили в уже изрядно переработанном и очищенном виде, а дамоклов меч сроков над ней практически не висел.

О попытках ухода от внутренней разработки

Периодически предпринимались попытки уйти от in-house разработки, передав проект внешнему интегратору. Проводились тендеры, просматривались команды, даже заводилась речь про развитие центра компетенций специально под банк, но каждый раз что-то не срасталось. История срыва последней попытки была особенно эпична — в качестве лакмусовой бумажки решено было выбрать запрос, являвший собой сборную солянку из маленьких независимых друг от друга улучшений. Одно из таких улучшений заключалось в добавлении возможности авторизованным пользователям добавлять только им видимые комментарии к новостям. Архитектор и продавец от именитого интегратора бодро расписали план и выкатили стоимость доработки. Напротив улучшения с комментированием новостей стояла трудоемкость — 8 человеко-часов. Сейчас неизвестно какими судьбами эта оценка попала автору запроса в Мадрид, но буквально на следующий день был устроен форменный разнос по видео-конференс связи, где сын какого-то испанского сотрудника в прямом эфире сделал функционал буквально за 10 минут. Понятно что парнишка использовал готовые, написанные им ранее куски SQL и Java кода, но задача, для реализации которой нужна одна таблица в БД и одна страница кода никак не тянула на 8 человеко часов. По ощущениям менеджмента максимум полчаса-час.
Вполне естественно что ни продавцы ни архитектор интегратора не смогли обосновать почти 16-ти кратную разницу в оценке трудозатрат, не помогла ни харизма главного продавца, ни ссылки на Брукса с его эволюцией системного программного продукта. Идея внутренней разработки, продолжала жить и побеждать.

Продукт или не продукт?

Попытки вести проект правильно, завести менеджера продукта, сделать четкий план релизов также проваливались. К ИТ в целом и к проекту в частности у бизнеса было сугубо утилитарное отношение — ИТ обслуживает бизнес. Есть охрана, есть службы уборки офиса и доставки. И есть ИТ-служба, которая денег просит не в пример больше, но которая не должна диктовать условия бизнесу — вы же не можете представить уборщицу, которая вторгается в переговорную комнату и просит всех выйти на полчаса под предлогом необходимой уборки? Так чем ИТ лучше? Так что всем региональным офисам были выделены бюджеты на реализацию новых возможностей системы, что для руководителя продукта было легким шоком: как так, есть строка — заказ канцелярских товаров, есть строка — доставка кофечаяводы в офис и есть строка бюджета, запросы на изменения его продукта? Естественно практически никакой централизации требований такая модель не подразумевала — если у подразделения остались на строке бюджета деньги, ИТ обязано реализовать данный функционал. А что касается уместности требований, так бизнесу на местах виднее, какие отчеты или какие возможности им нужны.

Схема процесса

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

Участники
End User — конечный пользователь системы
Manager — руководитель проекта
Tester — тестировщик
Architect — архитектор
Analyst — аналитик
Application Developer — разработчик
Code reviwer — ведущий разработчик отвечающий за code review

1. Конечный пользователь подает заявку на новую функциональность через BPM систему. Сейчас это самописное решение, рассматривается вариант миграции на Oracle BPM.
2. Руководитель проекта принимает заявку, фильтруя нереализуемыедублирующие.
3. Руководитель проекта передает заявку аналитикуархитектору, опять же через BPM систему.
4a. Аналитикархитектор формулируют задачу в терминах сначала бизнесфункциональных требований, затем в виде частного технического задания. Текст задачи уходит в Source Control (Git), задание в Jira и BPM, требования подвергаются трассировке (Rational ClearCase).
4b. Архитектор прогнозирует срок исполнения задачи и вносит информацию в систему управления проектом (Microsoft Project Server+доработки).
4c. Система управления проектом информирует конечного пользователя о прогнозируемых сроках и стоимости исполнения задачи.
5. Разработчик забирает последнюю версию исходных кодов, производит реализацию функционала.
6. Разработчик размещает код на code review (через Gerrit).
7. CI система (Hudson) забирает код, проводит тестовую сборку.
8. Отчет о тестовой сборке уходит в систему отчетности (на базе Microsoft SQL Server Analysis Services). Ответственному за code review отправляется извещение о необходимости провести анализ кода.
9. Code reviwer дает добро на внесенные изменения.
10. Код переносится в основную ветку разработки.
11. CI система забирает код из основной ветки, проводит сборку.
12. Отчет о которой выкладывается в систему отчетности.
13. CI система производит деплой кода на тестовое окружение.
14. CI система производит вызов систем функционального и нагрузочного тестирования.
15. Системы тестирования в автоматическом режиме проводят на тестовом окружении процедуры тестирования (JMeter, Selenium, RationalRobot).
16a. Отчет о которых выкладывается в систему отчетности. Производится извещение тестировщика о необходимости провести тесты.
16b. Системы тестирования меняют статус задачи в системе управления проектом.
17. Тестировщик производит тестирование.
18. В случае успеха изменяется статус в BPM системе, о чем
19. Руководитель проекта получает извещение.
20a. BPM система производит инициацию переноса сборки на pre prod окружение.
20b. Отметка о данном событии ставится в системе управления проектом.
20c. О чем извещается конечный пользователь, который может посмотреть функционал на pre prod окружении.
21. Руководитель проекта и конечный пользователь проверяют функционал на pre prod окружении.
22. В случае если принимается решение о передаче функционала в продуктив, руководитель проекта через BPM систему инициирует задачу на deploy на продуктивное окружение.

В фоновом режиме

1. Система автоматической настройки окружения (Puppet) производит выравнивание ландшафта в части настроек базового ПО.
2. Система мониторинга и отслеживания статусов (Zabbix) производит мониторинг инфраструктуры, включая не только dev, test, pre-prod и prod, но и прочую инфраструктуру, включая gerrit, Git, Hudson и т.д.
3. Система резервного копирования, помимо резервирования репозитариев проекта и инфраструктурного ПО, производит резервное копирование образов машин pre-prod ландшафта на случай форс-мажора или необходимости демонстрации предыдущих релизов системы.
4. Раз в сутки проводится статистический анализ кода, в первую очередь для поиска уязвимостей.

Вышеуказанная схема несет некий налет гигантомании и идеалистичности — РП часто манкирует своими обязанностями по просмотру нового функционала на pre prod, Code reviwer не глядя подтверждает код от знакомых доверенных разработчиков и т.д. но в целом данная схема вполне удобоварима для действительно больших проектов. И, самое замечательное, что из нее можно получить схему для другого проекта просто отсекая лишние, явно избыточные части.

Сухие выводы, обличенные в советы, которые автор вынес после нескольких лет участия в проекте

1. Всем кто в ИТ. Отношения ИТ-Бизнес в России и западной европе отличаются, порой кардинально. «У них» ИТ, это обслуга, в хорошем смысле этого слова. Пускай и привилегированная и высокооплачиваемая, но никак не претендующая на главенствующую роль и не качающая права на совете директоров. У нас вполне серьезно на CIO форумах обсуждается вопрос, почему CIO это Career Is Over, как с этим бороться и почему в генеральные директора чаще попадают с места финансового директора, но почти никогда с места директора ИТ. Позиция ИТ в корпоративной иерархии, где-то между АХО и бухгалтерией. Смиритесь, так будет и в России.
2. Совет начинающим архитекторам. «Для больших проектов не существует правильно выбранной архитектуры». Невозможно без костылей спроектировать то, что будет развиваться более пары лет. Все что вы можете придумать — это слабосвязанность и разумный уровень абстракции.
3. Совет разработчикам. «Потом не будет». Никто для серьезных систем не даст возможность «переписать правильно». Бизнес этого не понимает, поймите и вы. В конце концов вам с этим кодом детей не крестить.
4. Совет руководителям проекта. В классическом треугольнике качество-сроки-бюджет, бюджет как правило зафиксирован, категория качества является для топ-менеджмента довольно абстрактной (сокращать функционал не дают, так что качество это именно качество), так что вместо треугольника готовьтесь воевать только на одном фронте — фронте сроков. Просто учитывайте это при планировании.
5. Не существует никаких правил, забудьте что написано выше.

Автор: Andy_Day

Источник