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

Я был единственным автором этого программного продукта (около 30 000 строк кода). Я не владел формальной методологией, у меня было мало опыта создания ПО, а также не было менеджера, коуча или ментора. Но у меня имелось время, компьютер, видение и страстное желание создать великолепный продукт (рис. 2.1).

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

Как это вообще возможно? Как неопытному программисту удалось создать продукт столь высокого качества, что он работает почти безупречно вот уже почти двадцать лет?

Не имею ни малейшего представления.

Но… У меня есть список из нескольких пунктов, которые должны быть знакомы последователям гибких методологий разработки.

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

• Я сам был своим критично настроенным заказчиком. Я создавал эту программу для себя, а не для других. Безусловно, я был счастлив, когда мне удалось найти нескольких покупателей, хотя мне и не удалось заработать миллионы, на которые я рассчитывал. Но что бы я ни делал, самым важным было, чтобы продукт работал именно так, как я этого хотел.

• У меня не было плана, только список функциональных возможностей, которыми должен был обладать новый продукт. Я начал с такой наиболее часто применяемой операции, как ввод транзакций. Затем перешел к менее критичным функциям вроде составления баланса и внесения корректировок. В конце добавил такие необязательные приятные вещи, как подсказки и возможность экспорта данных. Я занимался этим до тех пор, пока мне все не надоело, и я просто не объявил продукт готовым.

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

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

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

Евангелие от Agile

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

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

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

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