Проблемы специфицирования

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

1. Планирование осуществляется по частям. Наиболее полно и почти что с минутной разбивкой во времени осуществляется планирование начальных частей проекта, а с большей свободой – последующих. Проект, как правило, разбит на двухнедельные части (модули).

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

3. Объектная технология, которую применяет SIL, хорошо встраивается в итеративный характер разработки.

4. Быстрое создание прототипов и испытание созданной части проекта пользователем помогает разработчикам быстро довести свои идеи до пользователя и дает последнему возможность конкретизировать свое отношение к ним.

5. Каждый модуль полностью тестируется перед передачей его результатов остальной команде. Для этого используются программы автоматической проверки, а затем новые коды передаются на вход системы. Так как для этого необходимо не более одного-двух дней, то исполнители склонны делать это “в рабочем порядке”, не дожидаясь выделенной планом фазы тестирования. Так как каждый модуль включает оценку валидности его результатов в системе, то устраняются многие побочные эффекты новых кодов перед их использованием остальной частью проектной команды.

На основании своего опыта SIL сформулировал ряд рекомендаций:

1. Когда система слишком сложна для специфицирования, ускорьте создание ее прототипа.

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

3. Включайте всю команду в организацию процессов разработки, это создает чувство сопричастности.

4. Если ваш процесс не изменяется, если он не является объектом дискуссии и дебатов, то он не может быть использован. Хороший процесс органичен, превращается в привычку. Как и любое действие, вы можете его документировать. Лучшее, что вы можете сделать – руководить его развитием, но попытки ускорить это в приказном порядке больше похожи на поощрение восстания, чем на участие.

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

6. Организуйте эффективные коммуникации в вашем процессе - тренируйте членов команды в командной динамике и эффективной технике совещаний.

7. Разделяйте проекты на малые куски. Выполняйте большое дело путем малых шагов.

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

9. Небольшие изменения лучше, чем их отсутствие. И всегда хорошо, если имеется ряд изменений.

10. Желательно, чтобы команда принимала решения консенсусом. Это позволяет работать вместе для нахождения приемлемых решений перед внесением их в план. Это не всегда легко, но групповой консенсус – помощь в создании техники.

11. Защищайте людей от препятствий и излишнего вмешательства руководства.

12. Обычно тестируйте план. Как правило, план отводит 1/3 времени кодированию, 1/3 – тестированию и ревизии и 1/3 чему-нибудь еще.

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

Распространено мнение, что малые команды талантливых людей лучше в сфере НИОКР, чем большие команды средних или даже талантливых людей. Было оценено, что при разработке программного обеспечения талантливые программисты в десять и более раз продуктивней наименее талантливых в команде. Однако это может оказаться неверным для других типов исследований и разработок, инжиниринга и прочей интеллектуальной работы. В то же время существует и другая истина: малым командам присущи и определенные ограничения, например, при создании очень больших изделий в сжатые сроки. В автомобильной промышленности для разработки нового образца требуется около семи миллионов инженеро-часов. В фирмах “Тойота”, “Хонда”, “Крайслер” над одним образцом работают 500-1000 инженеров в течение 3-5 лет. В “Боинге” этим заняты несколько тысяч инженеров.