Зачем мне SCRUM против менее формального, более легкого процесса для моей команды?

Я хотел бы начать свой вопрос с того, что я понимаю, что SCRUM или его производные, вероятно, являются хорошим способом управления разработкой программного обеспечения. Кажется, что все крупные компании и мои менеджеры используют это или использовали его, и я не могу спорить со всем этим опытом. Однако я изо всех сил пытаюсь понять «почему» и все чтение и даже мое официальное обучение SCRUM на работе не делают работу для меня. Это просто риторика. Поэтому я прихожу сюда в поисках ответов.

До сих пор я очень эффективно развивался в командах из 4-5 человек, полностью самоорганизовался и не нуждался в обучении, методологии или специальном программном обеспечении. Просто обсуждения в кубах, специальные встречи и персональные обзоры кода. Сейчас я нахожусь в положении, когда нам говорят, что SCRUM - это путь, и все, что с этим связано. Когда мне описывают SCRUM, я читаю такие вещи:

• Индивидуумы и взаимодействия над процессами и инструментами
• Рабочее программное обеспечение над полной документацией
• Сотрудничество с клиентом в рамках переговоров по контракту
• Реагирование на изменения после плана

Это здорово, но все это кажется мне здравым смыслом. Почему это нужно записать? Затем мне сказали, что методология помогает нам реагировать на изменения. Что конкретноаспекты SCRUM позволяют мне быть настолько гибким, что раньше я не достигал своих специальных совещаний, обсуждений кубов и совещаний по планированию разработчиков? Они объясняют необходимость иметь рабочие результаты каждые две недели или спринт. В моем конкретном проекте нет «клиента», программное обеспечение не будет завершено в течение года или более, и в то же время я, вероятно, буду переходить к высшему руководству каждый месяц или меньше. Так почему явная необходимость в доставке каждые две недели? Они подчеркивают важность встречи по планированию спринта, где вся команда выкладывает истории и задачи для следующего спринта. Это ничем не отличается от импровизированных совещаний по планированию, которые я проводил в прошлом. Почему это должно происходить каждый второй понедельник, и почему вся команда должна быть вовлечена? Я понимаю концепцию того, что каждый участник «владеет» продуктом, но на самом деле только несколько человек могут реально помочь разбить каждую историю на задачи, а остальные просто смотрят без дела.

Опять же, я понимаю, что большинство людей стоят за этим процессом, и поэтому он должен работать, и мне нужно сесть на борт. Я просто хотел бы понять почему. Моя проблема в том, что я уже практикую эти вещи и просто не люблю излишне кодифицировать их? Или, возможно, я еще не видел преимущества этих методов, потому что они выполняются неправильно? Любая реальная , личная информация или совет по этому вопросу, в отличие от того, что я привык получать, была бы чрезвычайно признательна.

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

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

Поскольку Scrum ничего не говорит о том, как следует разрабатывать программное обеспечение, он также дает команде свободу выбора для себя (например, вы все еще можете делать спринт, применяя довольно консервативный метод водопада, если вы делаете это на конец спринта).

Так что команда это одна проблема. Другая проблема - управление и доверительное управление. Здесь Scrum может быть хорошим, потому что он прозрачен и позволяет всем заинтересованным сторонам видеть прогресс, достигнутый командой в определенных циклах. Так что это не «мы прогрессируем, к сожалению, мы не можем вам сейчас ничего показать, но, поверьте нам, мы успеем». Это может быть даже верно, но для любого менеджера может быть обнадеживающим фактическое наличие регулярной демонстрации, где они могут видеть, что прогресс действительно произошел.

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

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

Может быть спорным, но Scrum лучше всего уменьшить страх менеджмента Agile или использовать его с уже недостаточно работающей командой. Если ваша команда работает отлично, достигает целей, зарабатывает деньги и счастлива, Scrum не собирается ничего вам покупать, потому что все, что она сделает, это нарушит хороший баланс действий, которые вы делаете (и сделайте вашу команду успешной). Скрам не серебряная пуля. По моему опыту, это только помогает командам, у которых была плохая оценка и общение с самого начала. Команде, работающей с реалистичными оценками в обстановке эффективного общения, мешают только издержки процесса в Scrum.

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

Большинство ответов здесь уже перечислили причину, хотя и немного косвенно. Ответ Энн особенно освещает, когда она касается прозрачности. То есть, позволяя менеджерам увидеть, что происходит. Ответ Шульца касается и этого, когда он говорит о людях, неспособных скрыть тот факт, что они расслабляются.

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

Другие системы пробовали раньше, и люди предложили бесчисленные метрики, чтобы попытаться измерить разработку программного обеспечения, но потерпели неудачу. SCRUM переворачивает проблему с ног на голову и переносит бремя измерений с менеджеров на самих разработчиков. Логика проста: кто может лучше оценить, сколько времени нужно сделать, чем те, кто выполняет работу самостоятельно?

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

• ежедневные встречи, чтобы оценить прогресс и получить общее представление о проекте
• оценки делаются в «точках» вместо часов / дней, чтобы абстрагироваться от времени
• Графики выжигания и криминальные / зайцы для визуализации скорости точек
• истории и задачи на доске, чтобы получить общее представление о рабочей нагрузке
• спринты и итерации в качестве сроков, чтобы мы могли измерить прогресс
• определенные роли для мастера схватки, владельца и члена команды, чтобы избежать соблазна обмануть

и т.п.

Вы можете заметить, что все вышеперечисленное в основном делает две вещи:

1. Они измеряют работу. Либо работа будет выполнена, либо работа будет выполнена, либо работа завершена.
2. Они изо всех сил стараются избежать проблемы чрезмерно оптимистичного программиста, чтобы получить лучшую, более реалистичную оценку.

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

Лично я думаю, что цель SCRUM - удовлетворить старые организации, где высшее руководство не может или не будет отставать от более узкого процесса. Я около года работаю архитектором (Chicken) в отделе, который активно использует SCRUM. Мой предыдущий опыт работы в стартапах Силиконовой долины, в большинстве из которых использовался гораздо более тонкий, специальный и весьма итеративный (иногда еженедельный или даже ежедневный толчок) процесс, ориентированный на функции. Я считаю SCRUM, по крайней мере, способ, которым мы реализуем его, чрезмерным с точки зрения процесса (и в некотором смысле более тяжелым, чем водопад (по крайней мере, с точки зрения разработчика). Чтобы быть честным, я скажу, что один аспект нашего процесса, который Отличие заключается в том, что владельцы наших продуктов на самом деле больше похожи на аналитиков требований в ИТ-организации. В результате они, как правило, притупляют информацию, поступающую из бизнеса, и, что еще хуже, оставляют бизнес не подотчетным команде разработчиков (что требует регулярных последовательных вливаний пользовательских историй). Тем не менее, в моем будущем запуске я бы не использовал SCRUM. Вероятно, я бы использовал его только в ситуации, когда управление требует дополнительных накладных расходов.

Я не буду говорить с точки зрения пуриста. Я чувствую, что вы можете выполнить это в некоторой степени аналогично тому, что говорит Scrum. Однако главное - это ваша способность управлять шоу. Что будет, если вы в отпуске на месяц?

Я рассматриваю схватку как механизм, позволяющий оптимизировать все, что вы делали, и придать этому определенный аспект. Так что в ваше отсутствие кто-то другой может также копировать его и другие проекты. Однако схватка - это не серебряная пуля. Я видел много людей, которые только начали использовать Scrum (потому что это в моде), и меня сильно избили, потому что они не поняли суть этого.

PS: Scrum не требует, чтобы ваш спринт длился две недели. Это может быть месяц (ваш случай).

Пожалуйста, смотрите мои комментарии к вопросу в первую очередь.

SCRUM - это парадигма гибкой разработки программного обеспечения. Как таковая, она сама по себе гибкая. Он не предполагает, что вы должны следовать его классической модели. И я сомневаюсь, что кто-то делает это на самом деле. Я работал в нескольких организациях, и каждая команда адаптировала его к своим потребностям. Нет ничего необычного в том, что нет клиентов / потребителей, когда дело доходит до выпуска какого-либо общедоступного продукта / библиотеки / API. У меня никогда не было одного. В моем случае наш гроссмейстер действовал как единое целое, а у ИМО ничего не было.

Имея 2 недели спринтов, это тяжело. Очень трудный. 3 недели лучше, но это действительно для опытных и знакомых с процессом команды. У нас было 4 недели или месяц. Это дало нам достаточно времени, чтобы, так сказать, вначале «договориться» и иметь больше уверенности в конце благодаря большему количеству тестов. Мне понравилось это, и я придерживался по крайней мере 3 недели.

У другой команды, с которой я сотрудничал, не было ничего, кроме отставания. Они собирались вместе, сообщали о статусе и о том, что будет дальше, и все. Как только все будет сделано, они придумают еще одно отставание. Они знали, что это не SCRUM, но это работало на них, и вот что важно.

Это более легкий? Это определенно так. Но это не СКРАМ. Что мне нравится в SCRUM, так это то, что он способствует дисциплине. Люди чувствуют давление доставки чего-то каждый день. Каждый знает, что делают другие, и он терпит неудачу, все это знают. Даже если кто-то пытается это скрыть (читай ложь), это становится очевидным гораздо раньше, чем с другими процессами. Поэтому, когда вы расходитесь и упрощаете, как с этой командой, вы должны быть уверены, что делаете это с правильными людьми. Иначе это может просто развалиться очень быстро, превращаясь в бессмысленные статусные встречи, где все просто останутся и подумают: «Что мне здесь делать? Я знаю, что мне нужно делать, что, черт возьми?»

Это мои два цента. Я занимаюсь разработкой, подобной SCRUM: планирую работу, делю задачи, оцениваю их, наблюдаю за ходом работ. Это действительно помогает мне быть в курсе событий. Я применил некоторые вещи из SCRUM к проектам, которые я сделал на аутсорсинге, и это отлично сработало.

Просто ... оставайся проворным ;-)

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

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

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

Это здорово, но все это кажется мне здравым смыслом. Почему это нужно записать?

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

Затем мне сказали, что методология помогает нам реагировать на изменения. Какие конкретные аспекты SCRUM позволяют мне быть настолько гибким, что я ранее не достигал своих специальных совещаний, обсуждений кубов и совещаний по планированию разработчиков?

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

Они объясняют необходимость иметь рабочие результаты каждые две недели или спринт. В моем конкретном проекте нет «клиента», программное обеспечение не будет завершено в течение года или более, и в то же время я, вероятно, буду переходить к высшему руководству каждый месяц или меньше. Так почему явная необходимость в доставке каждые две недели?

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

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

Scrum - это интерфейс, который ваша команда может реализовать. Если вы это сделаете, то у вас есть хорошее представление о том, как общаться с людьми, не входящими в группу, и у них есть хорошее представление о том, как общаться с вами. Только вы можете знать, нужно ли это вашей команде.

Мы не используем Scrum на работе. Мы используем методологию, основанную на Agile и Lean, которая во многих отношениях схожа. Я использовал этот процесс в командах различного размера от 3 до 5 человек, включая ведущих. Хотя есть различия, я думаю, что вы сможете помочь вам понять, полезен ли Scrum для вашей ситуации.

Создание методологии Explcit

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

Выйти

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

• Получить функцию с доски, трекера и т. Д.
• Поговорите с клиентом и поймите, что он ищет, прежде чем что-то писать.
• Реализуйте эту функцию.
• Покажите клиенту рабочую функцию в ее окончательной форме. Попросите клиента подписать эту функцию.

Вертикальные ломтики

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

• Амортизирует проблемы интеграции, объединяя их с каждой функцией. Помогает устранить время хруста в конце проекта.
• Позволяет нам легко вырезать функции, потому что мы устраняем много перекрестных зависимостей.
• Позволяет нам прекратить развитие, если нам нужно изменить направление.
• Мы можем делать итеративные выпуски , предоставляя заказчику функциональность на ранней стадии.

Принятие TDD

Мы используем модульные тестовые среды для принятия tdd. Это дает нам много преимуществ.

• Большая реструктуризация не требует больших затрат времени на переработку.
• Мы гарантируем функциональность клиента.
• Мы покрываем интеграцию кода.
• Поддержка практики разработки вертикальных срезов.

Сборка всегда доступна

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

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

Непрерывная интеграция

Каждое нажатие генерирует сборку через наш сервер сборки CI. Сервер сборки проверяет код, проходит через весь набор тестов, маркирует код и упаковывает его для развертывания. Укрепляет нашу политику, что сборка всегда выпускается.

Оценка очков для карт

Каждая ошибка, функция и задача становятся «карточкой». Карта - это наименьшая логическая единица работы, которая приносит пользу клиенту. Мы указываем это в соответствии с нашей шкалой. Любые, которые превышают нашу максимальную ценность пункта или сломаны далее. Мы обнаружили, что чем больше значение балла, тем больше может быть отклонение во времени до завершения, что приводит к дальнейшему разрушению больших карт. Если у карты достаточно неоднозначности, она округляется до следующего значения в шкале. Каждая карта должна быть подписана, прежде чем ее можно будет считать завершенной. Правильная оценка поддерживает нашу способность рассчитывать скорость.

Скорость

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

Инкрементальное улучшение и дизайн

У нас также есть политика, позволяющая оставить код, по крайней мере, немного лучше, чем вы его нашли. Рефакторинг / редизайн кода в начале карты. Цель состоит в том, чтобы учесть органический рост, который может быть распространен при постепенном развитии. Мы также рефакторинг в конце нормального.

По большей части это те правила, которым мы следуем и почему мы им следуем.

Для меня это звучит так, будто вы в очень опытной, высоко функционирующей команде. Поздравляю, Scrum / Agile в основном формализует то, что интуитивно понимала ваша команда все это время.

Я думаю, что преимущество вашей (всей) компании может заключаться в том, чтобы принять Scrum в качестве «точки соприкосновения» не между членами вашей команды разработчиков, а между вашей командой разработчиков и бизнес-отделом в целом .

В то время как Скрам Спринты ограничены по времени, команды могут выбирать между рекомендациями в диапазоне от двух недель до 1 месяца. Меньше и будет слишком много Обзоров и Ретроспектив, и это может помешать бизнесу изменить направление в течение года. Звучит так, как будто вы нашли свое любимое место за 1 месяц, так что настойчиво.

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