Comments 48
мне оч нравится фраза
"Сотрудничество с заказчиком важнее условий контракта"
Это вытекает что "делаем сейчас на все деньги, а потом обсудим изменений условий контракта"...а потом "как так что проект стал дороже на 100500млн? неее!! мы это оплачивать не будем!!"
Жаль что в суде это не работает) что прописано в контракте должно быть реализовано либо формализовано доп. соглашениями какими то...
Жаль что в суде это не работает
что? это какраз "сотрудничество важнее" не работает, работают только условия контракта
если там самовольно без ТЗ исполнитель чёто напилил, это будут проблемы исполнителя
Я про это и говорю) Сотрудничество хорошо в рамках ТЗ, не более...
Только не говорите, что подписывался контракт на разработку определенной функциональности за фиксированный бюджет, а делался он по скраму и по факту по T&M
подписывался контракт на разработку определенной функциональности за фиксированный бюджет
а как вы можете разрабатывать чтото без фиксированной вилки бюджета? подрядчик прожрет всё бабло и ничего не сделает в такой реальности, у него нет мотивации делать иначе
В договоре фиксируется стоимость часа разработки, постановка задач в трекере с оценкой там же, а дальше - любой каприз за ваши деньги.
а дальше - любой каприз за ваши деньги.
пока общий бюджет не кончится
у меня вот такой проект достался, 2 года разработки "вот вам безлимитное бабло, пилите", а на выходе нет даже интерфейса человеческого...и "оно както работает, но мы еще ниразу не запускали на реальных данных"...два бл.. года... капризы программили.
тут заказчик виноват конечно, но ограничения ТЗ и бюджетов еще и заказчика дисциплинируют, иначе работа никогда не будет закончена
А причем тут аджайл? T&M подход к бюджетированию и аджайл подход к управлению не должны превращаться в "психбольница в руках пациентов".
Кто всем этим безумием управлял-то?
Если взять канонический рафинированный скрам, то там декларируется, что "каждый спринт должен добавлять ценность". Грубо говоря мы каждый спринт чего-то выкатываем и в идеале проверяем на реальных пользователях. Вдруг мы выкатили то, что не заходит и разрабатывать его дальше смысла нет. Как могло получиться, что "мы что-то пилили два года и все еще не допилили и никто не видел что там у нас получилось"?
Только не говорите, что подписывался контракт на разработку определенной функциональности за фиксированный бюджет, а делался он по скраму
Мне кажется все так работают) Заказчик хочет получить фиксированную функциональность за понятные деньги, а лиды повсеместно внедряют скрамы т.к. это "круто, модно, молодежно" и в итоге получаем запоротой проект или поделку на коленке со свистелками, как это нравилось заказчику который постоянно лез в разработку т.к. "Сотрудничество с заказчиком важнее условий контракта"
Кто всем этим безумием управлял-то?
ну как, "команда всем управляет, люди важнее процессов" (с)
"каждый спринт должен добавлять ценность"
ценность, а кто ставит приоритеты? команда где аналитик и ПМ не следят за роадмапом (который не нужен?), а каждый спринт новую вводную приносят
Грубо говоря мы каждый спринт чего-то выкатываем и в идеале проверяем на реальных пользователях
Это когда продукт позволяет так сделать, такое не всегда возможно, а в заказной разработке особенно.
тут вопрос в том что аджайл как концепт прокатит только если продукт уже есть, живой, работает и у него полноценный rolling release цикл есть и разработка под него подстроена и клиенты тоже
Как могло получиться, что "мы что-то пилили два года и все еще не допилили и никто не видел что там у нас получилось"?
ну заказчик видел, ему нравилось, а когда дело до запуска в проде дошло, оказалось что клиенты заказчика вообще не понимают что это такое и как с этим работать...по частям всё что хотелось реализовано, а чтобы этим пользоваться надо учёную степень иметь.
В смысле "продукт уже есть". Он сам откуда-то возник или его все же кто-то сделал?
То, что вы описали - это классический бардак. Тут дело не в скраме.
В смысле "продукт уже есть". Он сам откуда-то возник или его все же кто-то сделал?
а как вы предлагаете делать продукт, если первый десяток спринтов его нельзя тестить на пользователях?
То, что вы описали - это классический бардак. Тут дело не в скраме.
а скрам бардак скрывает и никак с ним не борется
я был в команде где аджайл и скрам работал, и будучи самоназначенным тимлидом бегал по другим командам в попытках както структурировать то что мы делаем...потому что ...такой бред получался в глобальном смысле...вплоть до того что 3-4 команды пилят одно и тоже с разным названием и от разных аналитиков...клиенты (от конкретных ПМов) очень довольны, а архитектурно получается такая мешанина...потому что есть направление, а ТЗ и прочего такого лишнего не было
а как вы предлагаете делать продукт, если первый десяток спринтов его нельзя тестить на пользователях?
Мы же вроде начали с того, что у вас был проект, в котором за 2 года вообще ничего сделано не было. Ну, возьмите спринты не недельные, а двухнедельньные и назначьте демо для стейкхолдеров через 2 спринта. Пусть PO и стейкхолдеры посмотрят что там получается. Может и не на пользователях тестировать, но есть же фокус группа, внутренний заказчик и всё такое.
такой бред получался в глобальном смысле...вплоть до того что 3-4 команды пилят одно и тоже с разным названием и от разных аналитиков
А водопадный подход не исключает эту ситуацию. Здесь очевидно, что недостаточно хорошо построена коммуникация между командами, во-первых, и недостаточно продуман роадмап во вторых. Ну и плюс оказалось, что у владельцев продукта пересекающиеся зоны интереснов (что странно немного).
Мы же вроде начали с того, что у вас был проект, в котором за 2 года вообще ничего сделано не было
я попал на проект где такое было, меня взяли чтобы "всё это *дство исправить"
а так то там и демо были и даже клиентов умудрились найти и продать одному (что вылилось в срочном пилении на коленке минимальной версии нашего продукта с нуля, потому что то что было - пользоваться этим было невозможно))
можно много умных слов говорить, но аджайл без контроля, превращается бесконтрольный бардак, особенно в сложных проектах где разные модули делают разные команды с разными бюджетами и представителями заказчика. когда держать в голове весь продукт целиком у конечных разработчиков - невозможно, каждый отвечает за свой модуль...но никто не отвечает за всё сразу потому что это не вписывается в концепцию и налагает бюрократические процедуры
я это уже наблюдаю на втором проекте, на первом оно так работает долгие годы и команда сама себе мины замедленного действия пилит, а в другом мне пришлось стать тем кто следит за всеми ветками разработки сразу, чтобы попасть рамки когда проект должен НАКОНЕЦТО заработать
Суть аджайла не в том, чтобы выигрывать суды. И не в том, чтобы уложиться в бюджет. И вообще ни в чём. Суть аджайла в том, что сотрудничество с заказчиком важнее согласования условий контракта.
Суть аджайла в том, чтобы на выходе получить продукт идеально соответсвующий критериям, которые неизвестны в начале разработки. Пример - стартап проверяет гипотезы. Если все известно заранее, то аджайл там нафиг не нужен.
О да, мтс "перешел" на аджаил как и сбер на уровне внешних атрибутов) Как было там совковое управление без документации, планирования и родмапов так и осталось... истории когда все завязано на техлиде который постоянно накидывает правки потому что у него сроки по его кпи горят - нормальное дело, а постоянные полугодичные защиты проектов перед топ менеджментом делает абсолютно бессмысленным планирование дальше чем на пару спринтов...
Да, вы правы - это специфика крупной огранизации, ее практически невозможно целиком дотащить до уровня крутой продуктовой компании. Главная причина - много руководителей (так как компания огромная), и у каждого свой опыт и свое видение как правильно.
Но как человек, который начинал Agile-движ в МТС в 2015 году, могу вас заверить - тот МТС что есть сейчас и тот, который был 10 лет назад - это просто небо и земля. В разработке было прямо совсем плохо, ровно как и в Сбере того времени.
Если компаниям не нравится результат внедрения аджайл, значит, они неправильно его используют.
Нет, необязательно. Это значит, что то, что получилось, не соответствует их ожиданиям, даже если внедрено правильно. Например, стало сложнее бюджетировать, сложнее вести наём, и это не окупается более быстрым внедрением изменений в продукт
Да, отличное замечание! Недавно я работал с компанией, вот там изменения процессов остановилось на моменте, когда культура начала реально изменяться от авторитарной (все решения принимает директор) к культуре сотрудничества (каждый на своем уровне начинает задавать вопросы - а правильно ли мы делаем, а может лучше сделать вот так?).
Директор начал понимать, что теряет привычные ему рычаги управления и просто решил для себя, что это ему не подходит, лучше оставить как было.
На самом деле в этой статье автор "проговорился", упомянув, что "у заказчика постоянно меняются хотелки".
Если заказчик "внешний", и продавливает хотелки, которых не было в первоначальном договоре, то это значит, что у менеджера проекта не хватило яиц подписать доп соглашение на дополнительную работу.
Если заказчик "внутренний", то тут даже ничего подписывать не надо - вся работа через тикеты и если будут вопросы "Почему так долго/дорого" всегда будет понятно кто виноват.
Выбор между аджайлом и водопадом это не вопрос способа управления, на самом деле. Это вопрос неопределенности.
Когда у тебя есть осмеченный типовой проект дома, зачем там аджайл? Берешь и делаешь!
Но представим, что нужно построить дом для инопланетян о которых ты ничего не знаешь. И вот тут врубается аджайл. На первой итерации мы предполагаем, что они примерно как люди и строим дом как для людей. Прилетели.... Оказалось, что они ростом 3 метра.
На следующей итерации переделываем все дверные проёмы, окна, кровати и и.п. Надеюсь аналогия понятна.
Все так - весь вопрос в неопределенности. И если добавить сюда еще "мягкость" software, то есть возможность менять что угодно в коде условно достаточно дешево, то мы и получаем ситуацию, когда в любых проектах по разработке ПО разумно применять именно agile подход.
Не-не, не надо мягкость на сову натягивать. Есть огромное количество областей, в которых софт это прям буквально отлитая в граните штука. Начиная от авионики, автомобильного ПО и прочих систем с высокой критичностью, заканчивая всякими прошивками станков, которые так просто не обновишь. Ну и прочие штуки, живущие в закрытых контурах. Например, банки, госы, военка. Так что не все то мягкое, что софт :-)
Я бы здесь поспорил немного.
Софт с высокой критичностью заставляет нас особенно внимательно подходить к вопросам его качества в плане багов и незадокументированного поведения - это факт.
Но давайте возьмем для примеру автопилот на машине. Критично? Очень. Отлит ли код в граните - вряд ли, иначе бы автопилоты не развивались семимильными шагами.
А вот процедуры QA такого кода точно супер-формальные и многоступенчатые, иначе никак.
Основной минус водопадной модели в том, что у заказчика постоянно меняются хотелки по ходу проекта.
Наоборот. В "рафинированной" водопадной модели заказчик и исполнитель встречаются дважды: при подписании ТЗ, и потом акта приёмки. Заказчик не видит текущего состояния продукта и никакие хотелки у него возникать не могут в принципе. В реальности чуть иначе, но всё равно базовая идеология сохраняется: мы делаем ровно то, что заказано, а если заказчик ошибся в требованиях, то это его проблема.
А вот в эджайле регулярные изменения хотелок не просто возможны – они ещё и приветствуются, ибо целью является поставка максимальной ценности заказчику.
а как в аджайле дедлайны ставить?
у меня тоже такое было, делали учетную систему, дата сдачи отчёта через неё, условно 1 мая, постоянно вносим изменения хотелок и 20 апреля на отдельной встрече спрашиваем - ну что, 1 мая стартуем как планировали?...а у нас последние 5 спринтов шрифты в заголовке двигали и выгрузку в пдф прикручивали, вместо основного функционала..потому что ТЗ то нет..и продукт делаем в процессе..а сроки еще полгода назад все поехали..но ктож за ними следит то
а как в аджайле дедлайны ставить?
А как с заказчиком договоритесь, так и поставите. Ваша задача оценить трудоёмкость работ (я потом обычно умножаю на π/2 😁), согласовать дату релиза и что конкретно в него войдёт.
Дедлайны ставить очень легко, просто нужно это делать чуть по-другому.
Например, договорились что делаем релиз учетной системы 1 мая, значит каждый спринт задаем все вместе (мы и заказчики) себе вопрос: "Мы успеваем 1 мая? Что из важного еще не сделали? На чем правильнее всего в ближайшую неделю сфокусироваться?".
И тогда размеры шрифтов автоматически выпадут из рассмотрения, так как есть очевидно более важные вещи.
Дык у вас же спринты есть. Что вошло в спринт, то в конце его показать и надо. Вот и весь дедлайн.
есть дедлайн сдачи проекта.
Я клоню к тому что аджайл мыслит слишком мелкими итерациями, упуская весь сервис целиком
тут можно сказать "делайте правильно", но там где я видел аджайл..почти все это упускают сосредотачиваясь на конкретных задачах, забывая о том все модули как одно целое плохо работают..к примеру, мне приходилось буквально форсить некоторые задачи в у команд чтобы оно заработало вместе...и всё на фоне прям яростного сопротивления команд которые "у нас задача сделать чтобы интеграция жсончики обрабатывала мы спринты вокруг этого строим, нам плевать на ваше апи, ваша команда этим занимается"...а штатный ПМ там шрифтики перекладывал вместо того чтобы следить за командой
т.е. сам подход не подразумевает самоконтроль когда команды (если их несколько) начинают переть непонятно куда, а ПМ недостаточно квалифицирован чтобы это пресекать.
IMHO, очень часто словом Agile в проектном управлении пытаются мягко заменить словосочетание "здравый смысл", а словом Waterflow - мягко заменить словосочетание "даже ежу понятно, что так никто не работает". Но вот что интересно, после того как здравый смысл начинают называть Agile, здравый смысл на проекте начинает все больше становится похожим на Agile. В том числе и тогда, когда это противоречит здравому смыслу.
Наверное в любой хорошей идее бывают нюансы при ее реализации :)
Я тоже часто для себя называю agile здравым смыслом. Так проще находить в процессах разработки вещи, которые мы делаем просто потому что так принято, а не потому, что нам кажется это правильным. Поэтому и аппелируем к здравому смыслу.
Самый простой тест - бывает у вас на работе что-то, что вы делаете, но что вам кажется странным? А иногда вообще дичью? :)
Разные задачи могут требовать разные подходы в решении. Важно, что бы было гибкое управление, основанное на здравом смысле. Не уверен что внедрение аджайла всегда решает эту задачу.
В любом случае надо максимально выявить, что нужно заказчику. Это должна быть совместная работа, и заказчика и нас. Результат всегда должен быть задокументирован.
При этом, при разработке продукта, надо стараться, что бы его было просто и изменять и развивать. К возможным изменениям нужно относиться спокойно. Доработки, конечно, должны
дополнительно оплачиваться.
Золотые слова!
Был интересный кейс. Представитель госзаказчика внимательно слушал все мои предложения по проекту и со всем соглашался. Я был просто счастлив от такого внимательного и понятливого слушателя. Результаты наших бесед я старательно протоколировал. Через некоторое время выяснилось, что он даже не пытался понимать то, о чем ему говорят. Он считал, что все мои предложения будут реализованы ВМЕСТЕ , а не ВМЕСТО бреда который требовало ТЗ. Он так и сказал: "А зачем я буду отклонять дополнительную функциональность которую вы предлагаете? Ведь от этого стоимость и сроки проекта не изменятся. А ваши протоколы наших совещаний только подтверждают то, что вы согласны это выполнить." Хороший урок. Для меня.
Бывают ситуации, когда проще выполнить БРЕД заказчика (если это можно выполнить в строгом соответствии с ТЗ), получить о него деньги, а потом, когда он поймет, что нужно переделать - переделать, опять же за его счет. Безусловно, мы должны быть уверены, что это не повредит нашей репутации и БРЕДОМ является не все ТЗ проекта, а только ряд отдельных моментов.
Ну и если проект является социально важным, надо отстаивать свою точку зрения по максимуму.
В госзаказе конечно своя специфика, хотя инода такое бывает и в коммерческой разработке. Тут больше от личности человека зависит, и никакая методика не спасет.
Внедрение Agile чаще всего означает переход на Scrum, а в нём куча своих собственных недостатков, т.е. ситуация ещё сильнее ухудшается. Почему Kanban намного лучше, чем Srum, я подробно описывал в своей статье - https://habr.com/ru/articles/869164/. Многие моменты из неё перекликаются с текущей статьёй.
Несмотря на то, что ваша статья выглядит полностью написанной chatGPT, прокомментирую :)
Мир не бывает однобоким, и поэтому Канбан не лучше Скрама, как и наоборот. Это просто два подхода, и вы можете пользоваться любым из них, не пользоваться никаким, или попробовать СкрамБан (хотя это конечно сомнительная практика).
Во многих случаях канбан-метод хорош (вот примеры), но скрам в разработке хорошо помогает научиться поставлять осязаемый результат в короткий промежуток времени.
В общем каждый выбирает себе инструменты под рабочий контекст.
доверять команде самостоятельно принимать решения
Будь я командой, у меня постоянно было бы решение "я на этой неделе без сил, давайте сделаем чуть-чуть и свалимся спать"
Нам помог сервис: https://soundmemes.ru
Хуже всего - когда СЕО сверху прилетает команда: "Внедрить Agile за 2 месяца". Вопрос: "Каким образом перевести с водопада проект ,который уже несколько месяцев находится в работке ,и до конца еще несколько месяцев" - остается без ответа. Зато каждый день капают на мозг: "Переходите на Agile, бегом!" ,в результате чего проектный офис разбегается практически в полном составе. В одном чешском банке была такая история.
Кто-нибудь переживал процесс перехода на Agile? Как вы справились?