Когда Agile не работает: несколько примеров

Agile — наше всё. Причём его любят как разработчики, так и заказчики. Но есть проекты или их фазы, в которых Agile не работает или работает гораздо хуже старого доброго Waterfall. На моих проектах команды интуитивно чувствуют, когда сработает, а когда нет, когда пришло время заканчивать с Waterfall и переходить на Scrum или наоборот. Так почему и когда именно? От чего это зависит?

Пока я думал над этим, в Минске прошла IBA Conf, и я обсудил вопрос с Асхатом Уразбаевым и Дмитрием Безуглым. А их опыт просто бесценен. Ещё большой вклад в эту статью внесла Тоня Бинецкая, подсказав, что же собственно делать.

Особо подчеркну, что в этой статье будет рассматриваться успех проекта с точки зрения бизнеса, а не команды исполнителя. В чём разница? Очень просто. С точки зрения команды исполнителя проект успешен, если приложение разработано в соответствии с требованиями заказчика, акт подписан, заказчик заплатил деньги за работу, пришла зарплата и премия. А вот с позиции бизнеса проект считается успешным, только если он действительно помог достигнуть бизнес-цель, ради которой задумывался. Будь то получение прибыли от запуска нового продукта или услуги, захват части рынка, требования закона или социальная необходимость. Причём ещё очень важно достигнуть бизнес-цель вовремя. То есть, сроки у нас, как всегда, сжаты и требования по качеству высоки. Поставьте себя на место заказчика и давайте посмотрим, когда Agile не работает или работает плохо.

1. Содержание работ. Bullshit на входе = bullshit на выходе

Я сейчас делаю маленький веб-проект для себя. Диалог с разработчиком:

— Требования есть?

— Нет… (facepalm).

— Ясно! Тогда работаем по 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), уже не суть важно. Работать и выбирать методологии нужно, руководствуясь здравым смыслом в зависимости от конкретных условий каждого проекта. Помня при этом, что во главе угла должно стоять достижение бизнес-цели заказчика, а не «срубить побольше денег». Иначе чем мы будем отличаться от индийских коллег?

Нашли в тексте ошибку — выделите её и нажмите Ctrl+Enter.
Вакансии
Новые комментарии

Обсуждение

Missing-male
+4

Ха, лучше расскажите, когда Agile работает...

Missing
+3

Годно! Кстати я не люблю аджайл. Так что любят его не все

Missing-male
SEU
– Director, Delivery в EIS Group

+4

Agile или какие-либо другие подходы к разработке проектов не надо любить или не любить. Это инструменты которые надо использовать в нужное время и в нужном месте так как у всех их есть сильные и слабые стороны.

Вывод у автора верно написан, но вот аргументация "против" Agile не очень. Например пункт 1: в разработку входят с приоритезированным бэклогом одобренным заказчиком - разве это не высокоуровневое понимание что делать будем?

Picture_432?1356409809
+14

Нужно разделять мух и котлет. Если ты в разработку вступаешь с посылом "мы не знаем, что хотим", то у разработки может быть одна единственная цель — узнать, что же мы хотим. Вторая цель — распил бабла, но мы же рассматриваем честного беларуского разработчика. Garbage in — garbage out. Универсальное правило, которое работает для любого процесса.

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

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

Missing
+1

"Дело не в процессах, дело в людях. Все остальное вторично". Зачем же по принципу китайских пионеров сначала создавать людям трудности, а затем их героически преодолевать???? Может лучше людям помочь, процессы там удобные создать. Об этом и статья

Missing
+2

очень точно. и могу только добавить одну цитату из далекого 1935 года:

"Товарищи!

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

Ee0de4fca84c8c3e0d8dbe3424baf643?1401052271
+7

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

Почти 50 лет назад Ройс в своих трудах описал прекрасную модель и её вариации, а сейчас менеджеры-хипстеры втаптывают её в грязь не удосужившись даже почитать, хотя надо брать, модифицировать под проект и возможности современной разработки и спокойно спать, а не обсуждать на 100500 конференциях и требованиях.

Missing-male
+6

Если хочешь разбогатеть - создай свою религию (с)

Picture_432?1356409809

Ну да, все придумано до нас. Можно успокоиться и лежать на диване. Так?

Missing
-3

ну что Вы =) Лежать на диване это не наши методы.

Ee0de4fca84c8c3e0d8dbe3424baf643?1401052271

Нет, речь о том, что нужно читать. К вашему посту это тоже относится.

Missing

А! простите не понял =)

18bc3b062b778e1c928cb13afa526b9f?1529713312
+2

"Agile является патчем на водопадную модель, который регулирует приоритеты, но никак не изменяет сам процесс."

Почему он является патчем водопада?

Picture_432?1356409809

Вероятно, потому что Вячеслав прочитал Ройса.

Ee0de4fca84c8c3e0d8dbe3424baf643?1401052271

Вы правы, к сожалению, плохо знаком с другими методиками того времени, думаю, agile патч на многие из них, но вот на водопад манифест накладывается отлично, знаю по своему опыту.

18bc3b062b778e1c928cb13afa526b9f?1529713312

Коллеги, я не хотел бы вступать в полемику.

Мне действительно непонятна эта мысль: "Agile является патчем на водопадную модель, который регулирует приоритеты, но никак не изменяет сам процесс." и тем более в практическом ее применении: "водопад манифест накладывается отлично, знаю по своему опыту"

Вячеслав, если вас не затруднит поделиться опытом в личку или skype: pavel.vysotsky

Ee0de4fca84c8c3e0d8dbe3424baf643?1401052271
+1

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

18bc3b062b778e1c928cb13afa526b9f?1529713312
+1

Я скорее о другом. Мне непонятно почему не меняются процессы при применении Agile-подхода к Waterfall? Мы же помним о том, что Manifesto постулирует противоположные Waterfall принципы. Соответственно еще дополнительный вопрос: "Каким образом можно наложить Agile на Waterfall?"

220b18ebcbc6b461570af69990356f74?1529713220
AnthonyBY
– iOS Developer в Лаборатория А

+5

Затронута весьма любопытная тема, однако мне кажется что для данной проблематики (успех продукта с точки зрения бизнеса) не совсем актуально использовать старый добрый флэйм "Agile vs. Waterfall", немного корректней говорить о "Startup Lean (MVP) vs. полноценный комплексно работающий продукт".

Одним из самый серьёзных критиков MVP сейчас являеться Питер Тиль (co-founder at PayPal, early investor at Facebook, Twitter and Palantir Technologies). Очень рекомендую посмотреть его открытую стэнфордскую лекцию для Y Combinator - ttps://startupclass.co/lecture/83454/-welcome-and-ideas-products-teams-and-execution-part-i-sam-altman

Также почитать фрагмент книги из Zero to One.

Достаточно очевидно, что есть ниши для которых подход MVP не будет работать (особенно для кровавого энтерпрайза). Есть продукты (стартапы) о которых нельзя ничего сказать не вложив в них несколько миллионов долларов. Но это не значит, что разработка серьёзных продуктов не может ввестись по тому же Scrum (используя короткие спринты для внутренних нужд).

По большому счёту, не совсем корректно говорить о успехе решения бизнес-задачи с помощью какой бы то нибыло методологии разработки ПО. И, к сожалению, мы не можем в этом ключе выгодно выделиться перед нашими индийскими коллегами. Для решения бизнес-задач нужна экспертиза из конкретной области где введётся бизнес. Не совсем понимаю откуда у нас может появиться данный опыт.

Однако, не вериться что говорю это, но едиснтвенная компания в РБ которая позиционирует разработку ПО как business solution provider это - EPAM Systems, недавние манифестации и изменение в структуре компании на различные Competence Center - это подверждает. Разделение структуры компании не по технологиям, а экспертизам в областях — это чуть ли не единственный путь повысить маржинальность для наших аутсорсеров и успешно конкурировать по з.п. с высокодоходными продуктовыми компаниями.

Missing
-1

Всем привет! Спасибо за прекрасные комментарии!

Рад, что статья вызвала интрес.

@AnthonyBY, Антон привет! Как ты? очень клевый коммент! Посмотрим, судя по всему контента наберется на целый доклад на IT Spring =)

220b18ebcbc6b461570af69990356f74?1529713220
AnthonyBY
– iOS Developer в Лаборатория А

+1

Алексей привет! Спасибо за дискутабельную статью :)

Да, тема достаточно интересная, будет круто если ты сможешь её раскрыть на IT Spring.

P.S. я ещё зиму буду азиатить. Выпускаю MVP-шки под iOS как горячие пирожки и очень скучаю по нормальным процессам разработки ПО :)

Missing-male
Виталий Красильников
– Старший разработчик в Adform BY

+3

Привет, Алексей. Спасибо за статью. Выскажу свою точку зрения. Я не очень понимаю, почему Waterfall противопоставляется Agile, обычно Waterfall является антиподом итеративного процесса. Итеративный процесс - это не только Agile. Прошу меня здесь поправить, если я что-то упускаю. Так вот, те самые итерации уменьшают время обратной связи между заинтересованными сторонами, например BA и QA, заказчиком и исполнителем.

Как при использовании Waterfall исключить появление следующей проблемы: стадии анализа требований и написания дизайн-документа пройдены, кодирование закончено и QA находит баг, фикс для которого меняет дизайн системы/компонента? Насколько я понимаю, Waterfall на стадию maintenance оставляет лишь мелкие баги. Выходит, что проблема, найденная слишком поздно, увеличивает стоимость продукта почти в 2 раза, потому что об этой проблеме стало известно не через 2 недели (как при итеративном подходе [SCRUM]), а через 2 месяца, когда уже все должно быть готово. На практике же сроки не сдвигаются, а используется такой метод народного программирования, как "костыль". Неужели можно сесть и так крепко подумать, чтобы все предусмотреть для проекта на 6 месяцев и 10 человек? Я понимаю, что Waterfall идеален для промышленности, когда остановить конвейер слишком дорого, но для софта предусмотреть все заранее очень тяжело в силу меняющихся требований и среды (выходят новые версии браузеров и операционных систем).

Теперь поговорим об оценке. Как оценить весь проект по Waterfall? Достоверную оценку можно дать, пройдя стадии Requirements specification и Design. Иначе оценка будет приблизительной и будет базироваться на velocity команды, как и в итеративном подходе (например SCRUM). Еще возможно, что после шагов Requirements specification и Design оценка проекта не устроит заказчика.

Я считаю, что менеджеры используют Waterfall для проектов с жестким дедлайном, потому что он позволяет проще планировать, а проблемы в ходе разработки продукта всегда можно списать на программистов, BA, QA, которые что-то не предусмотрели на предыдущих стадиях и должны это исправить за счет личного времени (стратегия кнута и закручивания гаек). Другими словами Waterfall в сфере разработки стандартного офисного корпоративного софта для проектов с жестким дедлайном - индикатор неграмотности менеджера как руководителя. Однако если времени и денег много, требования в ходе работ меняться не могут, то Waterfall может привести к более качественному продукту на выходе из-за детальной проработки архитектуры. Это может быть необходимо, например, в авиационной промышленности, в которой как раз и работал Ройc, создатель Waterfall.

Missing
+1

Вы совершенно правы! О том и речь, что лучше методологии смешивать. Выработка требований и дизайн - пусть будет по Waterfall или RUP. разработка - любая гибкая методология. Внедрение или выход в прод - снова Waterfall или RUP. Честно признаюсь, что чистый Waterfall от начала и до конца я за 14 лет не встретил ни разу. Всегда был какой то микс в той, или иной степени =)

Missing-male

Так даже "выработка требований и дизайн" скорее всего будет итеративной, потому что сразу всего не предусмотришь. А внедрение - тем более. Так что да, рулят миксы )

18bc3b062b778e1c928cb13afa526b9f?1529713312
+1

"Другими словами Waterfall в сфере разработки стандартного офисного корпоративного софта для проектов с жестким дедлайном - индикатор неграмотности менеджера как руководителя."

Позволю поправить: Неверный выбор модели Waterfall там, где нужно выбрать другую - индикатор неграмотности руководителя проекта.

Что касается задачи "Как при использовании Waterfall исключить появление следующей проблемы: стадии анализа требований и написания дизайн-документа пройдены, кодирование закончено и QA находит баг, фикс для которого меняет дизайн системы/компонента?", то она была решена еще до появления Manifesto.

Missing-male
+5

когда этот идиотизм с аджайлом закончиться. понятие высосанное из пальца. работают по ситуации, но всегда, повторяю. всегда этот процесс итеративный так есть сегодня, так было вчера и 20 лет тому назад. вопрос только в длительности итерации. если кто любит красивые броские названия, то можете называть аджайл РУПом на короткой дистанции, никакой разницы.

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

Missing-male

такая "мелочь" как длительность итерации собствено и определяет будет бабло или продукт устареет еще до полки.

0cca63f66f0eb9eb487db4430b124e8e?1399482310

Отличная статья, особенно потравилось про фазу "Херачим!"

Missing-male
+1

Толстовато Алексей набросил...

Missing
-1

Володя привет! Рад тебя видеть! В крупную клетку. Все верно =) Ребята очень хорошие и умные комментарии отписали. Возможно, разберу детально на IT Spring

Missing-male
+3

Если спросить у комментаторов, что такое Agile, мы получим столько разных ответов, сколько комментаторов было опрошено.

А автор статьи добавит ещё один отличающийся ответ.

Аналогичная ситуация наблюдается в статьях о менеджменте и на некоторые другие демагогические темы.

Поэтому в статье объективна только одна фраза:

"на каждом проекте, как ты его ни планируй, рано или поздно наступает фаза «Херачим!»"

Missing-male
+2

А я по поводу последней фразы не понял - с каких это пор мы чем-то отличаемся от индийских коллег? :)

Пока это аутсорс - всё то же самое, насколько я вижу, разве что значительно отстаем от них по объемам.

Missing
-1

Хочется верить что все же отличаемся. Другая культура и другая ответственность. Как следствие, разное качество кода.

Missing-male
+3

Культура да, разная, но корреляция с качеством кода у этого факта слабая. А качество кода разное и тут и там, просто там из-за гигантских объемов заказов и написанного кода чисто статистически разброс этого качества очень большой. Это как факт о том, что в Китае людей с IQ гения больше, чем вообще людей в США - это же не означает что китайцы такие умные, просто их много и всё. Ну и к тому же вы наверняка не будете отрицать, что в белорусском аутсорсе работает очень много откровенно слабых "программистов" (некоторых вообще так назвать нельзя) и начинающих студентов (в том числе и в IBA). А в то же время, если съездите в под Сан-Франциско посмотреть кто работает в самых лучших IT компаниях мира, увидите какой огромный процент из них индусов.

А по теме статьи соглашусь с Михаилом, что решают люди, а не методологии, поэтому задача менеджера в первую очередь не мешать им делать свою работу, а уже во вторую очередь пытаться помочь повысить эффетивность :)


Авторизуйтесь, чтобы оставлять комментарии

Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси