Что надо делать для успеха программного проекта

Стив Макконнелл в своей книге приводит тест программного проекта на выживание. Этот чек-лист из 33-х пунктов, который я считаю необходимым процитировать с небольшими корректировками. Руководитель программного проекта должен его периодически использовать для внутреннего аудита своих процессов.

Чтобы программный проект стал успешным, необходимо:

1. Четко ставить цели.

2. Определять способ достижения целей.

3. Контролировать и управлять реализацией.

4. Анализировать угрозы и противодействовать им.

5. Создавать команду.

1. Ставим цели

1.1. Концепция определяет ясные недвусмысленные цели.

1.2. Все члены команды считают концепцию реалистичной.

1.3. У проекта имеется обоснование экономической эффективности.

1.4. Разработан прототип пользовательского интерфейса.

1.5. Разработана спецификация целевых функций программного продукта.

1.6. С конечными пользователями продукта налажена двухсторонняя связь

2. Определяем способ достижения целей

2.1. Имеется детальный письменный план разработки продукта.

2.2. В список задач проекта включены «второстепенные» задачи (управление конфигурациями, конвертация данных, интеграция с другими системами).

2.3. После каждой фазы проекта обновляется расписание и бюджет.

2.4. Архитектура и проектные решения документированы.

2.5. Имеется план обеспечения качества, определяющий тестирование и рецензирование.

2.6. Определен план многоэтапной поставки продукта.

2.7. В плане учтены обучение, выходные, отпуска, больничные.

2.8. План проекта и расписание одобрен всеми участниками команды.

3. Контролируем и управляем реализацией

3.1. У проекта есть куратор. Это такой топ-менеджер исполняющей компании, который лично заинтересован в успехе данного проекта.

3.2. У проекта есть менеджер, причем только один!

3.3. В плане проекта определены «бинарные» контрольные точки.

3.4. Все заинтересованные стороны могут получить необходимую информацию о ходе проекта.

3.5. Между руководством и разработчиками установлены доверительные отношения.

3.6. Установлена процедура управления изменениями в проекте.

3.7. Определены лица, ответственные за решение о принятии изменений в проекте.

3.8. План, расписание и статусная информация по проекту доступна каждому участнику.

3.9. Код системы проходит автоматическое рецензирование.

3.10. Применяется система управления дефектами.

4. Анализируем угрозы

4.1. Имеется список рисков проекта. Осуществляется его регулярный анализ и обновление.

4.2. Руководитель проекта отслеживает возникновение новых рисков.

4.3. Для каждого подрядчика определено лицо, ответственное за работу с ним.

5. Работаем над созданием команды

5.1. Опыт команды достаточен для выполнения проекта.

5.2. У команды достаточная компетенция в прикладной области.

5.3. В проекте имеется технический лидер.

5.4. Численность персонала достаточна.

5.5. У команды имеется достаточная сплоченность.

5.6. Все участники привержены проекту.

Оценка и интерпретация теста

Оценка: сумма баллов, каждый пункт оценивается от 0 до 3:

· 0 — даже не слышали об этом;

· 1 — слышали, но пока не применяем;

· 2 — применяется частично;

· 3 — применяется в полной мере.

Поправочные коэффициенты:

· для малых проектов (до 5 человек) — 1.5;

· для средних (от 5 до 20 человек) — 1.25.

Результат:

· <40 — завершение проекта сомнительно.

· 40-59 — средний результат. В ходе проекта следует ожидать серьезные проблемы.

· 60-79 — хороший результат. Проект, скорее всего, будет успешным.

· 80-89 — отличный результат. Вероятность успеха высока.

· >90 — великолепный результат. 100% шансов на успех.

Этот чек-лист перечисляет, что надо делать для успеха программного проекта, но не дает ответ на вопрос как это следует делать. Именно об этом пойдет речь в остальных лекциях.

Выводы

То, что производят программисты нематериально — это коллективные мысли и идеи, выраженные на языке программирования. В силу уникальности отрасли опыт, накопленный в отраслях материального производства, мало способствует успеху в управлении программным проектом. Прямые аналогии с этими отраслями не работают. Управлять разработкой ПО надо иначе.

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

Чтобы программный проект стал успешным, необходимо:

1. Четко ставить цели.

2. Определять способ достижения целей.

3. Контролировать и управлять реализацией.

4. Анализировать угрозы и противодействовать им.

5. Создавать команду.

Дополнительная литература и источники

1. IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.

2. IEEE Std 1074-1995, IEEE Standard for Developing Software Life Cycle Processes.

3. «Руководство к своду знаний по программной инженерии». The Guide to the Software Engineering Body of Knowledge, SWEBOK, IEEE Computer Society Professional Practices Committee, 2004.

4. David Rubinstein, «Standish Group Report: There's Less Development Chaos Today». 2007

5. Брукс Фредерик, «Мифический человеко-месяц, или Как создаются программные комплексы», Пер. с англ., СПб., Символ-Плюс, 1999.

6. «PMBOK. Руководство к Своду знаний по управлению проектами», 3-е изд., PMI, 2004.

7. Уолкер Ройс, «Адаптивный стиль управления программными проектами». Открытые системы. 2006. № 1.

8. Ершов А. П., «О человеческом и эстетическом факторе в программировании». Информатика и образование. 1993. № 6.

9. Paulk, Mark C., and others, Capability Maturity Model for Software, Version 1.1 (CMU/SEI-93-TR-24). Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 1993.

10. Филипп Крачтен, «Введение в Rational Unified Process», Вильямс, 2002 г.

11. «MSF, Microsoft, Microsoft Solutions Framework», Отдел MSF, Microsoft, 2002.

12. M. Pomeroy-Huff, J. Mullaney, R. Cannon, M. Sebern, «The Personal Software Process (PSP) Body of Knowledge», version 1.0, SPECIAL REPORT CMU/SEI, 2005

13. Watts S. Humphrey, «The Team Software Process (TSP)», Technical Report CMU/SEI, 2000

14. Kent Beck, and others, «Manifesto for Agile Software Development», 2001

15. А. Коуберн, «Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения», Humans and Technology Technical Report, Oct.1999 (русский перевод — К.Максимов, А.Максимова)

16. А. Коуберн, «Каждому проекту своя методология», Humans and Technology Technical Report, TR 99.04, Oct.1999 (русский перевод — К.Максимов, А.Максимова).

17. С. Макконнелл, «Остаться в живых. Руководство для менеджеров программных проектов», «Питер», 2006.

Поиск по сайту: