Каждому проекту своя методология (ЛП)

В ноябре мне сказали, что этот проект рассчитан на 15 рабочих недель, что всего в разработках участвует 3 человека, что дизайн программы уже практически завершен, и что у людей есть сходный опыт работы над предыдущей версией системы. Исходя из изложенной выше схемы методологий и моего собственного опыта, я предположил, что этот проект соответствует позиции D4 на схеме, а это означало, что трем разработчикам следует создавать систему просто работая сообща, обращая минимум внимания на всякие бюрократические штучки (нашей стандартной фразой было: "сделай свою работу и иди домой").

Впрочем, вскоре оказалось, что вся задача была оценена приблизительно, и к тому же, только частично. Мы провели дополнительные вычисления, и оказалось, что этот проект должен быть рассчитан на 130 рабочих недель. Кроме того, мы пересмотрели идею насчет того, что все три программиста могут работать в разных городах. В процессе работы использовались новые технологии, требовалось внедрение новой, более чувствительной схемы обработки ошибок, система должна была работать в реальном времени, и вдобавок обнаружились проблемы со взаимоисключающим доступом внутри основной базы данных. Кроме того, выяснилось, что им нужно еще и работать вместе с другой командой, которая находилась в другой части города. Ведущий архитектор через два месяца уходил в отпуск по уходу за ребенком, руководитель проекта не имел опыта работы ни в IT сфере, ни в руководстве проектами, а между тем, отчетность по проекту должна была осуществляться на высоком государственном уровне.

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

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

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

Уже через месяц персоналу удалось наладить свою работу, стабилизировался и план. Наконец-то вся история пришла к своему счастливому завершению. Мы сумели обнаружить все серьезные ошибки в дизайне на ранней стадии работ. Наш новый руководитель проекта сумел найти общий язык со своими подчиненными и хорошо отслеживал запланированные выпуски программы. Проект был закончен вовремя через год - в феврале. Все руководители были довольны как технической стороной проекта, так и по той причине, что общий план выпуска системы не изменился даже после мартовского пересмотра проекта. В этом проекте я впервые на практике применил схему с рис. 5 и с ее помощью последовательно менял методологию прямо в ходе проекта. Впрочем, неосознанно я пользовался всеми этими принципами и схемами, начиная с 1994 года. Вот еще несколько примеров, которые я привожу в порядке возрастания размеров проекта:

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

Проект Центрального банка Норвегии под названием BankLab представлял собой разработку прототипа для будущей критически важной банковской программной системы. Его можно отнести к категории С5: всю команду разработчиков посадили в одной комнате и постарались избавить от любых помех в работе. Руководитель и ведущий программист пришли к единому мнению относительно того, что привело проект к успеху: "Возьмите хороших специалистов, работайте небольшой командой, поместите всех в одну комнату, обеспечьте их необходимой информацией, а потом не мешайте". (Как сильно все это отличается от атмосферы работы над проектом Y2K в этом же банке!)