Agile — наше всё. Причём его любят как разработчики, так и заказчики. Но есть проекты или их фазы, в которых Agile не работает или работает гораздо хуже старого доброго Waterfall. На моих проектах команды интуитивно чувствуют, когда сработает, а когда нет, когда пришло время заканчивать с Waterfall и переходить на Scrum или наоборот. Так почему и когда именно? От чего это зависит?
Четыре вопроса к Agile
Пока я думал над этим, в Минске прошла IBA Conf, и я обсудил вопрос с Асхатом Уразбаевым и Дмитрием Безуглым. А их опыт просто бесценен. Ещё большой вклад в эту статью внесла Тоня Бинецкая, подсказав, что же собственно делать.
Особо подчеркну, что в этой статье будет рассматриваться успех проекта с точки зрения бизнеса, а не команды исполнителя. В чём разница? Очень просто. С точки зрения команды исполнителя проект успешен, если приложение разработано в соответствии с требованиями заказчика, акт подписан, заказчик заплатил деньги за работу, пришла зарплата и премия. А вот с позиции бизнеса проект считается успешным, только если он действительно помог достигнуть бизнес-цель, ради которой задумывался. Будь то получение прибыли от запуска нового продукта или услуги, захват части рынка, требования закона или социальная необходимость. Причём ещё очень важно достигнуть бизнес-цель вовремя. То есть, сроки у нас, как всегда, сжаты и требования по качеству высоки. Поставьте себя на место заказчика и давайте посмотрим, когда Agile не работает или работает плохо.
1. Содержание работ. Bullshit на входе = bullshit на выходе
Я сейчас делаю маленький веб-проект для себя. Диалог с разработчиком:
— Требования есть?
— Нет… (facepalm).
— Ясно! Тогда работаем по Agile!
Это весьма стандартный диалог с заказчиком. Agile хорош, если нет чётких требований. Но как вообще можно заходить в проект, не имея чёткого понятия, чего ты хочешь?
Да пребудет с вами Agile: гайд по основным терминам + курсы.
Да пребудет с вами Agile: гайд по основным терминам + курсы.
У каждой ценности должна быть стоимость. Нет стоимости — нет ценности. В итоге я как заказчик не хочу платить на старте проекта за разработку требований. Ну, нет у меня времени. Только желание. Тогда я должен понимать, что в итоге требования родятся в муках итераций. Следовательно, всё равно я за них заплачу. Что-то будет сделано не так, как я хотел, и не обойтись без переделок. Хорошо, когда проект небольшой, у вас отличный контакт с разработчиком, вы на одной волне и понимаете друг друга с полуслова. А если проект — большой? А если вы из Англии, а команда из РБ, и вы думаете совершенно по-разному? Переделок будет много. И тогда полетят сроки, начнётся спешка, и требования станут делиться на «Требования заказчика» и «Срочные требования заказчика». А потом придётся ввести новую категорию «Просьбы заказчика», дальше — «Беда заказчика», «Горе заказчика»… Ну, вы поняли мысль.
2. Главный вопрос: когда это закончится?
Те, кто делал ремонт, сразу меня поймут.
Проект — это ВРЕМЕННОЕ предприятие, направленное на создание уникального продукта, услуги или результата («Руководство к своду знаний по управлению проектами» (Руководство PMBOK®). Пятое издание. ©2013 Project Management Institute.)
Временное — ключевое слово в определении проекта. Agile не дает мне чётких сроков. Если у меня нет понимания, что я хочу сделать, то откуда взяться знанию, когда это закончится? Посему проект по Agile нельзя закончить — его можно только прекратить. А любой бизнесмен хочет именно с успехом завершить проект, а не прекратить его, реализовав 80% самого приоритетного бэклога. Про прямую связь между задержкой сроков и увеличением стоимости тоже понятно.
3. Вопросы по управлению кросс-функциональными командами
В проекте с командой в 5-7 человек, отвечающих за всё, вопросов нет. А если команды кросс-функциональные? Фронтэнд — в Минске, бэкэнд — в ЮАР на стороне заказчика, тестирование — в Индии (где именно — затрудняются сказать даже сами тестировщики).
Общее планирование для заказчика/руководителя проекта становится кошмаром. Нужно иметь железные нервы и фанатичный напор, чтобы работа шла синхронно. Получается очень мало у кого.
4. Беготня за зайцем по кругу
И напоследок главная, с моей точки зрения, мысль: «Agile помогает отсечь иллюзии, но это беготня за зайцем по кругу. Мы делаем то, что бизнесу нужно сейчас, не задумываясь о том, что будет нужно потом» (© Дмитрий Безуглый, http://www.system-approach.ru/).
Ну, ведь очевидно. Я много общался с бизнесом в последние два года. Этим ребятам нужно всё или ничего. Серого для них нет. Делая то, что нужно бизнесу сейчас, вы затыкаете дыры в текущей деятельности, не задумываясь о перспективе. Для того, чтобы сделать решение, которое будет востребовано через год, необходимо сесть и крепко подумать. А потом задокументировать это в требованиях.
Выводы
А делать нужно ровно то, что и так все делают. Мы сочетаем и применяем разнообразие методологий на наших проектах, а очень часто используем несколько методологий или их «микс» даже в рамках одного проекта. Разработка требований должна быть завершена до хх. хх.хххх, подготовка бэкэнда с чётко описанным функционалом — к хх. хх.хххх, точных три недели с 6 октября по 24 октября на тестирование и потом ровно неделя на выход в прод… Это жёсткое, чёткое классическое управление проектами.
На «Башорг» недавно писали, что на каждом проекте, как ты его ни планируй, рано или поздно наступает фаза «Херачим!» По какой методологии идёт разработка (Scrum, Kanban, Waterfall или RUP), уже не суть важно. Работать и выбирать методологии нужно, руководствуясь здравым смыслом в зависимости от конкретных условий каждого проекта. Помня при этом, что во главе угла должно стоять достижение бизнес-цели заказчика, а не «срубить побольше денег». Иначе чем мы будем отличаться от индийских коллег?
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.