Кейс: как agile спас проект c «подгорающими» дедлайнами
Волею судеб в далеком 2021 (только у меня ощущение, что у нас сейчас год за 3?) меня занесло в один прекрасный проект, который, работал по классическому вотерфолу*. Казалось бы, аналитики всех видов, четкие зоны ответственности, архитекторы, тимлиды - все как в лучших домах ЛондОна. Сиди себе работай и кайфуй, что может пойти не так?
Оказывается может, не успела я прийти в себя, как мне довольно четко рассказали вводные.
Вводные:
- сдача MVP** обещана высокопоставленному бизнесу ровно через 3 месяца;
- roadmap*** нарисован;
- MVP не продуман и не описан;
- команды разработки нет, то есть в штате разработчики и аналитики, но они заняты на других продуктах, и вырывать их часы работы нужно зубами;
- технологический стек до конца не определен;
- при любой попытке оценки задачи - «обращайтесь к тимлиду», «а, ну так это задача на 40 ч/д».
То есть, попытавшись логически разложить первые этапы доставшегося мне в наследство плана с дорожной карты и сложив оценки тимлидов по всем задачам, мне захотелось плакать, т.к. не то что через квартал, мы бы и за год не закончили.
В этот момент бог Agile**** ударил меня своим трезубцем, хотя до этого мне не приходилось agile внедрять с «0», и я пошла творить.
Что было сделано:
- была проведена ревизия роадмэп и переговоры с бизнесом на предмет выявления истинной первичной потребности, а не «нам нужно все и вчера». В результате определения ценности и приоритизации бэклога были определены границы MVP;
- были достигнуты договоренности по выделению людей в продуктовую команду и принято (мной) обязательство за результат взамен возможности оценивать задачи внутри команды, не привлекая тимлидов со стороны (которые работают сразу со всеми продуктами и не успевают вовлекаться в каждый отдельный продукт достаточно, чтобы оценивать сроки без сильной перестраховки);
- MVP был условно поделен на этапы (похоже на scrum*****), которые мы разрабатывали поэтапно, то есть аналитик не стал писать сначала полноценный документ на все требуемые фичи, а мы разделились на этапы, что позволило быстрее приступать следующим участникам команды к работе над продуктом, произошло распараллеливание;
- примерно раз в 2-3 недели мы проводили демо инкремента бизнесу. И хотя мы не выдавали работающий продукт, например, мы же не могли дать МП (мобильное приложение) только с функцией авторизации, которую мы показали на первом демо, однако мы были на одной волне и оперативно получали обратную связь;
- cместили приоритеты: разработка осложнялась тем, что велась на нативных языках, и у меня была проблема с ресурсом разработчика на Swift (язык разработки под iOS), поэтому я приняла решение в первую очередь выдать МП для Android, а потом уже догнать с iOS.
Итог:
первый бета-тестер установил приложение себе на телефон под управлением Android ровно через 3 месяца, и да, он словил КУЧУ багов, но началось бета-тестирование, а это лучший способ отладки вообще всего: от технологических багов и нагрузки до удобства UX.
*вотерфол (англ. waterfall (водопад)) - каскадная последовательная модель разработки ПО со строгой очередностью этапов, сначала определение требований и аналитика, потом разработка, потом тестирование. Требования не должны меняться вплоть до выхода в прод этой версии, поэтому частенько между началом работы над проектом и до завершения на ПСИ (приёмо-сдаточные испытания) может проходить от полугода до нескольких лет, в течение которых пользователь не касается продукта.
**MVP (англ. minimum viable product) - минимально жизнеспособный продукт, то есть если мы проектируем машину, то мы даем ценность передвижения из точки А в точку Б, то есть MVP будет велосипед, на крайний случай самокат, но никак не кузов автомобиля или двигатель.
***roadmap (англ. дорожная карта) - визуализация стратегии развития продукта на ближайший квартал-год, обычно это слайдик в powerpoint
****agile (эджайл) - гибкая методология разработки продуктов, у которой есть даже манифест из 12 принципов, но суть которого заключается в том, что в любой момент времени у пользователя должен оказываться рабочий продукт, несущий в себе ценность, см. ранее про mvp. То есть с каждой новой итерацией и релизом мы выдаем рабочий продукт с новой ценностью.
*****scrum - фреймворк agile
Интересно почитать про живой опыт, узнав терминологии и о ее практике из одного поста, больше чем из курсов 🦾🏄♂️ Благодарю за статью)
Да, лично мне не хватает реальных кейсов в статьях, обычно много теории, буду по возможности делиться ими тут😊
Мне кажется, вы слишком уж жестоки к вотерфолу; к тому же требования формулируются не в жёстком виде при написании ТЗ обычно, и их реализация уже может меняться. Где-то была красивая картинка мемная про подходы, поищу :)))
Сергей, нет, возможно, по статье показалось, что я слишком люблю agile, но это не так😀. Любому подходу нужны свои условия, waterfall до сих пор успешно применяют и в госсекторе и в финансовом, медицине, то есть там, где надежность получения результата, сроки и бюджеты не поддаются изменениям. В сфере рыночных околоинновационных продуктов, там, где вы еще не можете быть уверены сразу, как будет выглядеть конечный продукт, лучше подойдет agile.
А так вы молодец, вытащили людей из серьёзной передряги. Очень сложно расшевеливать болото
Спасибо, болото, это слишком грубое слово, просто в условиях трудных вводных пришлось что-то экстренно выдумывать😂
Я правильно понимаю, что тестирование подключилось на финальном этапе, а не в процессе проработки требований и вот этого всего? Штош, зря, грамотный qa (не бета, не манки тостер, не тыкатель кнопок, а синьор и выше) мог бы помочь и аналитикам, и разработчикам сильно раньше этапа готового mvp