Comments 106
Гнобить весь фрейворк по причине того, что команда не смогла корректно разделить задачии на атомарные, а скрам мастер не подобрав продолжительности сплита сосредоточился на velocity? Мне кажется, канбан скраму никак не мешает и наоборот.
Скрам в виде гибкой методологии в реальной жизни просто не работает. Как пример, я работаю в огромной корпорации, где торжественно перешли на гибкие методологии. В итоге, у всех разработчиков (несколько тысяч), спринт жестоко установлен в 2 недели, с обязательным демо в конце спринта для менеджеров уровня директоров департамента. Примерно так, оно работает и в других конторах.
Это пример того, как не разобраться и сделать криво, а не скрам не работает. Что в случае вашей организации мешало отдельным командам выбирать длину спринта индивидуально и делать демо только когда нужно? Ну и включать голову и адаптировать процессы. Если так подумать, многие правильные но хайповые идеи не работают, так как их внедряют абы как и потом страдают.
Что в случае вашей организации мешало отдельным командам выбирать
То, что топ менеджеры сходили на тренинги по SAFe (registered trademark), где им рассказали, что две недели это идеальный спринт.
Точно так же, как мы неможем делать эстимейты в «t-shirt size», потому что только имея сторипоинты можно сгенерировать красивые графики и показать топам. Почему обязательно рисовать презентацию на демо? Потому что директор департамента дупля не отстреливает, что ему показывают. А презентация «это сильно и надежно».
И моя точка зрения в том, что внедрение скрама это всегда такое порно и каргокульт.
Тогда, когда комманда может действительно гибко работать, от скрама остается только планнинг, стендапы и демо в 15 минут. Или вообще одна канбан доска.
И моя точка зрения в том, что внедрение скрама это всегда такое порно и каргокульт.
Часто. Может быть даже очень часто. Но точно не всегда.
Тогда, когда комманда может действительно гибко работать, от скрама остается только планнинг, стендапы и демо в 15 минут. Или вообще одна канбан доска.
Ну спринты вам всё-таки надо ещё оставить. Без них у вас идея скрама всё-таки теряется. Другое дело что длину спринта должна устанавливать сама команда.
И если так посмотреть, то ничего больше у вас в скраме то и не требуется. Или я что-то важное упустил?
Но где вы такое видели?
Гнобить весь фрейворк по причине того, что команда не смогла корректно разделить задачии на атомарные
Если задачи в конкретном проекте плохо делятся на сабтаски в рамках требований конкретного фреймворка — это как раз проблема фреймворка и, да, — очевидная причина сменить фреймворк.
Чем дольше я работаю тем глубже убеждаюсь что все эти скрамы с канбанами не пригодны для технически сложных проектов, где месяцы если не годы могут уйти на выработку правильной методологии/архитектуры
А все эти скрамы с канбанами годятся только для типовых проектов
Границы применимости есть у всего.
В частности, итеративная разработка, незаменима там, где неизвестно, что будет завтра. Что сделают конкуренты, что выяснят аналитики. Когда мы не можем планировать далеко.
Те же стартапы.
Под это есть даже специальный термин: запутанный домен.
В сложных системах тот же скрам не применим в чистом виде.
Но agile, в первую очередь, про гибкость. Все об этом забывают.
У нас был коуч, крутой, который говорил: да вообще пофигу, как вы будете работать. Цель — эффективность. Подстраивайте все под себя. Экспериментируйте с процессами.
А его работа — подсказывать возможные пути, изучать практики других компаний, учиться на чужих ошибках и успехах.
Все развивается таким образом, чтоб избежать подобных длительных проектов. Отсюда MVP, микросервисная архитектура и пр. Под это и пилится скрам, чтоб за две недели выкатить какой-то бизнесовый функционал.
Избавляются там, где это возможно и целесообразно.
В основном, это клиент-серверные приложения.
Сложные объемные проекты остаются. Десктопное ПО, game dev, ОСи (для тех же телевизоров) — первое, что приходит в голову.
Как вы собрались выкатывать функционал через 2 недели, если год может уйти только на поиски правильной архитектуры и смежные вопросы? По вашему после появления аджаила все сразу забили на серьезные проекты?
1. У нас тележка на двух (?) колёсах. Какие-то колёса, какие-то оси, какие-то подшипники. Катится, и ладно.
2. У нас самокат. Значит, переднее колесо уже поворотное, есть рулевая колонка… очевидно, на самокате надо будет ехать, уже требования к материалам. По сути, тележку надо переписать заново. Но поскольку той тележки десять строк кода, это мелочи.
3. Велосипед. Оппа, у нас рама. У нас большие тонкие колёса. У нас надувные шины. У нас цепочная передача. С самокатом ничего общего вообще. Всё надо делать с нуля, в том числе рассчитывать материалы.
4. Это же не электровелосипед, это мотоцикл? Внезапно, рама велосипеда совсем ни при чём, всё надо делать иначе. Надо присобачить ДВС. У нас уже совсем другие колёса, общего с предыдущими — надувные. Ну рулевую колонку можно взять с велосипеда и доработать, да, правда материалы опять другие…
5. Внезапно у нас четыре колеса. Внезапно вилка, которую мы с таким трудом проектировали, не нужна. Зубчатая передача тоже не нужна, и в целом трансмиссия существенно усложняется. Правда, можно кое-как использовать сам ДВС, да генератор с аккумулятором.
Итого — у нас вместо последовательных приближений пять разных продуктов, имеющих между собой общего в лучшем случае некоторые неочевидные тонкости реализации. 50% «сервисов» уходят на помойку к следующей итерации, 90% — через итерацию. Зато картинка красивая.
Плюс если он после установки каросерии и стекла замечает что скажем лобовое стекло его не устраивает по форме/размеру, то можно переделать каросерию пока на неё ещё не повесили двери. И получается что тогда двери переделывать не надо будет.
И так потихоньку шаг за шагом клиент получает новую машину.
Да, при переходе от каждого изделия к следующему, приходится много чего переделывать в самом изделии. Но…
1. Когда вы запустили в производство скейтборд, у вас пошли живые деньги. Не через 5 лет, а через полгода. И это совсем не то же самое, что делать с нуля автомобиль без денег, на одних обещаниях инвесторам.
2. Когда вы сделали скейтборд и начались продажи, вы уже не «тот придурок», который строит звездолет на пустом месте, а человек с опытом запуска бизнеса, которому инвесторы более охотно дают деньги. Это и корпораций касается. Там свои «инвесторы».
3. Да, для самоката нужно делать фактически новую конструкцию, но часть оборудования для производства подойдет от самоката, поставщики частично уже есть, сеть сбыта уже налажена, каналы продаж протестированы и известны. Кроме того, есть уже сработавшаяся команда, методы управления, постановки и решения задач и много чего еще.
4. Если для скейтборда достаточно команды из пары человек, то автомобиль уже может разрабатывать команда из пары тысяч человек. В итоге, мы вполне можем уложиться в те же полгода, условно говоря.
Если посмотрите на Маска, то он сначала сделал Paypa, потом Tesla, а уже потом замахнулся на Space X. И даже со Space X у него сначала простая ракета появилась, а уж потом он стал спасать первую ступень.
Если посмотрите на Маска
Я так понимаю, вы нам сейчас покажете тесла-скейтборды и тесла-велосипеды, которые были перед тесла-автомобилем?
Стоп. Это уже не MVP, это уже «запустили в производство» и «начались продажи»?
Откуда про MVP за 4 спринта? В настоящем скраме вам могут сказать, что цель — создать MVP. За сколько вы его создадите и какие работы будут входить в состав — решаете вы.
На первый взгляд — нет такого правила, что mvp за 4 недели. Кроме того, рефакторинг и архитектуру вообще можно вынести за mvp и делать только если прототип окажется кому-то нужен. Тут правда всплывает другой тонкий момент — руководство захочет пускать в прод как есть и надо быть готовым отстоять время на приведение кода в порядок.
А спринты могут длится месяца по 2.
И тут дело не в том, что кто то из нас — или мы все — некомпетентны и не умеем это готовить. Просто повторю специфика такая, а так за это время в муках выработали для себя более-менее приемлемый симбиоз, при котором развитие проекта в наших условиях происходит максимально продуктивно…
Месяц назад появляется новый менеджер, конечно же эффективный. Решивший, что этого его качества буквально не хватает ни нам ни проекту. И вот у нас уже сегодня слово в слово как в заголовке — долой скрам, на здравствует канбан. Типа это все изменит.
на 100% согласен — на крупных проектах фанатичные скрамы и канбаны не помогают, а только делают проект дороже, и зачастую бесконечным…
проверено много раз на практике…
а на мелких проектах скрамы и канбаны больше нужны для руководителей сомневающихся в своей команде исполнителей…
Чтобы это понять и верно оценить, нужен толковый начальник. И ему для этого не нужны скрамы с канбанами, если вы у него один, и он в процессе живого общения может регулярно оценивать, как продвигается ваша работа. Но если работников у него много, каждый занимается своими задачами в своем темпе, а у начальника есть еще и другие обязанности кроме отслеживания успехов работников, ему становится очень напряжно держать все процессы в команде под контролем. Потому что команда большая, процессов разных много и они разной сложности и длительности. И он, если не дурак, начинает придумывать какие-то ритуалы, позволяющие как-то систематизировать управление и контроль. Например, ежедневные пятиминутные летучки, типа как в совке по утрам были. Потом понимает, что этого все равно мало, и надо бы как-то все записывать, потому что уж очень много всего. Потом понимает, что сложные и длительные процессы надо стараться разбивать на более простые и короткие, потому что так легче отслеживать прогресс (или его отсутствие). И т.д. и т.п. В общем, постоянно оптимизирует свою систему. Либо берет уже готовую систему, чтобы не изобретать велосипед — вот эти вот скрамы с канбанами.
Проблемы начинаются тогда, когда скрамы с канбанами внедряются как карго-культ, без понимания. Как аборигены, которые строят самолет из говна и палок, чтобы он принес им вкусные ништяки. Ништяки волшебным образом почему-то не появляются, и аборигены говорят «фигня эти самолеты, отстой, не работает оно».
Да контроль нужен, но зачем нужны какие-то фреймворки с описанием на сотни страниц?
Хм, а где вы в скраме увидели «описание на сотни страниц»? Я помню нам раздали методичку и там всё влезло на две стороны обычного А4.
Неужто разработчики на столько глупые что сами не могут прогресс в решении задач как-то описать?
Ну по моему опыту большинство программистов просто банально не хотят таким заниматься. То есть программистов обычно мало интересует как там выглядят их процессы для других людей и насколько они прозрачны, повторяемы, скалируемы и т.д. и т.п.
Плюс как бы если там какой-то программист взял и придумал себе процессы, а потом уволился. То что потом всей фирме заново подстраиваться под процессы человека, которого возмут на его место? А если у вас фирма растёт и вы наняли несколько новых людей, а у каждого из них свой собственный процесс? Получается нужны какие-то более-менее общие стандарты.
А можете рассказать как вы строите процессы при разработке таких продуктов? А заодно пояснить как вы разделяте их на типовые и сложные?
Чем дольше я работаю тем глубже убеждаюсь что все эти скрамы с канбанами не пригодны для технически сложных проектов, где месяцы если не годы могут уйти на выработку правильной методологии/архитектуры
А все эти скрамы с канбанами годятся только для типовых проектов
Если посмотреть на технические задачи «дизайн» «анализ» и т.д. как на задачи у которых заказчик «команда», то все вполне ложится в «скрамы-канбаны» поскольку «business value» в конце итерации это найденные решения, идентифицированные риски, «физика» базы данных\API\файла и т. д.
Будет не одна команда, а несколько из одного или нескольких человек. не большая проблема
Скрам — это фреймворк.
И в нем всегда есть Product Owner (PO).
А канбан, приведу цитату скрамтрека:
«В Канбане нет строгого понятия, что есть Канбан, а что не есть Канбан»
Как построите — так и будет. Ничего не мешает ввести в команду PO.
И, не смотря на поток, в канбане есть мероприятия по планированию и т.д.
Канбан это более сотни практик по улучшению ваших процессов, а сколько из них пробовала ваша команда?
Скрам хоть немного ориентируется на результат, все эти демо в конце спринта и т.д. В канбане все проектное не является частью канбана. Это и плюс (может быть любым ) и минус (должно быть сделано отдельно).
Почему? Раскроете мысль?
Для себя я не вижу причин, для того, чтобы быстрее и хуже писать код в канбане.
Для себя я не вижу причин, для того, чтобы быстрее и хуже писать код в канбане.
Дело не в коде. Нюанс в стратегии — предсказуемость сроков или предсказуемость функционала.
Для скрама — недоделанную фичу просто исключат из релиза что бы уложиться в delivery. Для канбан — сдвинут срок delivery, но что бы были все запланированные фичи.
Вы частное переносите на общее.
Многие работают c ci/cd и разницы уже никакой. Фичу сделали, протестировали и в мастер.
Вы частное переносите на общее.
Вот я посмотрю как вы в банк, на завод или государственное учереждение (безопастность) или критическую инфраструктуру будете неприрывно пушить код без проверки безопасников, депонирования кода и внутренней проверки или если, по соображениям безопастности, внутренняя инфраструктура клиента изолированна :)
Но если у них будет такое желание — можно и в СD внедрить его. С остальным так же примерно мне видится.
Почему же "без проверки"? Пускай проверяют в едином флоу.
"Мамы разные нужны. Мамы всякие важны..." :)
Вообще у скрама и у канбана есть у каждого свои естественные ниши.
Канбан с его аморфным, если не отсутствующим, delivery-циклом не особо хорош для проектов, имеющих внешнего заказчика. Скрам в этом плане хорош тем, что позволяет отношения с заказчиком структурировать, и а прогресс сделать зримым и измеримым. В начале спринта цели наметили, в конце спринта достижения сверили с целями. Если всё сошлось — и заказчик, и исполнитель счастливы. Если что-то не сошлось — у исполнителя появляется задача объяснить причину нестыковки, а заказчик получает материал для оценки эффективности исполнителя. В результате достигается баланс. Многое, конечно, зависит от руководства проекта в той части, чтобы избегать неисполнимых или сомнительных целей. Включать, там где уместно, промежуточные исследовательские цели.
А у канбана есть естественная ниша всюду, где заказчик внутренний. Когда не надо непрерывно заказчику доказывать правильность его выбора исполнителя. Когда вместо этого появляется запрос на более оперативное реагирование на изменяющуюся ситуацию. Почти любой in-house, любые проекты с заметным уклоном в эксплуатацию — да, канбан для этого...
Ну и вообще нет такой хорошей вещи, которую нельзя было бы испортить неправильным применением… :)
А внешнему заказчику вообще лучше вотерфол. Плевать они хотели на все эти эджайлы.
Вы ошибаетесь насчёт внешнего заказчика. Они зачастую сами не могут сформулировать требования для водопада (или меняют их постоянно, что суть то же самое), поэтому приходится работать итерациями. Поэтому итеративная разработка набирает популярность, даже в гос.проектах(!)
Ну а я даже спорить не буду :)
Потому как у всякой методологии есть свои естественные показания и противопоказания. И вариантов здесь можно найти много, со всевозможными факторами, действующими как в одну, так и в другую сторону. А мои примеры — только отдельные частные случаи.
И с тем, что внешнему заказчику понятнее водопад с фиксированным бюджетом — тоже согласен. Только где ж такого заказчика взять, чтобы чётко знал, чего хочет? :) Хотя в конкретных не особо сложных случаях договариваться можно наверно...
Канбан с его аморфным, если не отсутствующим, delivery-циклом не особо хорош для проектов, имеющих внешнего заказчика.
Тойота ориентировалась на внутреннего заказчика с аморфным циклом отгрузки продукции? Это те самые, которые проповедовали принцип "точно в срок"? Вы ничего не перепутали?))
А я кстати ничего не говорил про отгрузку продукции :)
А имел я в виду в первую очередь поставку новых/обновлённых ИТ-решений.
И поточное материальное производство — это отдельный разговор…
Ну и опять: не вижу предмета для дискуссии на тему того, кто сильней — кит или слон :)
У каждой методологии есть свои естественные области применения, и я не претендую на то, чтобы очертить их исчерпывающим образом...
В то время в Toyota использовали доску с тремя колонками: «Запланировано», «В работе», «Завершено».
В большинстве команд, где мне приходилось бывать, оно в таким виде и используется. И на мой взгляд это совершенно бессмысленная штука. Применять канбан имеет смысл в случае конвейерного производства, когда работа одного сотрудника/отдела/etc блокирует работу следующих — тогда это действительно наглядно показывает узкие места.
Я пользовался методом управления проектами Scrum (скрам) с самого начала карьеры.
Скрам не являеться методом управления проектами, он фреймворк!
Канбан — это метод управления производством, который появился в компании Toyota в 1950-х годах.
Современный ИТ канбан, он очень сильно отличаеться от тайтовского.
В последние годы скрам и канбан сражаются за место ведущего agile-фреймворка.
Не сражаються, Канбан-Метод это МЕТОД, улучшения ваших процессов. Канбан он про процессы, а не про проекты!
В целом, очень плохая статья, про чувака, который и скрам не понял, да и в канбане не разобрался
Есть ощущение, что Вы откроете для себя удивительно дивный мир, если чуть глубже разберетесь в материале. Бонусом будет то, что Вы сможете значительно улучшить жизнь своей команды, применяя Kanban для улучшения Scrum.
Scrum работает в определенном контексте, который очень хорошо описан в Scrum Guide. Судя по вашему описанию, Вы не применяете Scrum целиком, а значит у вас никогда не было Scrum.
Современный Kanban метод уже давно не имеет никакого отношения к Toyota и насчитывает более сотни различных практик, которые применяются для решения конкретных задач и улучшения процессов.
Использовали канбан (скорее что-то выглядящее как канбан) на одном проекте. За год работы так и не понял смысл большинства метрик. Например, "Пропускная способность команды" — ну как можно мерить "в прошлом месяце мы закрыли 20 историй, а в этом 5", если 20 были на уровне "добавить статическую страницу на сайт", а 5 на уровне "реализовать систему управления статическими страницами"? Или "время цикла" — ну что нам даст информация "задачу А мы сделали за 3 дня, а Б за 30", если задача А была "сделать кнопку поярче", а задача Б — "перевести систему начислений и списаний по лицевым счетам с float на decimal и покрыть все денежные операции тестами"?
Единственное полезное — количество задач в статусе "готовы к разработке/тестированию/приёке/релизу", ну и динамика этого количества.
Разочарую вас, не применяли вы Канбан. Как пример время цикла считаеться обычно для определенных видов работ, вот добавлена страничка это один вид работы.
Мерить нужно не тупо в количестве задач же. А в их весе суммарном.
Вообще встречал часто когда от скрама берут только спринты и называют это скрамом. Скрам надо либо полностью внедрять, либо не использовать его.
Боже. Очередной опус у стиле "скрам не работает, канбан — то что надо". По сути все сводится к "канбан легче". Автору стоит разобраться для начала в азах почему работает скрам и как работает канбан. Канбан намного сложнее скрама. В том числе и "не нужен скрам мастер" — это 5. Канбан не работает сам по себе как и все остальное. Можно назвать "мастера" менеджером, коучем — суть не меняется.
Канбан не будет работать без того же рефайнмента по сути. То тут он куда сложнее. Для того чтобы понять как работает канбан надо хоть немножко вникнуть в суть LEAN и систему JiT. Тваюмать… Как так можно? Статья уровня "я прочитал манифест". Культ Карго шагает по планете
Канбан не отменяет планирование. И задачи точно также должны быть сделаны вовремя. Вам же показалось, что раз нет спешки, то использование этого фреймворка удобнее, лучше. Просто циклы идут не с привязкой к спринтам, а к скорости команды и конкретному набору задач в работе.
В итоге, вы неправильно использовали скрам, а теперь неправильно использовали канбан.
Не ограничивайтесь общими сведеньями. Дело не в ретроспективах и стендапах. Дело в гибкости, которую вы теряете соблюдая все стандартные протоколы.
Кажется, что то, кому разработчик поклоняется, — скраму или канбану, никак не влияет на то, с какой скоростью он продумывает код и потом воплощает его в жизнь.
Если на работу над user story ушло больше времени, чем запланировано, то, блин, просто ее оценили неправильно. По причине собственной неопытности, из-за того, что не были известны все данные, или заказчик просто на ходу переобулся. Правильную оценку можно почувствовать со временем. Видишь задачу и ощущаешь как долго придется вокруг нее танцевать. Ошибиться можно всегда. И это нормально. И для тех, кто живет по scrum, и для тех, кто выбрал для себя канбан.
Но самое крутое и вкусное, когда команда создает нечто свое, свой гибрид, который учтет и взаимоотношения с заказчиком, и настроение, с которым принято работать, и аналитика, внезапно свалившего в отпуск, но достающего даже оттуда.
В это и кайф agile — мы выбираем какими нам быть и какие команды строить!
которые призваны ОРГАНИЗОВАТЬ процесс для того, чтобы он был более прозрачен извне, как-то должны влиять на скорость работы?
Не должны, но могут. Например, кто-то извне может обнаружить, что куча времени тратится на тестирование и инициировать введение автотестов.
Инструменты agile, в свою очередь, нужны нам, чтобы разложить процесс по полочкам, чтобы заказчик видел эффективность каждого из игроков, чтобы сама команда могла настроить поток передачи задач из рук в рук. В этом случае на скорость команды можно повлиять. Но только в том случае, когда команда умеет пользоваться инструментами, настраивает скрипку под оркестр, а не заставляет весь оркестр играть в тональности одной ненастроенной скрипки.
В канбан нет итераций, ограниченных по времени (спринтов).
но мы их сохранили, просто они теперь перестали быть фиксированными
Канбан не требует оценки сроков выполнения работ по пользовательским историям.
но мы все-равно оцениваем
В канбан (очевидно) не нужен скрам-мастер.
да и в скраме он редко кому нужен, но его роль и там, и там выполняет кто-то другой, чаще — менеджер проекта
В моем видении, канбан работает на отлаженном производстве, коим и является производство автомобилей, к примеру. Где производственный цикл — известен, время на «разработку» — фиксированное и его не надо «выдумывать» или спорить над тем, как быстро будет произведена очередная деталь.
Навенрео, автор пытался в очередной «Скрамбан», но я вообще перестал их уже различать, потому что в конечном итоге все очень сильно зависит от команды, а не от того, какой agile они предпочитают готовить. И чаще всего — это именно «очередная вариация на тему Agile», чем чистый канбан или скрам или <что-то еще>. А раз так, было б гораздо интереснее чиать о том, как внедряли, почему, с чем столкнулись, а не про то, что мы нашли канбан и вот он какой классный.
А вот про Agile/Scram могу заявить авторитетно с высоты прожитых на нем 2+ лет. После отказа от классического Waterfall качество программного продукта в первый же год упало в 2,7 раза. Это если судить во сколько раз возросло количество обращений пользователей в службу техподдержки.
Поэтому подтверждаю слова автора статьи:
Программисты больше заботились о том, чтобы уложиться в срок, чем о том, чтобы достичь нужного уровня качества.
В результате вместо планомерного развития продукта и движения вперед мы были вынуждены топтаться на месте, разгребая проблемы пользователей.
Поставили цель «успешно» закрывать спринты — команда этим и занималась.
Если критерии готовности фичи/релиза допускали просадку качества, то их и нужно было корректировать. Зачем для этого ждать 2 года?
Я участвовал несколько раз во внедрениях Scrum именно с целью повышения качества. И задача решалась вполне успешно (в «водопаде» большая неопределенность в сроках стабилизации, при давлении по срокам, провалы качества могут быть фатальные).
И опять же, если количество пользователей выросло в сотни раз, а количество обращений в 2.7, то это очень хороший показатель.
В результате вместо планомерного развития продукта и движения вперед мы были вынуждены топтаться на месте, разгребая проблемы пользователей.
В этом тоже нет ничего плохого, если высокая скорость поставки фич позволила захватить или удержать рынок. Своего рода долг, который пришла пора выплачивать.
Продукт зрелый, с более чем 10-летней историей. Конкуренты на пятки особо не наступали. Количество пользователей не выросло, даже наоборот несколько снизилось из-за кризиса.
В общем, внедрение Agile\Scrum не зашло.
Кстати, первая версия проекта провалилась, а во второй я уже не участвовал вскоре после её начала.
Скрам умер. Да здравствует канбан