Скрам

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

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

Когда следует проигнорировать это конкурентное преимущество

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

Приложение Д Модель зрелости возможностей создания ПО (CMMI)

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

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

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

CMM в MegaFund

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