7 препятствий для внедрения гибких методологий в больших организациях

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

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

Одна из очень известных компаний, которая была примером успешного применения Scrum в 1997 году, обратилась за помощью в Danube Technologies, Inc. в 2009 году, потому что «рынок» показал, что они оказались менее гибкими, чем конкуренты. Начинания по внедрению Scrum, которые начались 1997 году, по-видимому, не могли выдержать десятилетие сосуществования с проблемами, присущими крупным предприятиям. К сожалению, большинство попыток внедрить Scrum в крупных организациях не приводит к долговременным преобразованиям. Препятствия для внедрения Scrum обычно также мешают достижению успеха в бизнесе в целом, а устоявшиеся организации обычно неохотно избавляются от них.

Препятствие #1: Наивный менеджмент ресурсов


В Руководстве PMBOK написано:
«зачастую возникает необходимость увеличения бюджета, чтобы добавить дополнительные ресурсы для выполнения того же объема работ в более сжатые сроки»
В отношении программного обеспечения, Фред Брукс (в книге «Мифический человеко-месяц») дает утверждение, которое противоречит предыдущему:
«Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»

Чтобы разрешить этот парадокс, давайте рассмотрим определение «ресурса».

Когда работа представляет собой разработку нового продукта, соответствующие ресурсы неосязаемы: понимание задачи, обучение, межличностное общение и инновации. Scrum-команды пытаются максимизировать их, создавая состояния индивидуального и группового «потока». Как утверждает психолог Mihaly Csikszentmihalyi: «[в потоке] вы полностью погружены в задачу, и вы используете все свои навыки на предельном уровне».

Члены Команды Разработки (Development Team) Scrum интенсивно взаимодействуют друг с другом, чтобы создавать продукты в соответствии с целями, которые они постоянно обсуждают с Владельцем Продукта (Product Owner). Владелец Продукта отвечает за принятие бизнес-решений в команде. Результаты работы демонстрируются в конце каждого Спринта (Sprint) фиксированной длительности (например, каждые две недели). Во время Спринта члены команды развивают заинтересованность в общих целях и учатся управлять друг-другом для их достижения. Даже при идеальных условиях (в том числе, говоря о помещении, где работает команда) команде требуется принять участие в нескольких спринтах, чтобы достичь успеха, и около года, чтобы реализовать свой потенциал полностью. Широко известно описание этого органического процесса — «формирование, штурм, нормирование, выполнение» модели Брюса Такмана. (Bruce Tuckman, “forming, storming, norming, performing”).

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

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

Препятствие #2: Команды, организованные по функциональной принадлежности


Scrum‐команды это кроссфункциональные команды, которые стараются создать тщательно протестированный инкремент продукта каждый спринт, постепенно наращивая функциональность. Самая популярная книга по Scrum использует фразу “потенциально “Готового” к выпуску Инкремента продукта” (“potentially shippable product increment”) 18 раз. Несмотря на это, я встречаю людей, которые утверждают, что «практикуют Scrum», используя при этом «аналитические спринты» или «спринты проектирования» в начале проекта, откладывая интеграцию и тестирование на потом, и привлекая разные команды для выполнения каждой части работы. Привычки, приобретённые из Водопадной Модели Управления Проектами, скрывают риски до тех пор, пока не становится слишком поздно что-то делать.

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

Препятствие #3: Команды, организованные по архитектурно-компонентной принадлежности


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

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

Противоположностью Компонентной Команды является Функциональная Команда, ориентированная на разработку новых возможностей продукта (feature team). Функциональная Команда охватывает как компоненты, так и дисциплины, и, таким образом, способна реализовывать функциональные задачи для бизнеса в тонких, полностью протестированных «вертикальных срезах» продукта. Такой подход призван заменить концепции прошлого века, основываясь на концепциях автономности команд, самоорганизованности и ответственности. Бэклог продукта Функциональных Команд основан на нуждах бизнеса, а не на зависимостях от технологий. Если вы до сих пор используете Диаграммы Гантта, скорее всего у вас пока не организованы Функциональные Команды.

Создание Функциональных Команд связано с затратами: разработчики будут должны освоить новые навыки, что замедлит их в начале. К счастью, большинство разработчиков любят осваивать новые навыки. Методы, такие как назначение технического «хранителя компонент» (“component guardian”) для каждой области могут помочь защитить архитектурную целостность, поскольку команды учатся. Как и при любой масштабной разработке, непрерывная интеграция (автоматические тесты, выполняемые гораздо чаще, чем один раз в день) имеет решающее значение для предотвращения необнаруженных дефектов общей работоспособности продукта.

После того, как организация научится управлять Функциональными Командами, следующим шагом может быть — создание Функциональных Команд Общего Назначения (general purpose feature teams) с минимальными зависимостями от функциональных областей. Этот процесс может потребовать годы непрерывного обучения внутри организации.

Препятствие #4: Отвлечение внимания


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

Традиционные методы управления, которые усиливают специализацию, только усугубят проблему. Работу следует давать Scrum-команде во время встречи для Планирования Спринта (Sprint Planning Meeting). Когда менеджер не берет это во внимание, назначая задачи на конкретных исполнителей, у специалистов не оказывается возможности наставлять и обучать других важным навыкам. На одной из встреч для Планирования Спринта я столкнулся с тем, что первый вопрос, который был задан, был: «Кто у нас будет работать на этом Спринте?». Люди, которых постоянно дергают, не будут заниматься обучением остальных, хоть это и ожидается от Scrum-команд. И организации закапываются в эти проблемы каждый день все больше и больше.

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

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

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

Препятствие #5: Нежелание непрерывно пересматривать, приоритезировать и детализировать Бэклог Продукта


При разработке продукта, скорость обнаружения новых задач, которые необходимо сделать, обычно опережает скорость самой разработки. Чтобы справляться с этим, Владелец Продукта должен проводить Уточняющие Встречи (Refinement Meetings) для пересмотра, приоретизации и уточнения задач в Бэклоге Продукта каждый Спринт. Когда в Бэклоге появляются слишком большие задачи («epics»), необходимо находить их ключевые аспекты и делить их на маленькие подзадачи (обычно называемые «User Stories»). Владелец Продукта управляет объемом работ, решая, какие задачи войдут в Релиз, с учетом данных о скорости разработки и объеме работ, выполняемом в течение Спринта.

Препятствие #6: «Технический Долг»


Проблемы управления организацией, в конечном итоге, видны в исходном коде. И «технический долг» становится причиной проблем в продукте и высокой стоимости изменений. В идеале, регрессионные тесты можно автоматизировать с помощью того же языка программирования, что используется при разработке продукта, без использования проприетарных инструментов, которые только усиливают зависимость от специфичных знаний. Навыки, такие как Test Driven Development (TDD), доказали свою ценность в 20-м веке. В 21-м веке от любого разработчика ожидается навыки владение гибкими методологиями. И команды, которые этими навыками еще не обладают, должны пытаться работать с «вертикальными срезами задач», пока они не научатся.

Препятствие #7: Нежелание меняться


Scrum выделяет по одному человеку на команду (ScrumMaster), чтобы уделять основное внимание выявлению и преодолению таких препятствий. Это требует смелости, воображения и поддержки со стороны руководства. Слишком мало Scrum-мастеров уделяют должное внимание таким проблемам, а руководство часто не поддерживает тех, кто это делает.

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



Текст оригинальной статьи: 7 Obstacles to Enterprise Agility
Автор: Michael James
Перевод: Daniel Chernyshev
Переведено с согласия автора.
Share post

Similar posts

Comments 54

    +2
    А ниче, что Agile никакая не гибкая методология?.. :)
      –1
      То, что под Agile могут маскировать всё что угодно, не отменяет её первичных принципов и признаков, как непосредственно гибкой методологии.
        0

        Как по мне, то Agile — не методология, а набор "первичных принципов и признаков", на базе которых создаются различные методологии, относимые к Agile.

          –1
          Тогда вообще не использовать слово «Agile», раз 99% неправильно его понимает.
          Используйте просто «гибкая методология».
          Под Agile обычно понимается Scrum.
            0
            Под Agile обычно понимается Scrum.

            А Kanban не Agile?

              0
              Обычно
              А статьи чуть реже, чем всегда, о Scrum.
                +1

                Тем не менее, это не синонимы. И если статья о Scrum, то это явно упоминается.

        0
        Поясните
          –1
          Поясните, чем она гибче водопада.
          Вернее, даже водопад в умных руках гибче ее. :)
            0
            На самом деле, многим.

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

            Но для того, чтобы разговор был предметным, не могли бы вы пояснить ваше понимание слова «Гибкости» в данном контексте.
              –2
              Я хз.
              Берите в том значении, в котором это слово используется в словосочетании «гибкая методология». :)
                +3
                Не понимаю вашего ответа.
                Сначала вы утверждаете, что:
                «Agile никакая не гибкая методология»

                А на вопрос, что вы понимаете под понятием «гибкости», то есть по каким параметрам сравниваете, вы отвечаете:
                «Я хз.»


                Также:
                «В том значении, в котором это слово используется в словосочетании «гибкая методология»»
                Если говорить об этом значении слова «Гибкость», то хотелось бы узнать ваше мнение, на чем основано ваше утверждение:
                водопад в умных руках гибче
                Но даже в этом случае, предполагаю, что возможно разночтение словосочетания «Гибкая методология». Поэтому для начала хочу спросить, что оно означает в вашем понимании?
                  –2
                  Дается утверждение, что Agile гибкая.
                  Ну так скажите в чем ее гибкость.
                  А то начали переливать из пустого в порожнее.
                    +1
                    Уважаемый http2, во первых с утверждений начали Вы.
                    А ниче, что Agile никакая не гибкая методология?.. :)
                    При этом несколько раз вас просили объяснить, как вы пришли к такому мнению, чем, что, и по каким параметрам мерили? Ответа вы так и не дали.

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

                    Итак, «Agile никакая не гибкая методология?»
                    1) «Agile» переводится на русский, как «Гибкий». Поэтому наверняка вы сравнивали с Водопадной моделью не по смыслу в названии

                    2) Agile — это не методология. Это семейство методологий, которые придерживаются Agile Манифеста . Это такие методологии, как Kanban, Lean Six Sigma, XP, Scrum. Это разные методологии, имеющие разные степени ограничений.

                    3) Если сравнивать Scrum, описанный в этой статье, с Водопадной моделью, то Скрам «гибче» в следующих моментах:
                    — В Скрам есть только 2 жестоких ограничения во время выполнения проекта:
                    — — Длительность Спринта после его начала
                    — — Цель Спринта
                    Также есть пункты, которые говорят о том, что это Скрам. Если их не придерживаться, то это уже не Скрам. Например: единственная роль в Дев. команде, это Разработчик, не зависимо от специализации сотрудника (ДБА, Тестировщих, Кодер, Аналитик и т.д.). Или то, что результатом любого Спринта должен быть потенциально «Готовый» к релизу инкремент продукта.

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

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

                    4) Ни один опытный человек (как я считаю) не скажет что Водопадная модель — хуже или лучше, к примеру Скрам. Потому как они просто разные. Каждая имеет свои плюсы и минусы. И каждая имеет области наилучшего применения.
                    То есть можно сказать, что в каком-то конкретном случае Водопадная модель будет работать хуже/лучше Agile модели. Но не в общем.

                    5) И последнее: Нельзя судить о самой методологии, основываясь на примере ее кривого применения. Как вы сказали, в умелых руках Водопадная модель отлично работает! И я с вами согласен. И добавлю, что в умелых руках, когда человек понимает разницу, плюсы, минуса и области применения, все хорошо работает.

                    Уважаемый http2, если Вы хотите обсудить какие-то тонкости, прошу Вас, делая утверждения, все-же давать объяснения, на чем эти утверждения основаны. Это поможет не угадывать, что именно вы имели в виду, пытаясь написать Вам ответ.
                      –1
                      Уважаемый http2, во первых с утверждений начали Вы.

                      Я?
                      А как же заголовок статьи?:
                      7 препятствий для внедрения гибких методологий в больших организациях


                      Agile — это не методология

                      ОК, берем рассматриваемый в статье Scrum (обычно под Agile и понимают Scrum).

                      Если сравнивать Scrum, описанный в этой статье, с Водопадной моделью

                      О, до Вас дошло. :)

                      Или то, что результатом любого Спринта должен быть потенциально «Готовый» к релизу инкремент продукта.

                      Не после любого спринта можно релизить.
                      Если это разработка нового продукта, то ничего вы не зарелизите.
                      А если это правки существующего, то да.

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

                      Кто Вам такое сказал? :)

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

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

                      То есть можно сказать, что в каком-то конкретном случае Водопадная модель будет работать хуже/лучше Agile модели.

                      Ах, уже водопад не всегда хуже? :)
                      А когда он лучше?

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

                      Просто чет нету некривых применений Скрама :)
                      Везде куча косяков и стало только хуже :)

                      Как вы сказали, в умелых руках Водопадная модель отлично работает!

                      Рад, что Вы согласились. :)
                      И от добра добра не ищут. :)
              0

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

                0
                Если все «прибито гвоздями» на уровне архитектуры, то потери будут большие.
                Если изменения поместятся в какоей-то уже распланированное «окно возможностей» то и незаметит никто.
                А с нормальной инструментальной поддержкой — перепланировать в виде «что если» и оценить на что повлияет будет тоже в рамках «текущей работы»
                  0
                  Коммент не туда упал :)
                    0

                    Я не про архитектуру, архитектура — это собственно разработка, а аджайл, водопад и т. п. — принципы управления разработкой, они для менеджеров прежде всего. И в водопаде можно сделать гибкую архитектуру, и в аджайле можно всё прибить гвоздями.


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

                    0
                    но горизонты планирования различаются на порядок

                    Сколько эти горизонты планирования?
                    То есть в Agile, начиная делать сайт вообще не понимают, что хотят получить или как? :)

                    Типа строим дом, но не планируем по началу канализацию, а потом быстренько покоцалили фундамент и ок? :)
                      0
                      Иногда и так бывавает.
                      — Хочу домик отдохнуть.
                      — Ок. мы их делаем. что именно вы хотите?
                      — Ну хз. предложите что-то «вы же спец»
                      — обычно по вашему профилю: делаем домик, окна со стеклом, кухню с газом но вам рекомендуем электричество и подключение к канализации и водопроводом.
                      — ок. беру.
                      Прошло Y дней…
                      — Парни что за хрень вы вы мне впарили, а где я поставлю аквариум с бегемотом ?!
                      — ?!?!?!?!
                        0
                        Сколько эти горизонты планирования?

                        Зависит от конкретных методологий и проектных решений. В скраме рекомендуется порядка двух недель планировать деятельность, остальное — в бэклог.


                        То есть в Agile, начиная делать сайт вообще не понимают, что хотят получить или как? :)

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


                        Типа строим дом, но не планируем по началу канализацию, а потом быстренько покоцалили фундамент и ок? :)

                        Типа да, если заказчик не сказал о канализации в начале.

                      0
                      Гибкость эджайла растет из структуры — множество коротких полных производственных циклов в противовес одному или нескольким циклам водопада. Предполагается, что бОльшую часть рисков, связанных с неопределенностью требований заказчика и все связанные с нею, выявляются на этапах реализации, тестирования и использования. Короткие производственные циклы позволяют выявлять эти риски рано и регулярно. Разработка же вертикальными срезами нужна для того, чтобы функциональный заказчик (внешний и внутренний) мог видеть прогресс и управлять им, корректируя требования.
                      Это несколько упрощенное объяснение, но суть должна стать ясна.
                        0
                        множество коротких полных производственных циклов

                        Сколько и какая длительность цикла при разработке среднего сайта?

                        в противовес одному или нескольким циклам водопада

                        Это Вы в книжках по Agile решили, что в водопаде будет 1 цикл? :)
                        Какая длительность цикла будет тут?
                          0
                          Сайтами не занимаюсь, с водопадом и с эджайлом знаком на практике и, надеюсь, достаточно в теории. Холиваром на эту тему не интересуюсь — подумал, что Вам интересен ответ на вопрос. Ну и вторую цитату в собственном каменте перечитайте еще разок — там написано «одному или нескольким». По Ройсу, кстати, именно один, емнип — да, с возвратами между этапами, но это совсем не итеративность циклов, а итеративность для этапов. Но в жизни, конечно, бывают очереди, которыми режут больших слонов.
                          Я дискретности, кстати, вообще не вижу здесь, по мне классический водопад — так вполне себе вырожденный [одно]итеративный процесс, и он лежит с абстрактным эджайлом в одном спектре итеративных процессов. Посередине не пустота, а кучка разных эджайл и совсем не эджайл зверушек с разными размерами циклов и обертками.
                          0
                          Гибкость эджайла растет из структуры ...

                          Крылья… ноги… главное хвост! Цель какая?
                          Короткие производственные циклы позволяют выявлять эти риски рано и регулярно.

                          Именно — минимизация рисков. От этого строится методология и управление рисками.
                    +1

                    короче — виноват народ

                      0
                      Главная причина невнедрения — ответственные лица не видят чем внедрение улучшит ситуацию. Или понимают, что в долгосрочной перспективе улучшит, но здесь и сейчас ухудшит…
                        +3
                        Работаю в такой организации :) Как раз пытаются «внедрить Agile» в виде SCRUM. Такие смешные… Во-первых, конечной цели нет — т.е. цели такие:
                        — сделать все дешевле
                        — четко знать, какой разработчик что делает, чтобы все были при деле
                        — ну и потому что Греф сказал, что надо быть Agile…

                        А так — все как написано — четкое разделение труда, кросс-функциональность встречается в штыки, еще больше наваливание работы, и прочее.
                          0
                          работаю в той же организации, но делаю совершенно противоположные выводы ;)
                            0
                            Я не в зеленом банке :)
                          0
                          В отношении программного обеспечения, Фред Брукс (в книге «Мифический человеко-месяц») дает утверждение, которое противоречит предыдущему


                          Брукс создавал операционную систему, если вы не в курсе.
                          И народу там было очень даже дохрена.

                          Если же речь идет о том, кто быстрее сделает сайт — программист-многорук
                          или отдельно: бэкендер, фронтендер, дизайнер — то я поспорю что вы не правы.

                          Брукс имел ввиду другое.
                            0
                            В статье говорится о том, что есть два противоречащих утверждения (в руководстве PMBOK и в книге Брукса «Мифический человеко-месяц»), и оба эти утверждения доказали свою состоятельность.

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

                            То есть противоречия на самом деле нет, если брать во внимание, что Брукс говорит о «нематериальных» ресурсах, а PMBOK обобщает понятие ресурса.

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

                            Эджайл — это методика, основанная на убеждении, что если пороть кодера нагайкой, то он быстрее и больше накодит. Я думаю, этой моде осталось года два — три от силы.
                            Успех внедрения методики не в самой методике, а в сопутствующих вложенных ресурсах в проект.
                            • UFO just landed and posted this here
                                0
                                Waterfall — это один из «китов» проектного менеджмента. Причем с очень широкой областью применения и степенью распространенности. Мне кажется, в этом причина подобных сравнений.

                                Но следует отметить, что Project Management Institute (PMI) , авторы PMBOK (руководство, на котором основывается Waterfall), организация, выдающая один из самых уважаемых и признаваемых сертификатов в области проектного менеджмента — PMP, также выдает сертификаты в области управления проектами посредствам Agile методологий — PMI-ACP.

                                Этот факт, по моему мнению, свидетельствует о том, что даже PMI признает Agile, понимая его различия в сравнении с Waterfall, и разные области применения. Признает право на существование различных подходов.
                                • UFO just landed and posted this here
                                    0
                                    Спасибо за ссылку!
                                    Подозреваю что те, кто не хочет прочитать PMOK, создают мифы про него :)
                                    Вы затронули очень важную тему. Я бы продолжил ее следующим образом: «Подозреваю, что все противостояние между методологиями развивают люди, которые не потрудились из изучить»

                                    Чаще всего, в сравнении Waterfall и Agile происходит сравнение нечто, что нельзя отнести ни к какой-то Agile методологии, ни к Waterfall

                                    Наличие ТЗ, после которого «херачим » до окончания срока, а потом мучаемся на этапе сдачи продукта, потому как Заказчик получил вообще не то, что хотел. И снова «дохерачиваем», чтобы подписать акт о приёмо-передачи — Это НЕ Waterfall. Это разработка «на коленке» с наличием какого-то ТЗ.

                                    Наличие понятия Спринта, хотя продолжается то же самое «херачим» что-то, но каждые 2-3 недели смотрим, на то, что получилось, и снова «херачим» код. А потом и вообще забываем даже о том, для чего нам Спринты. Без цели спринта, без фидбэка со стороны заказчика, без постоянного процесса интеграции, без переоценки Бэклога — Это не Scrum. Это снова разработка «на коленке»

                                    Вот и выходит, что не зависимо от используемых терминов, довольно часто сравниваются не методологии, а очень искаженное представление о них.
                                    • UFO just landed and posted this here
                                        0
                                        Если вы согласитесь отправить статью мне в ЛС, буду рад быть среди первых читателей. И обещаю написать Вам честный отзыв.
                                        • UFO just landed and posted this here
                                          • UFO just landed and posted this here
                                      0
                                      PMBOK (руководство, на котором основывается Waterfall)

                                      Когда уже читать научатся «проповедники Agile», такое впечатление, что специально обманывают.

                                      1.1 Цель Руководства PMBOK®

                                      Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Обычно считается» означает, что описываемые знания и практики применимы к большинству проектов в большинстве случаев, причем относительно их значения и пользы существует консенсус. «Хорошая практика» означает, что в целом существует согласие относительно того, что правильное применение этих знаний, навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов.
                                      «Хорошая практика» не означает, однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация и/или команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту.
                                        0
                                        Руководство PMBOK® состоит из ~600 страниц, у Agile всего одна:
                                        http://agilemanifesto.org
                                        Люди и взаимодействие важнее процессов и инструментов
                                        Работающий продукт важнее исчерпывающей документации
                                        Сотрудничество с заказчиком важнее согласования условий контракта
                                        Готовность к изменениям важнее следования первоначальному плану

                                        Waterfall, в большинстве случаев, и отличается тем, что согласование плана важнее всего процесса, а разработчики «общаются» с заказчиком через менеджеров.

                                        В рамках Agile/(Scrum/Kanban|XP|...) первоначальные условия могут измениться на диаметрально противоположные. Здесь вообще отсутствует что-либо, где можно было бы зацепиться за отсутствие гибкости у Agile или неприемлемость Waterfall.
                                        • UFO just landed and posted this here
                                            0
                                            Здесь разногласий нет совершенно. И дело вовсе не в том, что «многабукфф»… а том, как подходит руководство к процессу интеграции тех или иных подходов. В контексте Agile и PMBOK сравнивать вообще нельзя. «Манифест методологии не товарищ». Аля проповедование Agile направлено лишь на один единственный пункт из PMBOK — «Руководство проектом»
                                            … это функция надзора, соответствующая модели организационного руководства и охватывающая жизненный цикл проекта. Система руководства проектом предоставляет руководителю проекта и команде проекта структуру, процессы, модели принятия решений и инструменты для управления проектом, одновременно поддерживая и контролируя проект с целью достижения успеха.


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

                                            Где тут смайл «биться головой о стену» ?! С какого перепугу вы это решили ?!
                                            А контрольный вопрос такой: у кого знания предметной области в проекте? кто понимает значение термина HairCut для банка? а CMR ее жизненный цикл?

                                            Случаем не ProductOwner согласовывает, что нужно сделать в следующем спринте? Это как-то отличается от «согласование плана важнее всего процесса» иначе процесс тупо станет колом?
                                            Относитель принципов: сами эти принципы бред, если их «трактовать» в лоб.

                                            Люди и взаимодействие важнее процессов и инструментов

                                            Самая наглая ложь, пи... и провокация. Сам Святой SCRUM и есть регламентация… процесса.
                                            Методология, ставящая на первое место людей без соблюдения методологии и «Scrum board» просто… не выполнит своего предназначения. Забавно.

                                            Работающий продукт важнее исчерпывающей документации
                                            Сам по себе product backlog, sprint back log ну и конечно критерии приемки — есть часть документации проекта. Если их не вести и корректно с ними не работать — проект даже не начнется.
                                            Если коснемся вопросов «передачи знаний» при найме нового человека или «умер» участник команды, оценки последствий «а как эта фича повлияет на предыдущие» и что делать если возник конфликт хотелок 5, 8 и 16 спринтами — без вменяемой документации фиг разобраться.
                                            Добавим сюда «разбор полетов» после спринта и, конечно, Burn down chart…
                                            Так что та еще сказка.

                                            Сотрудничество с заказчиком важнее согласования условий контракта

                                            Ну ну… Этим кто-то будет себя успокаивать, когда будет продавать квартиру или почку что бы покрыть убытки клиента согласно условиям контрата :)) Банку будет пофиг, когда потребует возврат кредита с процентами :))

                                            Готовность к изменениям важнее следования первоначальному плану

                                            А вот с этим на 100% согласен. Только есть один нюанс — «водопад» не запрещает вносить измененния по ходу проекта :)
                                              0
                                              image
                                              Waterfall или существует другое представление данной методологии? Не раз возникали ситуации, когда не согласен со спецификацией, «спущенной сверху»… но договор подписан и суммы озвучены. В случае с Continues Integration, Agile/Scrum выглядит куда привлекательней лично для меня, Product Owner на каждом StandUp, можно высказаться и скорректировать развитие продукта.

                                              Scrum — лишь один из множества в семействе Agile, но даже при нем
                                              без соблюдения методологии и «Scrum board» просто… не выполнит своего предназначения

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

                                              Если коснемся вопросов «передачи знаний» при найме нового человека или «умер» участник команды

                                              Проще не брать нового человека, скорость разработки всегда существенно проседает. Перенабор команды происходит после потери более 3 разработчиков, minimal points rate при этом обнуляется и начинаются экспериментальные спринты для установки новой медианы.
                                              что делать если возник конфликт хотелок 5, 8 и 16 спринтами — без вменяемой документации фиг разобраться.

                                              Абсолютно не понял, как может возникнуть конфликт, если каждый спринт заканчивается релизом в production. 5 фича противоречит 8му спринту? не вопрос, обсудим на Refinement Session, выкосим функционал или перенастроим под 8ку. В 16м захотелось перебить функционал. Да не вопрос… В этом и есть весь смысл, в отсутствии противоречий в требованиях, даже если они противоречат себе из спринта в спринт. Заказчик значит захотел поэкспериментировать, имеет право.

                                              Этим кто-то будет себя успокаивать, когда будет продавать квартиру или почку что бы покрыть убытки клиента согласно условиям контрата :)) Банку будет пофиг, когда потребует возврат кредита с процентами

                                              Какой-то уж больно жирный троллинг… Обычное долгосрочное делегирование разработчиков напрямую заказчику. Клиент сам покрывает свои убытки, если таковые случаются; а бездарное составление контрактов никакого отношения к вопросу методологий не имеет.

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

                                                А причем тут «не согласен со спецификацией»? Ты кто? Ты что ?! Ты зонтик! (с) «Мультики: Мой друг зонтик»
                                                но договор подписан и суммы озвучены.

                                                Никакая религия не запрещает сделать дополнение к контракту, согласно вновь открытых обстоятельств, и юридически корректно провести. Этим ПМ занимается.

                                                В этом и есть весь смысл, в отсутствии противоречий в требованиях,

                                                Банальное: 15..20 спринтов пилили платежку «с преферансом и стразиками». Потом вспомнили, что PCI DSS сертификация нужна. Дооолго будете искать «на пальцах» что и куда в системе распихано и хранится и в каком виде и вообще как это все приводить во вменяемое состояние… Знаю одну контору что разорилась на таком просто «Scrum» и была продана с дисконтом 75% :)))

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

                                                Смешно… с личиком в калашный ряд. Вы можете скорректировать разработку продукта (выбрать контролы, базу данных и т.д.) но не его развитие.
                                                Развитие — это бизнес цели Клиента. А вы не знаете ни рынка, ни маркетинговых предпосылок, ни предметной области, и не несете никакой юридической и финансовой ответственности ни перед собственниками ни перед акционерами Клиента/Заказчика за результат который принесет Продукт по вашим «рекомндациям».
                                                Ваша задача — уменьшать риски, но никак не провоцировать новые.

                                                Какой-то уж больно жирный троллинг…

                                                Это когда вы собственной рукой будете подписывать контракт и брать на себя юридические и финансовые обязательства перед Клиентом — выглядит чуть по другому.
                                                А пока «ты зонтик» и максимум что тебе грозит просто не выплата з/п за месяц и увольнение — можно считать все «тролингом».
                                                  0
                                                  Хватит скатываться во флейм с элементами нарциссизма. Вы понятия не имеете, с кем общаетесь (собственно, как и я)… поэтому любой переход на личности с голословными обвинениями не более чем элементы черной риторики для смещения фокуса с непосредственной темы.

                                                  Никакая религия не запрещает сделать дополнение к контракту, согласно вновь открытых обстоятельств, и юридически корректно провести. Этим ПМ занимается

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

                                                  Банальное: 15..20 спринтов пилили платежку «с преферансом и стразиками». Потом вспомнили, что PCI DSS сертификация нужна

                                                  Если после 20 релизов заказчику (и пользователям) не понадобилась PCI DSS, так может она и не нужна была? За год то можно было выявить отсутствие краеугольных камней. А если не было вывода кода на реальные сервера, то при чем здесь Scrum? Аккредитованный Scrum Master с уровнем Solution/Sofrware Architect? Сертифицированные разработчики в команде с уровнем Senior? Scrum Master не следил за целостностью проекта? Документация не велась вообще? А тесты?

                                                  Если согнать студентов и назвать Scrum Team,… да еще и оставить их наедине с задачей на год или два, то эффекта в лучшем случае не будет. Отсутствие должной компетенции всегда продуцирует проблемы. Да и нет волшебной методологии, гарантирующей 100% успех… к слову:
                                                  image

                                                  Scrum предполагает высокую степень самоорганизации, соответствующей квалификации и мотивации всех членов команды. И если считать своё мнение превыше метров IT; а фамилии Фаулер, Бек и Дейв — воспринимать как пустой звук; то дискуссия в принципе завершена.
                                                    0
                                                    В рамках Watefall, когда каждую из итераций представляет отдельно взятая фирма (или несколько фирм), ни о каких дополнениях к соглашению речи не идет.

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


                                                    Если после 20 релизов заказчику (и пользователям) не понадобилась PCI DSS, так может она и не нужна была?

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

                                                      0
                                                      Хватит скатываться во флейм с элементами нарциссизма. Вы понятия не имеете, с кем общаетесь (собственно, как и я)… поэтому любой переход на личности с голословными обвинениями не более чем элементы черной риторики для смещения фокуса с непосредственной темы.

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

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

                                                      Кто платит тот и музыку заказывает. Бизнес. Ничего личного.

                                                      За год то можно было выявить отсутствие краеугольных камней.

                                                      Упсъ… это же Scrum Agile. зачем смотреть «вперед»? итерацию сделали — и ладушки.

                                                      Документация не велась вообще?

                                                      А как же указанный выше принцип «Работающий продукт важнее исчерпывающей документации»? продукт работал. Scrum заветы выполнены :)

                                                      Scrum Master с уровнем Solution/Sofrware Architect?

                                                      Нет. Сертификацированного не было. Полагаете именно в этом дело?
                                                      оставить их наедине с задачей на год или два, то эффекта в лучшем случае не будет.

                                                      Product Owner регулярно закидывал новые хотелки
                                                      А если не было вывода кода на реальные сервера

                                                      Scrum обязательно требует «рабочих серверов»? Вроде нет. А так были даже некоторые клиенты этой системы.

                                                      И если считать своё мнение превыше метров IT; а фамилии Фаулер, Бек и Дейв — воспринимать как пустой звук; то дискуссия в принципе завершена.

                                                      Я в общем-то отвык верить на слово, даже джентельменам.
                                                      Я привык видеть «value и их cost & profit» решения и по ним сравнивать. И пока мне не представят «сравнительную табличку» с costs сравниваемых решений — любые мэтры мне пофигу. Не получится сослаться на Фаулер, Бек и Дейв в случае если Клиенту не сделан продукт и был нанесен ущерб.
                                                      У этих уважаемых джентельменов value и их cost & profit были указаны.

                                                      В мире, идут сначала юридические соглашения, в которых платят реальными деньгами/активами. А уже после идут всякие Scrum Waterfall и прочие для исполнения этих юридических соглашений. Разработник на своей з/п этого не видит, ибо это не входит в круг его понятий да и ответственноти тоже. С этой точки зрения Сотрудничество с заказчиком важнее согласования условий контракта — выглядит забавно, поскольку это Сотрудничество ограничено уже заключенным контрактом.

                                                      Да и нет волшебной методологии, гарантирующей 100% успех… к слову:

                                                      А статистика что вы показали:
                                                      • Так 100% умерших оказались с рыжей бородой и пили морковный сок хоть раз в жизни. Умерли, правда, от старости :)
                                                      • Полагаю, что из этой статистики исключили плотину Гувера, запуск на луну, египетские пирамиды и собор «какой-то-там-матери». Врядли их делали по Scrum :)
                                                      Это я к тому, что было бы интересно посмотреть первоисточник этой статистики и методологию расчета. Без этого — не более чем прикольная картинка.
                                                        0
                                                        NASA работал и продолжает работать в рамках Scrum методологии

                                                        И да, Agile/Scrum требует, чтобы по завершению каждого спринта изменения уходили в LIVE.

                                                        И пока мне не представят «сравнительную табличку»

                                                        «value и их cost & profit» в силу вполне явных причин указывать не в праве, но переход с Watefall на Agile/Scrum c 3 недельным циклом дал ускорение разработке на ~30% и снизил рейт оплат на ~60%. Сам проект стабилен уже больше двух лет после миграции. Code Coverage по критическим модулям не ниже 95%, покрытие увеличивается каждый спринт и является обязательной частью разработки (Team City, Test Rail, Robot Framework, PHPUnit, JUnit, Jasmine). Документация через JIRA/Confluence обновляется через User Story и от изменений в коде, каждый push происходит через линковку с JIRA тикетом, что отражается в логах; ну и Api Gen никто не отменял.

                                                        Дело всегда в отсутствии должных знаний:
                                                        «Огромное число людей, помноженное на низкую квалификацию и чудовищный спрос, рождает высокую необъективную самооценку, невежество, илитизм» Perl Power
                                                        «Низкая квалификация ведет к незнанию стандартов, а высокая самооценка ведет к их игнорированию» Perl Power
                                                          0
                                                          И да, Agile/Scrum требует, чтобы по завершению каждого спринта изменения уходили в LIVE.

                                                          Давайте обратимся к первоисточнику
                                                          The Definitive Guide to Scrum: The Rules of the Game
                                                          ©2016 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http ://creativecommons.org/licenses/by -sa/4.0/legalcode and also described in summary form at http ://creativecommons.org/licenses/by -sa/4.0/.
                                                          By utilizing this Scrum Guide y ou acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

                                                          Scrum Artifacts
                                                          • Increment
                                                            The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.
                                                            Инкремент продукта
                                                            Инкремент продукта – новая функциональность продукта, созданная во время спринта спринта.


                                                          Что-то не заметно тут слов production/ live server и т.д.

                                                          Watefall на Agile/Scrum c 3 недельным циклом дал ускорение разработке на ~30% и снизил рейт оплат на ~60%

                                                          Я за НАСА безумно рад.
                                                          В общем-то ради этих денег бизнес и потребовал Agile методологий, потому что ИТ просто не был компетентен в предметных областях и просто не успевал за бизнесом. Поэтому бизнес начал просто «кушать слона по кусочкам», бизнес аналитиков вывел за штат ИТ проектов оставив техническую сторону технарям, а бизнес у бизнеса.

                                      Only users with full accounts can post comments. Log in, please.