Что такое Agile mindset или, говоря по-русски, пронырливый образ мысли

Управление - Управление проектом

40
Мне понравился встретившийся на просторах интернета перевод английского слова agile на русский – не как «гибкий», а как «пронырливый». В этом что-то есть – управлять проектом за счет пронырливых методов и пронырливости проектной команды. В этой статье я расскажу про то, почему для управления современными проектами необходимо быть пронырливым, а также как это выглядит в реальных командах по внедрению.

Я начинаю серию статей, посвященных образу мысли Agile. Американский институт PMI, законодатель мировых стандартов по проектному управлению, наконец, заметил существование Agile – гибких методов управления проектами. И выпустил по этому поводу несколько руководств:

  • 6-ую версию PMBOK, где в каждом разделе рассказывается про методы и инструменты гибкой методологии управления проектами.
  • Введение в Agile – Agile Guide.
  • И книгу, направленную на создание в голове руководителей проектов того, что  PMI называет Agile mindset (гибкий образ мысли) – «PMI-ACP Exam Prep: A Course in a Book for Passing the PMI Agile Certified Practitioner (PMI-ACP) Exam». 

Коль скоро я со всей этой литературой, частично на русский язык не переведенной, внимательно ознакомилась, попробую выделить из нее самое ценное для читателей Инфостарта. Серия статей по Agile, которую я планирую здесь опубликовать, основана на двух вещах:

  • на идеях и предложениях от адептов проектного управления PMI, изложенных в вышеупомянутой литературе;
  • на практическом опыте приложения указанных выше идей и принципов к российским ИТ-проектам и проектам внедрения 1С, в частности.

 

Откуда вообще появился подход Agile? Почему нам приходится быть «пронырливыми»?

Майк Гриффитс, автор третьей из упомянутых в начале статьи книг PMI, выделяет следующие принципиальные различия между производственной работой (industrial work) и работой в информационной сфере (knowledge work):

Разные подходы к работе

 

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

 

12 принципов Agile-манифеста

Итак, Agile родился как желание более эффективно выполнять «информационную работу». И для того, чтобы применять его на практике, нужно не просто регламентировать стэндап-совещания, канбан-доски и прочие атрибуты. Нужно суметь изменить взаимоотношения внутри команды и с заказчиками и сформировать тот самый «образ мысли Agile», о котором я веду сегодня речь. В чем же он заключается? Для этого давайте вернемся к истокам, к документам, которые придумал Agile Alliance, отцы-основатели гибкого подхода.
Манифест Agile я уже подробно разбирала в предыдущих статьях Можно ли объять необъятное или чем Agile отличается от водопада? и Почему Agile превращается в Тяп-ляп. Кто виноват и что делать?. Здесь я не буду повторяться и перечислю 12 принципов Agile-манифеста, а также дополню их комментариями по реализации на практике, иначе не интересно.


1.      Самое важное – удовлетворить потребности заказчика, регулярно и непрерывно поставляя необходимые ему продукты.

Антипример: «Мы собрали с заказчика требования, полная ерунда, но это его проблемы – все зафиксировано в контракте, и к нам не может быть никаких претензий».
Пример Agile: «Совещаемся с заказчиком в процессе работы, уточняя при необходимости требования, демонстрируя промежуточный результат (лучше не в текстовом описании, а в  виде конкретных решений, которые можно "потрогать")».

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

Антипример: Одна поставка в конце.
Пример Agile: В идеале – у нас несколько маленьких поставок, каждая с частью функционала, которые уже можно запускать в работу. Если невозможны промежуточные релизы, то используем моделирование и даем заказчику «поиграть» с будущим интерфейсом и протестировать в условиях, максимально приближенных к боевым.

3.      Разработчики и представители бизнеса должны ежедневно сотрудничать от начала до конца проекта.

Антипример: Без комментариев.
Пример Agile: Придумываем, как мотивировать представителей заказчика к постоянному участию в проекте. Универсального и простого решения тут быть не может, в моей практике работают: человеческие дружеские отношения, упоминание в контракте, налаженное расписание, распоряжения высшего руководства, завязка KPI заказчика на успех проекта, приглашение заказчика в ресторан (ваши варианты в комментариях).


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

Комментарий: Меня всегда восхищает этот принцип. Честно скажу, встречать с радостью получается... с трудом. Скорее, принимать как данность.
Антипример: Ситуация, когда одна сторона старательно прижимает другую к стенке. Например, заказчик настаивает на том, чтобы все переделать, «а иначе не подпишем акты». Или исполнитель, который не соглашается ударить лишний раз пальцем о палец под лозунгом «в контракте этого нет, мы этого делать не будем». Не люблю в такой ситуации обвинять одну сторону и обелять другую, просто можно констатировать, что люди «не договорились».
Пример Agile: При грамотно выстроенной системе допсоглашений, если из-за изменений требований исполнителю приходится делать двойную (тройную, четверную и так далее) работу, то она оплачивается, поскольку допсоглашение подписывается по каждой итерации отдельно. 

5.      Выполняйте проекты, привлекая мотивированных личностей. Создайте этим людям условия, дайте, что им необходимо, а затем доверьтесь – работа будет сделана.

Прокомментирую этот принцип в комплекте с еще одним, забегая вперед по списку: 

11.    Самые лучшие требования, архитектурные и технические решения рождаются у самоуправляемых команд.

Комментарий: PMBOK ссылается на концепцию X и Y Дугласа Макгрегора.
Макгрегор исследовал связь производительности труда работников с тем, насколько им передают ответственность. Часть менеджеров (их он назван руководители X), были уверены что: 

  • люди изначально не любят трудиться и при любой возможности избегают работы;
  • у людей нет честолюбия, и они стараются избавиться от ответственности, предпочитая, чтобы ими руководили;
  • больше всего люди хотят защищенности;
  • чтобы заставить работников трудиться, необходимо использовать принуждение, контроль и угрозу наказания.

А другая часть менеджеров (руководители Y), напротив, считала что: 

  • труд — процесс естественный, если условия благоприятные, работники не просто примут на себя ответственность, но будут стремиться к ней;
  • если работники приобщены к организационным целям, они будут использовать самоуправление и самоконтроль;
  • приобщение является функцией вознаграждения, связанного с достижением цели;
  • способность к творческому решению проблем есть у многих, а интеллектуальный потенциал среднего человека используется лишь частично.

И, как нетрудно догадаться, производительность работников под началом менеджеров Y оказалась в итоге выше.  Исследования Макрегора проводились в 1960-х годах, с тех пор концепции мотивации неоднократно развивались и совершенствовались. Но общая идея осталась неизменной – людям важно, чтобы им доверяли и делегировали ответственность. 

Пример и антипример: Моя практика наблюдения за руководством проектами внедрения с точки зрения модели X и Y говорит о следующем: 

  • Инициативные и здравые сотрудники от «микроменеджмента» (то есть попытки руководить каждым их шагом) портятся и увольняются. Когда им даешь инициативу – система работает лучше. 
  • Бывает такое, что ленивые и бестолковые сотрудники, когда перестаешь их жестко контролировать, а предлагаешь проявлять инициативу, пытаются сесть на шею, то есть перестают что-либо делать. Для меня это, скорее, повод с сотрудником расстаться, чем переходить с модели Y на модель X. 

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

6.      Личное общение – самый эффективный и результативный способ обмена информацией как внутри команды, так и с окружающим миром.

Комментарий: Автор семейства методологий Crystal (фреймворк внутри семейства Agile) Алистер Кокбёрн ввел специальное понятие «осмотическая коммуникация» (от слова «осмос» – проникновение через непрочные стенки). Имеется в виду, что когда люди, работающие над проектом, физически находятся в одном помещении, то информация «фоном» витает в воздухе, и все окружающие невольно оказываются в теме. Что повышает общую продуктивность работы: когда ваши коллеги обсуждают вслух проблему, имеющую отношение к проекту, вы можете принять решение, пропустить беседу мимо ушей или послушать «вполуха» и, тем самым, расширить свое представление о происходящем.
Пример Agile: Мой опыт знакомства с проектами внедрения показывает, что когда представители заказчика и исполнители работают физически в одном помещении, то эффективность работы возрастает. Заодно заказчику наглядно видно, что исполнитель занят делом. У этого могут быть свои недостатки – например, повышается шанс, что сотрудника «схантят» в организацию исполнителя, и он перейдет к ним работать. Или, например, исполнителю сложнее скрывать от заказчика, что члены команды работают над несколькими проектами одновременно. Но речь не об этом.


7.     Самый верный показатель прогресса — работающий продукт.

Пример Agile: Если вы исправно выдаете работающий продукт в конце каждой итерации (или нескольких итераций), то это лучше всего позволяет победить страхи заказчиков вроде «за что мы им платим, если неизвестно, сколько это будет стоить».
Антипример: В проектах внедрения 1С очень часто множество небольших поставок невозможно. То есть в теории возможно, но никому не нужно – клиент все-равно будет работать со старым продуктом, пока какая-то критическая масса функционала не будет реализована. Часто в такой ситуации приходится применять так называемые гибридные методы – например, WaterScrumFall.

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

Антипример: Очень часто на разработчиков наваливается заведомо больше работы, чем они могут успеть за нужное время. На практике это, увы, приводит к полной непредсказуемости результата. В период моей работы на НПК на предложение расставить приоритеты главный конструктор только отмахивался – все задачи приоритетные, все задачи срочные, все надо делать прямо сейчас (читай – отказывался от ответственности). В результате время поставки было категорически непредсказуемым.
Пример Agile:  Про WIP-лимиты и ограничение времени поставки я рассказывала в статье Канбан в условиях российской действительности (см. разделы про WIP-лимиты, про измерение потока работ). Добавить к этому могу разве что замечание, что четкий ритм работы упрощает прогнозирование и взаимопонимание с коллегами.
Я как-то имела возможность сравнить работу двух команд разработчиков на одном предприятии – обе состояли из компетентных профессионалов. Только одна работала под началом одного архитектора, добилась четкого структурирования задач и одного канала их постановки. А другой приходилось разрываться между несколькими проектами, отрабатывать ситуацию частой смены приоритетов, простаивать из-за ожидания решений от смежников и т. п. – ни о каком ритме речи идти не могло. В результате эффективность работы команд различалась буквально в разы. Выходом стало обеспечение стабильного темпа работы и для второй команды.

9.      Постоянное внимание к повышению мастерства и хороший дизайн повышают гибкость проекта.

Комментарий: Никто, я думаю, не станет спорить с тем, что «лучше быть богатым и здоровым, чем бедным и больным». В смысле, что лучше быть внимательным к повышению мастерства, и хорошо продумывать то, что мы делаем. Тем не менее, не у всех получается. Сталкиваясь в рамках своей профессиональной деятельности с разными командами разработки, я задумываюсь над вопросом, почему кто-то может? Мои версии примерно следующие:
Почему некоторые команды уделяют внимание хорошему дизайну?

  • Потому что могут себе это позволить (а не находятся непрерывно в ситуации жесткого дедлайна, когда выдохнуть некогда, а все сроки сгорели еще вчера).
  • Потому что есть внешний контроль. Например, практика code review – анализа кода. Она требует больших затрат, ибо приходится работать двум людям там, где вполне может справиться один. Зато позволяет поймать больше багов сразу, повышает самодисциплину разработчиков, взаимозаменяемость специалистов. Люди, конечно, могут сами себя мотивировать хорошо работать, но когда кроме внутренних мотиваторов есть еще и внешние, то всё работает лучше. 
  • Потому что есть выстроенная система. Когда организация находится на начальном уровне зрелости, проект внедрения вытягивается в условиях ограниченного бюджета за счет титанических усилий разработчика и аналитика – тут не до грамотной архитектуры. 

10.    Простота – искусство воздержаться от лишней работы – основа Agile.


Делаем, в первую очередь, то, что представляет для заказчика ценность. Подробнее про ценность для заказчика я собираюсь рассказать в следующей статье, а пока просто вспомню часто цитируемое исследование про частоту использования фич:

Как часто используются фичи?

Идея водопада заключается в том, чтобы реализовать все фичи единым махом (как нужные, так и не очень). Идея инкрементального управления проектом – что, в первую очередь, делаются те фичи, которые используются всегда и часто, и уже потом все остальные. Идея Agile в том, чтобы остановить проект после выполнения куска «всегда и часто», и переключиться на другие, более ценные проекты.

12.    Каждый раз в конце заранее определенного интервала времени команда размышляет, как повысить результативность своей работы, и затем вносит коррективы в процессы.

Комментарий: В этом месте как раз кроется один из способов отличить Agile от «Тяп-ляп». Это – наличие в команде рефлексии, что можно сделать лучше и где можно совершенствоваться. И применение итогов этой рефлексии на практике!

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

 

Коллеги, буду рада вашему опыту по теме. Каким образом в проектах внедрения получается проявлять «пронырливость»? Где не получается, а хотелось бы? Какими находками хочется поделиться?

40

См. также

Комментарии
Сортировка: Древо
1. genayo 04.09.18 19:24 Сейчас в теме
Agile - это стильно, модно, молодёжно https://habr.com/post/422123/
2. pm74 126 05.09.18 08:17 Сейчас в теме
что меня всегда восхищает в американцах - так это способность делать деньги из ничего , буквально из воздуха .
простую мысль " делите большие задачи на маленькие " назвать Agile , раскрутить это до некого подобия философии и даже " образа мышления ", используя при этом много красивых и непонятных слов

зы. прошу пардона у адептов Agile , возможно я таки еще не дорос
LordKim; tormozit; Gilev.Vyacheslav; Aphanas; +4 Ответить
3. Сурикат 178 05.09.18 09:11 Сейчас в теме
(2)

Agile немного не про разбиение задач на маленькие.
Agile про то, когда мы задачи формулируем.

И сейчас возможно идеи, предложенные Agile, кажутся очевидными, но когда он появился это была небольшая революция.
MariaTemchina; +1 Ответить
5. MariaTemchina 249 05.09.18 10:16 Сейчас в теме
(3)
И сейчас возможно идеи, предложенные Agile, кажутся очевидными, но когда он появился это была небольшая революция.

Да и сейчас, честно скажем, многие до сих пор впадают в ступор от предложений работать "по-гибкому": "как это в начале нет полного ТЗ? как это мы не знаем полную стоимость/функционал внедрения? как это постоянная тесная работа заказчиков с командой проекта?"
13. pro-rok 228 05.09.18 14:25 Сейчас в теме
(5) Мария, Вы все очень красиво описываете, да и я с Вами согласен, что это очень удобный и эффективный механизм, как бы его там не называли. Но теперь от Вас нужна статья "Как донести до клиента что нужно внедрять по гибкой технологии". Буквально сегодня от меня требовали стоимость внедрения ERP "под ключ" на основании двух страниц требований к системе. Как быть? Все вопросы одни и те же сколько нужно времени и денег? Предлагаю подготовить ТЗ-проект внедрения, без общей стоимости и рубля дать не хотят. А я им тут давай заливать гибкие технологии, частые поставки результатов, тесная работа.Не не катит.
23. MariaTemchina 249 05.09.18 16:25 Сейчас в теме
(13)
Но теперь от Вас нужна статья "Как донести до клиента что нужно внедрять по гибкой технологии"


pro-rok - это тема, надо будет создать ))).

В двух словах, опыт мой и моих коллег:

- Заказчики бывают разные, но все хотят быстрый результат, поэтому можно прогнуть на гибкие методологии.
- После нескольких опытов проектов по Водопаду, когда результат оказался вообще не нужен, заказчики оказываются сговорчивее.
- Обещание сделать поставку с первым куском функционала позволяет замять тему "сколько будет стоить всё целиком".

Разумеется, не всех заказчиков можно убедить работать по такой схеме. Да и не всех нужно...
29. Крококот 06.09.18 05:51 Сейчас в теме
(23)
Заказчики бывают разные, но все хотят быстрый результат

Несомненно. Но прежде результата хотят ещё и того, чтобы было понятно что за результат они получат, в какие сроки и за какие деньги. Надо отметить, что желание вполне себе разумное

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

"Но есть нюансы" (с)
Редко бывает так, чтобы результат оказался совсем не нужен.
Поэтому чаще результат просто "дорабатывают напильником" до некоего работоспособного состояния.
Как минимум потому, что полный провал проекта по водопаду признавать не хочет никто, в том числе и "ответственные лица со стороны заказчика", на которых лежит значительная доля вины с точки зрения высшего руководства заказчика.

Обещание сделать поставку с первым куском функционала позволяет замять тему "сколько будет стоить всё целиком"

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

Вообще ваши статьи для меня весьма интересны. Вы правильно описываете недостатки водопада и я с ними в общем и целом согласен.
Но вот agile... пока представляется мне в виде какой-то хрустальной мечты, которая не выдерживает столкновения с чугунным основанием реальности. Потому что непонятно где найти высококвалифицированных и высокомотивированных сотрудников (это я о пункте 11) и где найти всецело доверяющих тебе и платежеспособных клиентов.
31. genayo 06.09.18 08:20 Сейчас в теме
(29) Agile - это не про 1С. Вот и весь сказ.
34. Крококот 06.09.18 09:06 Сейчас в теме
(31)
Проблема в том, что водопад тоже подходит далеко не всегда. Претензии, высказываемые к нему вполне себе оправданы.
35. genayo 06.09.18 09:58 Сейчас в теме
32. MariaTemchina 249 06.09.18 08:39 Сейчас в теме
(29)
Редко бывает так, чтобы результат оказался совсем не нужен.
Поэтому чаще результат просто "дорабатывают напильником" до некоего работоспособного состояния.
Как минимум потому, что полный провал проекта по водопаду признавать не хочет никто, в том числе и "ответственные лица со стороны заказчика", на которых лежит значительная доля вины с точки зрения высшего руководства заказчика.

Скажем так, полный провал внедренческих проектов по системам управления проектами, Workflow-системам и т. п. я, увы, видела. Когда внедряют, но не используют. Видела провал, когда 1С:УПП не получалось использовать для задач управленческого учета, только "для галочки" (из-за специфики бизнес-процессов заказчика). Формально результат проекта принят, но бизнес-ценности нет.
Во-первых, первый кусок функционала тоже не бесплатный (я правильно понимаю?), и о его цене, сроках и содержанию клиент будет живо интересоваться.

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

Во-вторых, не встречал я такого ни разу такого, чтобы руководство клиента интересовалось кусками функционала. И не слышал ни разу. Как-то все больше вопросы "а сколько будет стоить весь проект?".

В этом случае можно назвать полную сумму, а конкретный функционал, который туда войдет уточнять по ходу.
Или, другой вариант из моей практики - размытые границы окончания внедрения и сопровождения. То есть руководство готово к тому, что поддержка ERP-системы обходится в месяц в сумму в определенных пределах. И "допиливание" некритичного функционала в таком формате и происходит.
36. pro-rok 228 06.09.18 10:24 Сейчас в теме
(32)
В этом случае можно назвать полную сумму, а конкретный функционал, который туда войдет уточнять по ходу.
Можем промахнуться со стоимостью или необходимо в изначальную цену закладывать все возможные риски.
И "допиливание" некритичного функционала
с не критичным согласен, а как быть с критичным?.

Дано: предприятие. Цель: запустить ERP с января 2019.
Соответственно нужно к этому сроку выполнить:
проектирование по отдельности(Agile) или все сразу(Водопад)
доработки
Обучение персонала
Перенос данных
Тут все критично, можно конечно "мелочевку" скинуть на период эксплуатации, но и то не все. На подобных проектах весь некритичный функционал всегда относиться на "потом".

Мое личное мнение от водопада никуда не уйдем, слишком много предприятия в свое время обжигалось на проектах внедрения, которые растягивались на неопределенный срок и бюджет, и заканчивались как говорит автор ТЯП-ЛЯП. Собственник бизнеса или руководитель хочет четко понимать объем финансирования и результат в конце. И тут рождается мысль, а что если совместить водопад и Agile, может получиться как раз та модель которая необходима для нашей суровой реальности. Про это нужно статью написать, Мария, как Вы считаете?
4. MariaTemchina 249 05.09.18 10:14 Сейчас в теме
(2)
что меня всегда восхищает в американцах - так это способность делать деньги из ничего ... используя при этом много красивых и непонятных слов

Да ладно, что вы всё про американцев! Наши тоже так умеют! Превратить какую-то идею в философию. Нашим даже проще - можно не придумывать красивые и непонятные слова, а взять из английского языка...
6. pm74 126 05.09.18 11:03 Сейчас в теме
(4)
взять из английского языка...
это обязательно . В английском одно слово зачастую и глагол и существительное и прилагательное , что очень удобно .

Agile software development - звучит красиво ,

Проворная разработка программ - ну , не очень ...

если выдумать новую методику , например когда нужно кодить стоя на голове , ее
лучше назвать Upside down software development
LordKim; Rain88; Vlad_2008; ducks01; MariaTemchina; +5 Ответить
7. Aphanas 125 05.09.18 11:04 Сейчас в теме
Остается только вопрос - кто за всё это заплатит?

Повысить результативность? Да легко! Хоть до космических пределов.
Ресурсов давайте побольше раз в сто.

ЗЫ: И времени.
8. MariaTemchina 249 05.09.18 11:25 Сейчас в теме
(7)
Повысить результативность? Да легко! Хоть до космических пределов. Ресурсов давайте побольше раз в сто.

Если вы получите в сто раз больше ресурсов и сделаете больше в 50 раз - тут нельзя говорить про рост результативности ;-)))
9. sahn 05.09.18 12:10 Сейчас в теме
Все смешалось, кони, люди... Цели, задачи, реализация - в котел, добавить личных мотиваций по вкусу... Результат в тумане. Дао пути, реализация как суть, как процесс... Хочешь стать по настоящему богатым человеком - придумай религию... Слава Богу самолеты по методике Agile не строят, поскольку паровозы не летают. Если проект не укладывается в голове, не формализуется - то и не взлетает. Идя на поводу заказчика, его хотелок, диаметрально противополжных в подразделениях предприятия приходим к успешному внедрению? Сунь Цзы принесет больше результата, нежели Agile IMHO.
Gilev.Vyacheslav; +1 Ответить
12. MariaTemchina 249 05.09.18 13:37 Сейчас в теме
(9) /Ушла читать Сунь Цзы/ .

Если серьезно, то у Agile методов есть серьезные ограничения. Не надо строить самолет по методике Agile - в этом Вы, sahn, совершенно правы. Самолет нужно строить по водопаду (см. мою статью https://infostart.ru/public/871965/ ).
А вот, допустим, исследование по методам уменьшения турбулентности для самолета можно проводить по Agile. Предположили, попробовали, провели ретроспективу, попробовали еще раз и т. п.

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

P. S. А Сунь Цзы действительно надо будет почитать... Я с ним пока знакома только в переложении Владимира Тарасова, но уже понимаю, что сильный стратег...
16. pm74 126 05.09.18 14:42 Сейчас в теме
(12)[
А вот, допустим, исследование по методам уменьшения турбулентности для самолета можно проводить по Agile. Предположили, попробовали, провели ретроспективу, попробовали еще раз и т. п.

- Друзья 2 последних разбившихся самолёта показали , что наша методика уменьшения турбулентности не сработала. Какие идеи?
-. Может крылья жёлтой краской покрасим.
Gilev.Vyacheslav; MariaTemchina; +2 Ответить
19. Дмитрий Кузнецов 3 05.09.18 15:44 Сейчас в теме
(16) Для этого есть мат.моделирование, испытания в аэродинамической трубе, создание моделей и прототипов. И как правило, если выяснилось, что турбулентность выше расчетной, ни один конструктор не скажет - вот план, через 2 месяца найдем причину и устраним ее. Потому что ее, возможно нельзя устранить на данном этапе развития технологии. В принципе нельзя. Таких случаев в истории авиации тоже не мало.
14. Дмитрий Кузнецов 3 05.09.18 14:32 Сейчас в теме
(9) В общем-то, самолеты строили и по Agile. Возьмите историю любого массового боевого самолет второй мировой войны, увидите все это - постоянное изменение требований, расширение функционала, необходимость частых поставок новых модификаций, тесную работу с заказчиком. Неплохо получалось в общем-то. По водопаду тоже строили много чего. Хрестоматийный XB-70 например, или сверхзвуковые пассажирские, судьба которых не впечатляет.
27. A1ice1990 110 05.09.18 18:33 Сейчас в теме
(9) Почти всегда веду разработку в одиночку и по agile. На небольших проектах пока вы получите техзадание, мой пользователь уже будет вовсю использовать готовый продукт.

Да, с минимум документации (а она и не нужна, если есть всего 1 кнопка: "сделать хорошо"), да кое-где с довольно велосипедно-костыльной реализацией, зато получит то, что ему надо, а не то что хотел. И получит гораздо быстрее, приложив минимум усилий (пару раз пощупать, дать фидбэк на словах).
38. acanta 44 06.09.18 12:22 Сейчас в теме
(27) по agile клиент получает не то что ему надо, а то, на что хватает времени и сил у него и у разработчика.
В водопаде - на что хватает денег.
В этих подходах используются разные виды ресурсов, точнее человекоемкость аджайла выше чем материалоемкость/фондоемкость.
Единственный мотив заказчика в пользу аджайла- когда внимание специалистов стоит дешевле чем готовое оборудование с готовой документацией и плановым обучением. Аджайл - это инструмент (проект исследования) для разработки водопада(стандарта), который получат следующие клиенты в следующих проектах. Успех заказчика в аджайл - это побочный эффект, а не цель. Если проект привел к привел к вырождению аджайл в тяп-ляп значит неправильно определены спринты.
10. Olga_aku 05.09.18 13:25 Сейчас в теме
Статья понравилась. Спасибо.
MariaTemchina; +1 Ответить
11. MariaTemchina 249 05.09.18 13:30 Сейчас в теме
(10) Olga_aku - спасибо на тёплом слове.
15. andironenko 209 05.09.18 14:37 Сейчас в теме
У гибких (итеративных) методов работы есть один существенный минус - требуется некий специальный визионер, который видит картину целиком - и не с точки зрения текущего спринта, а с точки зрения того, к чему всё это должно прийти после завершения последнего спринта. И тут возникает концептуальная проблема - а мы не знаем какой у нас будет последний спринт. Мы плывем в потоке текущих задач - максимум что у нас есть - это бэклог, где есть какой общий список задач, но насколько он полон мы не знаем.

То есть тактически Agile великолепен, но совершенно не гарантирует качественного решения в итоге проекта. Живой пример такого проекта - это работающая конфигурация 1С, после 2-3-4 лет эксплуатации, когда она дорабатывается силами своего отдела (такие доработки достаточно близки к идеологии Agile - работа идет небольшими циклами под конкретный запрос конкретного ЛПРа) - за редким исключением ситуация там характеризуется так - "Мы вот тут наворотили в процессе. Криво конечно получилось, сейчас бы сделали по другому, но сейчас проще новую программу поставить с нуля, чем делать на текущей".

Вторая критическая проблема - это продажа таких проектов заказчику при работе в подрядной организации. Заказчики хотят фиксированную стоимость проекта +/- допустимые колебания. Agile этого совершенно не гарантирует.
Gilev.Vyacheslav; +1 Ответить
17. MariaTemchina 249 05.09.18 15:26 Сейчас в теме
(15)
У гибких (итеративных) методов работы есть один существенный минус - требуется некий специальный визионер, который видит картину целиком

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

То есть тактически Agile великолепен, но совершенно не гарантирует качественного решения в итоге проекта.

Качественного решения никто не гарантирует ))). Но на самом деле, вы по существу правы. У Agile есть существенные ограничения, и он подходит далеко не для всех проектов. Скажем, 1С рекомендует применять гибкую методологию 1С:ТБР (технология быстрого результата) только для более-менее типовых внедрений, не сопровождающихся кардинальной переработкой архитектуры. Потому что кардинальную переработку архитектуры лучше планировать целиком, а не по кусочкам.

Вторая критическая проблема - это продажа таких проектов заказчику при работе в подрядной организации. Заказчики хотят фиксированную стоимость проекта +/- допустимые колебания. Agile этого совершенно не гарантирует.

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

Как-то так...
45. andironenko 209 07.09.18 11:05 Сейчас в теме
(17)
нам нужен не только при работе по Agile, но и при работе по любой методологии, включая водопад

Водопадная методология на первом этапе предполагает постановку задач и их консолидацию в итоговые функциональные требования к системе и чем детальнее требования, тем лучше. Эти требования затем декомпозируются на конкретные работы по автоматизации и можно контролировать как решение конкретной задачи, так и прогресс по проекту в целом.
Для Agile итоговые требования более декларативны - большее значение имеют ситуативные предпочтения. Понятно что и то и то - декларация о намерениях, всё зависит от конкретного исполнителя, но в водопаде хотя бы нужно стараться так делать, в Scrum этого не требуется даже в теории - если ошибаюсь, поправьте - опишите какие методологии Agile содержат конкретные метрики, которые увязывают результаты текущего спринта с прогрессом по всему проекту в целом. Было бы очень интересно.

Скажем, 1С рекомендует применять гибкую методологию 1С:ТБР (технология быстрого результата) только для более-менее типовых внедрений


Вот тут я не соглашусь с 1С.Типовые решения лучше внедрять по Waterfall (со скидкой на реальность), а вот не типовое решение зачастую лучше идет по Scrum - потому что реально тяжело описать детальные требования к системе, которой еще нет. Тут и раннее прототипирование очень даже помогает - прежде чем писать код, лучше "видеть" как это выглядит, и рефакторинг кода по итогам готовности каких-то функциональных блоков очень даже помогает и парное программирование и пр. инструменты Agile.

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


Старая истина - лучше всего проект внедряет "вторая" команда. Накопленный опыт ошибок в рамках первых попыток - это бесценный опыт - тут уже и заказчик знает что он хочет и сам он гораздо более сговорчив и ставит реалистичные цели. У нас в Раздолье ситуация обратная - много обращений от тех кто внедрял 1С:ERP с использованием гибких методик и где ситуация зашла в тупик - вроде бы всё было хорошо в процессе, но бюджет съели, а систему так и не запустили в эксплуатацию. Задают вопрос - что делать? Мы вынуждены предлагать собирать новый бюджет и звать нас.
50. VladimirL 772 07.09.18 19:56 Сейчас в теме
(45)
а систему так и не запустили в эксплуатацию

Все таки Agile - это набор ценностей и принципов, а не методик и методов, применяемых на практике. Применять можно наборы инструментов, например Scrum или Kanban. И их применение требует соблюдения определенных правил. Даже если "ценность людей выше чем ценность процессов и документации" и люди вдруг потребовали отказаться от правил ))

В случае если речь идет о скраме, то итеративный инкрементальный подход предполагает готовность продукта к выпуску в конце каждой итерации (спринта) независимо от того, решит продакт-оунер делать релиз или нет. Это фундаментальный принцип. Работа над продуктом в этой концепции - это фактически множество проектов аналогичных водопаду длинной 1-4 недели. Пускай продукт на первой итерации можно использовать только для справочного ведения НСИ, но нужно сделать так, чтобы это было ценно и применимо. На второй итерации можно запустить для оприходования и реализации. Но его действительно можно запустить. Следующая итерация - новый "водопадный" мини-проект в конце которого опять будет "инкремент" - новая версия работоспособного продукта. И оценка качества этого проекта - спринт ревью и ретроспектива. Подготовка к следующему мини-проекту для выпуска следующей жизнеспособной версии продукта.

Если 2 недели мало для создания жизнеспособного продукта - можно сделать итерацию длинной до 4 недель. Как бы такая продолжительность ни пугала. Особенно если альтернатива - "спринт" длинной в полгода )) Если же проект разогнался, инкременты стабильны и бизнес требует релизиться чаще - переходим на 2-ух недельные или даже 1-недельные спринты. Хотя это потребует больших управленческих затрат - управленческие инструменты, в основном планирование, приходится применять с большей частотой.


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


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


"Although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices." - напутствие от авторов ))


Да, подготовка продукта к тому чтобы он был работоспособен и готов к релизу в конце каждой итерации - это дополнительные затраты ресурсов. Его надо всесторонне протестировать к концу каждого спринта, подготовить поставку для релиза в виде cf- или setup- файла. И здесь не получится просто "ускориться в 4 раза". Это плата за снижение рисков и готовность инкремента к релизу. Скорость же затем можно вернуть за счет применения DevOps практик, которые к сожалению в 1С пока слабо развиты.

И конечно, если команда (в смысле бизнеса, а не группы разработчиков) не готова отказаться от идеи оторвать два колеса от автомобиля, или ставит целью исключительно увеличение скорости, а не снижения рисков за счет готовности каждого инкремента к релизу, то лучше просчитанный на полгода вперед водопадный подход. В нем может выручить высокая квалификация специалистов в команде разработки и большой опыт аналогичных крупных проектов.
55. acanta 44 08.09.18 20:32 Сейчас в теме
(50)
А потом как снег на голову оказывается, что проект на новой итерации "неожиданно" потребовал навыков, которых пока нет. "Неожиданно пришла зима".

Вы правы. Причина провала всегда одна - у команды нет компетенций, необходимых для следующего спринта.
26. pm74 126 05.09.18 17:23 Сейчас в теме
(15)
Живой пример такого проекта - это работающая конфигурация 1С, после 2-3-4 лет эксплуатации, когда она дорабатывается силами своего отдела (такие доработки достаточно близки к идеологии Agile - работа идет небольшими циклами под конкретный запрос конкретного ЛПРа) - за редким исключением ситуация там характеризуется так - "Мы вот тут наворотили в процессе. Криво конечно получилось, сейчас бы сделали по другому, но сейчас проще новую программу поставить с нуля, чем делать на текущей".


Абсолютно " в точку". Я еще называю это лоскутной разработкой. Тут пришили , здесь прилепили . В итоге получается "кафтан" почти полностью сделанный из лоскутков , который трудно перекраивать , но зато он сидит по размеру и часто имеет оригинальный фасон.
18. Дмитрий Кузнецов 3 05.09.18 15:38 Сейчас в теме
Когда мы говорим, что "Agile великолепен, но совершенно не гарантирует качественного решения в итоге проекта", имеем ли мы в виду что он не гарантирует решения "В СРАВНЕНИИ С" другими методологиями? Есть ведь известная фраза про демократию, которая не гарантирует качественного управления (но все остальные режимы не гарантируют его как минимум в такой же степени). Насколько реально предсказуемой оказывается работа по водопадному методу, если смотреть постфактум?

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

Может быть, в популярности водопада гораздо больше социально-психологических причин? Легче продать заказчику проект по водопадной модели, а потом в случае выхода за рамки обосновать его (особенно если заказчик меняет требования сам - "вы сами видите, теперь надо переделывать"), чем изначально сказать - один Бог знает, сколько это займет все (пусть это и будет правда).
VladimirL; MariaTemchina; +2 Ответить
46. andironenko 209 07.09.18 11:08 Сейчас в теме
(18)
етодологии применяются к разным ситуациям. При тех уровнях неопределенности, где работают гибкие методологии, водопад не то что был бы дольше или дороже - он был бы невозможен, как невозможно плавать в пустом бассейне. Это тоже может сказываться на качестве сравнения - в


Для ответа на эти вопросы написал эту статью https://infostart.ru/public/898904/
20. Fragster 813 05.09.18 15:55 Сейчас в теме
22. MariaTemchina 249 05.09.18 16:07 Сейчас в теме
(20) Он рядом с 5-ым, я их вместе комментировала.
21. herfis 261 05.09.18 16:05 Сейчас в теме
Смотрю на этот цикл статей и на другие подобные статьи в интернете - имя им легион.
Все правильно, все солидно, все взвешенно и - абсолютно бесполезно.
Ну да - объясняются концепции, если человек вообще ничего про это не слышал.
Но смех в том, что эти концепции можно разъяснить несколькими матерными предложениями. Все остальное - мишура по большей части. Чего сильно не хватает - так это реального практического "мяса".
Деталей хода реальных проектов и описание деталей действий и взаимодействий реальных команд.
Типа "и тут заказчик нам ТЫДЫЩЬ! Бегу к канбану и плачу...". Вот такое я почитал бы.
MariaTemchina; +1 Ответить
24. MariaTemchina 249 05.09.18 16:30 Сейчас в теме
(21) Вообще, и в этой, и в предыдущих статьях, я стараюсь приводить конкретные примеры конкретных внедрений (максимально деперсонифицированные, ибо не хочется ничего лишнего озвучивать)...

Может быть, стоит их описывать более жизненным языком, чтобы было "ТЫДЫЩЬ!" ?...
25. herfis 261 05.09.18 16:41 Сейчас в теме
37. Сурикат 178 06.09.18 10:54 Сейчас в теме
(21)
Для практических демонстрации практического примера в большинстве своем нанимают же консультантов.
Вы же наверняка свои знания тоже не за бесплатно предоставляете?
28. Gilev.Vyacheslav 1789 05.09.18 21:47 Сейчас в теме
все больше убеждаюсь что Agile это религия, и не более того
вы еще дом постройте или операцию больному проведите

прям вижу - больной, какой еще наркоз, а кто согласовывать будет, вот тут разрез побольше сделать?...
30. sahn 06.09.18 07:24 Сейчас в теме
Мария молодец, написала статью, мы почитали, подискутировали. В очередной раз порадовались за буржуинов, эк они красивую обертку в очередной раз создали и ее плодотворно продают. Молодцы. В целом, попытка подтянуть любое внедрение под одну методику, мало перспективно. Модель системы с обратной связью, насколько отличается от парадигмы agile? А применять когда? Каковы граничные условия и ресурсы для выбора данной конкретной методики? Мне лично, этого не хватило в статье. Хорошее описание, вырванное из контекста, попытка обобщения в рамках одной статьи. Все хорошо, но чуть - чуть чего то не хватает... Перчика?. Нет. Исходных данных. Как то так. Ждем продолжения...
33. MariaTemchina 249 06.09.18 08:44 Сейчас в теме
(30)
Модель системы с обратной связью, насколько отличается от парадигмы agile?

Об этом я писала в первой статье. Система с обратной связью, где одна поставка - это итеративная модель. Система с обратной связью где много небольших поставок - это Agile.
https://infostart.ru/public/871965/

А применять когда? Каковы граничные условия и ресурсы для выбора данной конкретной методики?

Нюанс в том, что Agile - это не одна методика, а набор методик. Поэтому четкие границы провести сложно. Это, кстати, неплохо сделала компания 1С в описании одной конкретной методологии 1С:ТБР (технология быстрого результата), которая тоже относится к "семейству" Agile. Они прям SWOT-анализ провели с границами применения (кстати, видео-урок на эту тему лежит в открытом доступе). Там рекомендуют при помощи гибких методов реализовывать внедрения не предполагающие кардинальной переработки архитектуры.
51. andironenko 209 08.09.18 00:26 Сейчас в теме
(30) можно что-то полезное сделать.
(50) А Вы когда такое пишите «в следующий спринт запустить оприходование и реализацию» складывается ощущение что Вы глубокий теоретик.
Вы как будете поддерживать систему где на складе что-то только появляется и исчезает - а где заказы? А что будете делать со взаиморасчетами? Вы в следующий спринт будете чистить регистры от левых движений? Перепривязывать накладные к заказам?
Не боитесь что пользователи побьют за обезьянью работу? А если их (пользователей) пара сотен?
(50)
52. VladimirL 772 08.09.18 01:29 Сейчас в теме
(51)

как будете поддерживать систему где на складе что-то только появляется и исчезает - а где заказы?


Хм. Например в ERP, УТ 11 заказы включаются и отключаются функциональной опцией. Система изначально предполагает возможность работать без заказов и включать их при внедрении позаказного учета, если он будет необходим. Точно также как возможность включения ордерного учета и потребность в нем на складах не означает необходимости немедленно включать его при внедрении.

Иначе продолжая эту цепочку можно сказать "Реализации, поступления и заказы!? А где же коммерческие предложения и сделки? Вы потом будете привязывать заказы к сделкам?". "А где ордерный учет, вы потом будете связывать ПТУ и ордера?" И так можно до бесконечности пока не будут включены все функциональные опции в ERP ))

Вовсе нет. При старте позаказного учета можно начать этот учет с новых документов. И ордерный учет можно запускать не с начала учета. Разумеется об этом нужно заранее предупредить заказчика и в качестве альтернативы предложить в первых инкрементах выдать цепочку "Заказ поставщику - Поступление - Реализация - Оплата". Для этого и водопадная модель и итеративная предлагают свои инструменты.


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

И это главный признак того, что они не работали в рамках фреймворка и не применяли его. Итеративный подход конечно может привести к лоскутной автоматизации и костылям. Но это при любой модели может быть, зависит как принятие технических решений построено. BPR как раз минимизирует риск этого. Вот только неработоспособных инкрементов быть не должно. Все же нельзя обвинять машину в том, что она не работает, если ей открутили колеса и сняли двигатель ))
MariaTemchina; +1 Ответить
53. andironenko 209 08.09.18 10:10 Сейчас в теме
(30) можно что-то полезное сделать.
(50) А Вы когда такое пишите «в следующий спринт запустить оприходование и реализацию» складывается ощущение что Вы глубокий теоретик.
Вы как будете поддерживать систему где на складе что-то только появляется и исчезает - а где заказы? А что будете делать со взаиморасчетами? Вы в следующий спринт будете чистить регистры от левых движений? Перепривязывать накладные к заказам?
Не боитесь что пользователи побьют за обезьянью работу? А если их (пользователей) пара сотен?
(52)

Сколько в Вашей практике успешно выполненных проектов с числом пользователей более 100 человек?
54. VladimirL 772 08.09.18 13:39 Сейчас в теме
(53) Ушел считать и думать как мерянье "у кого больше" и переход на личности относится к вопросу о корректности примеров с командами, которые не работали в рамках фреймворка и не соблюдали его требования, и выводов о неработоспособности подхода на основе этого ))

Напомню, что изначально некоторые ребята также изначально водопад закидали, что сейчас часто приводится как самый яркий пример опасностей водопада. Хотя там проблема не в водопаде, а незаинтересованности участников проекта, эффекте "второй команды внедрения" и большей склонности заказчика к сотрудничеству после первых неудач : Sentinel Project: 5 Lessons Learned
56. andironenko 209 08.09.18 21:35 Сейчас в теме
(54) Здесь нет перехода на личность, здесь вопрос об опыте. Я бы с интересом пообщался с человеком, который имеет реальный опыт комплексной автоматизации предприятий на продуктах класса 1С:ERP с числом рабочих мест от 100. Это та комбинация (комплексность задачи, сложность программного решения, масштаб проекта), которая порождает определенные проблемы, которые в иных случаях просто не встречаются.
Поэтому я задал прямой вопрос - сколько у Вас таких проектов есть, какую часть из них Вы делали с использованием Agile, можно ли посетить одно из этих предприятий, чтобы пообщаться лично с пользователями. Если это действительно работающая практика, то я буду рад пропиарить этот опыт в сообществе - помочь в написании развёрнутой статьи с упором на те проблемы, которые не удаётся решить в водопаде и которые были решены с помощью гибких методов.
У меня действительно есть интерес к такому опыту. И не у одного меня, думаю.
Варианты: писали программу с нуля или внедряли простое решение или внедряли проект на 50 рабочих мест, к сожалению, не интересны - там нет таких проблем.
39. TODD22 17 06.09.18 12:59 Сейчас в теме
Году так в 2009 читал статью по разработке на 1с и там было описан метод "быстрого прототипирования", сделал документ, сделал форму, показал пользователю, получил обратную связь, доработал, показал пользователю, получил обратную снова доработал.... но тогда это модным словом "эйджаил" не называлось ещё....
А сейчас как верно заметили выше придумали очередную религию....

А термин эйджаил в каком году вошёл в обиход?
42. MariaTemchina 249 06.09.18 20:47 Сейчас в теме
(39) Манифест Agile был написан, если мне не изменяет память, в 2001 году. А вообще все эти идеи гораздо старше, конечно. До работающих принципов разные умные люди часто додумываются независимо. Важно это всё описать и сделать возможной передачу опыта...
40. acanta 44 06.09.18 14:44 Сейчас в теме
Уже после "Смертельного марша - руководства по выживанию в безнадежных проектах". Т.е. сначала были проекты провалившиеся по каким-либо объективным причинам. После "разборов полетов" (который сам по себе не имеет смысла, без участников команды) и классификации причин провалов появились проекты безнадежные, в которых таковые причины наличествуют изначально в большой пропорции и участники проекта это осознают. Когда же проектанты научились выживать в условиях безнадежных проектов, встал вопрос о том, а не был ли возможен успех?
Аджайл это удовлетворение потребности человека в успехах, при в целом всеобщей безнадежности. Аджайл призван снизить требования и желания заказчиков до минимального допустимого уровня "на сейчас" и при этом как-нибудь не забыть о "потом".
Без глубокого понимания этой безнадежности, я бы даже сказала физического ощущения - невозможно почувствовать успех, поскольку на каждом отдельном этапе он действительно мизерный.
41. acanta 44 06.09.18 15:28 Сейчас в теме
Если потребность в успехе у клиента и у разработчика уже удовлетворены, то аджайл это не то что можно рекомендовать клиенту. Вариант, когда потребность в успехе удовлетворена только у одной из сторон, приводит к взаимному непониманию. Аджайл - выбор двух неудачников, которые стремятся к успеху.
43. MariaTemchina 249 06.09.18 20:49 Сейчас в теме
(41) acanta - вот не люблю я такой категоричности "выбор двух неудачников"...
Не для всех ситуаций Agile подходит - согласна.
Если требования можно определить на старте и уровень технической определенности высокий - Agile тоже не нужен, согласна.
44. Infector 120 07.09.18 09:55 Сейчас в теме
47. acanta 44 07.09.18 12:45 Сейчас в теме
Т.е.все рекомендации сводятся к одному- не показывать одному исполнителю весь бюджет проекта, а на каждое очередное внедрение "под ключ" выделять максимум половину (или треть или четверть).
48. alex-l19041 9 07.09.18 16:51 Сейчас в теме
Идея Agile в том, чтобы остановить проект после выполнения куска «всегда и часто», и переключиться на другие, более ценные проекты.
- не понятно, "переключиться" - совсем? а остальное доделывать?
49. acanta 44 07.09.18 17:09 Сейчас в теме
Конечно! обязательно доделывать, но только "потом", когда договорная цена на эти доделки поднимется выше любого альтернативного проекта. Из принципа 80/20 можно предположить что в очередной проект включается 20% текущих задач. Это при условии что бэклог проекта обновляется. Следующий проект - 20% из актуального бэклога, которые декомпозируем на спринты и т.д.
Идея водопада - не допустить повышения цен на доделки, доделывание или исправление ошибок всегда бесплатное. Таким образом пик затрат у разработчика в водопаде приходится на окончание проекта.
Оставьте свое сообщение