Стадии разработки программ

В процессе прочтения замечательной книги Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets and Manages People обнаружил описание процесса разработки в Microsoft. Спешу поделиться, но заранее предупреждаю, что книга вышла в 1995 году, так что описание имеет скорее исторический и "общекультурный" интерес.

Итак, сам процесс разбит на три основные фазы: Планирование, Разработка и Стабилизация.

1. Планирование
   В результате выполнения фазы планирования должны образоваться следующие материалы:
   
• vision statement
• спецификация
• описание функциональных возможностей продукта (product features)
• приоритет каждой из функциональных возможностей
• прототипы различных частей продукта, пользовательских интерфейсов
  
• план проекта, включающий в себя календарный план
2. Разработка
• состоит из нескольких milestones
• "Замораживание" пользовательского интерфейса
• Завершение добавления всех функциональных возможностей
  
• Окончание кодирования
  
3. Стабилизация
• Тестирование
• Исправление найденных ошибок
• Проведение оценки проекта (post-mortem)

Согласитесь, ничего такого особенно нового в таких этапах нет. Все примерно таким образом и делают. Тем не менее, хочу отметить несколько моментов, которые отличают именно Microsoft:

• Чрезвычайно активное использование "буферного" времени, причём исключительно для неопределённых вещей. Часто бывает так, что буферное время используется в качестве дополнительного времени для проведения инспекций кода, unit-тестирования, планирования и тому подобного. В Microsoft же для всей этой активности выделяется отдельное специальное время. А буферное время - это именно буферное время.
  
  
• Для продуктов разрабатываемых в Operating Systems Division, его начальник, Brad Silverberg, требовал не менее 50% буферного времени. (то есть если оценка времени на задание была 1 месяц, то Silverberg требовал 2 месяца)
  
  
• Концепция "milestone 0". Время, между окончанием работы над одной версией продукта и началом разработки следующей, в течении которого разработчики "подчищают хвосты" - исправляют то, что они хотели исправить в только что вышедшей версии, но не успели.
  
  Например, между окончанием работ над Excel 4.0 и началом работ над Excel 5.0 на это было потрачено 2 месяца.
  
  
• "Поддержкой" предыдущих версий (починкой ошибок в них) занимаются те же самые
  разработчики, что и разрабатывающие новую версию
  
  
• Принцип "бездефектных" milestones - идея состоит в том, что по достижении milestone - продукт не содержит дефектов и (относительно того, что было запланировано для данного milestone) является готовым чуть ли не к выпуску

Вот такая история. Хочу заметить, что все эти принципы, хотя и являются уже почти что общеизвестными, тем не менее применяются у спехом далеко не всегда и не во всех компаниях. Большая часть из них служит исключительно для того чтобы повысить точность оценок сроков выхода продуктов. Вроде бы, судя по книге из которой я выдернул это описание, Microsoft добилась существенных улучшений, благодаря введения этих принципов. В настоящее время существует масса оценок времени создания проектов, куча методик планирования, разбиения на задачи и так далее. Написано множество книг на эту тему. Тем не менее проекты по созданию программного обеспечения все равно чрезвычайно не укладываются в срок. Почему так? Мне кажется вот почему.