Agile-менеджмент. Лидерство и управление командами - страница 20

Вот, собственно, и все. У меня была мотивация, а также критично настроенный заказчик, при этом отсутствовал предварительный план, но присутствовали дисциплина и самоорганизующийся процесс. Не имело никакого значения, что ранее я никогда ничего подобного не делал. Важно было то, что у меня было страстное желание учиться.

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

Вначале инженеры сотворили компьютеры и программное обеспечение. Программное обеспечение же было бесформенно и нефункционально, и тьма царила над пользователями. И инженеры сказали: «Да будет структура». И возникла структура.

И даже в избытке.

За последние пять-шесть десятков лет многие инженеры-компьютерщики озаботились проблемой нестабильности качества при разработке ПО. Она объяснялась тем, что разные команды пользовались разными методами разработки, в основном созданными на коленке. И инженеры окунулись в работу. В результате возник ряд формализованных подходов. Родилась профессия разработчика программного обеспечения. Отправной гипотезой служило представление, что создание ПО – чисто инженерная задача. В результате появилось большое количество моделей, методов, подходов и технических приемов, которые, по идее, должны были помочь программистам повысить качество готовых программ. Но странное дело – при реализации большинства проектов эти методы оказывались неэффективными. Гораздо чаще их результатом становилось возникновение очередной бюрократии. Проекты по разработке ПО занимали столько времени и требовали создания такого количества документации, что «формальные» требования к продукту успевали по нескольку раз измениться за то время, что проект находился в разработке. Тем временем небольшим командам программистов удавалось выпускать на рынок продукты гораздо более высокого качества, на порядки дешевле и существенно быстрее. На их стороне были энтузиазм, дисциплина, гибкость и методы, адаптируемые под каждый проект. Эволюция произвела на свет динозавров, но вся пища доставалась муравьям.

В начале 1990-х была предложена новая методология под названием быстрая разработка приложений (Rapid Application Development, RAD). В рамках этой методологии наиболее успешным командам разработчиков удавалось сочетать некоторые формализованные методы, позаимствованные у «тяжеловесного» инженерного подхода (контроль за внесением изменений в техдокументацию, инспекции и применение контрольных показателей), с такими продиктованными практикой методами, как создание прототипов, выпуск инкрементных версий ПО и тесное сотрудничество с заказчиком [McConnell 1996]. В результате такого скрещивания формализованных и неформализованных методик возникли первые «легкие» методологии, включая эволюционное управление разработкой (Evo) (1988), Scrum (1995), методы разработки динамических систем (DSDM) (1995), методы Crystal (1997), Экстремальное программирование (XP) (1999), разработка, управляемая функциональностью (FDD) (1999), прагматическое программирование (1999) и