Мастерская бизнес-анализа

Григорий Грин, декабрь 2009

Мы являемся свидетелями большой шумихи вокруг гибких процессов разработки (Agile Software Development, [1]). Термин, введённый разработчиками, распространился в мире ПО и за его пределами и используется часто не по назначению. Сегодня все «агильные», а быть «неагильным» просто стыдно. Сам будучи разработчиком пару лет назад, я зачитывался книгами Кента Бека [2] и Мартина Фоулера [3]. Книги замечательные. Эти люди создали очень эффективные методологии разработки ПО. Со смещением моего фокуса в сторону управления проектами, я научился видеть методологии разработки в бизнес-контексте и, в том числе, видеть границы применимости гибких методик. Некоторыми мыслями я хочу поделиться с этой статье.

Начальные условия

Для дальшейших рассуждений важно знать, из каких начальных условий я исхожу. В другой среде могут действовать совсем иные законы.

В нашей фирме несколько десятков программистов. Мы занимаемся индивидуальной разработкой преимущественно веб-приложений с использованием новейших технологий. В каждый момент времени у нас пара десятков актуальных проектов на разных стадиях цикла разработки. За все время существования фирмы были завершены сотни проектов. Наш типичный проект длится 3-6 месяцев, в команде 3-6 человек. Практически все контракты имеют фиксированную стоимость.

Принципы гибких методологий

Давайте взглянем на некоторые принципы гибкой разработки, сформулированные в агильном манифесте [4, 5]:

«Нашим главным приоритетом является удовлетворение заказчика посредством ранней и непрерывной поставки работоспособного программного обеспечения.»

Быть может прямо здесь и зарыта собака? Главным приоритетом является удовлетворение заказчика. Звучит логично, но кто этот заказчик?

(далее…)