Книга: Экстремальное программирование

Что делать?

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

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

Для начала небольшое отклонение от темы. Если кто-нибудь спросит у меня, какой автомобиль я хочу: Феррари или минивэн, я уверен, что выберу Феррари. Но если этот кто-то спросит у меня: Хочешь ли ты „Феррари" за 200 000 франков или минивэн за 40 000? – я начну формировать взвешенное решение. Если добавить к этому еще пару требований, например, мне необходимо брать с собой в дорогу пять детей или я должен быть способен развить скорость 200 километров в час, картина еще более прояснится. Существуют случаи, в которых каждое из решений по-своему оправданно, однако вы, скорее всего, не сможете сформировать хорошее решение исходя только лишь из глянцевых фотографий.

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

Следуя этой модели, бизнесмены должны определить:

• Объем работ или время выпуска версий продукта;

• Относительные приоритеты предполагаемых возможностей системы;

• Конкретный объем работ, связанных с предполагаемыми возможностями системы.

Для того чтобы помочь бизнесменам сформировать эти решения, разработчики должны сообщить:

• Оценки времени, необходимого для реализации различных возможностей системы.

• Предположительные последствия использования различных технических альтернатив.

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

• С использования какого набора методик они начнут свою работу и при помощи какого процесса они будут пересматривать эффекты использования этих методик и экспериментировать с изменениями. Это напоминает Американскую конституцию, которая устанавливает базовую философию, базовый набор правил (билль о правах и первые 10 поправок), а также правила изменения правил (добавления новых поправок).

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

Оглавление книги