Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2025 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Agile — это стильно, модно, молодёжно
что меня всегда восхищает в американцах — так это способность делать деньги из ничего , буквально из воздуха .
простую мысль » делите большие задачи на маленькие » назвать Agile , раскрутить это до некого подобия философии и даже » образа мышления «, используя при этом много красивых и непонятных слов
зы. прошу пардона у адептов Agile , возможно я таки еще не дорос
(2)
Agile немного не про разбиение задач на маленькие.
Agile про то, когда мы задачи формулируем.
И сейчас возможно идеи, предложенные Agile, кажутся очевидными, но когда он появился это была небольшая революция.
(2)
Да ладно, что вы всё про американцев! Наши тоже так умеют! Превратить какую-то идею в философию. Нашим даже проще — можно не придумывать красивые и непонятные слова, а взять из английского языка…
(3)
Да и сейчас, честно скажем, многие до сих пор впадают в ступор от предложений работать «по-гибкому»: «как это в начале нет полного ТЗ? как это мы не знаем полную стоимость/функционал внедрения? как это постоянная тесная работа заказчиков с командой проекта?»
(4)
это обязательно . В английском одно слово зачастую и глагол и существительное и прилагательное , что очень удобно .
Agile software development — звучит красиво ,
Проворная разработка программ — ну , не очень …
если выдумать новую методику , например когда нужно кодить стоя на голове , ее
лучше назвать Upside down software development
Остается только вопрос — кто за всё это заплатит?
Повысить результативность? Да легко! Хоть до космических пределов.
Ресурсов давайте побольше раз в сто.
ЗЫ: И времени.
(7)
Если вы получите в сто раз больше ресурсов и сделаете больше в 50 раз — тут нельзя говорить про рост результативности ;-)))
Все смешалось, кони, люди… Цели, задачи, реализация — в котел, добавить личных мотиваций по вкусу… Результат в тумане. Дао пути, реализация как суть, как процесс… Хочешь стать по настоящему богатым человеком — придумай религию… Слава Богу самолеты по методике Agile не строят, поскольку паровозы не летают. Если проект не укладывается в голове, не формализуется — то и не взлетает. Идя на поводу заказчика, его хотелок, диаметрально противополжных в подразделениях предприятия приходим к успешному внедрению? Сунь Цзы принесет больше результата, нежели Agile IMHO.
Статья понравилась. Спасибо.
(10) Olga_aku — спасибо на тёплом слове.
(9) /Ушла читать Сунь Цзы/ .
Если серьезно, то у Agile методов есть серьезные ограничения. Не надо строить самолет по методике Agile — в этом Вы, sahn, совершенно правы. Самолет нужно строить по водопаду (см. мою статью ).
А вот, допустим, исследование по методам уменьшения турбулентности для самолета можно проводить по Agile. Предположили, попробовали, провели ретроспективу, попробовали еще раз и т. п.
Про хотелки — тоже всё непросто. Еще раз вспомню мысль про то, что очень часто «заказчик и пользователи считают, что знают, что именно им нужно до тех пор, пока вы не даете то, что они просили». Как раз при Agile, когда вы выдаете модель, прототип, кусочек с тем, что они заказывали — заказчики скорее осознают, что это не то, и сумеют к концу проекта одуматься и переформулировать требования. А в водопаде очень часто мы имеем записанные в ТЗ требования в формате «7 параллельных пересекающихся зеленых линий красного цвета», и никуда от них не уйдем.
P. S. А Сунь Цзы действительно надо будет почитать… Я с ним пока знакома только в переложении Владимира Тарасова, но уже понимаю, что сильный стратег…
(5) Мария, Вы все очень красиво описываете, да и я с Вами согласен, что это очень удобный и эффективный механизм, как бы его там не называли. Но теперь от Вас нужна статья «Как донести до клиента что нужно внедрять по гибкой технологии». Буквально сегодня от меня требовали стоимость внедрения ERP «под ключ» на основании двух страниц требований к системе. Как быть? Все вопросы одни и те же сколько нужно времени и денег? Предлагаю подготовить ТЗ-проект внедрения, без общей стоимости и рубля дать не хотят. А я им тут давай заливать гибкие технологии, частые поставки результатов, тесная работа.Не не катит.
(9) В общем-то, самолеты строили и по Agile. Возьмите историю любого массового боевого самолет второй мировой войны, увидите все это — постоянное изменение требований, расширение функционала, необходимость частых поставок новых модификаций, тесную работу с заказчиком. Неплохо получалось в общем-то. По водопаду тоже строили много чего. Хрестоматийный XB-70 например, или сверхзвуковые пассажирские, судьба которых не впечатляет.
У гибких (итеративных) методов работы есть один существенный минус — требуется некий специальный визионер, который видит картину целиком — и не с точки зрения текущего спринта, а с точки зрения того, к чему всё это должно прийти после завершения последнего спринта. И тут возникает концептуальная проблема — а мы не знаем какой у нас будет последний спринт. Мы плывем в потоке текущих задач — максимум что у нас есть — это бэклог, где есть какой общий список задач, но насколько он полон мы не знаем.
То есть тактически Agile великолепен, но совершенно не гарантирует качественного решения в итоге проекта. Живой пример такого проекта — это работающая конфигурация 1С, после 2-3-4 лет эксплуатации, когда она дорабатывается силами своего отдела (такие доработки достаточно близки к идеологии Agile — работа идет небольшими циклами под конкретный запрос конкретного ЛПРа) — за редким исключением ситуация там характеризуется так — «Мы вот тут наворотили в процессе. Криво конечно получилось, сейчас бы сделали по другому, но сейчас проще новую программу поставить с нуля, чем делать на текущей».
Вторая критическая проблема — это продажа таких проектов заказчику при работе в подрядной организации. Заказчики хотят фиксированную стоимость проекта +/- допустимые колебания. Agile этого совершенно не гарантирует.
(12)[
— Друзья 2 последних разбившихся самолёта показали , что наша методика уменьшения турбулентности не сработала. Какие идеи?
-. Может крылья жёлтой краской покрасим.
(15)
Я бы сказала, что такой визионер нам нужен не только при работе по Agile, но и при работе по любой методологии, включая водопад. Если финальной картины нет ни у кого в голове — мы получим что-то странное независимо от применяемой методологии.
Качественного решения никто не гарантирует ))). Но на самом деле, вы по существу правы. У Agile есть существенные ограничения, и он подходит далеко не для всех проектов. Скажем, 1С рекомендует применять гибкую методологию 1С:ТБР (технология быстрого результата) только для более-менее типовых внедрений, не сопровождающихся кардинальной переработкой архитектуры. Потому что кардинальную переработку архитектуры лучше планировать целиком, а не по кусочкам.
Это проблема, да. Большинство франчайзи, успешно или не успешно пытающиеся внедрять Agile говорят о том, что это сложно. А те, кому удается, отвечают обычно примерно следующее: «Заказчик хочет видеть фиксированную стоимость, но после провала нескольких проектов по водопаду, когда он получает абсолютно ненужный ему результат, скрипя сердце соглашается на Agile».
Как-то так…
Когда мы говорим, что «Agile великолепен, но совершенно не гарантирует качественного решения в итоге проекта», имеем ли мы в виду что он не гарантирует решения «В СРАВНЕНИИ С» другими методологиями? Есть ведь известная фраза про демократию, которая не гарантирует качественного управления (но все остальные режимы не гарантируют его как минимум в такой же степени). Насколько реально предсказуемой оказывается работа по водопадному методу, если смотреть постфактум?
Другой момент — методологии применяются к разным ситуациям. При тех уровнях неопределенности, где работают гибкие методологии, водопад не то что был бы дольше или дороже — он был бы невозможен, как невозможно плавать в пустом бассейне. Это тоже может сказываться на качестве сравнения — ведь трудно сравнивать то что есть (пусть оно и довольно кривое) с тем, чего вообще нет.
Может быть, в популярности водопада гораздо больше социально-психологических причин? Легче продать заказчику проект по водопадной модели, а потом в случае выхода за рамки обосновать его (особенно если заказчик меняет требования сам — «вы сами видите, теперь надо переделывать»), чем изначально сказать — один Бог знает, сколько это займет все (пусть это и будет правда).
(16) Для этого есть мат.моделирование, испытания в аэродинамической трубе, создание моделей и прототипов. И как правило, если выяснилось, что турбулентность выше расчетной, ни один конструктор не скажет — вот план, через 2 месяца найдем причину и устраним ее. Потому что ее, возможно нельзя устранить на данном этапе развития технологии. В принципе нельзя. Таких случаев в истории авиации тоже не мало.
а что 11 пункт съехал?
Смотрю на этот цикл статей и на другие подобные статьи в интернете — имя им легион.
Все правильно, все солидно, все взвешенно и — абсолютно бесполезно.
Ну да — объясняются концепции, если человек вообще ничего про это не слышал.
Но смех в том, что эти концепции можно разъяснить несколькими матерными предложениями. Все остальное — мишура по большей части. Чего сильно не хватает — так это реального практического «мяса».
Деталей хода реальных проектов и описание деталей действий и взаимодействий реальных команд.
Типа «и тут заказчик нам ТЫДЫЩЬ! Бегу к канбану и плачу…». Вот такое я почитал бы.
(20) Он рядом с 5-ым, я их вместе комментировала.
(13)
pro-rok — это тема, надо будет создать ))).
В двух словах, опыт мой и моих коллег:
— Заказчики бывают разные, но все хотят быстрый результат, поэтому можно прогнуть на гибкие методологии.
— После нескольких опытов проектов по Водопаду, когда результат оказался вообще не нужен, заказчики оказываются сговорчивее.
— Обещание сделать поставку с первым куском функционала позволяет замять тему «сколько будет стоить всё целиком».
Разумеется, не всех заказчиков можно убедить работать по такой схеме. Да и не всех нужно…
(21) Вообще, и в этой, и в предыдущих статьях, я стараюсь приводить конкретные примеры конкретных внедрений (максимально деперсонифицированные, ибо не хочется ничего лишнего озвучивать)…
Может быть, стоит их описывать более жизненным языком, чтобы было «ТЫДЫЩЬ!» ?…
(24) Плохо стараетесь.
(15)
Абсолютно » в точку». Я еще называю это лоскутной разработкой. Тут пришили , здесь прилепили . В итоге получается «кафтан» почти полностью сделанный из лоскутков , который трудно перекраивать , но зато он сидит по размеру и часто имеет оригинальный фасон.
(9) Почти всегда веду разработку в одиночку и по agile. На небольших проектах пока вы получите техзадание, мой пользователь уже будет вовсю использовать готовый продукт.
Да, с минимум документации (а она и не нужна, если есть всего 1 кнопка: «сделать хорошо»), да кое-где с довольно велосипедно-костыльной реализацией, зато получит то, что ему надо, а не то что хотел. И получит гораздо быстрее, приложив минимум усилий (пару раз пощупать, дать фидбэк на словах).
все больше убеждаюсь что Agile это религия, и не более того
вы еще дом постройте или операцию больному проведите
прям вижу — больной, какой еще наркоз, а кто согласовывать будет, вот тут разрез побольше сделать?…
(23)
Несомненно. Но прежде результата хотят ещё и того, чтобы было понятно что за результат они получат, в какие сроки и за какие деньги. Надо отметить, что желание вполне себе разумное
«Но есть нюансы» (с)
Редко бывает так, чтобы результат оказался совсем не нужен.
Поэтому чаще результат просто «дорабатывают напильником» до некоего работоспособного состояния.
Как минимум потому, что полный провал проекта по водопаду признавать не хочет никто, в том числе и «ответственные лица со стороны заказчика», на которых лежит значительная доля вины с точки зрения высшего руководства заказчика.
«Меня терзают смутные сомнения» (с).
Во-первых, первый кусок функционала тоже не бесплатный (я правильно понимаю?), и о его цене, сроках и содержанию клиент будет живо интересоваться.
Во-вторых, не встречал я такого ни разу такого, чтобы руководство клиента интересовалось кусками функционала. И не слышал ни разу. Как-то все больше вопросы «а сколько будет стоить весь проект?».
Вообще ваши статьи для меня весьма интересны. Вы правильно описываете недостатки водопада и я с ними в общем и целом согласен.
Но вот agile… пока представляется мне в виде какой-то хрустальной мечты, которая не выдерживает столкновения с чугунным основанием реальности. Потому что непонятно где найти высококвалифицированных и высокомотивированных сотрудников (это я о пункте 11) и где найти всецело доверяющих тебе и платежеспособных клиентов.
Мария молодец, написала статью, мы почитали, подискутировали. В очередной раз порадовались за буржуинов, эк они красивую обертку в очередной раз создали и ее плодотворно продают. Молодцы. В целом, попытка подтянуть любое внедрение под одну методику, мало перспективно. Модель системы с обратной связью, насколько отличается от парадигмы agile? А применять когда? Каковы граничные условия и ресурсы для выбора данной конкретной методики? Мне лично, этого не хватило в статье. Хорошее описание, вырванное из контекста, попытка обобщения в рамках одной статьи. Все хорошо, но чуть — чуть чего то не хватает… Перчика?. Нет. Исходных данных. Как то так. Ждем продолжения…
(29) Agile — это не про 1С. Вот и весь сказ.
(29)
Поэтому чаще результат просто «дорабатывают напильником» до некоего работоспособного состояния.
Как минимум потому, что полный провал проекта по водопаду признавать не хочет никто, в том числе и «ответственные лица со стороны заказчика», на которых лежит значительная доля вины с точки зрения высшего руководства заказчика.
Скажем так, полный провал внедренческих проектов по системам управления проектами, Workflow-системам и т. п. я, увы, видела. Когда внедряют, но не используют. Видела провал, когда 1С:УПП не получалось использовать для задач управленческого учета, только «для галочки» (из-за специфики бизнес-процессов заказчика). Формально результат проекта принят, но бизнес-ценности нет.
Про первый кусок функционала — его цену, срок и содержание, команда обычно способна внятно ответить. В конце концов, если речь идет про серию контрактов, то хотя бы первый-то контракт уже заключать надо в момент начала работы ))).
В этом случае можно назвать полную сумму, а конкретный функционал, который туда войдет уточнять по ходу.
Или, другой вариант из моей практики — размытые границы окончания внедрения и сопровождения. То есть руководство готово к тому, что поддержка ERP-системы обходится в месяц в сумму в определенных пределах. И «допиливание» некритичного функционала в таком формате и происходит.
(30)
Об этом я писала в первой статье. Система с обратной связью, где одна поставка — это итеративная модель. Система с обратной связью где много небольших поставок — это Agile.
Нюанс в том, что Agile — это не одна методика, а набор методик. Поэтому четкие границы провести сложно. Это, кстати, неплохо сделала компания 1С в описании одной конкретной методологии 1С:ТБР (технология быстрого результата), которая тоже относится к «семейству» Agile. Они прям SWOT-анализ провели с границами применения (кстати, видео-урок на эту тему лежит в открытом доступе). Там рекомендуют при помощи гибких методов реализовывать внедрения не предполагающие кардинальной переработки архитектуры.
(31)
Проблема в том, что водопад тоже подходит далеко не всегда. Претензии, высказываемые к нему вполне себе оправданы.
(34) С этим не спорю.
(32)
Можем промахнуться со стоимостью или необходимо в изначальную цену закладывать все возможные риски.
с не критичным согласен, а как быть с критичным?.
Дано: предприятие. Цель: запустить ERP с января 2019.
Соответственно нужно к этому сроку выполнить:
проектирование по отдельности(Agile) или все сразу(Водопад)
доработки
Обучение персонала
Перенос данных
Тут все критично, можно конечно «мелочевку» скинуть на период эксплуатации, но и то не все. На подобных проектах весь некритичный функционал всегда относиться на «потом».
Мое личное мнение от водопада никуда не уйдем, слишком много предприятия в свое время обжигалось на проектах внедрения, которые растягивались на неопределенный срок и бюджет, и заканчивались как говорит автор ТЯП-ЛЯП. Собственник бизнеса или руководитель хочет четко понимать объем финансирования и результат в конце. И тут рождается мысль, а что если совместить водопад и Agile, может получиться как раз та модель которая необходима для нашей суровой реальности. Про это нужно статью написать, Мария, как Вы считаете?
(21)
Для практических демонстрации практического примера в большинстве своем нанимают же консультантов.
Вы же наверняка свои знания тоже не за бесплатно предоставляете?
(27) по agile клиент получает не то что ему надо, а то, на что хватает времени и сил у него и у разработчика.
В водопаде — на что хватает денег.
В этих подходах используются разные виды ресурсов, точнее человекоемкость аджайла выше чем материалоемкость/фондоемкость.
Единственный мотив заказчика в пользу аджайла- когда внимание специалистов стоит дешевле чем готовое оборудование с готовой документацией и плановым обучением. Аджайл — это инструмент (проект исследования) для разработки водопада(стандарта), который получат следующие клиенты в следующих проектах. Успех заказчика в аджайл — это побочный эффект, а не цель. Если проект привел к привел к вырождению аджайл в тяп-ляп значит неправильно определены спринты.
Году так в 2009 читал статью по разработке на 1с и там было описан метод «быстрого прототипирования», сделал документ, сделал форму, показал пользователю, получил обратную связь, доработал, показал пользователю, получил обратную снова доработал…. но тогда это модным словом «эйджаил» не называлось ещё….
А сейчас как верно заметили выше придумали очередную религию….
А термин эйджаил в каком году вошёл в обиход?
Уже после «Смертельного марша — руководства по выживанию в безнадежных проектах». Т.е. сначала были проекты провалившиеся по каким-либо объективным причинам. После «разборов полетов» (который сам по себе не имеет смысла, без участников команды) и классификации причин провалов появились проекты безнадежные, в которых таковые причины наличествуют изначально в большой пропорции и участники проекта это осознают. Когда же проектанты научились выживать в условиях безнадежных проектов, встал вопрос о том, а не был ли возможен успех?
Аджайл это удовлетворение потребности человека в успехах, при в целом всеобщей безнадежности. Аджайл призван снизить требования и желания заказчиков до минимального допустимого уровня «на сейчас» и при этом как-нибудь не забыть о «потом».
Без глубокого понимания этой безнадежности, я бы даже сказала физического ощущения — невозможно почувствовать успех, поскольку на каждом отдельном этапе он действительно мизерный.
Если потребность в успехе у клиента и у разработчика уже удовлетворены, то аджайл это не то что можно рекомендовать клиенту. Вариант, когда потребность в успехе удовлетворена только у одной из сторон, приводит к взаимному непониманию. Аджайл — выбор двух неудачников, которые стремятся к успеху.
(39) Манифест Agile был написан, если мне не изменяет память, в 2001 году. А вообще все эти идеи гораздо старше, конечно. До работающих принципов разные умные люди часто додумываются независимо. Важно это всё описать и сделать возможной передачу опыта…
(41) acanta — вот не люблю я такой категоричности «выбор двух неудачников»…
Не для всех ситуаций Agile подходит — согласна.
Если требования можно определить на старте и уровень технической определенности высокий — Agile тоже не нужен, согласна.
Маркетолог detected
(17)
Водопадная методология на первом этапе предполагает постановку задач и их консолидацию в итоговые функциональные требования к системе и чем детальнее требования, тем лучше. Эти требования затем декомпозируются на конкретные работы по автоматизации и можно контролировать как решение конкретной задачи, так и прогресс по проекту в целом.
Для Agile итоговые требования более декларативны — большее значение имеют ситуативные предпочтения. Понятно что и то и то — декларация о намерениях, всё зависит от конкретного исполнителя, но в водопаде хотя бы нужно стараться так делать, в Scrum этого не требуется даже в теории — если ошибаюсь, поправьте — опишите какие методологии Agile содержат конкретные метрики, которые увязывают результаты текущего спринта с прогрессом по всему проекту в целом. Было бы очень интересно.
Вот тут я не соглашусь с 1С.Типовые решения лучше внедрять по Waterfall (со скидкой на реальность), а вот не типовое решение зачастую лучше идет по Scrum — потому что реально тяжело описать детальные требования к системе, которой еще нет. Тут и раннее прототипирование очень даже помогает — прежде чем писать код, лучше «видеть» как это выглядит, и рефакторинг кода по итогам готовности каких-то функциональных блоков очень даже помогает и парное программирование и пр. инструменты Agile.
Старая истина — лучше всего проект внедряет «вторая» команда. Накопленный опыт ошибок в рамках первых попыток — это бесценный опыт — тут уже и заказчик знает что он хочет и сам он гораздо более сговорчив и ставит реалистичные цели. У нас в Раздолье ситуация обратная — много обращений от тех кто внедрял 1С:ERP с использованием гибких методик и где ситуация зашла в тупик — вроде бы всё было хорошо в процессе, но бюджет съели, а систему так и не запустили в эксплуатацию. Задают вопрос — что делать? Мы вынуждены предлагать собирать новый бюджет и звать нас.
(18)
Для ответа на эти вопросы написал эту статью
Т.е.все рекомендации сводятся к одному- не показывать одному исполнителю весь бюджет проекта, а на каждое очередное внедрение «под ключ» выделять максимум половину (или треть или четверть).
— не понятно, «переключиться» — совсем? а остальное доделывать?
Конечно! обязательно доделывать, но только «потом», когда договорная цена на эти доделки поднимется выше любого альтернативного проекта. Из принципа 80/20 можно предположить что в очередной проект включается 20% текущих задач. Это при условии что бэклог проекта обновляется. Следующий проект — 20% из актуального бэклога, которые декомпозируем на спринты и т.д.
Идея водопада — не допустить повышения цен на доделки, доделывание или исправление ошибок всегда бесплатное. Таким образом пик затрат у разработчика в водопаде приходится на окончание проекта.
(30) можно что-то полезное сделать.
(50) А Вы когда такое пишите «в следующий спринт запустить оприходование и реализацию» складывается ощущение что Вы глубокий теоретик.
Вы как будете поддерживать систему где на складе что-то только появляется и исчезает — а где заказы? А что будете делать со взаиморасчетами? Вы в следующий спринт будете чистить регистры от левых движений? Перепривязывать накладные к заказам?
Не боитесь что пользователи побьют за обезьянью работу? А если их (пользователей) пара сотен?
(50)
(51)
Хм. Например в ERP, УТ 11 заказы включаются и отключаются функциональной опцией. Система изначально предполагает возможность работать без заказов и включать их при внедрении позаказного учета, если он будет необходим. Точно также как возможность включения ордерного учета и потребность в нем на складах не означает необходимости немедленно включать его при внедрении.
Иначе продолжая эту цепочку можно сказать «Реализации, поступления и заказы!? А где же коммерческие предложения и сделки? Вы потом будете привязывать заказы к сделкам?«. «А где ордерный учет, вы потом будете связывать ПТУ и ордера?» И так можно до бесконечности пока не будут включены все функциональные опции в ERP ))
Вовсе нет. При старте позаказного учета можно начать этот учет с новых документов. И ордерный учет можно запускать не с начала учета. Разумеется об этом нужно заранее предупредить заказчика и в качестве альтернативы предложить в первых инкрементах выдать цепочку «Заказ поставщику — Поступление — Реализация — Оплата». Для этого и водопадная модель и итеративная предлагают свои инструменты.
Вообще это слабо относится к теме. Просто показался некорректным пример с заказами, со взаиморасчетами более корректен. Речь изначально шла о том, что в Ваших примерах команды, внедрявшие системы, не выдавали работоспособных инкрементов, исходя из слов
И это главный признак того, что они не работали в рамках фреймворка и не применяли его. Итеративный подход конечно может привести к лоскутной автоматизации и костылям. Но это при любой модели может быть, зависит как принятие технических решений построено. BPR как раз минимизирует риск этого. Вот только неработоспособных инкрементов быть не должно. Все же нельзя обвинять машину в том, что она не работает, если ей открутили колеса и сняли двигатель ))
(30) можно что-то полезное сделать.
(50) А Вы когда такое пишите «в следующий спринт запустить оприходование и реализацию» складывается ощущение что Вы глубокий теоретик.
Вы как будете поддерживать систему где на складе что-то только появляется и исчезает — а где заказы? А что будете делать со взаиморасчетами? Вы в следующий спринт будете чистить регистры от левых движений? Перепривязывать накладные к заказам?
Не боитесь что пользователи побьют за обезьянью работу? А если их (пользователей) пара сотен?
(52)
Сколько в Вашей практике успешно выполненных проектов с числом пользователей более 100 человек?
(53) Ушел считать и думать как мерянье «у кого больше» и переход на личности относится к вопросу о корректности примеров с командами, которые не работали в рамках фреймворка и не соблюдали его требования, и выводов о неработоспособности подхода на основе этого ))
Напомню, что изначально некоторые ребята также изначально водопад закидали, что сейчас часто приводится как самый яркий пример опасностей водопада. Хотя там проблема не в водопаде, а незаинтересованности участников проекта, эффекте «второй команды внедрения» и большей склонности заказчика к сотрудничеству после первых неудач :
(50)
Вы правы. Причина провала всегда одна — у команды нет компетенций, необходимых для следующего спринта.
(54) Здесь нет перехода на личность, здесь вопрос об опыте. Я бы с интересом пообщался с человеком, который имеет реальный опыт комплексной автоматизации предприятий на продуктах класса 1С:ERP с числом рабочих мест от 100. Это та комбинация (комплексность задачи, сложность программного решения, масштаб проекта), которая порождает определенные проблемы, которые в иных случаях просто не встречаются.
Поэтому я задал прямой вопрос — сколько у Вас таких проектов есть, какую часть из них Вы делали с использованием Agile, можно ли посетить одно из этих предприятий, чтобы пообщаться лично с пользователями. Если это действительно работающая практика, то я буду рад пропиарить этот опыт в сообществе — помочь в написании развёрнутой статьи с упором на те проблемы, которые не удаётся решить в водопаде и которые были решены с помощью гибких методов.
У меня действительно есть интерес к такому опыту. И не у одного меня, думаю.
Варианты: писали программу с нуля или внедряли простое решение или внедряли проект на 50 рабочих мест, к сожалению, не интересны — там нет таких проблем.
(12)
Либо Вы откровенно не договариваете, либо предоставляете не совсем качественные услуги. Ведь именно поэтому заказчики часто недовольны, что франч сделал как просил заказчик, а потом долгие годы проблем и денежных потерь остаются с заказчиком.
Например, один из наикрутейших франчей, который получал от одной конторы огромные деньги ежемесячно, добавил уникальную кнопку на договоры, при нажатии на которую договор мог становиться либо с покупателем, либо с поставщиком. Всё по методикам (каким, не знаю и знать не хочу, хоть и рекламировали) — Штат бухгалтеров раздут (контролируют плавающие договора и контролёр за контролёрами), программистов орава, все работают, отчитываются результатах…
Ну? Вы ж понимаете, что так нельзя поступать? Вы поймите, это прописные истины и Вы их перечёркиваете: Заказчик никогда не признает ошибку, если от этого зависит голова на его плечах. Люди очень ленивы к изменениям и если привыкли с 1998 года так вести договоры, то и в 2008 году им тоже будет так привычней. Неужели Вы не знаете основу этих познаний заказчика??? Да на любом предприятии есть один или несколько зазнаек, которые точно уверены, что у них уникальные в стране (в мире) бизнес-процессы и только они являются обладателями этих знаний. Это же основы основ всех автоматизаций!
Нет, конечно же это мой хлеб — исправлять предприятия после горе-автоматизаторов, но мне же обидно за нас, за программистов. Эх… агля всё больше и больше отталкивает.
Когда работал в консалтинговой компании, левая колонка весила процентов тридцать, правая — 70. Перешел в самозанятый режим — и левая колонка обнулилась, 100% — в правой.