[Управление проектами, Agile, Управление продуктом] Как мы разрабатывали корпоративное iOS-приложение по Agile, и почему он нас не спас от рисков
Автор
Сообщение
news_bot ®
Стаж: 6 лет 7 месяцев
Сообщений: 27286
Дано:
- Корпоративное iOS-приложение, реализованное только под форм-фактор Apple iPad с устаревшим дизайном (особенно, если изучать гайдлайны Apple).
- Заказчик = крупное российское полукоммерческое предприятие. Со стороны Заказчика участвуют 4 департамента (с одинаковым влиянием друг на друга), один из департаментов является функциональным заказчиком (ФЗ) и владельцем бюджета. Остальные отвечают за безопасность и ИТ-сопровождение.
- Распределенная на 2 города команда со стороны Исполнителя, проблемы с коммуникациями отсутствуют.
Найти:
- OS-приложение под iPhone с современным интерфейсом и доп. функционалом
Ограничения:
- Заказчик на момент проекта никогда ранее не работал по Agile-методологиям, но их руководство на основе последних трендов повсеместно пыталось запустить использование Agile;
- Договорные отношения между Заказчиком и нами были FixedPrice (оформить T&M было невозможно).
Решение:При инициации проекта между Заказчиком и нами была достигнута договоренность, что все готовы работать в рамках Agile, но с фиксированным скоупом, который был четко ограничен рамками договора. Для удержания скоупа (по лучшим практикам agile) по каждой фичи озвучили условные эстимейты, расставили приоритеты и договорились «на берегу», что при возникновении исключений и увеличении скоупа просто обменяем часть требований на другую. В рамках существующих договоренностей и оценок также предполагалось переиспользовать существующее приложение, в котором были реализованы необходимые бизнес-процессы.Разработка продукта происходила, как и положено, итерациями. Каждая итерация составляла 2 недели: формирование скоупа -> разработка -> тестирование -> демонстрации -> фиксирование замечаний -> формирование скоупа -> …В итоге количество промежуточных поставок составило 18 штук, учтены были все основные пожелания стейкхолдеров и реализован весь необходимый набор требований, последняя поставка была признана релизом с обеих сторон. Приемо-сдаточные испытания (которые из-за бюрократии Заказчика и договора FixedPrice даже в рамках используемого гибкого подхода отменить невозможно) были пройдены без критичных и условно-критичных замечаний с первого раза.Что было неизменно (для отношений Заказчик-Исполнитель):
- Постоянное давление статусом Заказчика и уровнем важности его конечных целевых пользователей.
- Растущие аппетиты Заказчика и «жонглирование» требований между 4 заинтересованными департаментами. Например, в ходе разработки продукта появилось требование использования библиотек корпоративной MDM-системы для сохранения конфиденциальности данных внутри приложения. Как итог: из-за внутренних противоречий Заказчика было разработано 2 сборки (с поддержкой MDM и без), первый год после внедрения в пром 99% пользователей использовали принципиально версию без MDM-системы все из-за тех же внутренних противоречий между департаментами.
Немного графиков со статистикой растущих аппетитов (цифры про трудоемкости и длительности опущены на графиках из-за NDA компании с Заказчиком):
Почему Agile не помогВ рамках каждой итерации готовились кликабельные макеты приложения, которые детально согласовывали со стейкхолдерами Заказчика (как и учит Agile). Заказчик со своей стороны собрал пилотную группу из будущих пользователей около 10 человек (в которую также входили лица, принимающие решение «наверху») для апробации будущего продукта. Согласованные макеты превращались в приложение, и каждый выпуск промежуточной законченной версии продукта позволял пилотной группе «пощупать» и дать свой фидбек. Все замечания обрабатывались, обсуждались, оценивались, после обсуждения и согласования адекватные замечания исправлялись в следующих итерациях. Все как в лучших практиках.НО…Как писала выше, после использования лучших практик успешно прошли приемо-сдаточные испытание, начали тиражировать приложение в промышленную эксплуатацию. Во время тиража приложение получил руководитель департамента ФЗ, начал использовать, а мы радостно и весело стали переписывать половину интерфейса приложения, так как гайдлайны Apple ничего не понимают о дизайне корпоративных приложений, и нужно было срочно сделать устаревшие формы экранов из iPad на iPhone.Выводы или зачем нужна эта статьяКазалось бы, все просто: методологии Agile в своих принципах нацелены на минимизацию рисков путем сведения разработки к серии итераций и постоянному тесному контакту со стейкхолдерами. Не согласовали дизайн приложения и свои многочисленные макеты со всеми заинтересованными стейкхолдерами – сами виноваты, у вас было 18 поставок, чтобы спросить ключевого пользователя, что не так. А еще одно из главных достоинств Agile – это отсутствие бюрократии. Только российская действительность и некоторые полукоммерческие предприятия, даже с внедренным у себя Agile, не готовы отказаться от бюрократии и жесткой иерархии в своих структурах, а большие начальники порой не готовы участвовать в проектной работе. Проектные команды могут сколько угодно формировать списки стейкхолдеров, проводить демонстрации и соблюдать все принципы гибких методологий, но не смогут избежать рисков того, что по итогу продукт придется переделывать. А как работать с рисками недоступности стейкхолдеров, да и в принципе как работать с рисками методологии Agile не учат. Потому что это про продукт, а не про риски при его выпуске. Собственно, возникшую проблему после опытной эксплуатации продукта решали другими методологиями, где подробно рассматривается управления рисками. И как учит туториал Хабра: «Неуспешные кейсы тоже полезны, они помогут кому-то не наступать на грабли, на которые другие уже наступали». Не скажу, что мой кейс неуспешен, сотрудники Заказчика пользуются продуктом уже несколько лет, в рамках проекта были достигнуты почти все поставленные цели. Но мой кейс – один из примеров, когда нельзя забывать о стратегиях управления рисками в угоду пропаганде повсеместного использования Agile.
===========
Источник:
habr.com
===========
Похожие новости:
- [Agile] Сертификации в Agile. Пара слов для HR и для коллег-разработчиков
- [Agile] Disciplined Agile. В чем смысл?
- [Тестирование IT-систем, Big Data, Agile, Будущее здесь, IT-компании] Тестирование ПО в мире пост-COVID: Big Data, AI, Smart Machines, IoT, 5G, Robotics (перевод)
- [Agile] 10 примеров эффективного общения для тестировщиков (перевод)
- [Разработка игр, Управление продуктом, Игры и игровые приставки, IT-компании] CD Projekt Red признала, что «игнорировала сигналы» о проблемах с Cyberpunk 2077 на консолях Xbox One и PlayStation 4
- [Управление проектами, Развитие стартапа, Управление персоналом, IT-компании] Как мы находим, адаптируем и сохраняем IT-специалистов в кровавом энтерпрайзе
- [Управление разработкой, Управление проектами, Управление продуктом, Управление персоналом, Бизнес-модели] А будет больно? Чего не стоит бояться, когда работаешь с ИТ-аутстаффингом
- [IT-инфраструктура, Управление проектами] Как попадает товар в магазины «Леруа Мерлен» с точки зрения математики заказа
- [Управление разработкой, Управление проектами, Управление продуктом, Управление персоналом] Представляем YouTrack Lite
- [IT-инфраструктура, CRM-системы, Управление проектами, Софт] Не ведаю, что хочу. Как не надо выбирать CRM-систему
Теги для поиска: #_upravlenie_proektami (Управление проектами), #_agile, #_upravlenie_produktom (Управление продуктом), #_upravlenie_proektami (управление проектами), #_upravlenie_produktom (управление продуктом), #_agile, #_gibkie_metodologii (гибкие методологии), #_upravlenie_riskami (управление рисками), #_riski (риски), #_upravlenie_proektami (
Управление проектами
), #_agile, #_upravlenie_produktom (
Управление продуктом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 06-Окт 03:30
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 7 месяцев |
|
|
Дано:
 Почему Agile не помогВ рамках каждой итерации готовились кликабельные макеты приложения, которые детально согласовывали со стейкхолдерами Заказчика (как и учит Agile). Заказчик со своей стороны собрал пилотную группу из будущих пользователей около 10 человек (в которую также входили лица, принимающие решение «наверху») для апробации будущего продукта. Согласованные макеты превращались в приложение, и каждый выпуск промежуточной законченной версии продукта позволял пилотной группе «пощупать» и дать свой фидбек. Все замечания обрабатывались, обсуждались, оценивались, после обсуждения и согласования адекватные замечания исправлялись в следующих итерациях. Все как в лучших практиках.НО…Как писала выше, после использования лучших практик успешно прошли приемо-сдаточные испытание, начали тиражировать приложение в промышленную эксплуатацию. Во время тиража приложение получил руководитель департамента ФЗ, начал использовать, а мы радостно и весело стали переписывать половину интерфейса приложения, так как гайдлайны Apple ничего не понимают о дизайне корпоративных приложений, и нужно было срочно сделать устаревшие формы экранов из iPad на iPhone.Выводы или зачем нужна эта статьяКазалось бы, все просто: методологии Agile в своих принципах нацелены на минимизацию рисков путем сведения разработки к серии итераций и постоянному тесному контакту со стейкхолдерами. Не согласовали дизайн приложения и свои многочисленные макеты со всеми заинтересованными стейкхолдерами – сами виноваты, у вас было 18 поставок, чтобы спросить ключевого пользователя, что не так. А еще одно из главных достоинств Agile – это отсутствие бюрократии. Только российская действительность и некоторые полукоммерческие предприятия, даже с внедренным у себя Agile, не готовы отказаться от бюрократии и жесткой иерархии в своих структурах, а большие начальники порой не готовы участвовать в проектной работе. Проектные команды могут сколько угодно формировать списки стейкхолдеров, проводить демонстрации и соблюдать все принципы гибких методологий, но не смогут избежать рисков того, что по итогу продукт придется переделывать. А как работать с рисками недоступности стейкхолдеров, да и в принципе как работать с рисками методологии Agile не учат. Потому что это про продукт, а не про риски при его выпуске. Собственно, возникшую проблему после опытной эксплуатации продукта решали другими методологиями, где подробно рассматривается управления рисками. И как учит туториал Хабра: «Неуспешные кейсы тоже полезны, они помогут кому-то не наступать на грабли, на которые другие уже наступали». Не скажу, что мой кейс неуспешен, сотрудники Заказчика пользуются продуктом уже несколько лет, в рамках проекта были достигнуты почти все поставленные цели. Но мой кейс – один из примеров, когда нельзя забывать о стратегиях управления рисками в угоду пропаганде повсеместного использования Agile. =========== Источник: habr.com =========== Похожие новости:
Управление проектами ), #_agile, #_upravlenie_produktom ( Управление продуктом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 06-Окт 03:30
Часовой пояс: UTC + 5