Валерий Фунтов - Agile. Процессы, проекты, компании

♦ проект не очень масштабный;

♦ графики и алгоритмы проектов можно использовать в будущем для идентичных или аналогичных проектов;

♦ проект типовой, существует понятное ТЗ, заказчик не хочет управлять проектом и похожие ситуации.

Гибкость на практике

Руководство компании Toyota, знаменитое созданием Lean и Канбан, часто критикуют за недостаток гибкости: до конца 2000-х для нужд производства компания пользовалась каскадной моделью разработки ПО.

Анализ разработки сайта в компании Ericsson AB показал, что предиктивный вариант привел к путанице и 26 % изначальных требований оказались просто бесполезными.

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

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

Одним из вариантов адаптивного цикла является пошаговая реализация проекта; выпуск на первом шаге (или итерации) продукта в базовой функциональности и затем, на следующих итерациях – создание отдельных составных частей или функциональностей продукта, так называемых инкрементов, с приращением ценности. Процесс продолжается до тех пор, пока не будет создана полная система, при этом требования могут вырабатываться постепенно, по итерациям, так же вносятся и изменения. В конце каждой итерации заказчик и/или потребители принимают активное регулярное участие в оценке. Контроль рисков и стоимости осуществляется на основе постепенно разрабатываемых планов по мере поступления новых вводных. Промежуточные результаты содержат необходимые характеристики для выработки новых требований и для анализа их ценности. Такой цикл называется инкрементным и используется там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы или требуется ранний вывод продукта на рынок. Команда обычно постоянна.

Так можно создавать портал компании – сначала немедленно вводить в работу основные функции или «кнопки», потом дополнять следующими, получая пользу от уже введенных.

Фавелы

Фавелы в Латинской Америке строятся по комнатам. У жителей времени много, зимы нет, как и денег. Они строят свою первую комнату из кирпичей, пока не кончатся или сколько есть. Потом достраивают, ставят окна, накрывают крышу и иногда даже штукатурят и красят. Когда семья растет, пристраивают следующую комнату.

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

Кино

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

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

По результатам итераций разрабатывается продукт с минимально необходимым набором возможностей или функций. Заказчик его оценивает, давая свои новые требования и по возможности начиная использовать этот продукт уже в своей деятельности. Такая версия продукта называется MVP – Minimum Viable Product (минимально ценный продукт) (исполнительный директор SyncDev Фрэнк Робинсон, 2001 г., позже Эрик Райс, основатель IMVU) или PSPI – Potentially Shippable Product Increment (готовое к поставке приращение продукта). Например, это базовая функциональность продукта, первый тестовый продукт для рынка.

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

Zappos – интернет-магазин обуви

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.