Комментарии 92
Всегда готов поставить лайк статье, которая набрасывает на скрам и хорошо отзывается о канбан-методе:)
Автор говорит: Скрам мёртв.
Я говорю: Скрам ещё переживёт автора.
А теперь рубрика "Разрушаем мифы о Скраме":
Команда обязана выполнить все задачи, взятые в спринт. Строго говоря, команда обязана создать инкремент - полезную доработку продукта. Возможно ли сделать это, не допилив все-все-все задачи? Возможно.
Сложность и неточность оценок. Это проблема неопытных разработчиков, молодых команд, ранних этапов проекта, отсутствия документации. Со временем ситуация выравнивается и команда работает с хорошим процентом попадания в оценки. Важно понимать ещё и вот что: процесс оценки это своего рода тестирование требований и ретроспективная оценка уже проделанной работы.
Спринты - это ненужное давление. Скажем так, время - деньги. А значит заказчик не будет ждать свой продукт вечно. В Канбане нет спринтов? Окей, а сроков там тоже нет? Вообще никаких? И по мере приближения сроков ни заказчик, ни менеджер не просят апдейтов, не проводят какие-то срезы? Анбеливабл!
Фиксированные роли. Посмотрите на сами роли и задайте себе вопрос: в разработке по Канбану у вас их точно нет? У вас нет владельца продукта? Или нет разработчиков? Чаще всего достаётся Скрам мастеру, конечно. Но роли ведь можно и совмещать. И если у вас в команде никто и никогда не занимается процессами?
Более высокая прозрачность. Ну да, ну да, в Канбане команды прописывают все зависимости на год вперёд. Слышу звуки водопада.
Не в коем случае не хочу принизить Канбан и говорить, что ему нет места в мире. Любой инструмент имеет свои сильные и слабые стороны. И выбирать инструмент нужно исходя из тех вводных, которые вы получаете.
Ну а натягивать сову на глобус и сообщать, что Скрам мёртв... Это уже классика для статей на Хабре. Можно уже конкурс каждый месяц проводить)
Я говорю: Скрам ещё переживёт автора.
Я даже больше скажу. Древний язык программирования Cobol, появившийся 65 лет назад, переживёт меня и моих будущих внуков.
Работали по канбану с пулом задач и ежедневным непрерывными микрорелизами. Максимальной быстрая коммуникация с заказчиком и фидбек от команды.Пришли ИБешники со своими НОВЫМИ требованиями, сроки релиза увеличились до 14 дней. Команда вынуждена была перейти на SCRUM - релизы перестали были прогнозируемыми ,а так же выросла стоимость ошибки. SCRUM хорош, когда у Вас нет внешних факторов от которых зависит хоть 1 из этапов выхода в прод.
SCRUM хорош, когда у Вас нет внешних факторов от которых зависит хоть 1 из этапов выхода в прод.
Но ведь scrum заявляется как agile-методика для постоянно меняющихся условий заказчика?!
И что? Теперь вы безопасникам говорите, что отложите их хотелки до грядущих спринтов и покатите ближайшие релизы без учёта их требований?
Если нет, то в чём разница? Если да, то что раньше мешало отложить?
Далее, тут отсутствие прогнозируемости времени выпуска релиза выдвигается как некоторая серьёзная проблема. В зависимости от специфики конкретного проекта это может быть так, но это не так во многих проектах. О чём и пишет автор поста -- чем тратить время на оценку времени ради оценки времени, часто рациональнее потратить время на саму работу.
Строго говоря, команда обязана создать инкремент - полезную доработку продукта. Возможно ли сделать это, не допилив все-все-все задачи? Возможно.
А можно создавать инкремент по мере запиливания фич / выпиливания багов, а не по таймеру спринта? Можно же.
Со временем ситуация выравнивается и команда работает с хорошим процентом попадания в оценки.
А без спринтов, опытная команда не может оценивать время выполнения задач? Считать сроки не в спринтах, а в неделях?
В Канбане нет спринтов? Окей, а сроков там тоже нет? Вообще никаких?
При необходимости, дедлайны в канбане добавляются элементарно. Ничто этому не мешает. Причём ведь, в отличии от спринтов, у каждой задачи может быть свой дедлайн.
Scrum это много глубже чем просто тикеты.
Есть такая притча
На стройке работали три человека. Они выполняли одинаковую работу. Каждого из них спросили, что он тут делает.
- Я кладу кирпичи, - сказал один.
- Я зарабатываю себе на жизнь, - ответил другой.
- Я строю храм, - произнес третий.
Scrum это про цель, а не про тикеты.
А что мешает релизить фичи, по мере готовности? Кто заставляет ждать конца спринта?
А какой тогда смысл в спринте?
Для меня очевидно что смыслов в спринте много.
Например, ограничить скоуп задачь, что бы команда могла спокойно заниматься понятными задачами, в идеале без большого переключения контекста.
Сфокусировать усилия команды, на какой-то ограниченной области продукта.
Так же, ограничить возможность различных внешних факторов влиять на задачи в спринте (менеджеров например), что бы не бегали каждый день и не меняли приоритеты, запихивали ещё задач и т.д. (если, конечно, это не действительно что-то очень важное, тогда можно и поменять всё, но это должно быть скорее исключение из правил)
Так же спринты удобны и для менеджемента, ведь после некоторого времени команда выходит на понятный уровень производительности и можно легко понять, сколько примерно и за какой срок будет сделано, что очень помогает в среднесрочном планировании и не создаёт дополнительного давления на команду.
И много других вещей
Но ограничение поставки концом спринта, точно не его смысл.
Вы говорите о достоинствах канбана, а не скрама. Именно канбан позволяет сфокусироваться на задаче, минимизируя переключение контекста ограничением на количество задач в "in work" этапе. Скрам же наоборот создаёт давление, выставляя в начале спринта ворох задач на весь двух-четырёх недельный спринт. Сколько и за какой срок будет сделано видно в любом случае, спринтами вы работаете или нет, потому что это просто количество сделанных тасков за единицу времени, хоть за неделю, хоть за месяц, хоть за год.
В канбане главная метрика это время прохождения задачи через всю доску, от todo до done, не важно сколько там будет статусов, важно полное время прохождения. И вот это как раз создаёт давление.
Как и переключения контекста, из-за того что в todo нет фиксированного скоупа задач, он может меняться без ограничений, скачки между разными контекстами весьма вероятны. Что бы этого избежать команда должна прилагать для этого большие усилия, за счёт само организованности и понимания, что и зачем они делают. Большинство команд, на моей практике, такими качествами не обладают, особенно в начале работы.
В то время как скрам, со своими "ритуалами" позволяет решать эти вопросы легче при старте новой команды. При этом впоследствии никто не мешает изменять процесс под реалии команды, её состав и внешние факторы. Для этого тоже есть "ритуал" ретроспектива. (если что в канбане без ретроспективы тоже нельзя, просто команда сама должна это понимать)
Конечно, в первых спринтах может быть ворох задач, но в дальнейшем команда уже сама будет понимать, сколько она может сделать за спринт. И это зависит по сути от команды, потому что во многом скрам направлен на защиту команды, её спокойную и продуктивную работу.
Есть даже график, который показывает уровень "боли" канбана и скрама, в зависимости от времени.
И да у скрама "боль" приходит сразу, и потом уменьшается по мере становления процесса, у канбана чуть иначе, но в итоге всё должно прийти к уменьшению этой "боли".
Так же никто не мешает, а часто и прямо рекомендуется, устанавливать лимит задач "in work".
из-за того что в todo нет фиксированного скоупа задач, он может меняться без ограничений, скачки между разными контекстами весьма вероятны
Ничего не понял. Todo это пул готовых к работе задач и он может меняться хоть каждый час и это никак не сказывается на прогрессе работы, так как из него в in work берут лишь по окончании задач, пока есть текущая задача, исполнители в todo вообще не заглядывают. Переключение контекста происходить может лишь по двум причинам - 1) тупик, задача упёрлась во что-то и её необходимо отложить до возможности продолжить, либо задача потеряла смысл; и 2) внезапная критическая задача ("ребята, у нас прод упал").
Конечно, в первых спринтах может быть ворох задач, но в дальнейшем команда уже сама будет понимать, сколько она может сделать за спринт.
Вот это "знать сколько нужно времени" вообще, честно говоря, не волнует непосредственных исполнителей и никак не влияет на срок выполнения, это нужно менеджерам для отчёта "наверх", чтобы не брать на себя обязательств больше, чем коллектив способен потянуть. И скрам - это о том (ИМХО), как брать задач "под завязку" и заставлять команду работать на пределе. Канбан же это о том (опять ИМХО) как вместо того чтобы тратить время на попытку предсказать будущее, анализировать прошлое чтобы увидеть бутылочное горлышко и приложить усилия там, где они принесут наибольший эффект.
По-моему, ключевой недостаток в скраме - это высокие затраты времени на деятельность, что не относится напрямую к производству продукта.
Совокупно эти активности занимают до 30% рабочего времени спринта. Иногда значительно больше. Ведь на ревью не пойдешь, не собрав данные, на груминг не пойдешь, не изучив предстоящие задачи из бэклога, планирование спринта не сделаешь без груминга. И т.д.
В Канбане нет спринтов? Окей, а сроков там тоже нет? Вообще никаких?
Конечно в канбане есть сроки. Только другой принцип их применения. Это совсем другая философия.
Первое что надо помнить - работа это поток. Все что там можно сделать - это управлять его пропускной способностью и направлением. Канбан доска наглядно показывает заторы. Устраняешь причину - поток течет стабильнее и быстрее. Если поток сворачивает в сторону (начинаете делать "левые" или второстепенные задачи) - помогаешь ему вернутся на прежний путь (в сторону цели). Падает качество - замедляешь поток задачами, что увеличивают качество (пишутся автотесты, юнит-тесты). И т.д.
И сроки в этой системе - это лишь способ замерить скорость. Как деления на линейке. Можно замерять прогресс хоть каждую неделю. Или раз в 2 недели, раз в месяц. По одной фиче или по всем сразу. Нет требования сделать инкремент к моменту замера. Просто фиксируешь сколько сделали за неделю. Когда у тебя сделано в первую неделю 3%, ты можешь посчитать, что тебе понадобиться 33 недели, чтобы сделать проект. Но у тебя ограничение в 15 недель. Значит стараешься увеличить производительность. Через неделю замеряешь - сделали уже 12% (9%+3%), это по 6% в неделю, значит проект сделаешь за 16 недель. И т.д. Опять работаешь над ускорением потока. Как ускорять поток - это уже тема отдельного разговора.
А спринты реально - тупое, не нужное давление!
Да, автор вообще не понимает Scrum.
О, вижу очередной заплюсованный комментарий в статье про скрам - хоть кто-нибудь из вас напишите статью, как у вас четко и круто работает тру-каноничный-скрам. Я бы там задал всякие неудобные вопросы по ходу дела, например каким образом можно в две недели сделать "полезную доработку продукта", если переделка архитектуры оценена в три месяца. А к ней привело, соответственно, mvp на коленке по скраму за две недели. Вместо нормального предварительного анализа по чмошному ватерфолу.
Но начать можно с более простых вопросов - вот спринт две недели (первая с понедельника по пятницу и вторая с понедельника по пятницу), когда у вас там демо?
Давайте отвечу на простой вопрос из абзаца в конце.
Например, граница спринта в четверг, в который идут demo/review и retro закончившегося спринта, а потом planning начинающегося. А во вторник за два дня -- backlog review, чтобы были готовы актуальные задачи для выбора в четверг.
в который идут demo/review и retro закончившегося спринта, а потом planning начинающегося
День, когда у моих наушников батарейка не доживает до конца всех коллов.
Demo/review -- 30 минут. Retro -- 45 минут. Planning -- 30 минут. Если у вас существенно дольше, то что-то делается не так :-) Это если вы разработчик. Если вы -- заинтересованное лицо (stakeholder, не уверен, какой устоявшийся русский термин), то календарь, конечно, может быть забит сильно. Но у stakeholders всегда так независимо от методологии.
Daily ещё не забудьте, у нас из за размера команды на полчаса растягивается. Retro - 1.5 часа, планирование - час и еще презентация задач к оценке от получаса до часа, 3-6 задач всего, но обсуждения никто нормально не прерывает. Больше всего людей бесит не сам скрам, а то что его мало кто умеет готовить, но по какой то причине именно неумёхи настаивают на его наличии. У нас красиво канбан был настроен на подкоманду из 5 человек. В основной команде - срам (именно срам). Пришли эффективные менеджеры - "нам неудобно косты считать, у нас релизы по спринтам расписаны, а вы тут что-то непонятное делаете" - на минуточку самая эффективная команда была, просто потому что не раздутая, и настроили свои процессы и жили по ним, подстраиваясь под даты релизов - "давайте у вас тоже спринты будут, причем не отдельные, а в основную команду из 22 человек вливайтесь". Получасовые дейлики, как можно догадаться, были и до нас там. Раньше на ретро и получасовые дейли только я как руководитель подкоманды приходил, ребята изъявляли желание поработать. Пока не знаю как повлияет вливание, но без изменений в процессах явно будет ещё хуже, только уже вопросы возникнут почему мы раньше больше делать успевали...
Daily 15 минут. Если нужно что-то более подробно пообсуждать, то те, кому надо, отдельными группами собираются после daily.
Максимальный размер скрам команды 6-8 человек. Причем 7-8 только если все очень организованные и сработанные. Реально 4-6 человек макс.
То, что вы описали, скрам на 22 человека -- это вообще ужас-ужас-ужас бессмысленно и беспощадно. Такая игра в agile без понимания 🙁
Так, у вас выходит спринт с четверга по четверг, две недели?
Пока я понял вот так
Непосредственная работа в спринте с пятницы до понедельника, при двух неделях - это 7 рабочих дней
Вторник - backlog review
Среда - ?
Четверг - demo/review + retro + planning следующего спринта
И еще несколько вопросов, мне правда интересно без всякой токсикологии
В какой день релиз?
Каждая "штуковина" (я их буду так называть, потому что они у всех по-разному называются - стори, юз кейсы, задачи) в backlog, которая попадает в спринт - внутри спринта она пройдет через все этапы (анализ, кодинг, функциональное тестирование) или у нее уже готов, например, анализ и тест кейсы (например в рамках TDD и то есть останется только кодинг)?
Куда вы впихиваете регрессионное тестирование?
Бывали ситуации когда на демо выясняется, что сделали что-то не то или не так (все мы люди и все мы ошибаемся)? И какие действия предпринимались?
И если в этом случае принималось решение о новой "штуковине" (типа доработка/исправление) - куда она шла? В бэклог или вы ее впихивали в будущий спринт? [хотя тут пожалуй ответ очевиден - в зависимости от приоритета/критичности]
Конкретно у меня сейчас спринт одна неделя, но не суть. Одна-две почти без разницы, вопрос предпочтений команд и других процессов в конторе. Больше двух недель -- имхо, плохо, слишком долго между моментами синхронизации "а в правильную сторону ли я иду" :-)
Вторник -- backlog review это час плюс какое-то время на подготовку для тех, у кого была "домашняя работа" с прошлого раза приготовить содержательно новые задачи. В остальном это обычный рабочий день.
Среда -- тоже обычный рабочий день, но может быть с неким фокусом на чистку хвостов, которые отложили в начале спринта.
Про четверг я выше в другом ответе написал, но повторю для контекста. Demo/review -- 30 минут. Retro -- 45 минут. Planning -- 30 минут.
В какой день релиз?
У нас то, что можно описать Trunk-Based Development (на хабре была статья про это https://habr.com/ru/articles/794246/ со ссылками на доп материал). Сейчас релиз раз в две недели. Утром во вторник выбирается билд, в котором за ночь ничего страшного не сломалось и делается release candidate branch, из которой через две недели идет релиз.
День внешнего релиза по идее не должен быть никак связан с границами ваших спринтов.
Каждая "штуковина" (я их буду так называть, потому что они у всех по-разному называются - стори, юз кейсы, задачи) в backlog, которая попадает в спринт - внутри спринта она пройдет через все этапы (анализ, кодинг, функциональное тестирование) или у нее уже готов, например, анализ и тест кейсы (например в рамках TDD и то есть останется только кодинг)?
Штуковина, идущая в спринт должна быть размера, который хотя бы теоретически можно сделать за спринт. Если нужен анализ и дизайн, то это отдельная штуковина, делается раньше (как часть спринта) и производит новые штуковины в бэклог. Понятно, что анализ и дизайн не всегда можно вместить в рамки спринта (может, надо время на подумать и утрясти идеи), такие штуковины могут длиться дольше.
Имхо, важный момент, что это ошибка считать, что все штуковины должны быть выполнены в спринт или ужас-ужас-ужас :-) Спринты -- это про организацию работы и точки корректировки, а не про обещания сделать что-то к определенному дню.
Куда вы впихиваете регрессионное тестирование?
В agile почти все тестирование -- это часть обычной работы, и почти все тестирование автоматическое. Вы пишите и тесты и код. Continuous Integration гоняет тесты на ваших изменениях и на основной ветке постоянно.
Если говорить совсем категорично: например, если вы делаете задачу, а потом неделю ждете, пока человеческие тестеры ее проверят и вернут на доработку (баги или недочеты), то это не agile, а что-то другое.
Бывали ситуации когда на демо выясняется, что сделали что-то не то или не так (все мы люди и все мы ошибаемся)? И какие действия предпринимались?
Если косяк выясняется на демо, это значит, что на нескольких более ранних этапах его не выявили (например, во время проверки Acceptance Criteria). Бывает, конечно, тогда это тема для ретро -- обсудить, почему не выявили раньше. Но так как спринт короткий, то цена ошибки не очень велика. Если косяк небольшой и делать все равно нужно, штуковина остается открытой и переходит в следующий спринт. Если косяк существенный, но можно выделить в новую штуковину.
И если в этом случае принималось решение о новой "штуковине" (типа доработка/исправление) - куда она шла? В бэклог или вы ее впихивали в будущий спринт? [хотя тут пожалуй ответ очевиден - в зависимости от приоритета/критичности]
В бэклог по умолчанию. На следующем backlog review разбираться с приоритетом. Если важно и срочно, то естественно можно на месте со stakeholder разобраться, когда делать. Вполне нормально, что новая вещь идет в верх бэклога и берется сразу в следующий спринт.
Конкретно у меня сейчас спринт одна неделя, но не суть
Допустим, это выходит пятница > четверг - 5 рабочих дней, за вычетом времени на backlog review / demo-review / retro.
Если нужен анализ и дизайн, то это отдельная штуковина, делается раньше (как часть спринта) и производит новые штуковины в бэклог
Ок, выходит, что каждая штуковина проходит через все этапы в рамках скрама и спринтов, может длиться дольше чем один спринт и это воспринимается нормально. Отсюда еще вопрос - получается какие-то спринты могут содержать только например анализ и дизайн (без кодинга и тестирования) - это норм? Ведь тогда нет никакого инкрементного полезного изменения в продукте.
Если косяк небольшой и делать все равно нужно, штуковина остается открытой и переходит в следующий спринт. Если косяк существенный, но можно выделить в новую штуковину
Ок, понял.
Сейчас релиз раз в две недели. Утром во вторник выбирается билд, в котором за ночь ничего страшного не сломалось и делается release candidate branch, из которой через две недели идет релиз
Тут хотелось бы пояснений - выходит, что релиз никак не связан со спринтами и идет с запозданием. Я такого не припомню в каноничном скраме. Да и в целом в голове не укладывается (спринт должен всегда заканчиваться релизом последних задач). Почему так сделано? И что с продуктом происходит эти две недели? Я почитал про TBD - я так понимаю в trunk у вас всегда рабочая версия с зелеными тестами. То есть стараются не сливать в trunk без тестов, а если это произошло, то в первую очередь исправляют, чтобы тесты стали зелеными. Следовательно от нее в любой момент времени можно сделать релиз-кандидат.
И у меня еще есть вопросы, если позволите.
Какой состав команды у вас по ролям и кол-ву людей?
Стейкхолдер очень занят, гарантированно бывает только на планировании и на демо, на демо приходит и говорит - "немного не так" или "все не так, переделывайте, надо вот так". Сталкивались ли с такими ситуациями? Какие действия предпринимали? И в целом ваше мнение?
Работа в условиях ограниченных ресурсов. Там разные варианты могут быть. Идеальный конечно - одна полноценная команда со всеми ролями на один продукт. Худшая ситуация - только один программист и на несколько продуктов параллельно (и он везде должен успеть и в анализ, дизайн, кодинг, тестирование). Средние ситуации типа - программист занимается только одним продуктом, но Стейкхолдер/PM/PO/тестировщики - занимаются параллельно несколькими продуктами. Сталкивались ли с такими ситуациями? Какие действия предпринимали? И в целом ваше мнение?
Разработка длительных "штуковин". Например какая-то долгая задача по переделке архитектуры (так как изначально было сделано MVP на коленке) или долгие задачи, которые нельзя выложить частично или просто долгие задачи. Сталкивались ли с такими ситуациями? Какие действия предпринимали? И в целом ваше мнение?
Да и в целом смущает 5 рабочих дней на спринт. Одна обычная небольшая задача может занять больше времени - 1-2 дня на анализ, 1-2 дня на дизайн, 1-2 на кодинг, 1-2 на написание тестов. То есть по хорошему скорость будет 1 полная задача в спринт на одного программиста.
Да, много вопросов :-) это хорошо, наверное. Попробую ответить на все.
Отсюда еще вопрос - получается какие-то спринты могут содержать только например анализ и дизайн (без кодинга и тестирования) - это норм? Ведь тогда нет никакого инкрементного полезного изменения в продукте.
В теории, да, могут. Тут есть несколько наблюдений.
Во-первых, на практике никто не может дизайнить 8 часов в день, нужны отвлечения на утрясти мысли.
Во-вторых, даже в новом проекте всегда есть понятная работа, которую все равно нужно делать. Плюс разобраться с багами из Continuous Integration. Или код ревью для соседней команды. Или наконец-то уговорить PO протащить в верх бэклога задачу (штуковину, юзер стори) по улучшению какой-нибудь внутренней утилиты, которую долго откладывали. Всегда есть, чем заняться.
В-третьих, в agile в целом не принято big design upfront. Если три месяца что-то анализировать и дизайнить, а потом год делать, то может оказаться, что задизайненное и не нужно. :-) Понятно, что решения, которые потом сложно изменить, стоит продумывать хорошо. Но в целом, если у вас хорошее тестирование, не слишком страшная организация кода, то важный agile принцип -- дизайнить минимальную вещь, а кодовая база должна быть в состоянии, когда можно относительно легко делать большие изменения.
В четвертых, инкременты. В сферическом вакууме, да, каждая юзер стори и каждый спринт должны приносить пользу некоторому пользователю, который в конечном итоге приносит деньги. На практике, выгодополучать юзер стори (иногда, называют персона) может быть не конечный пользователь продукта, а сисадмин, сотрудник тех поддержки, ваш тестировщик, ваш аналитик телеметрии, даже вы как разработчик. Например, инкремент вполне может быть "Мы разобрались с неведомой хней Х и теперь знаем, что делать в фиче Y".
Тут хотелось бы пояснений - выходит, что релиз никак не связан со спринтами и идет с запозданием. Я такого не припомню в каноничном скраме. Да и в целом в голове не укладывается (спринт должен всегда заканчиваться релизом последних задач). Почему так сделано?
Честно говоря, не припомню, чтобы скрам предписывал механизм релиза продукта. Сейчас мельком глянул https://scrumguides.org/scrum-guide.html -- тоже не вижу, но может не заметил. Да, спринт заканчивается релизом последних задач в том смысле, что код влит в основную ветку, все работает, вы можете продемонстрировать улучшение. А вот когда это улучшение попадет к пользователям, вы не контролируете.
И что с продуктом происходит эти две недели?
Конкретно у нас на release candidate ветке команда тестирования/сертификации гоняет особенные долгие тесты, выкатывает на тестовые серверы и серверы внутреннего пользования (dogfood, не знаю, есть ли устоявший русский термин), гоняет стресс тесты, делает некоторое ручное тестирование по чеклистам. Это чтобы поймать баги, которые пролезли через обычный continuous integration/testing.
Я почитал про TBD - я так понимаю в trunk у вас всегда рабочая версия с зелеными тестами. То есть стараются не сливать в trunk без тестов, а если это произошло, то в первую очередь исправляют, чтобы тесты стали зелеными. Следовательно от нее в любой момент времени можно сделать релиз-кандидат.
Да, именно так. За попытку залить в транк без тестов будет ай-ай-ай на код ревью.
Какой состав команды у вас по ролям и кол-ву людей?
Сейчас команда 8 разработчиков (два принципал, три сеньора, два мидл, один джуниор -- но звания между конторами и странами сложно сравнивать). я выше (https://habr.com/ru/articles/869164/comments/#comment_27731170) писал, что 8 -- это максимум. Роли примерно все одинаковые из-за особенностей проекта (не могу деталей).
Стейкхолдер очень занят, гарантированно бывает только на планировании и на демо, на демо приходит и говорит - "немного не так" или "все не так, переделывайте, надо вот так". Сталкивались ли с такими ситуациями? Какие действия предпринимали? И в целом ваше мнение?
Ну, стейкхолдер и должен быть только на планировании, демо, ну и backlog review. Работа стейкхолдера -- быть в курсе, что команда делает и зачем. Вот прямо, чтобы "все не так, переделывайте, надо вот так" не припомню.
Худшая ситуация - только один программист и на несколько продуктов параллельно (и он везде должен успеть и в анализ, дизайн, кодинг, тестирование).
"только один программист и на несколько продуктов параллельно" -- это не скрам :-) Это что-то другое. Хорошо или плохо -- отдельный вопрос. Но скрам это про то, когда команда работает над одной общей целью в течение некоторого времени. Если нужно все везде успеть, то канбан будет лучше.
Стейкхолдер/PM/PO/тестировщики - занимаются параллельно несколькими продуктами.
Это как раз нормальное. PO часто курирует несколько команд, иногда по несвязанным проектам. Тяжелая доля :-)
Разработка длительных "штуковин". Например какая-то долгая задача по переделке архитектуры (так как изначально было сделано MVP на коленке) или долгие задачи, которые нельзя выложить частично или просто долгие задачи.
Декомпозиция и инкрементальное исполнение. Долгая переделка и потом мучительное вливание в основную ветку -- это зло, имхо. И против идей trunk-based development, используемой у нас в конторе.
Да и в целом смущает 5 рабочих дней на спринт. Одна обычная небольшая задача может занять больше времени - 1-2 дня на анализ, 1-2 дня на дизайн, 1-2 на кодинг, 1-2 на написание тестов. То есть по хорошему скорость будет 1 полная задача в спринт на одного программиста.
Если коротко, то это нормально. Большие задача бьют на части, которые предположительно можно сделать за один спринт.
Конкретно у нас на release candidate ветке команда тестирования/сертификации гоняет особенные долгие тесты, выкатывает на тестовые серверы и серверы внутреннего пользования
Ну вот оно и тестирование, которое я имел ввиду (автотесты конечно тоже тестирование, но все же это только нижняя часть пирамиды). Получается, что остальное тестирование проводится вне рамках спринта. Отсюда вопрос. Что если нашли косяк? Что тогда с релизом и как косяк попадает обратно в спринт?
И смежный вопрос - в компании есть саппорт? Там обычно делают уровни L1 / 2 / 3, и программисты - одни из последних. И вот если есть - то кто решает саппорт тикеты на уровне программистов? Есть отдельная команда / дежурства? Или они тоже попадают в бэклог и спринты? И туда же баги, которые обнаружили уже на проде?
Ну, стейкхолдер и должен быть только на планировании, демо, ну и backlog review. Работа стейкхолдера -- быть в курсе, что команда делает и зачем. Вот прямо, чтобы "все не так, переделывайте, надо вот так" не припомню
Пожалуй, я не совсем точно задал вопрос. Поясню. Чтобы сделать нормальный продукт - надо знать что и как должно работать. В продуктах с простой предметной областью - программисты могут и сами разобраться. Но в продуктах со сложной предметной областью (финансы, логистика) - нужен бизнес-аналитик. В agile - это эксперт предметной области. Конкретно в моих успешных проектах про agile - стейкхолдер был одновременно и экспертной предметной области. И как итог - если такого человека нет, значит продукт может работать неправильно и его регулярно переделывают.
Декомпозиция и инкрементальное исполнение. Долгая переделка и потом мучительное вливание в основную ветку -- это зло, имхо. И против идей trunk-based development, используемой у нас в конторе
Тут на самом деле отдельная глубокая тема. Разве только скажу, что вот среди моих знакомых и с кем я общался в личке на хабре (кто писал крутые статьи по архитектуре и разработке) - все мы видим примерно одинаковые проблемы и предлагаем похожие идеи и решения. Нет каких-то действительно прорывных идей или серебряной пули. То есть в среднем по больнице мы все как-то пытаемся с этим справится, но вот конкретно в моем случае - этого не хватает, чтобы быстро внедрять изменения.
Можно конечно каждую секунду думать с позиции "что это все будет переделано" как на уровне архитектуры, так и кодинга. Но порой проще и быстрее тупо написать код, чем подстилать соломку везде где только можно, превращая это в fizzbuzz enterprise edition.
У меня есть конкретные примеры задач (лично моих и коллег), которые не уложились бы в недельный спринт (особенно если на продукте один программист):
БД Oracle, пришел клиент и хочет MS SQL. Если продукт находится на ранней стадии и там используется ORM - это 2-3 часа, переключить диалект, поправить строку подключения и сделать smoke тест. Но если уже были оптимизации запросов на нативном SQL - это надо все провалидировать и исправить. В зависимости от проекта это может быть десятки и сотни мест / хранимок. Плюс дефолтные уровни транзакций могут работать немного по-разному в разных СУБД. Плюс спец средства разные в разных СУБД. Плюс если до этого не выделяли время на автотесты - еще и тестирование.
Со сменой версии БД перестали работать оптимизации для нативных запросов и пришлось это все изучать и переписывать.
Замена некоторых этапов бизнес-процессов с синхронной обработки на работу через очередь.
В системе, которая работает со складскими запасам - смена парадигмы. Вместо асинхронного перерасчета после всех действий и событий - на работу в реальном времени с блокировками. Так как было несколько действий, которые влияли на состояние склада (списание, оприходование, инвентаризация) - поправить например только списание нельзя. Остальные действия будут в этот момент ломать склад или не получать актуальную информацию. А переписать все три блока - это точно не неделя.
В целом по моему личному мнению - все это из-за agile и mvp.
У меня есть пример удачного проекта в сложной предметной области - банковской сфере. Но там архитектура делалась по ватерфоллу. Oт банка даже был специальный документ по их стандартам архитектуры и встройке сторонних продуктов в их существующую инфраструктуру. И в рамках этой архитектуры, которая была сделана с запасом - реализация бизнес-логики по agile. Вот там все взлетело на ура.
В последнее время у меня соответственно неудачный пример - начали с кукурузника из говна и палок, а оказывается надо было стратегический бомбардировщик с ядерными ракетами.
С наступающим.
Ну вот оно и тестирование, которое я имел ввиду (автотесты конечно тоже тестирование, но все же это только нижняя часть пирамиды). Получается, что остальное тестирование проводится вне рамках спринта.
Нет! :-) Отдельное тестирование release candidate -- важная, но все же небольшая часть тестирования. Это дополнительная линия защиты. Каждый случай бага, требующего фикса в релизной ветке -- это экстренная ситуация. Почти всегда делаем Root Cause Analysis и улучшаем основное тестирование.
Но я последний десяток лет работаю в data storage и с чрезвычайно сильным фокусов на качестве и тестировании. Потому что терять данные пользователей -- нехорошо :-) Возможно, в других областях сложнее достичь высокий уровень тестирования.
Отсюда вопрос. Что если нашли косяк? Что тогда с релизом и как косяк попадает обратно в спринт?
Сначала решаем, насколько серьезный косяк. Иногда можно все же выпустить релиз, а чинить потом. Идет в бэклог команды, ответственной за область продукта, где нашли косяк. Ведь скорей всего эта команда косяк и произвела :-) Команда со своим стейкхолдером решает, когда делать.
Если чинить нужно обязательно в этом релизе, то это release blocker. Ответственная команда все бросает (не обязательно вся команда, конечно, может быть, что только один-два человека) и фокусируется на починке косяка в основной ветке и бэкпорт в релизную ветку (или откат функционала из релизной ветки, если быстро починить нельзя -- потом идет в обычный бэклог). Это, конечно, влияет на текущий спринт, а то и два. Что-то будет не сделано и пойдет в следующий спринт. Это нормально. Если PO не понимает, что происходит, и требует выполнения целей спринта, ну, это плохой PO :-)
Тут хочу отметить, что я фундаментально не согласен вот с этим утверждением из исходной статьи ("команда обязана выполнить все запланированные задачи"). Скрам нигде это не требует. Это идеальная цель, но не жесткое требование.
И смежный вопрос - в компании есть саппорт? Там обычно делают уровни L1 / 2 / 3, и программисты - одни из последних. И вот если есть - то кто решает саппорт тикеты на уровне программистов? Есть отдельная команда / дежурства? Или они тоже попадают в бэклог и спринты? И туда же баги, которые обнаружили уже на проде?
Могу рассказать, как у нас устроено, это не секрет. Так как продукт -- data storage, то "пользователи" обычно люди типа сис-админов. Первый уровень саппорта -- технические специалисты поддержки, которые хорошо разбираются в продукте и разных предметных областях применения (есть специализация, конечно). Дальше есть выделенная команда программистов с ротацией в полгода примерно (кто-то сидит дольше, потому что нравится). Их работа -- разбираться со сложными проблемами непосредственно у пользователей и чинить баги, на которые они могут найти время. У этой команда, естественно никакого скрама, потому что работа часто меняется. Канбан в чистом виде. Но иногда они могут делать вполне себе фичи. Например, улучшить телеметрию или запилить улучшение производительности.
Если нужна экспертиза в какой-то специальной части продукта, то привлекают нужных людей из других команда для консультации и код ревью. Если фикс слишком большой, то стейкхолдеры между собой договариваются, в какую обычную команду надо отправить, и какое место в их бэклоге. Тут уже вопрос приоритетов. Если нужно починить Б быстрее, то работа над А замедлится. Нет волшебного решения.
Эта специальная команда дежурит в обычное рабочее время. В остальное время дежурят программисты из обычных команд. Получается 2-3 дежурства в год по неделе. За прошедший год у меня бы один вызов ночью :-) и то не в мое дежурство, а так получилось по цепочке специалистов в конкретной предметной области. В общем, мне кажется, не на что жаловаться.
Конкретно в моих успешных проектах про agile - стейкхолдер был одновременно и экспертной предметной области. И как итог - если такого человека нет, значит продукт может работать неправильно и его регулярно переделывают.
Это обязательно! Стейкхолдер/PO обязан быть экспертом в предметной области для успешной работы команды. В целом, agile подразумевает, что программисты в команде понимают предметную область. Это значит, что в начале всегда будет этап обучения и разбирательства. Но у программиста команды всегда должна быть возможность позвать PO и сказать, что "X -- это не технический вопрос, а продуктовый. Разберись и реши, как должно быть". Причем, один-два программиста из команды вполне могут принимать участие в разбирательстве.
У меня есть конкретные примеры задач (лично моих и коллег), которые не уложились бы в недельный спринт
Примеры очень жизненные! Конечно, полно задач, которые занимают месяц, два, три, дольше. Но это очень высокоуровневые задачи. Опять же, с колокольни Trunk-Based Development это решается с помощью feature flags. Например, если нужно переехать с асинхронного пересчета на блокирующий, то начинаем с крохотной подсистемы, которая выключена по умолчанию в продукте. Но! Мы постоянно гоняем тесты в новом режиме для той функциональности, которая уже работает. Каждый спринт что-то улучшается и можно продемонстрировать новый результат. Даже если он еще недоступен в основном продукте, это все равно инкремент. В какой-то момент можно делать пробные переключения на новую подсистему, смотреть, что сломалось и планировать работу дальше.
Может показаться, что тут много работы на выброс. Имхо, это не так. Уверенность в том, что все работает так, как задумано, стоит затрат.
банковской сфере. Но там архитектура делалась по ватерфоллу.
Банковская сфера очень сильно зарегулирована, как я понимаю. Многие решения и требования определяются законами и правилами.
начали с кукурузника из говна и палок, а оказывается надо было стратегический бомбардировщик с ядерными ракетами.
Да, бывает такое. я не знаю общего решения, но по опыту выходит, что какой именно бомбардировщик нужен -- точно неизвестно пока не попробовать. Часто кукурузник через три месяца лучше, чем авиалайнер через два года.
С наступающим.
Cheers!
Демо в абсолютно любой день после спринта.
Задачи можно декомпозировать до одной рабочей функциональности.
Позвольте задать примерно те же вопросы...
У вас двух недельные спринты?
Как вы его тратите по дням? И когда у вас релиз?
Почему демо после спринта, если по канонам (вроде как) - демо это составной элемент спринта?
Бывали ситуации когда на демо выясняется, что сделали что-то не то или не так (все мы люди и все мы ошибаемся)? И какие действия предпринимались?
_ Со временем ситуация выравнивается и команда работает с хорошим процентом попадания в оценки._
Ничего подобного. Само наличие чисел фибоначчи и скрам-покера математически обуславливает что это невозможно сделать с 100% точностью. А значит, кто-то либо будет иметь пустое время, либо не успеет.
Кроме того, бывают задачи > спринта. Например переработка архитектуры, потому что старая перестала справляться. Или сложные баги. Есть много примеров.
_Команда обязана выполнить все задачи, взятые в спринт. Строго говоря, команда обязана создать инкремент - полезную доработку продукта. Возможно ли сделать это, не допилив все-все-все задачи? Возможно _
Но у PM все равно появляется соблазн всех поторопить.
По-моему, в любой "системе планирования" на 80% все зависит от того человека кто создает "план" и/или контролирует его. Или иными словами, везде где есть человек - есть человеческий фактор, который может полностью нивелировать любые достоинства используемых инструментов.
Что-ж, прежде всего хочу сказать, что я разделяю Вашу боль и негодование по поводу скрама. Мое отношение к нему подробнее раскрывается в моих предыдущих комментариях.
Лет 12 назад, когда скрам начал бодро шагать по умам, ходило такое утверждение: "Все, что не по скрам-гайду это не скрам". Теперь же, спустя десятилетие, доказавшее ущербность этого подхода, утверждение сменилось на: "пук-среньк, скрам это набор рекомендаций для профессионалов".
Должен сказать, что реально "настоящего" скрама я не встречал ни разу в жизни. Так же и то, что Вы описываете - это, скорее, "краткосрочное планирование", а не скрамный скрам.
Разница в следующем:
Во первых, утверждение, что "команда обязана выполнить все запланированные задачи", противоречит положениям скрама. Вот такая неожиданность! В большинстве команд, с которыми я взаимодействовал, тоже, почему-то, воспринимали конец спринта как дедлайн. Тут возникает много вопросов компетенциям менеджеров и скрам-мастеров...
Тем не менее, идея скрама(тоже не работающая) как раз в том, что мы не можем ничего заранее спланировать и оценить, но можем начать делать, собрать статистику за пол года, и предположить что в ближайший спринт мы сможем сделать примерно столько же, сколько в предыдущие.
Во вторых, задачи следующего спринта, конечно, не стоят в ожидании. Допускается взять в текущий спринт новую задачу, если:
а) цели спринта достигнуты
б) есть задача, которая по оценке влезет в оставшиеся сторипоинты
Так же, хотел бы заметить темную сторону Kanban-а, которую обычно прячут за формулировками типа "перераспределить ресурсы" или "оптимизировать процесс".
Например, если в разделе «Тестирование» накопилось слишком много задач, это может означать, что можно уволить парочку программистов, парочку аналитиков и провести сокращения далее по цепочке - тогда, в теории, выход продукции окажется прежним (сколько может переварить тестировщик), а затраты сократятся. На практике, конечно, надо учитывать пики загрузки разработки, настроения в коллективе, общий уровень комфорта и чувство безопасности работников, и много чего еще. Но простые методы приманивают "простых" людей - в этом есть некоторая опасность.
Спасибо за отличное дополнение к моей статье. Не могу поставить плюсик в карму, т.к. пишет, что у вас нет статей и выше +4 карму поднять нельзя, хотя я ясно вижу, что карма у вас сейчас +5.
утверждение, что "команда обязана выполнить все запланированные задачи", противоречит положениям скрама. Вот такая неожиданность!
Scrum предполагает, что в конце спринта будет создан некий инкремент, т.к. кусочек готовой работы. А он, в свою очередь, появляется, если выполнить запланированные на спринт задачи.
Если выполняются не все задачи спринта, а только их часть, то это либо исполнители плохо поработали, либо аналитики плохо разделили большие задачи на более мелкие и попался слишком большой кусок работы, либо менеджер запихнул в спринт больше задач, чем может выполнить команда.
А разве менеджер запихивает задачи, а не команда их берет на основании своих оценок? А остатки времени забиваются тасками из бэклога как баблайтемы?
И как аналитик может эстимировать объём работы по задаче и подводные камни?
Scrum предполагает, что в конце спринта будет создан некий инкремент, т.к. кусочек готовой работы.
Чем это отличается от "давайте будем выпускать по релизу примерно раз в две недели, включая в него то что готово к этому времени (попало в колонку Done)"?
зачем? Еще лучше просто раз в две недели демо делать вот и все, а релизить по готовности (Continious Deployment так сказать)
100 лайков! Я реально не понимаю, почему нельзя просто взять и через 2-3 недели срелизить то, что уже сделано! Зачем вообще тогда нужен этот скрам и спринты и вся эта суета???
Почему нельзя? Можно и даже может быть нужно! Если у вас основная ветка всегда в хорошем состоянии, то вы легко каждые 2-3 недели можете делать релиз с тем, что работает.
"Суета" она не про релизы, а про то, чтобы все в команде точно знали, что они делают, зачем они это делают, и куда проект в целом двигается. Границы спринтов это точки корректировки направления работы.
“Пук среньк перенесем на следующий спринт”. И задачи путешествуют бесконечно создавая “инкремент”. Обе методики мертвы без дедлайнов поскольку люди очень хорошо оптимизируют процесс “сделать поменьше и получить побольше”.
Усреднение оценки в скраме хорошо работает когда есть одинаковые круды к реализации и примерно одного уровня разработчики без оверэмплоймента. Иначе это средняя температура по больнице включая морг и крематорий.
В канбане всегда есть соблазн начать “делать” огромную задачу дополняя ее подзадачами на ресерч и прочим. В результате движение вроде есть, а jira на карточке задачи показывает красные точки “100 дней в столбце”, а задача уже до размера кашалота раздулась подзадачами.
Срезание углов это хорошо в меру, мы заранее не знаем принесет ли денег скругление кнопки по радиусу, так что не стоит делать фреймворк для скругления, а именно это начнется если нет сроков.
Так дедлайны есть всегда. Независимо от методологии. Любая методология мертва без дедлайна. Работа без сроков - это уже не методология, а идеология.
В канбане всегда есть соблазн начать “делать” огромную задачу дополняя ее подзадачами на ресерч и прочим. В результате движение вроде есть, а jira на карточке задачи показывает красные точки “100 дней в столбце”, а задача уже до размера кашалота раздулась подзадачами.
Это не проблема методологии. Это проблема организации. Ведь можно сделать одну доску для отображения крупных задач (эпиков, например). Это делается фильтрами в настройках доски. А другая доска будет будет конкретно по этой задаче, где вся работа идет с подзадачами. Более того, я иногда и для аналитиков делал отдельную доску, т.к. у них свои этапы (открыто, в работе, требует уточнения, на уточнении, готово). И когда аналитик завершал по фиче все свои подзадачи, фича целиком меняла статус из "Аналитика" на "Готова к работе"
А что, в канбане нет планирования и оценки? Откуда берутся таски, которых не более чем сколько то на разработчика? Как увязать тест план новой фичи по 3 командам с её разработкой и деплоем? Эстимейты фиксов и фич откуда берутся, или менеджмент не требует сроков и не считает ресурсы?
Точно такие же статьи писали про аджайл и вотерфол - как трудно работать по второму и какое счастье по первому - теперь "они" начали пожирать себя изнутри, ха-ха-ха)))
Команда могла бы выбрать способ организации работы сама, но есть продакты, проджект менеджеры, релиз менеджмент, адм деление на команды и отделы, и всем нужны какие то красивые доски с перманентно улучшающимися показателями. Всё это упирается в команду из нескольких "ресурсов", которая в итого и делает всех счастливее.) И во что превращается какой то конкретный аджайл определяется именно этим менеджментом. И как срезают углы в ясно прописанном скраме или канбане -тоже, а их срезают..
возможно тут есть опытные управленцы проектами и они смогут мне объяснить прописные истины.
часто я вижу в описаниях канбана, что есть три группы задач - к исполнению, в работе, завершено (названия могут отличаться, промежуточные группы тоже могут быть добавлены, например на ревизии).
это выглядит так, что в таком подходе люди это некоторые роботы, которые мгновенно переключаются на следующие задачи, порой даже в другом контексте. но это не так.
как быть с срочными/авральными задачами? в канбане это выглядит так, что одна задача ставится на паузу, а другая задача берётся в работу.
второй вопрос это сроки в канбане. закончили одну задачу, делаем следующую. конвейер, все дела. но как заказчику/менеджеру планировать сроки? у нас же не каждый проект дебиан с его релизным циклом "оно будет готово тогда, когда будет готово". все хотят планирования и хотя бы приблизительных сроков. и я хоть и управленец проектами, я понимаю своих коллег.
в итоге, для меня канбан выглядит как какая-то заготовка методики управления проектом. будто её написал какой-то менеджер, абсолютно не понимающий, а что там происходит "под капотом". нам нужна фича? вот мы создали задачу с описанием фичи (максимально верхнеуровневым), вот задача когда-то пошла в работу, вот мы получили фичу через какой-то срок (нам не известный).
может кто-то пояснить, как в канбане происходит планирование сроков и как отрабатываются срочные задачи?
Дело тут вот в чем.
Два важнейших понятия для канбана: потоки и лимиты.
Канбан, как Вы правильно заметили, изначально изобретен именно для конвейерных задач. Т.е. вы "штампуете" на производстве какую-нибудь свистульку - у нее есть этапы, типа (фантазирую): грубая заготовка, точная заготовка, покраска, лакировка, забивание гвоздика - это и будут этапы канбана. Процесс строго определен, спроектирован и посчитан. Тут нет места "переключению" на задачи, так же как и сроков в it-шном понятии. Допустим, 10 минут на свистульку - 6 свистулек в час.
Канбан позволяет наглядно видеть следующие ситуации:
1. Допустим, поток упал до 5 свистулек в час, Вы смотрите на доску, и видите, что например, на последнем этапе скопились свистульки(задачи), оказывается, что например, не вовремя поставляют гвоздики.
2. Вы хотите увеличить производительность до 7 свистулек в час, для этого смотрите на доску и видите самые загруженные участки - это будут первые претенденты на оптимизацию, а не загруженные, наоборот, можно не трогать.
Проблема же в том, что разработкой новых продуктов в новых отраслях пытаются управлять как 200-летней фабрикой. Такие вот у нас компетенции менеджеров. И соответствующие результаты.
Допустим, поток упал до 5 свистулек в час, Вы смотрите на доску, и видите, что например, на последнем этапе скопились свистульки(задачи), оказывается, что например, не вовремя поставляют гвоздики.
О! Отличная кстати подводка для моей статьи Горизонтальное масштабирование https://ders.by/arch/scale/scale.html
Потоки и лимиты ОБЯЗАТЕЛЬНО надо видеть! Иначе даже такая простая задача, как масштабирование серверов, будет НЕПРАВИЛЬНО сделана. А "масштабирование" людей - проблема гораздо сложнее!
Канбан - это управление потоком задач, т.е. да, это как работа конвейера. Производительность канбан - это производительность конвейера по производству ценности (полезного для бизнеса продукта).
Планирование там на самом деле очень простое. После нескольких месяцев работы по канбан становится понятно, сколько задач команда решает за одну неделю. Например, команда решает 8 задач.
Один раз в неделю руководители бизнес подразделений собираются вместе на планирование и в течение часа решают, какие задачи они хотят получить выполненными через неделю. Среди этих задач они выбирают 8 наиболее актуальных, которые команда будет выполнять всю следующую неделю. Неделя закончилась, бизнес получил 8 выполненных задач, руководители снова собрались, выбрали 8 новых задач на следующую интеракцию и т.д. В данном случае релизный цикл - это одна неделя. Задачи получили, через неделю они все выполнены.
Если кто-то заболел или в отпуске, то производительность упадёт до 6 задач в неделю, т.е. на следующую неделю можно будет предложить команде для выполнения только 6 задач.
как быть с срочными/авральными задачами? в канбане это выглядит так, что одна задача ставится на паузу, а другая задача берётся в работу.
Сотрудник всегда видит только 2 активные задачи. Больше ничего. Сотрудник выбирает одну задачу и начинает её выполнять. Если сделал, то приступает к выполнению второй задачи. Представим, что прилетает срочная задача. Сотрудник делает одну задачу, а вторая в очереди. Сотрудник заканчивает первую и у него есть выбор: начать вторую задачу, как он планировал ранее или же взять в работу новую срочную задачу. Нет никакого переключения контекста, т.к. первую задачу сотрудник выполнил, вторую он ещё не начинал, а о срочной узнал только что. В канбан приоритет всегда отдаётся тому, чтобы сначала закончить свою текущую задачу, прежде чем браться за новую задачу, т.е. приветствуется однозадачность, а не многозадачность.
в итоге, для меня канбан выглядит как какая-то заготовка методики управления проектом
В общем-то, так оно и есть. Канбан – просто один из инструментов, полная система управления проектом им не ограничивается. Но инструмент весьма полезный.
может кто-то пояснить, как в канбане происходит планирование сроков и как отрабатываются срочные задачи?
Да с целом так же, как и без него. Но доска помогает увидеть ошибки планирования, и оперативно корректировать их по мере выполнения работ.
Scrum и Kanban, стали основными инструментами для команд
Жаль, что люди забыли еще один метод: Бригада хирурга!
Где-то лежит у меня старая бумажная книга времен СССР. Перевод еще более старой книги, естественно.
Там, на заре компьютерной эры, очень неглупые люди пытались найти эффективные формы организации труда. И предложили взглянуть на хирургов:
Операцию выполняет хирург! А бригада ему помогает.
Высококвалифицированный хирург приходит к уже подготовленному пациенту. А низкоквалифицированные помощники готовят пациента, подают инструменты, держат края раны, зашивают что могут...
В результате чего самый квалифицированный специалист работает с МАКСИМАЛЬНОЙ ЭФФЕКТИВНОСТЬЮ, не отвлекаясь на ерунду.
А теперь берем макдональдс. Там любой сотрудник в ротации и может делать все что угодно. И нет никакого "великого" хирурга, который есть не что иное как огромный риск для бизнеса.
Это не метод, а подход. Называется предложение Харлана Миллза. Был такой математик, теоретик структурного подхода к созданию ПО и один из CTO в IBM в 70-х годах.
Это у Брукса в «мефический человеко-месяц» описано
Всё справедливо, но нельзя о процессах (любых) говорить, забывая, зачем команда работает. А работает она, что бы выпускать продукт. Именно ВЫПУСКАТЬ. И в плане релизов скрам - модель более логичная, так как в идеале релиз складывается именно из спринтов. Это даёт возможность планировать релизы оунеру и стейхолдерам более понятным для них образом. При канбане планирование релизов становится более сложной задачей, особенно если, как в статье написано, разработчик дёргает то, что ему нравится из беклога, а не менеджер следит за очерёдностью выполняемых задач.
Но, такой канбан способен работать, если релизный процесс позволяет выкатывать фичи не релизами, а on demand, со всей соответсвующей инфраструктурой вокруг этого процесса, что само по себе далеко не бесплатно и просто.
Вообще, канбан, по ощущениям, требует большего уровня осознанности и ответственности от всех сторон. Это не всем по нраву, поэтому вот и хочется прикрываться какие-нибудь ритуалами.
И ещё, кажется, что канбан лучше работает, когда команда совсем небольшая. Сильно большие команды, при этом в принципе не жизнеспособны, а вот в средних некоторые элементы скрама неплохо помогают бороться с хаосом.
Хотя вот помню эти утомительные сессии планирования, когда берешь с потолка сторипойнты и пытаешься в спринт впихнуть работы чтобы он не лопнул. При том, что многие фичи, когда их делать начинаешь, сразу нарываются на тех долг, который не был запланирован, но который вот прямо надо сделать, иначе пара таких фичей ещё сверху и проект погибнет под грузом комбинаторного взрыва. А потом в конце спринта часть задач переезжала в следующий и приходилось резать скоуп. И начинались утомительные споры о том, что важнее а что нет.
Что для себя понял, что сроки, сторипойнты и все такое сами по себе не имеют смысла и ценности. Они нужны лишь для того, чтобы сприоритезировать что делать дальше. И тут сложность и длительность умножается на срочность задачи. В итоге где-то на этой связке между срочностью и трудоемкостью все и балансирует. А вот какие сроки в реальности будут, то это одному Ктулху известно.
Вы просто не умеете их готовить. Такой скрам, который вы описали не то, что не мёртв, он никогда и не рождался как методология гибкой разработки.
Оценка сроков нужна для оценки корректного разбиения задачи на подзадачи, которые выполняются за спринт - это не угадайка. Срок задачи в один спринт некуда ускорять и некем. Если задача большая, то ее нужно разбить на более мелкие - в этом основной смысл. Если у вас за спринт у каждого несколько задач - укорачивайте спринты.
Скрам-мастер - это роль, а не специально обученный человек. Эту роль хорошо передавать между членами команды.
Если на спринт вам "дают" задачи, то у вас не знакомы с Agile-манифестом и это у вас что угодно, только не скрам. Задачи разбирают те, кому они интересны.
Ну и сравнение гибкой методологии разработки с доской задач - это, похоже, какая-то шутка.
А где тестирование всего продукта?
Как по мне, дело не в методиках как таковых, а в деталях их применения. Скрам уместно применять, если стоит цель хоть как-нибудь (даже костылями) закрыть задачу и потом улучшать то, что натворили (по сути, путь mvp). В таком случае, конечно, нет смысла спрашивать исполнителя за качество и пытаться выжать из него все соки. Либо, как второй вариант, накидывают теоретический максимум задач, а решается только, сколько успели, без претензий к исполнителям. Такое тоже не всем подходит, но если нет критически важных взаимозависимых задач - работает. Оба варианта не работают, если в это влезает менеджер, который пытается оценить качество и количество закрытых задач, как раз потому что скрам не про это. Из описанного понятно, что скрам - это про работу маленькой команды или стратапа.
Вы просто смотрите с колокольни разработчика, и как для молотка все в мире гвозди, то и для девелопера все задачи это про немедленное и жесточайшее написание кода. Отступление законченно.
Я рискну предположить что проблемы со скрамом и канбаном проистекают из проблем с планированием. Если у вас канбан, то все задачи должны быть одинакового размера, иначе ритмичности работы вы не добьетесь. И вот тут и прячеться дьявол, ибо это довольно сложная сама по себе задача, грамотно разбить сложный таск на допустим 6 «стандартных» которые можно сделать за день и протестировать за день.
В скраме задачи могут быть любого размера, но и там проблема с эстимейтвми.
Грамотное среднесрочное планирование и многократное разбиение тасков на более мелкие отнимает много времени и сил, и потому очень непопулярно у команд - ну все и так же ясно, погнали!
Полностью согласен с вами, что задачи должны быть одинакового размера, иначе ритмичности работы добиться будет сложно. Спасибо за отличное дополнение.
Поясните, зачем нужна некая мифическая ритмичность? 80% задач имеют примерно одинаковую длительность, 20% же требуют заметно большего или наоборот меньшего времени. Тем не менее их всех нужно делать согласно приоритетности. Если в приоритете сейчас сложная длительная задача, её всё равно будем делать, потому что она должна быть готова, прежде чем можно будет заниматься чем-то другим. И наоборот, если есть две-три срочные задачи не требующие много времени, их делаем друг за дружкой, но при чём тут какой-то ритм?
автор слишком плохо замаскировал свое предвзятое отношение ;) все работают по как бы по скраму и используют для этого канбан доску, даже интересно узнать у кого и почему не так. Просто потому, что бизнес платит деньги и ему нужен результат, а не ваше "когда сделаю хз, just leave me alone". Для скрама действует простая житейская логика: надо ставить людям маленькие дедланы, потому что попасть в один большой дедлайн невозможно (ну только если вы сильно не переэстимируете). Такова человеческая натура. Чтобы люди не выгорали надо ставить неделю на тестирование и доделки между двумя-тремя неделями разработки. Вот и вся наука.
не ваше "когда сделаю хз, just leave me alone"
как ни смешно, но это САМЫЙ ЭФФЕКТИВНЫЙ метод! Инженер сел за Задачу и полностью на ней сосредоточен. а любые сторонние прерывания лишь удлиняют сроки.
да, есть вариант, когда надо вмешаться чтобы прекратить выполнение (если задача утратила бизнес смысл). но вмешаться чтобы потом продолжить - это потеря Времени!
Называется предложение Харлана Миллза. Был такой математик
из статьи:
При некотором размышлении ясно, что эта идея приведет к желаемому, если ее удастся осуществить. Лишь несколько голов занято проектированием и разработкой, и в то же время много работников находится на подхвате. Будет ли такая организация работать? Кто играет роль анестезиологов и операционных сестер в группе программистов, а как осуществляется разделение труда?
а знает ли Уважаемая Общественность для чего нужен анестезиолог?
анестезиолог нужен не для того, чтобы пациент уснул. анестезиолог нужен, чтобы пациент проснулся!
ЗЫ а усыпыпить могут даже в макдональдсе.
Начнем.
Пункт 1.
На протяжении спринта команда обязана выполнить все запланированные задачи, что может создавать давление на исполнителей и вынуждать их принимать не самые оптимальные решения, а также склонять их к «срезанию углов», чтобы успеть всё выполнить к ранее обозначенным срокам.
Вы хотите сказать, что, поскольку в Канбане нет формальных ограничений по времени выполнения задач, в условиях использования этого метода исполнители будут зачастую иметь возможность принимать оптимальные решения? Или вы хотите сказать, что в Канбане вообще нет сроков выполнения задач? Уточните, пожалуйста, что вы имеете в виду.
Отвечу наперед:
Ограничение по времени выполнения задачи напрямую не относится ни к Скраму, ни к Канбану. Это базовые вопросы проектного управления, которые стоят над методами и фреймворками. В Скраме идея спринтов (если упрощенно) – это вовсе не «жесткий коридор», а средство снизить неопределенность и структурировать работу, аккуратно спланировать ближайший блок работы и вместе обсудить, как именно мы это будем делать. Если необходимость «срезать углы» и происходит в реальной практике, то это, скорее, проблема конкретной организации или менеджмента, а не теоретическая установка Скрама.
В Канбане задачи не делают «вечно» — есть понятие срока поставки (delivery date), которое может оговариваться со стейкхолдерами. Если же вы имеете в виду, что формат спринтов поощряет жёсткие сроки, тогда стоит уточнить, что это не установка самого Скрама, а возможный перекос в практике конкретных команд.
Пример: Есть компании, которые успешно совмещают Скрам и точечные сроки, не провоцируя команду на «героизм» и «уголосрезание». А в Канбане, как правило, тоже есть дедлайны, когда это оговаривается со стейкхолдерами. Спринты в Скраме – просто один из форматов, а не жесткое правило «успеть любой ценой».
Пункт 2.
Никто и никогда не знает реальных сроков выполнения той или иной задачи, поэтому команды впустую тратят своё время, чтобы примерно оценить сроки выполнения. Было бы лучше, если бы это время было потрачено на реальную работу, а не попытки угадать сроки выполнения задач.
Здесь вы фактически говорите: «Не нужно ничего планировать, просто работайте». Но полный отказ от планирования противоречит и классическому треугольнику «Scope—Time—Budget», и любым разумным подходам к управлению проектами. Скрам, кстати, не настаивает на «угадывании» точных сроков: достаточно грубых оценок (story points, t-shirt sizes и т. д.), чтобы понимать примерный объём работы.
Добавьте уточнение, если речь идёт о слишком детальных или долгосрочных прогнозах, которые действительно могут быть излишне трудозатратны. Но говорить, что «вообще не надо оценивать» — звучит радикально и не отражает гибкие практики, используемые в реальных командах.
Пункт 3.
Если во время планирования спринта исполнитель сообщает о коротких сроках выполнения, то на спринт ему просто дают больше задач, чтобы он не скучал без работы. Если же исполнитель называет очень большие сроки, то ему говорят, что это очень долго и что сроки нужно уменьшить. И вообще, у нас тут очень много задач в очереди, поэтому работать надо быстрее и эффективнее.
Примерные сроки выполнения, названные наугад во время планирования, становятся вдруг обязательствами во время спринта, что ещё сильнее демотивирует команду и ведёт к постоянным спорам между исполнителями и Product Owner’ом по поводу сроков и количества задач для спринта.
Подобная ситуация говорит не о Скраме как таковом, а о неправильной реализации: команда должна сама определять, сколько задач способна взять на спринт, и Scrum Guide это чётко фиксирует. Если в вашей практике происходит давление на оценки (когда «меньше времени» = «возьмём больше задач», а «больше времени» = «не оправдывает ожиданий») — значит, налицо организационная проблема, а не дефект Скрама.
Пункт 4.
Третий момент. Scrum – это работа спринтами, т.е. интенсивная работа над задачами в течение короткого промежутка времени. Любой спринт, например, в спорте, предполагает длительную фазу отдыха после окончания спринта. Но в Scrum ничего подобного нет, поэтому команды очень быстро выгорают из-за постоянных интенсивных нагрузок. Спринты хороши лишь в краткосрочной перспективе, например, чтобы закончить работу, когда до дедлайна осталось всего пару недель или месяц. Scrum же превратил спринты в долгосрочный марафон на выживание, в котором сжигаются целые команды.
Kanban не использует спринты, что позволяет команде работать в режиме непрерывного потока. Задачи выполняются по мере их поступления, и нет необходимости ограничиваться конкретными временными рамками. Команда может адаптироваться к изменениям более гибко и быстро, без необходимости подгонять работу под спринт.
Вы пишете "В Скраме нет отдыха - это плохо". А затем вы пишете "Канбан лучше, потому что позволяет работать в режиме непрерывного потока". Слово непрерывно, вроде бы, обозначает без перерыва.
Как Канбан или другие методы / фреймворки / методологии предусматривают время на отдых по вашему? Конечно, никак. И то, сколько команда будет отдыхать, каким образом, и от чего это зависит - не зависит от метода / фреймворка / методологии.
Ни один фреймворк (Scrum, Kanban и др.) напрямую не регламентирует перерывы или отдых. То, как команда берёт отпуск или распределяет нагрузку, — это вопрос менеджмента и организационных процессов.
Если говорить про «выгорание» из-за спринтов: в теории Скрам не подразумевает постоянные «забеги на максимальной скорости». Это обычные короткие итерации (1–4 недели), и нет запрета договориться о паузах. Точно так же в Канбане можно столкнуться с выгоранием, если поток задач нескончаемый.
Пункт 5.
В статье вы упоминаете WIP-лимиты как отличительную черту Канбана. Но WIP-лимиты (ограничение количества задач в работе) можно применять и в Скраме, как и в любой другой методологии, если это помогает команде не «распыляться» и грамотно контролировать «незавершёнку». Канбан-система сделала упор на этом инструменте, но это вовсе не значит, что он «эксклюзивный» и недоступен тем, кто практикует Скрам.
Пункт 6.
2. Гибкость и отсутствие фиксированных ролей.
Одним из главных отличий Kanban от Scrum является отсутствие фиксированных ролей. В Scrum четко определены роли: Scrum Master, Product Owner, и команда разработчиков. Эти роли накладывают определенные обязательства и требуют от участников команды строго придерживаться своих задач и обязанностей.
Scrum Master, Product Owner, Agile Coach, фасилитатор – кто все эти люди? Почему Scrum не может работать без них?
Сначала вы верно определяете ограниченный набор ролей в Скраме, а следующим абзацем перечисляете роли, совершенно не относящиеся к Скраму. Зачем? Для чего? Какую пользу несет этот комментарий?
В Канбане есть Менеджер, естественно. Который также управляет потоком, договаривается, проводит общие встречи и координирует поток в рамках системы.
Kanban, напротив, не ограничивает команду жесткими ролями. Команда сама решает, как распределять задачи, и кто за что отвечает. Это предоставляет больше гибкости, так как члены команды могут переключаться между задачами в зависимости от текущих потребностей проекта.
Кстати, в классическом Скраме, Команда тоже сама решает, как распределить задачи, и кто за что будет отвечать.
Пункт 7.
3. Более высокая прозрачность и управление потоком.
Kanban делает акцент на визуализации рабочего процесса с помощью доски Kanban. Задачи на доске проходят через различные этапы: от «Backlog» и «To do» до «Done», что даёт полное представление о текущем состоянии всех задач в проекте. Такой подход позволяет всем членам команды и заинтересованным сторонам быстро оценить, на какой стадии находятся работы и какие задачи требуют дополнительного внимания.
В Scrum каждая команда планирует задачи на конкретный спринт, но нет такой же глубокой визуализации потока задач, как в Kanban. Scrum ориентирован на завершение определенного объёма работы в ограниченное время, что может затруднить наблюдение за прогрессом работы в реальном времени.
Как применение визуализации противоречит Скрам? Почему вы считаете что в скраме не применяют визуализацию рабочего процесса? Вы пишете что задачи проходят через различные этапы. И потом выделяете "такой подход позволяет..". А в скраме этого использовать нельзя, чтоли? Что такое глубокая визуализация?
На практике большинство Скрам-команд тоже используют доску, очень похожую на Канбан-доску: «To Do / In Progress / Done». Визуализация — общий подход к гибкому управлению. Говорить, что Scrum-команды не визуализируют поток, неверно.
Пункт 8.
4. Процесс непрерывного улучшения.
Хотя Scrum включает регулярные ретроспективы для оценки и улучшения процесса, Kanban позволяет внедрять изменения гораздо более гибко и постепенно. В Kanban можно внедрять улучшения по мере выявления проблем, в отличие от Scrum, где улучшения часто происходят в рамках определенных спринтов.
Абсолютно не раскрыты способы и методики внедрения изменений "Более гибко и постепенно". В чем проблема внедрить изменение в течение 2-х недель? Приведите пример изменений, которые Канбан позволит внедрить быстрее чем Скрам и это сильно поможет бизнесу в цифрах? И как это измерить?
Пункт 9.
5. Более эффективное управление при изменяющихся приоритетах.
В проектах, где приоритеты могут изменяться часто, Kanban может быть более подходящим выбором, чем Scrum. В Scrum изменения приоритетов между спринтами могут привести к нарушению планов и перераспределению задач, что требует времени и усилий. В Kanban изменения могут быть внесены мгновенно — задачи могут быть переоценены и перемещены по доске без необходимости ждать завершения спринта.
Это особенно полезно в динамичных средах, где важно быстро реагировать на изменения в бизнесе или на рынке.
Вы думаете, что если планы бизнеса поменялись в течение спринта, вся команда или команды полностью проигнорируют эту информацию и будут работать по изначальному плану? Что за бред? Это не так работает. Корректировать бэклог спринта можно при необходимости, естественно.
Пункт 10.
6. Нет необходимости в сложном планировании.
В Scrum планирование является важной частью работы. Команды должны заранее определить задачи на весь спринт и утвердить их на планировании. Это может стать затратным и временами излишне сложным процессом, особенно если проект динамичен и часто меняются требования.
Большие статьи, как правило, мало кто дочитывает до конца, поэтому если тебе это удалось, то пусть удача и хорошее настроение не покидают тебя весь следующий год.
Kanban, в свою очередь, минимизирует необходимость в детализированном долгосрочном планировании. Задачи поступают и выполняются по мере необходимости, а управление происходит через ограничение работы в процессе и контроль за её потоками. Это упрощает планирование и позволяет команде сфокусироваться на текущих задачах, а не на долгосрочных планах.
Для вас 2 недели это долгосрочное планирование? Что вообще такое долгосрочное планирование в контексте вашего 6 пункта? Скрам-итерации, которые длятся обычно 1–4 недели, трудно назвать «долгосрочным горизонтальным планированием». Даже если требования меняются каждую неделю, концепция коротких циклов позволяет подстраиваться.
Не существует разработки без планирования. И там и там есть лицо или группа лиц, которые должны сделать так, чтобы было понятно к чему идти и из чего будет примерно состоять работа. Планирование - неотъемлемая часть разработки.
--------------------------------------
Пункт 11. Итоги.
Важно понимать, что Скрам в том виде, в каком он описан в скрам-гайде полностью от начала и до конца - используют очень маленькое количество компаний / команд. Учитывая это и то, что скрам это фреймворк - вы вольны брать принципы / практики и применять их на свои процессы. Тоже самое, кстати, что и с Канбан-методом.
Один из самых важных моментов что вы упускаете - Скрам не противоречит Канбану. Это взаимодополняемые инструменты. Можно использовать принципы Канбан в Скраме.
Ваш текст, к сожалению, иногда смешивает критические замечания об отдельных «косячных» реализациях Скрама с самим фреймворком и принципами. При этом вы не раскрываете до конца все аспекты Канбана, которые делают его действительно мощным инструментом.
Вы попытались написать экспертную статью о преимуществах Канбана, но не упомянули многих его ключевых возможностей и инструментов для управления проектами — например, каденций, метрик (Lead Time, Cycle Time, CFD) или Kanban Maturity Model (KMM). Если ваша цель — показать глубину понимания Канбана, стоит раскрыть эти детали.
Просто процитирую Василия Савунова:
"Прежде всего, Kanban-метод — это инструмент менеджмента, то есть он предназначен для руководителей.
..
Scrum — это не инструмент менеджмента, а способ организации рабочих процессов для разработки новых продуктов."Полезный смысл статьи не понятен. В основном противоречивое чуть ли не в каждом заголовке сравнение фреймворка и метода с абсолютно неполными знаниями. Вывод о «превосходстве Канбана над Скрамом» в вашей статье выглядит спорным. Если хочется подчеркнуть, что вы предпочитаете Канбан, то лучше было бы дать детальное описание его преимуществ, подкреплённое метриками, каденциями и примерами реальной практики.
Все, абсолютно все методики управления, начиная от водопада и заканчивая скрамом, стоят на одном основании - на оценке задач.
Но ведь именно это основание по сути своей миф. Давайте уже наконец признаем - любая оценка - это просто случайное число, которая высасывается из пальца. Да, какие то тривиальные вещи можно оценить, но много ли тривиальных и похожих вещей приходится делать разработчику? Уровень неопределенности в разработке просто запредельный.
И вот на таком основании из тумана в головах разработчиков держатся вообше все методики, даже те которые призваны нивелировать эту проблему.
Можно до хрипоты спорить про то что лучше, но в итоге все выходит боком, просто потому что оценка задачи - это миф. Любая методика основанная на этом мифе сама становится мифом.
Спасибо автору за такое повествование. По большей части я с ним согласен, и объясню почему.
У меня ещё ни разу не было слаженного scrum, а вот kanban был. Поэтому и склоняюсь в сторону второго. Но если бы в моей карьере случилось наоборот, то и думал бы, соответственно, наоборот.
Помимо нескольких других статей про kanban, я также прочёл книгу Алексея Пименова "Метод Канбан. Базовая практика". Далее, хочу прокомментировать точечно, опираясь на книгу Пименова.
На Kanban доске WIP обозначает ограничение на количество задач, которые могут находиться одновременно на каждом из этапов рабочего процесса.
Не на каждом этапе, а только на одном - в процессе :) Из расшифровки WIP - work in progress - понятно, что речь про задачи "в процессе". То есть выполняемые задачи в настоящий момент.
...которое называется WIP (Work in Progress). Это один из ключевых принципов, направленных на управление потоком работы и повышение эффективности команды.
Да, один из, но не единственный. В книге хорошо изложены и другие аспекты. Будь то выявление потребностей и неудовлетворённостей заказчика, выявление узких мест в своей системе и действия над ними: перемещение узкого места на другой этап, его расширение. И дальнейшее подчинение всего процесса узкому месту... Было бы интересно прочесть здесь и эти моменты, как бы автор раскрыл их.
3. Более высокая прозрачность и управление потоком
Kanban делает акцент на визуализации рабочего процесса с помощью доски Kanban. Задачи на доске проходят через различные этапы: от «Backlog» и «To do» до «Done», что даёт полное представление о текущем состоянии всех задач в проекте.
Никто не мешает, работая по scrum или другому методу, включить kanban-доску для отображения задач по стадиям. Многие так и делают :) Сама канбан-доска это просто доска - всего лишь способ визуализации рабочего процесса. Такая доска вовсе не означает, что работа организована по канбану :) И канбан не акцентируется на визуализации рабочего процесса. Канбан акцентируется на управлении работой, а не людьми.
4. Процесс непрерывного улучшения
Этот пункт не раскрыт и не аргументирован совсем :/
6. Нет необходимости в сложном планировании
А вот тут не понял. Любое планирование везде можно усложнить. Это уже от людей зависит, а не от метода организации работы :)
Не на каждом этапе, а только на одном - в процессе :) Из расшифровки WIP - work in progress - понятно, что речь про задачи "в процессе". То есть выполняемые задачи в настоящий момент.
Дело в том, что существует несколько видов досок:
Доска для одной команды, например, только для разработчиков. Команда видит только свой flow и там может быть только один столбец In Progress. Тут всё верно и я с вами согласен.
Доска, где работает сразу несколько разных команд, например, аналитики, разработчики и тестировщики, т.е. все они видят сразу весь flow от аналитики до тестирования. В таком случае может быть несколько столбцов In Progress, по одному на каждую команду.
При внедрении в компании Канбан вначале всегда используется только доска для одной команды. И когда опыт работы по Канбан признаётся успешным, то его можно масштабировать дальше. Например, если соседи слева и справа по потоку создания ценности (flow) хотят участвовать в нашем Канбане, то на доску можно добавить этапы работы этих соседей. Таким образом на доске будет flow сразу трёх команд, т.е. по факту можно будет видеть, как из идеи формируется конкретная задача и как она далее движется по конвейеру вплоть до выхода в продуктив.
Основным плюсом большой доски (отображение всего конвейера) является то, что все видят, как именно их работа будет влиять на людей, стоящих дальше по flow. В работе появляется осознанность, люди из разных групп начинают больше общаться между собой, чтобы выбрать удобный для всех формат совместной работы, запускается процесс постоянного совершенствования (кайдзен).
Канбан доска также служит аналогом офисного кулера, т.е. становится местом притяжения людей, обсуждения рабочих задач и налаживания хороших отношений между коллегами. Все видят на доске реальное положение вещей, видят возникающие задержки в выполнении задач и стараются всячески помочь, чтобы продвинуть эти задачи дальше по flow.
Ужасно не компетентно. Но подчерк узнаваем. Скажите честно, промт был типа: "напиши 10 причин почему Kanban лучше Scrum "?
koba_dmitry пишет "Никогда не понимал хейт со стороны некоторых разработчиков в сторону Scrum! Особенно его много здесь, на Habr." https://habr.com/ru/companies/alfa/articles/868354/
Может быть причина вашего недовольства в том, что моя статья задела ваши нежные чувства к Scrum? Почему бы вам не признаться в этом? Хотя бы самому себе.
С автором статьи согласен в том смысле, что менеджеры гораздо чаще воспринимают скрам как волшебную палочку, которая позволяет "за две недели сделать всё, что написано" (хотя, как подчеркивают многие комментаторы, методология на этом не настаивает). Если же команда работает по канбану, то шанс увидеть адекватного менеджера выше.
Scrum is dead, kanban лучше.
Porsche 911 мертв, карьерный Белаз лучше.
Ножи мертвы, вилки лучше.
Да блин, когда уже прекратят сравнивать между собой инструменты, созданные для разных целей.
Я примерно четверть века работал со стороны ИТ с производственными процессами. Они продолжительны по времени и цена ошибки часто высока. Основной посыл как по книжкам так и по лучшим практикам это непрерывное улучшение. Второй не менее важный посыл - отталкиваться от потребностей заказчиков. Обычно это баланс между сроками исполнения, качеством и ценой.
Для улучшения в базовом случае процесс разбивается на этапы и улучшается тот этап, в котором сложности. Вполне нормально, когда условный прокатный стан работает на 30% мощности и при этом улучшается процессы закупки для ускорения исполнения заказов.
Скрам по мне вполне нормальный подход для команды до 12 человек. ИТ делает всё, чтобы не раздувать команды до большего размера и избегать иерархии. При таком подходе скрам вполне себе работает. Задачи отражают их реальный статус, спринты задают некоторую ритмичность, обязательства в рамках спринта подстёгивает исполнителей. Отлично работает для стартап команд которые обладают всеми полномочиями для, выпуска пролукта, для работы с новым продуктом. Плохо работает, когда команда одновременно выполняет функцию третьей линии поддержки, когда задачи часто блокируются другой командой.
Канбан, который используется в ИТ улучшает взаимодействие команд, плохо работает с задачами среднего и большого размера, некорректно отображает актуальный статус задач (мы же не двигаем задачи влево по доске). Основное отличие - ориентирован на непрерывное улучшение процесса разработки и доставки ценности.
Лично мне нравится некий микс. Регулярность в планировании, концентрация на понятных ближайших целях в рамках 1-2 недель, перенос карточек в сервис, которым они обрабатываются (из тестирования в анализ, например), улучшение времени поставки и гибкое взаимодействие со связанными командами.
Плохой пример: У нас срам ежемесячный и мы добавим реквизит, который ты просишь, в рамках следующего спринта, если туда влезет эта задача. И то, что на это несколько часов надо и для вас критично не так важно. Тут же не скрам виноват, а отсутствие здорового взаимодействия между командами и ортодоксальное следование методологии.
Kanban метод - идеальный инструмент для управления поставкой в разработке. Это факт. Намного лучше проектного менеджмента. В 99.9% случаев заказчику в России нужен именно Kanban метод просто потому, что он (заказчик) не хочет на старте разработки определяться не только с окупаемостью, но и даже с тем, что он будет делать, когда получит результаты разработки. Цитирую то, что я слышу чаще всего: "это мы позже придумаем, ближе к концу проекта". Так и хочется спросить: а вы уверены, что план действий, который вы придумаете потом, не похоронит все ваши требования к разработке вместе с разработчиками, которые вам доверили свое драгоценное время и профессионализм?
Scrum решает эту проблему, потому что на старте заставляет заказчика определиться с тем, как он окупит разработку. Но почти всегда именно этот элемент Scrum (Product / Increment) просто выкидывают, забывают про него, или заменяют его на то, что им не является. Спросите себя, как часто в тех неудачных попытках применить Scrum, которые вы видели, цели спринтов отражали бизнесовые проблемы, а не просто "запилить все в бэклоге спринта" или "стабилизировать релиз" или же цель просто перманентно отсутствовала? Как часто в этих командах вместе с разработчиками работал сотрудник, который персонально отвечает за то, чтоб затраты на разработку отбились через какие то изменения в бизнесе после внедрения результатов этой разработки? Уверен что никогда. Иначе бы эта статья не появилась.
Scrum is dead только для целей управления поставкой фичей, для чего его собственно чаще всего и применяют. Это как забивать микроскопом гвозди, а потом сказать что микроскоп - плохой инструмент. Особенно странно выглядит, когда Scrum пытаются применить для управления проектом. Появляются такие странные артефакты, как бэклог проекта. В общем да, Scrum is dead. Потому что те, кто озабочен проблемой окупаемости разработки, просто не знают о нем или не готовы его применять для решения этих проблем.
Кстати, по моим оценкам, из 2 трлн руб рынка IT в России окупаются от силы 15-20%. ~1.6 трлн руб просто в урну, в мусорку. Людей жаль. Они ведь работали в стол, сделали то, что никому и никогда не понадобится. Инвесторов/собственников жаль, они потеряли свои деньги.
Scrum is dead или почему Kanban намного эффективнее Scrum