company_banner

Скрам умер. Да здравствует канбан

Автор оригинала: Emanuel Marques
  • Перевод
Я пользовался методом управления проектами Scrum (скрам) с самого начала карьеры. Я изучал скрам в колледже. Тогда он считался лучшим методом управления разработкой программного обеспечения. Когда я начал работать, мне нравилось всё, что имеет отношение к скраму: ежедневные встречи, планирование, ретроспективные совещания, спринты и так далее. В конце концов, я пользовался на практике тем, чему меня учили.



Но через несколько лет я начал кое-что замечать: в последние дни спринта все бросаются доделывать всё то, чем занимались в предыдущие две недели, стремясь избежать переноса задач на будущее. Часто те, кто так поступали, брали на себя ненужный риск.

Почему? Разве какие-то задачи не могут подождать до следующей недели? Так ли важно доделать абсолютно всё до выходных? Нет, не так уж это и важно. А всё это происходит из-за того, что «Переносы задач — это плохо».

Скрам — это уже не совсем «гибкая методология разработки»


Я пришёл к выводу о том, что в скрам слишком большое внимание уделяется процессу работы. Или, как минимум, люди обращают на это слишком много внимания, что выражается в следующем:

  • Завершение работы над пользовательской историей в последний день спринта — это нормально. Но завершение работы в следующий понедельник — это уже «перенос задачи».
  • Если нужно сделать что-то незапланированное (исправить ошибку, решить проблему в продакшне и так далее), это повлияет на заранее расписанное время разработчика, и, как следствие, приведёт к тому, что на очередном совещании он не сможет сообщить об успешном исполнении взятых на себя обязательств.
  • Для оценки успешности разработчика чаще всего применяют такую метрику, как соотношение обязательств, которые он на себя взял, к объёму выполненных задач. Сравниваются пользовательские истории, которые обработчик обязался выполнить в начале спринта, с историями, завершёнными в конце (я даже не пытаюсь говорить о том, какие проблемы может принести такой подход).

В результате оказалось, что скрам больше не помогал нам идти к цели. Этот метод управления проектами теперь нас ограничивал.

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

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

Тогда мы нашли Kanban (канбан).

Что такое канбан?


Канбан — это метод управления производством, который появился в компании Toyota в 1950-х годах. В то время в Toyota использовали доску с тремя колонками: «Запланировано», «В работе», «Завершено». Данный фреймворк позволял Toyota более эффективно выделять ресурсы в ситуациях, когда где-то на производственной линии возникали узкие места.

Затем, когда стало ясно, что применение канбан способно повысить скорость разработки ПО, канбан перенесли и в сферу технологий.

Сравнение фреймворков скрам и канбан


В последние годы скрам и канбан сражаются за место ведущего agile-фреймворка. Несмотря на то, что скрам занимает первое место, канбан постепенно распространяется всё сильнее. А что если их сравнить?

Если взять за основу скрам и сравнить его с канбан, то получится следующее:

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

Более подробное сравнение скрам и канбан можно найти здесь.

Канбан даёт команде разработчиков достаточно высокий уровень гибкости. Пользовательские истории, в сравнении со скрам, выполняются в более свободной манере. Но свобода — это ответственность. Несмотря на то, что канбан не требует того, что разработчики каждые две недели берут на себя какие-то обязательства, применение этого метода управления разработкой предусматривает собственные средства контроля за работой. Это, например, такие метрики, как время цикла и пропускная способность системы.

Всё дело в метриках


Нельзя оценить эффективность (или неэффективность) работы, не имея специализированных метрик. Рассмотрим метрики, применяемые в скрам и в канбан.

▍Метрики скрам


При применении скрам используются следующие метрики и графики:

  • Скорость команды (velocity). Количество этапов пользовательской истории, завершённых во время каждого спринта.
  • Соотношение обязательств, которые взял на себя разработчик, к объёму выполненных задач (commitment vs. done). Процент пользовательских историй, по которым были взяты обязательства, и работы по которым были успешно завершены.
  • Диаграмма сгорания задач (Burndown Chart). Диаграмма, которая визуализирует ход работ по пользовательским историям во время конкретного спринта.

Эти метрики вряд ли помогут вам улучшить рабочий процесс.

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

«Соотношение обязательств, которые взял на себя разработчик, к объёму выполненных задач» вообще не должно рассматриваться как метрика. Эта «метрика» сопоставляет обязательства с результатами. Не стоит и говорить о том, что это может привести к тому, что люди будут закрывать и повторно открывать задачи только для того, чтобы они были бы «выполнены».

«Диаграмма сгорания задач» — это то, на что лично я никогда не обращал особого внимания. В основном это так из-за того, что подобные диаграммы часто выглядят примерно так, как показано ниже.


Диаграмма сгорания задач

Почему это так? Предположим, вы начинаете с пустой доски, и приступаете к параллельной работе, например, с тремя пользовательскими историями. Работы по этим историям, вероятно, будут вестись с одинаковой скоростью — именно поэтому на диаграмме сгорания задач можно видеть такие мощные нисходящие движения. Более того, если в команде имеется всего один тестировщик, который должен тестировать результаты выполнения работ по всем задачам, то он окажется узким местом команды.

▍Метрики канбан


Я полагаю, что метрики — это самая важная из сильных сторон канбан. В канбан имеется множество различных метрик, которые помогают лучше понять то, что происходит с командой. Например:

  • Пропускная способность команды (throughput). Количество пользовательских историй, работы по которым завершены в заданный промежуток времени.
  • Время цикла (cycle time). Число дней, которое уходит на завершение работ по истории с момента начала работы. Здесь используются такие показатели, как доверительные интервалы. Наиболее распространенным является доверие на 85%.
  • Кумулятивная диаграмма потока (cumulative flow diagram). Такая диаграмма позволяет визуализировать процесс решения задач по пользовательским историям. Выглядеть эта диаграмма должна примерно так, как показано ниже.


Кумулятивная диаграмма потока

Существует плагин для Jira, который позволяет пользоваться всеми этими метриками. Это — ActionableAgile for Jira — Agile Metrics. Он помогает исследовать метрики, имеющие отношение к деятельности команды, используя ту же платформу, что используется для управления работой.

Адаптация канбан


Применение «чистого» канбан не предусматривает выполнение некоторых операций, обязательных при применении скрам. Но этот метод управления проектами достаточно гибок и позволяет, если подобные действия кажутся полезными, добавлять их в рабочий процесс.

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

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

Мы сохранили и ещё один элемент из наших скрам-времён, который необязательно применять при использовании канбан. Речь идёт об оценке времени, необходимого для работы над пользовательской историей. Это делается в ходе уточнения задач, которые входят в историю. В скрам подобные оценки используются для того чтобы лучше понять то, что «поместится» в спринт. Можно подумать, что, так как в канбан нет спринтов, то оценка историй тут не нужна. Но, на самом деле, это не так.

Оценка сроков, необходимых на выполнение пользовательской истории помогает обеспечить то, что все члены команды одинаково видят объём задач, который необходимо решить в ходе работы над историей. Если кто-то даёт истории оценку в 8 баллов, а кто-то — в 3, очевидно то, что нужно продолжить обсуждение этого вопроса. Кто-то может, оценивая сроки, учитывать какие-то проблемы, о которых другие не знают. В чьём-то понимании в объём работ по пользовательской истории должно входить что-то такое, что другие в таком качестве не рассматривают.

Собственно говоря, всё это подталкивает членов команды к дискуссиям.

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

Ещё один часто встречающийся сценарий выглядит так: вся команда даёт трудоёмкости истории довольно высокую оценку (обычно это — всё, что больше 8 баллов). Это говорит о неуверенности. Это значит, что либо речь идёт о большом объёме работы, либо — о решении очень сложных задач, что вызывает у членов команды неприятные ощущения. В подобном случае лучше всего будет разделить пользовательскую историю на несколько более мелких историй и чётче определить цели работ.

Итоги


Скрам навсегда останется в наших сердцах как первая широко распространившаяся agile-методология. Но по мере того, как компании переходят к схемам непрерывного развёртывания решений, использование спринтов, ограниченных по времени, больше не имеет смысла.

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

Что больше подходит вам? Скрам или канбан?

RUVDS.com
RUVDS – хостинг VDS/VPS серверов

Похожие публикации

Комментарии 106

    +1

    Гнобить весь фрейворк по причине того, что команда не смогла корректно разделить задачии на атомарные, а скрам мастер не подобрав продолжительности сплита сосредоточился на velocity? Мне кажется, канбан скраму никак не мешает и наоборот.

      +10

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

        +1
        Scrum о другом, у вас просто итеративная разработка, которую называют Scrum-ом, но которая им не является.
          0
          Та же фигня с BDD — объявляют о переходе на BDD, затем обмазывают тесты геркиным и считают, что этого достаточно.
            +2
            Agile это про гибкость, Scrum это про итеративную разработку с каргокультом
            0

            Это пример того, как не разобраться и сделать криво, а не скрам не работает. Что в случае вашей организации мешало отдельным командам выбирать длину спринта индивидуально и делать демо только когда нужно? Ну и включать голову и адаптировать процессы. Если так подумать, многие правильные но хайповые идеи не работают, так как их внедряют абы как и потом страдают.

              +6
              Что в случае вашей организации мешало отдельным командам выбирать

              То, что топ менеджеры сходили на тренинги по SAFe (registered trademark), где им рассказали, что две недели это идеальный спринт.
              Точно так же, как мы неможем делать эстимейты в «t-shirt size», потому что только имея сторипоинты можно сгенерировать красивые графики и показать топам. Почему обязательно рисовать презентацию на демо? Потому что директор департамента дупля не отстреливает, что ему показывают. А презентация «это сильно и надежно».
              И моя точка зрения в том, что внедрение скрама это всегда такое порно и каргокульт.
              Тогда, когда комманда может действительно гибко работать, от скрама остается только планнинг, стендапы и демо в 15 минут. Или вообще одна канбан доска.
                +1
                И моя точка зрения в том, что внедрение скрама это всегда такое порно и каргокульт.

                Часто. Может быть даже очень часто. Но точно не всегда.

                Тогда, когда комманда может действительно гибко работать, от скрама остается только планнинг, стендапы и демо в 15 минут. Или вообще одна канбан доска.

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

                  Ретроспективу — обсуждение того, что можно улучшить в целом в текущих процессах.

                    +2
                    Зачем ретроспективы каждый спринт, когда комманда уже сработалась за 6-12 месяцев работы?
                    Что мешает поговорить о проблеме сразу после ее обнаружения? зачем ждать конца спринта?
                      0

                      И решила все проблемы?


                      Ну, например, все заняты работой, чтобы успеть достичь целей спринта. Ну или несильно их зафейлить.

                    0
                    >Или я что-то важное упустил?
                    Нет конечно, но посмотрите на диаграммы SAFe, которую интенсивно навязывают компаниям, и смахните слезу вспоминая манифест agile
                      0
                      Я даже не знаю что это за диаграммы и с чем их едят. А я уже ЛММ знает сколько разных вариантов «реализации скрама» успел повидать :)

                +1
                Вполне работает. Но для этого все должны понимать, зачем он нужен и какая от него польза.
                  +1

                  И стремиться эту пользу получить.

                  0
                  Мое мнение — методология должна быть под задачу. Т.е. нет одной универсальной методологии, оптимальной для всех задач. Но манагерам слишком сложно понимать и управлять зоопарком методологий. Им нужно одно спасительное средство, чтобы не перенапрячь мозги. И мерить все в майках, желательно одного размера. Поэтому и идет нездоровая волна найти одно универсальное лекарство.
                    +1
                    Да, по хорошему переход на гибкие методологии должен звучать «вы комманда профессионалов с опытом больше 10 лет, посмотрите на доступные фреймворки и решите как вам работать эффективнее, чтобы и разработка двигалась и клиенты были довольны. Если понадобяться тренинги и литература — обратитесь в своему менеджеру».
                    Но где вы такое видели?
                      +1

                      А зачем тут фреймворки?

                  +4
                  Гнобить весь фрейворк по причине того, что команда не смогла корректно разделить задачии на атомарные

                  Если задачи в конкретном проекте плохо делятся на сабтаски в рамках требований конкретного фреймворка — это как раз проблема фреймворка и, да, — очевидная причина сменить фреймворк.

                    +2
                    Так «сменить фреймворк» или заявить что «феймворк умер»? То есть вы же не будете кричать что JavaScript умер только потому что пытались использовать его в каком-нибудь эмбеддеде и у вас ничего не вышло? :)
                  +7
                  «Единственным достоинством Скрам-а является то, что ваше начальство в любой момент знает — сколько времени займет передача вашего проекта индийскому аутсорсингу» (с) кто-то в Интернете
                    +10

                    Чем дольше я работаю тем глубже убеждаюсь что все эти скрамы с канбанами не пригодны для технически сложных проектов, где месяцы если не годы могут уйти на выработку правильной методологии/архитектуры


                    А все эти скрамы с канбанами годятся только для типовых проектов

                      +8

                      Границы применимости есть у всего.
                      В частности, итеративная разработка, незаменима там, где неизвестно, что будет завтра. Что сделают конкуренты, что выяснят аналитики. Когда мы не можем планировать далеко.
                      Те же стартапы.
                      Под это есть даже специальный термин: запутанный домен.


                      В сложных системах тот же скрам не применим в чистом виде.


                      Но agile, в первую очередь, про гибкость. Все об этом забывают.
                      У нас был коуч, крутой, который говорил: да вообще пофигу, как вы будете работать. Цель — эффективность. Подстраивайте все под себя. Экспериментируйте с процессами.
                      А его работа — подсказывать возможные пути, изучать практики других компаний, учиться на чужих ошибках и успехах.

                        0

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

                          0

                          Избавляются там, где это возможно и целесообразно.
                          В основном, это клиент-серверные приложения.


                          Сложные объемные проекты остаются. Десктопное ПО, game dev, ОСи (для тех же телевизоров) — первое, что приходит в голову.

                            +3

                            Работаю уже в 4й компании в ГеймДеве, используют и скрам и канбан. Да, если вы делаете новую игру, вы не знаете сроки, но почему это мешает использовать аджайл фреймворк?

                              0

                              Мои слова были про «избежать длительных процессов» и «две недели — новый функционал». Посмотрите по ветке.


                              Ничего не мешает использовать скрам/канбан :)

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

                            Как вы собрались выкатывать функционал через 2 недели, если год может уйти только на поиски правильной архитектуры и смежные вопросы? По вашему после появления аджаила все сразу забили на серьезные проекты?
                              0
                              Как-то вот так
                              image
                                0
                                И как разбивка на спринты помогает решить проблему?
                                  +2
                                  Интересная, кстати, картинка.
                                  1. У нас тележка на двух (?) колёсах. Какие-то колёса, какие-то оси, какие-то подшипники. Катится, и ладно.
                                  2. У нас самокат. Значит, переднее колесо уже поворотное, есть рулевая колонка… очевидно, на самокате надо будет ехать, уже требования к материалам. По сути, тележку надо переписать заново. Но поскольку той тележки десять строк кода, это мелочи.
                                  3. Велосипед. Оппа, у нас рама. У нас большие тонкие колёса. У нас надувные шины. У нас цепочная передача. С самокатом ничего общего вообще. Всё надо делать с нуля, в том числе рассчитывать материалы.
                                  4. Это же не электровелосипед, это мотоцикл? Внезапно, рама велосипеда совсем ни при чём, всё надо делать иначе. Надо присобачить ДВС. У нас уже совсем другие колёса, общего с предыдущими — надувные. Ну рулевую колонку можно взять с велосипеда и доработать, да, правда материалы опять другие…
                                  5. Внезапно у нас четыре колеса. Внезапно вилка, которую мы с таким трудом проектировали, не нужна. Зубчатая передача тоже не нужна, и в целом трансмиссия существенно усложняется. Правда, можно кое-как использовать сам ДВС, да генератор с аккумулятором.

                                  Итого — у нас вместо последовательных приближений пять разных продуктов, имеющих между собой общего в лучшем случае некоторые неочевидные тонкости реализации. 50% «сервисов» уходят на помойку к следующей итерации, 90% — через итерацию. Зато картинка красивая.
                                    +1
                                    Естественно так никто не делает. По хорошему клиент сначала получает машину с рамой, четыремя колёсами, одним сиденьем, рулём и педалями. И уже может на этом потихоньку начинать кататься у себя во дворе. А потом он сам решает что ему надо добавить в первую очередь: лобовое стекло, крышу или магнитолу. Опять же если скажем лобовое стекло не добавить пока нет каросерии, то клиенту обьясняют зависимости и он выбирает свои хотелки уже в соответствии с ними.

                                    Плюс если он после установки каросерии и стекла замечает что скажем лобовое стекло его не устраивает по форме/размеру, то можно переделать каросерию пока на неё ещё не повесили двери. И получается что тогда двери переделывать не надо будет.

                                    И так потихоньку шаг за шагом клиент получает новую машину.
                                      +2
                                      :) Хороший анализ. Но есть кое-какие нюансы.
                                      Да, при переходе от каждого изделия к следующему, приходится много чего переделывать в самом изделии. Но…
                                      1. Когда вы запустили в производство скейтборд, у вас пошли живые деньги. Не через 5 лет, а через полгода. И это совсем не то же самое, что делать с нуля автомобиль без денег, на одних обещаниях инвесторам.
                                      2. Когда вы сделали скейтборд и начались продажи, вы уже не «тот придурок», который строит звездолет на пустом месте, а человек с опытом запуска бизнеса, которому инвесторы более охотно дают деньги. Это и корпораций касается. Там свои «инвесторы».
                                      3. Да, для самоката нужно делать фактически новую конструкцию, но часть оборудования для производства подойдет от самоката, поставщики частично уже есть, сеть сбыта уже налажена, каналы продаж протестированы и известны. Кроме того, есть уже сработавшаяся команда, методы управления, постановки и решения задач и много чего еще.
                                      4. Если для скейтборда достаточно команды из пары человек, то автомобиль уже может разрабатывать команда из пары тысяч человек. В итоге, мы вполне можем уложиться в те же полгода, условно говоря.

                                      Если посмотрите на Маска, то он сначала сделал Paypa, потом Tesla, а уже потом замахнулся на Space X. И даже со Space X у него сначала простая ракета появилась, а уж потом он стал спасать первую ступень.
                                        0
                                        Если посмотрите на Маска

                                        Я так понимаю, вы нам сейчас покажете тесла-скейтборды и тесла-велосипеды, которые были перед тесла-автомобилем?
                                          –1
                                          > Когда вы запустили в производство скейтборд, у вас пошли живые деньги

                                          Стоп. Это уже не MVP, это уже «запустили в производство» и «начались продажи»?
                                            +2
                                            Пожалуйста, отличайте прототип от MVP. Цель MVP — это продажа. MVP — minimal Viable product. Прототип действительно никто не собирается продавать, его цель — подтверждение технической возможности создания продукта, либо получение инвестиций.
                                              0
                                              То есть MVP автомобиля — это двухколёсная тележка. Ну ладно, я вижу тут с этим полный консенсус, куда мне против ветра.
                                                0

                                                Нет, MVP автомобиля — это не двухколёсная тележка в настоящее время. Это автомобиль, который хоть кто-то из ЦА возьмёт хотя бы бесплатно, но будет реально пользоваться

                                  0

                                  Согласен. По скраму, я должен за 4 спринта выдать MVP. По хорошему я должен сначала потратить четыре спринта на пару итераций рефакторинга и стабилизации архитектуры.

                                    +2

                                    Откуда про MVP за 4 спринта? В настоящем скраме вам могут сказать, что цель — создать MVP. За сколько вы его создадите и какие работы будут входить в состав — решаете вы.

                                      +1

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

                                        +1

                                        А это от процесса особо не зависит.

                                      0

                                      На первый взгляд — нет такого правила, что mvp за 4 недели. Кроме того, рефакторинг и архитектуру вообще можно вынести за mvp и делать только если прототип окажется кому-то нужен. Тут правда всплывает другой тонкий момент — руководство захочет пускать в прод как есть и надо быть готовым отстоять время на приведение кода в порядок.

                                      0
                                      вот да, у нас на работе 2 года где то как один очень активный эффективный менеджер внедрил аджайл со скрамом. При этом специфика такова, что от дейли отказались где то год назад — делаем сверку раз в неделю — «викли» что ли )
                                      А спринты могут длится месяца по 2.
                                      И тут дело не в том, что кто то из нас — или мы все — некомпетентны и не умеем это готовить. Просто повторю специфика такая, а так за это время в муках выработали для себя более-менее приемлемый симбиоз, при котором развитие проекта в наших условиях происходит максимально продуктивно…
                                      Месяц назад появляется новый менеджер, конечно же эффективный. Решивший, что этого его качества буквально не хватает ни нам ни проекту. И вот у нас уже сегодня слово в слово как в заголовке — долой скрам, на здравствует канбан. Типа это все изменит.
                                        +3
                                        beduin01
                                        на 100% согласен — на крупных проектах фанатичные скрамы и канбаны не помогают, а только делают проект дороже, и зачастую бесконечным…
                                        проверено много раз на практике…
                                        а на мелких проектах скрамы и канбаны больше нужны для руководителей сомневающихся в своей команде исполнителей…
                                          +1

                                          Мне, как исполнителю, совсем не интересно сидеть и закрывать по очереди таски, не понимая кому и зачем они нужны.

                                            0
                                            Или закрывать таску и через одну таску в новом спринте пилить CR к ней. Просто потому, что надо было не вылезать за спринт. Зато теперь и в код заново погружаться, и тестировать и с регрессом покопаться. Да и аналитику ФО обновить не помешает…
                                          0
                                          Скрамы с канбанами это отличные инструменты, пригодные для проектов любой сложности. Проблемы возникают не из-за инструментов, а из-за дураков начальников.
                                            0
                                            Окей, расскажите какой толк мне от скрамов с канбанами если мне пол года пришлось изучать предметную область и пол года потратить на выбор правильных инструментов и проработку самой архитектуры?
                                              +1
                                              А полгода, которые вы потратили на изучение предметной области и полгода, которые вы потратили на выбор правильных инструментов — это вообще много или мало? Может, среднестатистический разработчик потратил бы на это все в сумме месяца два, и вы по сути почти год груши околачивали. Может, ваша тема настолько сложная и новаторская, что среднестатистический разработчик и за полжизни бы не справился, и вы буквально за год совершили прорыв мирового уровня в разработке.

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

                                              Проблемы начинаются тогда, когда скрамы с канбанами внедряются как карго-культ, без понимания. Как аборигены, которые строят самолет из говна и палок, чтобы он принес им вкусные ништяки. Ништяки волшебным образом почему-то не появляются, и аборигены говорят «фигня эти самолеты, отстой, не работает оно».
                                                –1
                                                Да контроль нужен, но зачем нужны какие-то фреймворки с описанием на сотни страниц? Неужто разработчики на столько глупые что сами не могут прогресс в решении задач как-то описать?
                                                  +1
                                                  Да контроль нужен, но зачем нужны какие-то фреймворки с описанием на сотни страниц?

                                                  Хм, а где вы в скраме увидели «описание на сотни страниц»? Я помню нам раздали методичку и там всё влезло на две стороны обычного А4.

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

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

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

                                            А можете рассказать как вы строите процессы при разработке таких продуктов? А заодно пояснить как вы разделяте их на типовые и сложные?

                                            +1
                                            Чем дольше я работаю тем глубже убеждаюсь что все эти скрамы с канбанами не пригодны для технически сложных проектов, где месяцы если не годы могут уйти на выработку правильной методологии/архитектуры
                                            А все эти скрамы с канбанами годятся только для типовых проектов

                                            Если посмотреть на технические задачи «дизайн» «анализ» и т.д. как на задачи у которых заказчик «команда», то все вполне ложится в «скрамы-канбаны» поскольку «business value» в конце итерации это найденные решения, идентифицированные риски, «физика» базы данных\API\файла и т. д.
                                            Будет не одна команда, а несколько из одного или нескольких человек. не большая проблема
                                              0
                                              Кажется мне, что если скрам еще можно натянуть на проектное управление, то канбан это чистый поток (хелпдеск 2-3 линии). А если захочется все-таки сдать заказчику проект, то над командой, работающей по канбану придется ставить РП с какими-то надкомандными методами управления проектом, архитектурой, очередностью и тд.
                                                0

                                                Скрам — это фреймворк.
                                                И в нем всегда есть Product Owner (PO).


                                                А канбан, приведу цитату скрамтрека:
                                                «В Канбане нет строгого понятия, что есть Канбан, а что не есть Канбан»


                                                Как построите — так и будет. Ничего не мешает ввести в команду PO.
                                                И, не смотря на поток, в канбане есть мероприятия по планированию и т.д.

                                                  0
                                                  «В Канбане нет строгого понятия, что есть Канбан, а что не есть Канбан»


                                                  Вы о чем?
                                                  — О «Канбан-Методе»
                                                  — О «Канбан-системе» (где правильно работающий Scrum можно назвать таковым)
                                                  — Или о «канбан» — сигнале к вытягиванию?
                                                    0

                                                    О методе.

                                                  +1
                                                  Канбан это метод улучшения, а не доска со стикерами, доски может вообще не быть ;)
                                                  Канбан это более сотни практик по улучшению ваших процессов, а сколько из них пробовала ваша команда?
                                                    +1
                                                    Канбан это пул вместо пуша и ограничение на ворк ин прогресс, собственно все. Откуда еще сотни практик именно канбана? Или просто есть сотни практик которые можно применять в том числе с канбаном?
                                                    Скрам хоть немного ориентируется на результат, все эти демо в конце спринта и т.д. В канбане все проектное не является частью канбана. Это и плюс (может быть любым ) и минус (должно быть сделано отдельно).
                                                  +1
                                                  Имхо: канбан больше подходит тем, кому важнее качество продукта, скрам тем, кому важнее сроки.
                                                    0

                                                    Почему? Раскроете мысль?


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

                                                      0
                                                      Для себя я не вижу причин, для того, чтобы быстрее и хуже писать код в канбане.

                                                      Дело не в коде. Нюанс в стратегии — предсказуемость сроков или предсказуемость функционала.
                                                      Для скрама — недоделанную фичу просто исключат из релиза что бы уложиться в delivery. Для канбан — сдвинут срок delivery, но что бы были все запланированные фичи.
                                                        0

                                                        Вы частное переносите на общее.
                                                        Многие работают c ci/cd и разницы уже никакой. Фичу сделали, протестировали и в мастер.

                                                          +1
                                                          Вы частное переносите на общее.

                                                          Вот я посмотрю как вы в банк, на завод или государственное учереждение (безопастность) или критическую инфраструктуру будете неприрывно пушить код без проверки безопасников, депонирования кода и внутренней проверки или если, по соображениям безопастности, внутренняя инфраструктура клиента изолированна :)
                                                            +1
                                                            У нас (правда мы не банк) безопасники, например, какой то свой статистический анализатор используют, раз в неделю берут код из репозиотория и генерят отчеты по потенциальным уязвимостям.
                                                            Но если у них будет такое желание — можно и в СD внедрить его. С остальным так же примерно мне видится.
                                                              0

                                                              Почему же "без проверки"? Пускай проверяют в едином флоу.

                                                                0
                                                                И в чем проблема? Давно уже банки работают по методологиям, близким к Agile.
                                                            +4
                                                            Да по опыту работы. Там где был скрам был вечный техдолг, никто ничего не успевал, ну все обычные проблемы когда надо эстимейт всего и вся делать даже не видя толком тз ещё и внутренностей проекта. А там где был просто канбан, там обычно фокус ставился именно на завершении задачи, тестировании и не было давления и необходимости эстимейтить. В итоге тот проект получался намного качественнее и работа велась в спокойном режиме, а в скраме трата времени на планирования, митинги и прочее плюс вечные вопросы менеджеров команде «почему вы не успеваете всё сделать в срок?». В данный момент у нас просто доска в Asana и всё, плавно делаешь карточку за карточкой, раз в пару недель созваниваясь для обсуждения прогресса.

                                                            Эстимейты и вот это всё хорошо для аутсорса когда в договоре с заказчиком лежат сроки и просрочка стоит серьезных денежных затрат, вот они и внедряют скрамы чтобы оптимизировать процессы со сроками. А в своем продукте нет какой то необходимости торопиться как ошпаренный, просто плановые задачи выполняешь без спешки.
                                                          +6

                                                          "Мамы разные нужны. Мамы всякие важны..." :)


                                                          Вообще у скрама и у канбана есть у каждого свои естественные ниши.


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


                                                          А у канбана есть естественная ниша всюду, где заказчик внутренний. Когда не надо непрерывно заказчику доказывать правильность его выбора исполнителя. Когда вместо этого появляется запрос на более оперативное реагирование на изменяющуюся ситуацию. Почти любой in-house, любые проекты с заметным уклоном в эксплуатацию — да, канбан для этого...


                                                          Ну и вообще нет такой хорошей вещи, которую нельзя было бы испортить неправильным применением… :)

                                                            +2
                                                            Дело не в нишах, дело совсем в другом. И итеративность никак не связана с фреймворком. По опыту скажу — если у вас живой продукт с устоявшейся аудиторией, то привет канбан. Если вы мега-молодой стартап, которому нужно быстро проверять гипотезы — то привет скрам. Причем, даже в одной компании разные команды могут использовать разные подходы.
                                                            А внешнему заказчику вообще лучше вотерфол. Плевать они хотели на все эти эджайлы.
                                                              +1

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

                                                                0

                                                                Ну а я даже спорить не буду :)
                                                                Потому как у всякой методологии есть свои естественные показания и противопоказания. И вариантов здесь можно найти много, со всевозможными факторами, действующими как в одну, так и в другую сторону. А мои примеры — только отдельные частные случаи.


                                                                И с тем, что внешнему заказчику понятнее водопад с фиксированным бюджетом — тоже согласен. Только где ж такого заказчика взять, чтобы чётко знал, чего хочет? :) Хотя в конкретных не особо сложных случаях договариваться можно наверно...

                                                                0
                                                                Канбан с его аморфным, если не отсутствующим, delivery-циклом не особо хорош для проектов, имеющих внешнего заказчика.

                                                                Тойота ориентировалась на внутреннего заказчика с аморфным циклом отгрузки продукции? Это те самые, которые проповедовали принцип "точно в срок"? Вы ничего не перепутали?))

                                                                  +1

                                                                  А я кстати ничего не говорил про отгрузку продукции :)
                                                                  А имел я в виду в первую очередь поставку новых/обновлённых ИТ-решений.
                                                                  И поточное материальное производство — это отдельный разговор…
                                                                  Ну и опять: не вижу предмета для дискуссии на тему того, кто сильней — кит или слон :)
                                                                  У каждой методологии есть свои естественные области применения, и я не претендую на то, чтобы очертить их исчерпывающим образом...

                                                                    0
                                                                    Тойота продакшн вообще не софт не писала, а картонные карточки в коробки складывала. А доской был цех. А разработка у Тойоты не по канбану ни разу — см знаменитый приус — куча одновременных вариантов с выбраковкой, а не «берем не больше трех задач».
                                                                  0
                                                                  В то время в Toyota использовали доску с тремя колонками: «Запланировано», «В работе», «Завершено».


                                                                  В большинстве команд, где мне приходилось бывать, оно в таким виде и используется. И на мой взгляд это совершенно бессмысленная штука. Применять канбан имеет смысл в случае конвейерного производства, когда работа одного сотрудника/отдела/etc блокирует работу следующих — тогда это действительно наглядно показывает узкие места.
                                                                    +5
                                                                    Приведу цитаты:

                                                                    Я пользовался методом управления проектами Scrum (скрам) с самого начала карьеры.


                                                                    Скрам не являеться методом управления проектами, он фреймворк!

                                                                    Канбан — это метод управления производством, который появился в компании Toyota в 1950-х годах.


                                                                    Современный ИТ канбан, он очень сильно отличаеться от тайтовского.

                                                                    В последние годы скрам и канбан сражаются за место ведущего agile-фреймворка.


                                                                    Не сражаються, Канбан-Метод это МЕТОД, улучшения ваших процессов. Канбан он про процессы, а не про проекты!

                                                                    В целом, очень плохая статья, про чувака, который и скрам не понял, да и в канбане не разобрался
                                                                      +1
                                                                      Автор, пожалуйста, уделите время для изучения фреймворка Scrum и метода Kanban.
                                                                      Есть ощущение, что Вы откроете для себя удивительно дивный мир, если чуть глубже разберетесь в материале. Бонусом будет то, что Вы сможете значительно улучшить жизнь своей команды, применяя Kanban для улучшения Scrum.

                                                                      Scrum работает в определенном контексте, который очень хорошо описан в Scrum Guide. Судя по вашему описанию, Вы не применяете Scrum целиком, а значит у вас никогда не было Scrum.

                                                                      Современный Kanban метод уже давно не имеет никакого отношения к Toyota и насчитывает более сотни различных практик, которые применяются для решения конкретных задач и улучшения процессов.
                                                                        0

                                                                        Использовали канбан (скорее что-то выглядящее как канбан) на одном проекте. За год работы так и не понял смысл большинства метрик. Например, "Пропускная способность команды" — ну как можно мерить "в прошлом месяце мы закрыли 20 историй, а в этом 5", если 20 были на уровне "добавить статическую страницу на сайт", а 5 на уровне "реализовать систему управления статическими страницами"? Или "время цикла" — ну что нам даст информация "задачу А мы сделали за 3 дня, а Б за 30", если задача А была "сделать кнопку поярче", а задача Б — "перевести систему начислений и списаний по лицевым счетам с float на decimal и покрыть все денежные операции тестами"?


                                                                        Единственное полезное — количество задач в статусе "готовы к разработке/тестированию/приёке/релизу", ну и динамика этого количества.

                                                                          0

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

                                                                            0

                                                                            То есть только для потока, где точно можно определить вид работ?

                                                                              0
                                                                              Практически везде можно выделить виды работ.
                                                                              Есть даже маркер, если все говорят, что мы уникальные и каждая наша фича абсолютно уникальна, не похожа на другие, то обычо там и меньше видов работ.
                                                                            0
                                                                            И в чем проблема? 20 задач по 10 условных баллов, например, а 5 — по 40 баллов. Итого пропускная способность — 200 баллов в месяц. Дальше смотрите отклонения.
                                                                            Мерить нужно не тупо в количестве задач же. А в их весе суммарном.
                                                                              0

                                                                              По слухам там ушли от скрама к канбану именно потому что плохо получалось оценивать задачи в часах или баллах и от оценок почти отказались при переходе к канбану, только устная на этапе "груминга", которую если и фиксировал кто-то, то где-то в недоступном команде месте.

                                                                                0

                                                                                Ну если отказались от оценки задач, то не будет оценки задач.

                                                                                  0

                                                                                  Оценка была, но чисто консультационная, для того, чтобы ПМ понимал порядок сложности задач. Это даже планированием не было, ни то что обязательством. просто для выставления приоритетов.

                                                                            0

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

                                                                              0

                                                                              Можно использовать только часть скрама, но нельзя называть это скрамом :)

                                                                              +1

                                                                              Боже. Очередной опус у стиле "скрам не работает, канбан — то что надо". По сути все сводится к "канбан легче". Автору стоит разобраться для начала в азах почему работает скрам и как работает канбан. Канбан намного сложнее скрама. В том числе и "не нужен скрам мастер" — это 5. Канбан не работает сам по себе как и все остальное. Можно назвать "мастера" менеджером, коучем — суть не меняется.
                                                                              Канбан не будет работать без того же рефайнмента по сути. То тут он куда сложнее. Для того чтобы понять как работает канбан надо хоть немножко вникнуть в суть LEAN и систему JiT. Тваюмать… Как так можно? Статья уровня "я прочитал манифест". Культ Карго шагает по планете

                                                                                0
                                                                                Конечно, именно фреймворк виноват в том, что у вас спринт делался в последние три дня. То есть семь дней все ленились, а потом «у нас всё горит». В нормальной работе бёрндаун будет идти постепенно. По вашему графику ощущение, что все таски были рассчитаны на две недели. Вот они и сгорели массово в конце спринта. То есть вопрос к тому, кто ставит таски. И кто контролирует выполнение работ.
                                                                                Канбан не отменяет планирование. И задачи точно также должны быть сделаны вовремя. Вам же показалось, что раз нет спешки, то использование этого фреймворка удобнее, лучше. Просто циклы идут не с привязкой к спринтам, а к скорости команды и конкретному набору задач в работе.
                                                                                В итоге, вы неправильно использовали скрам, а теперь неправильно использовали канбан.
                                                                                Не ограничивайтесь общими сведеньями. Дело не в ретроспективах и стендапах. Дело в гибкости, которую вы теряете соблюдая все стандартные протоколы.
                                                                                  0
                                                                                  А, еще. Про TPS вы очень много глупостей написали. Вы же не сталкивались с системой. Тогда и не надо говорить. Ибо канбан — это скорее сигнальный ярлык о говоности перехода изделия на следующую стадию, на следующий этап производственного цикла. На производстве их куда больше, чем в разработке. То есть вовсе не три.
                                                                                    0
                                                                                    Субъективно. Менталитет исполнителя (сформированный многими поколениями). Что немцу (японцу) хорошо, то русскому — смерть. Кого-то гложет совесть и ответственность, а кто-то без пинка не полетит (но, если полетит — не догонишь).
                                                                                      0
                                                                                      Не совсем понятно, почему люди, которые лишь поверхностно знакомы с фреймворком, берутся писать какие-то статьи, если они даже не могут в терминах и понятиях разобраться… Что со скрамом, что с канбаном — каша в понимании и аргументации…
                                                                                        0
                                                                                        Вот чего я понять не могу — с чего вдруг методологии, технологии и иже с ними, которые призваны ОРГАНИЗОВАТЬ процесс для того, чтобы он был более прозрачен извне, как-то должны влиять на скорость работы? Скорость аналитики, разработки, тестирования, документирования задач зависит от собственных скилов/лени игроков в команде, адекватности контрагентов и того, насколько команда — это действительно команда, а не коллектив разрозненных сотрудников.
                                                                                        Кажется, что то, кому разработчик поклоняется, — скраму или канбану, никак не влияет на то, с какой скоростью он продумывает код и потом воплощает его в жизнь.
                                                                                        Если на работу над user story ушло больше времени, чем запланировано, то, блин, просто ее оценили неправильно. По причине собственной неопытности, из-за того, что не были известны все данные, или заказчик просто на ходу переобулся. Правильную оценку можно почувствовать со временем. Видишь задачу и ощущаешь как долго придется вокруг нее танцевать. Ошибиться можно всегда. И это нормально. И для тех, кто живет по scrum, и для тех, кто выбрал для себя канбан.
                                                                                        Но самое крутое и вкусное, когда команда создает нечто свое, свой гибрид, который учтет и взаимоотношения с заказчиком, и настроение, с которым принято работать, и аналитика, внезапно свалившего в отпуск, но достающего даже оттуда.
                                                                                        В это и кайф agile — мы выбираем какими нам быть и какие команды строить!
                                                                                          0
                                                                                          которые призваны ОРГАНИЗОВАТЬ процесс для того, чтобы он был более прозрачен извне, как-то должны влиять на скорость работы?

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

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

                                                                                          В канбан нет итераций, ограниченных по времени (спринтов).

                                                                                          но мы их сохранили, просто они теперь перестали быть фиксированными

                                                                                          Канбан не требует оценки сроков выполнения работ по пользовательским историям.

                                                                                          но мы все-равно оцениваем

                                                                                          В канбан (очевидно) не нужен скрам-мастер.

                                                                                          да и в скраме он редко кому нужен, но его роль и там, и там выполняет кто-то другой, чаще — менеджер проекта

                                                                                          В моем видении, канбан работает на отлаженном производстве, коим и является производство автомобилей, к примеру. Где производственный цикл — известен, время на «разработку» — фиксированное и его не надо «выдумывать» или спорить над тем, как быстро будет произведена очередная деталь.

                                                                                          Навенрео, автор пытался в очередной «Скрамбан», но я вообще перестал их уже различать, потому что в конечном итоге все очень сильно зависит от команды, а не от того, какой agile они предпочитают готовить. И чаще всего — это именно «очередная вариация на тему Agile», чем чистый канбан или скрам или <что-то еще>. А раз так, было б гораздо интереснее чиать о том, как внедряли, почему, с чем столкнулись, а не про то, что мы нашли канбан и вот он какой классный.
                                                                                            0
                                                                                            ИМХО, что скрам, что канбан в «книжном» исполнении существует только в мире с розовыми пони и единорогами. В жизни компании адаптируют то, что они прочитали/услышали про agile методологии под свои нужды. Кто-то более удачно, кто-то менее удачно… Результатами «менее удачно» выходят такие статьи.
                                                                                              +3
                                                                                              Про Канбан не скажу, не сталкивался.

                                                                                              А вот про Agile/Scram могу заявить авторитетно с высоты прожитых на нем 2+ лет. После отказа от классического Waterfall качество программного продукта в первый же год упало в 2,7 раза. Это если судить во сколько раз возросло количество обращений пользователей в службу техподдержки.

                                                                                              Поэтому подтверждаю слова автора статьи:
                                                                                              Программисты больше заботились о том, чтобы уложиться в срок, чем о том, чтобы достичь нужного уровня качества.
                                                                                                –1
                                                                                                Возможно потому, что в первый год, даже при хорошем владении теорией, сложно построить процесс на практике, так как нужно время на его адаптацию к команде?
                                                                                                  0
                                                                                                  Тоже поначалу предполагал, что дело в адаптации. Но к концу второго года количество тикетов от техподдержки уменьшилось лишь незначительно.

                                                                                                  В результате вместо планомерного развития продукта и движения вперед мы были вынуждены топтаться на месте, разгребая проблемы пользователей.
                                                                                                    0
                                                                                                    Это же вопрос постановки целей команде, а не Scrum.
                                                                                                    Поставили цель «успешно» закрывать спринты — команда этим и занималась.
                                                                                                    Если критерии готовности фичи/релиза допускали просадку качества, то их и нужно было корректировать. Зачем для этого ждать 2 года?
                                                                                                    Я участвовал несколько раз во внедрениях Scrum именно с целью повышения качества. И задача решалась вполне успешно (в «водопаде» большая неопределенность в сроках стабилизации, при давлении по срокам, провалы качества могут быть фатальные).
                                                                                                    И опять же, если количество пользователей выросло в сотни раз, а количество обращений в 2.7, то это очень хороший показатель.
                                                                                                    В результате вместо планомерного развития продукта и движения вперед мы были вынуждены топтаться на месте, разгребая проблемы пользователей.

                                                                                                    В этом тоже нет ничего плохого, если высокая скорость поставки фич позволила захватить или удержать рынок. Своего рода долг, который пришла пора выплачивать.
                                                                                                      +1
                                                                                                      Цели были вполне осязаемые: при неизменном количестве новых фич за полгода и их неизменном качестве выкатывать релиз каждые 3 недели.

                                                                                                      Продукт зрелый, с более чем 10-летней историей. Конкуренты на пятки особо не наступали. Количество пользователей не выросло, даже наоборот несколько снизилось из-за кризиса.

                                                                                                      В общем, внедрение Agile\Scrum не зашло.
                                                                                                0
                                                                                                Странно, что автору потребовалось так много времени, чтобы понять все недостатки скрама. Я это понял сразу после первого же скрам-митинга в единственном проекте со скрамом, в котором я участвовал. Там задача, которую я обычно делаю за день, разделялась на 5 подзадач (crud), и выполнялась неделю.
                                                                                                Кстати, первая версия проекта провалилась, а во второй я уже не участвовал вскоре после её начала.
                                                                                                  +1
                                                                                                  Статья странная, потому что Канбан не является заменой какой-то методологии, он помогает найти способы улучшить то, что есть сейчас

                                                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                  Самое читаемое