Кен Швабер - Скрам [Гибкое управление продуктом и бизнесом] [litres]

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

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

В качестве заключительного аргумента фирма-претендент может объяснить, что многие ее клиенты получили всю изначально ожидаемую бизнес-ценность задолго до реализации всех требований. Следуя правилу 80/20, они получили 80 % выгод проекта от всего лишь 20 % функциональности. Требования с самым низким приоритетом часто оказываются лишними. Фирма предоставит заказчику возможность отказаться от дальнейшей работы раньше даты окончания контракта, если он считает, что получено достаточно пользы для бизнеса. Разумеется, придется выплатить неустойку, но это будет дешевле, чем реализация и внедрение ненужных требований.

Чтобы выиграть в конкурсе и получить контракт с фиксированными датой и ценой, применяющая скрам фирма может использовать все перечисленные конкурентные преимущества, если потенциальный клиент открыт к обсуждению. Некоторые клиенты будут заинтригованы. Другим не понравится такой подход. Третьи не будут знать, как его обсуждать. На семинаре министерства обороны США в 2002 году я был участником дискуссии об этом подходе. В конце обсуждения специалист ВВС США по контрактам сказал: «Я даже не знаю, о чем вы, коллеги, говорили. Если бы вы предоставили мне материалы, поясняющие это, я отклонил бы вашу заявку по причине несоответствия критериям. Специалисты по контрактам ВВС и других ведомств проходят формальную, строгую подготовку, и ничто из изучаемых тем даже не намекает на то, о чем вы говорили». Претендуя на контракт с фиксированными датой и ценой, вы можете использовать скрам для получения дополнительных преимуществ, но только если ваша аудитория знает, как слушать, и хочет слушать.

CMMI–Capability Maturity Model Integration, набор моделей зрелости возможностей создания ПО, или «моделей полноты потенциала», – это набор моделей эволюционного развития способностей компании разрабатывать программное обеспечение.

В 1986 году Билл Кертис и Марк Полк из Института программной инженерии (Software Engineering Institute, SEI) при Университете Карнеги – Меллона [25] Университет Карнеги – Меллона находится в Питсбурге, штат Пенсильвания, США. В рейтинге QS World University Rankings 2019 занимает 46-ю строку среди университетов мира и 19-ю среди вузов США. начали всесторонний обзор зрелости процессов разработки программного обеспечения, чтобы впоследствии улучшать их, и в 1991 году впервые опубликовали CMM, которая, постоянно дорабатываясь, в 2009 году была переименована в CMMI.

CMMI состоит из пяти уровней с номерами от одного до пяти. Первый уровень означает, что организация не имеет определенного, повторяемого или улучшаемого подхода к созданию программного обеспечения. Фактически разработчики самостоятельно прокладывают свой путь к решению. На пятом уровне организация имеет определенный, повторяемый и улучшаемый набор методов для разработки программного обеспечения. Организация первого уровня считается незрелой, организация пятого уровня – зрелой. На каждом уровне методы, которые следует использовать, определяются как ключевые процессные области (КПО). Если организация считает, что полностью реализовала КПО на определенном уровне, она может привлечь оценщика. Если организация соответствует требованиям, ее сертифицируют. Сертификация – большое дело, потому что некоторые компании и правительственные агентства не нанимают фирмы, не сертифицированные как минимум на уровне CMMI 3.

Я уже рассказывал о MegaFund в третьей, пятой и девятой главах. Компания потратила три года и более $40 млн на совершенствование своих подходов к разработке программного обеспечения, пока не была сертифицирована на уровне CMM 3. На этом уровне MegaFund не только обладала стандартизированным подходом к управлению совершенно любым проектом разработки программного обеспечения, но также могла формально определять эти методы. В девятой главе мы рассмотрели, как компания MegaFund масштабировала проект, чтобы быстрее реализовать для клиентов возможность управлять счетами с помощью телефона и через интернет.

К сожалению для MegaFund, компания не определила практики, позволяющие в важном проекте c жесткими сроками автоматизировать нечеткие требования к передовым и непроверенным технологиям, как это описано в восьмой главе. Когда MegaFund начала использовать скрам в этом проекте, он буксовал уже более девяти месяцев, а участники команды безуспешно пытались преодолеть процессуальные и бюрократические препоны, которые CMM третьего уровня наложил на деятельность в неопределенных и непредвиденных обстоятельствах. Я получил неблагоприятное впечатление от CMM в этом проекте и других компаниях. Однако меня все чаще спрашивали, что я думал о CMM и как эта модель связана со скрамом. Поняв, что мне нужны дополнительные информация и знания, я организовал встречу с Марком Полком в Институте программной инженерии осенью 2002 года.

О скраме Марк только слышал, зато был знаком с экстремальным программированием – еще одним аджайловым процессом, подобным скраму, но сконцентрированным больше на инженерии ПО, чем на управлении. В течение первого дня Марк учил меня CMM, а я учил его скраму. Признаюсь, я был очень удивлен и впечатлен CMM. Марк отметил, что это всего лишь фреймворк, описывающий зрелость компании по разработке программного обеспечения. Каким образом добиваться соответствия критериям уровней зрелости – выбор самой организации. Оценщики CMM должны были определить, адекватен ли способ удовлетворения критериев. И тут меня озарило: до 2001 года почти каждая компания использовала предопределенные процессы разработки ПО, поэтому естественно, что фреймворк CMM содержал жесткие предписывающие методы. У них были те же слабые стороны, что и у всех предопределенных подходов, – они работают только в ситуациях, предусмотренных их создателями. Поскольку разработка программного обеспечения является очень комплексным процессом, нашлось очень немного реальных проектов, к которым эти подходы были бы применимы.