Как мы разрабатывали корпоративное iOS-приложение по Agile, и почему он нас не спас от рисков

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Дано:

  1. Корпоративное iOS-приложение, реализованное только под форм-фактор Apple iPad с устаревшим дизайном (особенно, если изучать гайдлайны Apple).

  2. Заказчик = крупное российское полукоммерческое предприятие. Со стороны Заказчика участвуют 4 департамента (с одинаковым влиянием друг на друга), один из департаментов является функциональным заказчиком (ФЗ) и владельцем бюджета. Остальные отвечают за безопасность и ИТ-сопровождение.

  3. Распределенная на 2 города команда со стороны Исполнителя, проблемы с коммуникациями отсутствуют.

Найти:

  1. OS-приложение под iPhone с современным интерфейсом и доп. функционалом

Ограничения:

  1. Заказчик на момент проекта никогда ранее не работал по Agile-методологиям, но их руководство на основе последних трендов повсеместно пыталось запустить использование Agile;

  2. Договорные отношения между Заказчиком и нами были FixedPrice (оформить T&M было невозможно).

Решение:

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

Разработка продукта происходила, как и положено, итерациями. Каждая итерация составляла 2 недели: формирование скоупа -> разработка -> тестирование -> демонстрации -> фиксирование замечаний -> формирование скоупа -> …

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

Что было неизменно (для отношений Заказчик-Исполнитель):

  1. Постоянное давление статусом Заказчика и уровнем важности его конечных целевых пользователей.

  2. Растущие аппетиты Заказчика и «жонглирование» требований между 4 заинтересованными департаментами. Например, в ходе разработки продукта появилось требование использования библиотек корпоративной MDM-системы для сохранения конфиденциальности данных внутри приложения. Как итог: из-за внутренних противоречий Заказчика было разработано 2 сборки (с поддержкой MDM и без), первый год после внедрения в пром 99% пользователей использовали принципиально версию без MDM-системы все из-за тех же внутренних противоречий между департаментами.

Немного графиков со статистикой растущих аппетитов (цифры про трудоемкости и длительности опущены на графиках из-за NDA компании с Заказчиком):

Почему Agile не помог

В рамках каждой итерации готовились кликабельные макеты приложения, которые детально согласовывали со стейкхолдерами Заказчика (как и учит Agile). Заказчик со своей стороны собрал пилотную группу из будущих пользователей около 10 человек (в которую также входили лица, принимающие решение «наверху») для апробации будущего продукта. Согласованные макеты превращались в приложение, и каждый выпуск промежуточной законченной версии продукта позволял пилотной группе «пощупать» и дать свой фидбек. Все замечания обрабатывались, обсуждались, оценивались, после обсуждения и согласования адекватные замечания исправлялись в следующих итерациях. Все как в лучших практиках.

НО…

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

Выводы или зачем нужна эта статья

Казалось бы, все просто: методологии Agile в своих принципах нацелены на минимизацию рисков путем сведения разработки к серии итераций и постоянному тесному контакту со стейкхолдерами. Не согласовали дизайн приложения и свои многочисленные макеты со всеми заинтересованными стейкхолдерами – сами виноваты, у вас было 18 поставок, чтобы спросить ключевого пользователя, что не так.

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

Собственно, возникшую проблему после опытной эксплуатации продукта решали другими методологиями, где подробно рассматривается управления рисками. И как учит туториал Хабра: «Неуспешные кейсы тоже полезны, они помогут кому-то не наступать на грабли, на которые другие уже наступали». Не скажу, что мой кейс неуспешен, сотрудники Заказчика пользуются продуктом уже несколько лет, в рамках проекта были достигнуты почти все поставленные цели. Но мой кейс – один из примеров, когда нельзя забывать о стратегиях управления рисками в угоду пропаганде повсеместного использования Agile.

Источник: https://habr.com/ru/post/532150/


Интересные статьи

Интересные статьи

Мы недавно писали, как затеяли конференцию, полностью посвященную инженерным процессам и практикам. Наша цель — собрать в одном месте профессионалов, которые развивают техническое лидерство у ком...
Художник изобразил экзопланету размером меньше, чем Нептун. Новое исследование предполагает причину, по которой такие планеты редко становятся больше Нептуна: магматические океаны планеты начин...
Последнее время из каждого утюга слышатся хвалебные высказывания о многомировой интерпретации квантовой механики и негативные в сторону Копенгагенской. Вот, например, относительно недавняя статья...
Получить трафик для интернет-магазина сегодня не проблема. Есть много каналов его привлечения: органическая выдача, контекстная реклама, контент-маркетинг, RTB-сети и т. д. Вопрос в том, как вы распор...
Релиз часто подкрадывается незаметно. И любая ошибка, внезапно обнаруженная перед ним, грозит нам сдвигом сроков, хотфиксами, работой до утра и потраченными нервами. Когда подобный аврал стал про...