Основные заблуждения о SCRUM

SCRUM? Какой SCRUM?


Впервые подход SCRUM (англ. scrum «схватка вокруг мяча») описали Хиротака Такэути и Икудзиро Нонака, которые заметили, что небольшие команды (5 — 9 человек), укомплектованные разнопрофильными специалистами, дают лучшие результаты. Наиболее полное описание SCRUM впервые представил в своей книге Джефф Сазерланд. Книга так и называется — SCRUM. Джефф начинал свою карьеру как военный летчик, во время войны во Вьетнаме выполнивший более ста боевых вылетов. Затем Джефф занимался наукой, но мир его запомнит как одного из родоначальников SCRUM. Книга начинается с реальной истории из жизни ФБР, тратившего миллионы долларов на разработку автоматизированной системы, предназначенной для поиска и отслеживания преступников. Проблема заключалась в том, что по истечении сроков проекта подрядчики демонстрировали ФБР абсолютно нерабочий продукт. Это означало лишь одно — американские налогоплательщики потратили миллионы впустую. Ситуация казалась безвыходной до тех пор, пока руководство ФБР не обратилось к тогда еще зарождавшемуся методу управления проектами SCRUM. Этот метод описан доступным языком в вышеупомянутой книге, которая, кстати, переведена на русский язык. Далее в статье рассмотрены основные заблуждения и мифы, которые могут отпугнуть топ менеджеров, задумавших внедрить SCRUM в свои проекты.

image

1. Тотальный контроль, который убивает творческий подход


В SCRUM как достичь бизнес-цели, решает проектная команда, а не руководство. Такой метод мотивирует и стимулирует творческий подход, в отличие от классического менеджмента, где сотрудникам делегируют выполнение конкретных низкоуровневых действий, а те, в cвою очередь, часто даже не понимают, для чего это и как это повлияет на проект в целом. Таким образом, в SCRUM руководство не контролирует действия проектной команды, а та, в свою очередь, отчитывается только о результатах в конце каждого спринта (установленного заранее промежутка времени, например, 2 недели). Прозрачность существует только среди членов проектной команды. В чем она она проявляется? В первую очередь, ежедневные stand-up митинги, на которых каждый участник проектной команды рассказывает, что он сделал вчера, что сделает сегодня, какие проблемы у него возникли. Такая практика не преследует цели проконтролировать объем работ, выполненный каждым сотрудником. Stand-up митинги предназначены для того, чтобы помочь каждому члену команды устранить препятствия в работе и посвятить коллег в свои планы, чтобы каждый понимал куда движется проект сегодня и осознавал свою роль в развитии продукта. Для этих же целей, кстати, служит общая SCRUM доска со стикерами, которую может посмотреть каждый, и опенспейсы, которые уничтожают препятствия для свободного общения членов команды.

2. SCRUM лишает прав самых опытных инженеров, потому что они подчиняются решению команды


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

3. SCRUM нацелен на краткосрочные ценности бизнеса, а не на долгосрочное развитие проекта


Данная проблема, действительно, актуальна. К счастью, на вопрос «Что же делать?» есть ответы. Следует начать с того, что если проект не долгоиграющий, с продолжительностью не более полугода, то данная проблема скорее всего не всплывет. Другое дело, когда софт развивается 2-3 и более лет. Существует множество статей, в которых авторы изливают свою боль касаемо таких проектов. Армия джунов и мидлов (синеры, как известно, стоят дорого и их мало) уверенно коммитит в master своё творчество, а заказчик спринт за спринтом пожинает блестящие результаты SCRUM. Но вот незадача, через 5-10 спринтов добавлять новые фичи становится проблематично, и чем дальше, тем сложнее. Следовательно, SCRUM — это хорошо, но о стратегии и об архитектуре задумываться надо. Предотвратить подобную ситуацию можно. Во-первых, на проекте должны работать как минимум 1-2 как можно больше опытных инженеров, которые будут пропускать через себя все коммиты в репозиторий во время code review. Во-вторых, уделять много времени обучению (не менее 3 часов в неделю) младших и средних инженеров архитектуре ПО, паттернам проектирования и тому, как это накладывается на существующий проект. Такие занятия должны сопровождаться практикой и минимальным домашним заданием для лучшего усвоения. Выполнение практических заданий можно встраивать в backlog проектных спринтов. Это не сильно ударит по рентабельности проекта, зато ускорит процесс роста сотрудников и предотвратит потенциальные проблемы с архитектурой ПО. Проведение периодических meetup-ов позволит проектным командам перенимать опыт друг у друга, что не навредит качеству выпускаемого софта.

4. SCRUM не дает развиваться инженерам


SCRUM предполагает, что все решения, касаемые способа достижения бизнес-целей делегируются команде. Владелец продукта решает, что нужно сделать, а команда решает — как. Из этого вытекает, что команда должна быть достаточно компетентной, чтобы принимать эффективные решения. Таким образом, краеугольным камнем методологии SCRUM является обучение. Вот почему во всех крупнейших банках и IT аутсорсерах так много внимания уделяется развитию: тренингам, семинарам, курсам. Профессиональный рост сотрудников — это неотъемлемая составная часть SCRUM. За счет того, что SCRUM команды относительно маленькие, членам команды приходится осваивать весь стек технологий в рамках проекта, над которым они работают. По окончании проекта инженер получает новые навыки, что увеличивает его стоимость на рынке труда.

Промежуточный итог


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

1. Джефф Сазерленд // SCRUM 2017.
Поделиться публикацией

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

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

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

    В противном случае применение хайповых методик напоминает русскую народную сказку Солнце, Месяц и Ворон Воронович. Да и кстати если уж применять методики то на всех этапах проекта. Поясню что имею в виду. Полтора года потрачено на предварительные невнятные работы. За три месяца до сдачи проекта наконец дело доходит с высот менеджмента до низов разработки. И тут кого то наконец осеняет идея. А давайте будем теперь пинать их по скраму.
      0
      > 1 наладить взаимодействие в команде

      это и называется организовать работу ;) Собственно скрам, канбан и весь остальной аджайл вроде именно про то, как «наладить взаимодействие в команде». Подходят ли конкретные практики для компании и команды и как они «внедряются» — это конечно отдельный разговор.
        0
        Да если эти предметы не превращаются в фетиш за которыми уже некогда думать о взаимодействии людей, в формальность так сказать.
        +2
        Полтора года потрачено на предварительные невнятные работы. За три месяца до сдачи проекта наконец дело доходит с высот менеджмента до низов разработки

        Классика.
        Скоро сдавать один из проектов. Полгода по нему кидают десятки задач. Ничего не согласовано — менеджмент договаривается еще.
        На что они рассчитывают? Не ясно.
        По сути срок сорван еще на уровне менеджмента: до разработчиков задачи еще не дошли, и оставшегося времени на их реализацию им при всем желании не хватит.
        Так и живем.
          +2

          Да все так живут.
          Каждый новый проект — все то же… Достало.

        +6

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

          0
          > Хотя если команда компетентна, регулярно повышает свой уровень компетентности, то зачем ей траты времени на всякие организационные мероприятия.

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

          > Также, если на первое место выводится здравомыслие, навыки и опыт, то зачем нужна производственная иерархия

          Скрам про организацию не любых работ или проектов, а только в применении к разработке продуктов в небольших (до 9 человек) кросс-функциональных командах
            0
            Вот Вы сказали 9 человек. И упомянули о кросс-функиональности. Хотелось бы знать на реальном (не гипотетическом примере) из реальной разработки кто эти девять человек. Не поименно, а по функциям, конечно.
              0
              На реальном примере: владелец продукта, 2 фронтенд разработчика, 3 бекенд разработчика.

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

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

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

                  Поставленная админам задача не содержит business value — краеугольного камня скрама.

                    0

                    Т.е. бизнесу пофиг выкатят релиз или нет — никакого value нет?

                      0

                      А постановка задачи админам — это ещё не выкатка. Более того, сама по себе выкатка — это ещё не business value, если релиз пришлось откатить из-за того, что он не держит нагрузки.

                        0
                        Поставленная админам задача не содержит business value
                        Более того, сама по себе выкатка — это ещё не business value

                        Да, выкатка не value, но его содержит. Так же как канистра не является молоком, например, но может его содержать.

                    0
                    Кроссфункциональость часто понимают как владение всеми навыками всеми членами команды.

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

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

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

                        Ответ был в виде, если грубо, "админы, выкатывающие наши релизы должны быть в нашей команде, команда должна быть способна предоставить бизнесу нужный ему результат самостоятельно — или админов давайте, или админские доступы нам, или результат — готовое к выкате приложение, а не выкатанное"

                +12
                В SCRUM как достичь бизнес-цели, решает проектная команда, а не руководство
                Другими словами, руководство перекладывает часть своих обязанностей на команду? Логично, пусть «тыжпрограммисты» думают — они же в очках и умные. Но в чем тогда функция руководства? Увольнять и делить прибыль?
                SCRUM дает власть именно тем членам команды, кто ясно формулирует здравые идеи
                То есть тем, кто понаглее, и громче кричит? Кто и как определяет здравость этих идей? Каким-то общим голосованием? За кем последнее слово? Тут я серьезно спрашиваю, без сарказма.
                  –1
                  > Другими словами, руководство перекладывает часть своих обязанностей на команду? Логично, пусть «тыжпрограммисты» думают — они же в очках и умные. Но в чем тогда функция руководства? Увольнять и делить прибыль?

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

                  > То есть тем, кто понаглее, и громче кричит? Кто и как определяет здравость этих идей? Каким-то общим голосованием? За кем последнее слово? Тут я серьезно спрашиваю, без сарказма.

                  У команд есть обычно командные правила относительно того, как принимаются решения. Это может быть консенсус — все должны быть согласны или не-против, большинство — мнение большинства, это может быть апрув самого важного по функциональной части. Или все три.

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

                    Спорное утверждение. Но если заменить слово «неопределенности» на «некомпетентности», то тогда ближе к правде. Глупость начальника многократно усиливается его административным рычагом, и может все разрушить. В такой ситуации отдать решения команде будет эффективнее. А руководитель пусть ретранслирует желания клиента, или сам фантазирует — назовем это целеуказанием.
                    Это может быть консенсус — все должны быть согласны или не-против
                    Т.е. если два фронтендера не могут определиться с выбором фреймворка, решающие голоса будут у девопса и бэкэндера?
                    Предполагается, что люди в команде обычно взрослые и зрелые и могут договорится друг с другом
                    Эх, если бы это было так — насколько лучше и спокойнее было бы в нашем мире. Не могут договориться лидеры мировых держав, не могут договориться депутаты в парламенте. Даже здесь, на Хабре, среди, казалось бы, спокойных уравновешенных айтишников, Вы легко найдете полемику на сотни комментариев. Рассчитывать, что разногласия в команде решатся «как-то сами» несколько наивно и безответственно. По факту, инакомыслящие и несогласные при такой методике из команды будут вынуждены уйти, не получив даже шанса на реализацию своих нестандартных или старомодных подходов. Останутся только приверженцы одинаковых взглядов и идей, одинаковых ценностей, как в какой-то тоталитарной секте.
                      +1
                      > Т.е. если два фронтендера не могут определиться с выбором фреймворка, решающие голоса будут у девопса и бэкэндера?

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

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

                      Все так. Ровно так же как это происходит в случае начальника, который нанимает в команду только тех, кто ему нравится, с кем он может и хочет работать, и увольняет остальных. Т.е. вместо тоталитарный секты — авторитарная. Хотя какая разница какая секта, если работа сделана в срок? ;)

                      > Эх, если бы это было так — насколько лучше и спокойнее было бы в нашем мире.

                      А если конфликтов в команде много, то получается, что начальник по факту принимает все решения и чуть ли не один везет весь проект? В таком случае не проще ли научить команду саму принимать решения — дать критерии принятия решений, и помогать решать только важные и сложные конфликты?

                      Начальник — это очень часто ОДНА из сторон конфликта. И получается, что начальник должен разрешить конфликт, в котором он участвует. Совершенно очевидно, как будет конфликт решен и в чью пользу. И конфликты с начальником не будут разрешаться должным образом.

                      И по моему опыту проблема ровно обратная: конфликт разных инициатив встречается реже, чем отсутствие инициативы и проактивности со стороны разработчиков в принципе. Люди не хотят брать на себя ответственность, им проще, чтобы за них решил начальник.
                        0
                        Т.е. должен определять начальник (тим лид)? Т.е. он должен уметь разбираться прекрасно в бекенде, во фронтенде, в девопсе, в архитектуре
                        Да, а в чем проблема? Разве тим лид не должен быть более зрелым и опытным, чем остальные члены команды? Сначала он выслушает все мнения, но решение в итоге принимает он. Я вижу такой подход более эффективным, чем псевдодемократия.
                        Ровно так же как это происходит в случае начальника, который нанимает в команду только тех, кто ему нравится, с кем он может и хочет работать, и увольняет остальных
                        Так начальник в любом случае уволит того, кто его не устраивает. Но компетентный начальник будет больше оценивать профессиональные качества сотрудника, в то время как SCRUM-начальник может оценить только софт-скиллы (т.е., проще говоря, умение работать языком).
                        Начальник — это очень часто ОДНА из сторон конфликта
                        Начальник и подчиненный изначально на разных ступенях, какой между ними может быть конфликт? Подчиненный говорит — начальник слушает. Начальник говорит — подчиненный выполняет. Не согласен с решением начальника? Выбор есть: смириться и делать, обращаться в высшие инстанции, увольняться, самому становиться руководителем.
                        конфликт разных инициатив встречается реже, чем отсутствие инициативы и проактивности со стороны разработчиков в принципе

                        Здесь интересно было бы послушать, как SCRUM мотивирует реально проявлять инициативу, а не радостно поддакивать на митингах и со всем соглашаться, оставаясь пассивным на деле. Как распределяется ответственность в команде, кто ее распределяет, и как применяется система поощрений и наказаний, если она вообще есть.
                        Я допускаю, что если взять группу отборных высококвалифицированных японских трудоголиков, они могут показать очень высокий результат, работая по данной системе. Но это вовсе не означает, что эту методику можно перенести на всех остальных.
                          0
                          > Да, а в чем проблема? Разве тим лид не должен быть более зрелым и опытным, чем остальные члены команды? Сначала он выслушает все мнения, но решение в итоге принимает он.

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

                          > Я вижу такой подход более эффективным, чем псевдодемократия.

                          В скраме нет задачи сделать всем хорошо, в скраме есть задача сделать качественный продукт за минимальное время.
                          Псевдодемократии — нет. При принятии рабочих решений есть критерий, который все знают, и которым руководствуются. Если критерий не срабатывают — идут к медиатору (и это совсем не обязательно начальник), который решает конфликт.

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

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

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

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

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

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

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

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

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

                          Система поощрений и наказаний тоже вне рамок скрама. Но обычно проста как палка — функциональный руководитель принимает решение о том поощрять человека или нет.

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

                          нельзя, поэтому главное требование к таким командам — это зрелость. Скрам не заработает в случае, если у нас склочная команда инфантильных разработчиков. Более того, в таких ситуациях скрам противопоказан.
                            0
                            Одновременно разбираться во всем невозможно. Быть самым умным чуваком в команде можно только в том случае, если ты управляешь джунами-мидлами.

                            Почему тилид должен быть один на всех? У нас их два, один по фронту, другой по беку. На скраме — общаемся все вместе.
                              0

                              Если их мнения каким должно быть, например, API или кто должен заниматься северным рендерингом, не совпадает?

                                0
                                Договариваются.
                          0
                          Т.е. должен определять начальник (тим лид)?
                          Конечно, ведь ответственность за команду и результаты на нём.

                          К тому же простым большинством решать вопросы не всегда продуктивно даже среди представителей одного узкого направления ввиду разного опыта. Например в команде, где есть сеньор, два мидла и два джуна я однозначно не стал бы играться в демократию.
                      +3
                      Идеология скрама произрастает из исследования Нонака и Такеуши (Ikujiro Nonaka, Hirotaka Takeuchi, 1986, "The New Product Development Game"). Они рассмотрели, как успешные компании изменяют подход к разработке новых продуктов. Раньше разработка новых продуктов проходила фазы, продукт передавался по цепочке от одного отдела другому. А подход «рэгби», как они назвали его в работе, стирает эти границы. Собирают команду, и дают им задачу. Например сделать фотокамеру компактной, надежной, простой и на 30% ниже средней рыночной стоимости. (Т.е. дают явно «невозможную» задачу)
                      Такая команда представляет собой «Task Force». Выкладываясь более чем на 100 %, люди работают в тесном взаимодействии друг с другом. Они притираются друг к другу и работают как одно целое.

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

                      В статье говорится,
                      It may not apply to organizations where product development is masterminded by a genius
                      who makes the invention and hands down a welldefined set of specifications for people below to follow
                      что такой подход может быть не пригоден в организациях, где разработкой нового продукта руководит «гений», который рождает на свет идею/изобретение, и спускает вниз четкую инструкцию по ее реализации.

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

                      Я думаю, что у японцев другой ментатлитет. Они черезвычайно лояльны, и никогда не проявляют своего эго. Поэтому такой подход работает в Японии. (Подумайте о Камикадзе). И успех внедрения зависит именно от того, смогут ли люди сформировать такую команду, которая будет готова на все ради цели.

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

                      В статье говорится,
                      It requires extraordinary effort on the part of all project memhers throughout the span of the
                      development process. Sometimes, team members record monthly overtime of 100 hours during the peak and 60 hours during the rest of the project
                      что недостатком такого подхода являются возможные пиковые перегрузки до ста часов в месяц, и шестьдесят часов в месяц в остальное время.

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

                      Функция руководства — ставить команде цели.

                      И другой вопрос: за кем в команде последнее слово ?

                      Вопрос хороший.

                      В статье говорится,
                      Second, a different kind of learning is required. Under the traditional approach, a highly competent group of specialists undertakes new product development. An elite group of technical experts does most of the learning. Knowledge is accumulated on an individual basis, within a narrow area of focus-what we call learning in depth.

                      In contrast, under the new approach (in its extreme form) nonexperts undertake product development. They are encouraged to acquire the necessary knowledge and skills on the job. Unlike the experts, who cannot tolerate mistakes even 1% of the time, the nonexperts are willing to challenge the status quo. But to do so, they must accumulate knowledge from across
                      all areas of management, across different levels of the organization, functional specializations, and even organizational boundaries. Such learning in breadth serves as the necessary condition for shared division of labor to function effectively

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

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

                      P.S.
                      От себя еще добавлю совет: хотите внедрять аджайл, читайте статьи не на тему «scrum», а на тему «психология команды»
                        0
                        С фотокамерой, допустим, понятно: там неудачная идея сразу же негативно отразится на характеристиках, а через два года камера морально устареет и её выбросят.
                        Как быть с разработкой софта, где выбор неподходящего инструмента или технологии, на определенном этапе, может создать большие проблемы спустя годы, а чтобы это предвидеть, нужно обладать опытом в определенной сфере, которым не владеют все члены команды?
                        И существуют ли примеры создания серьезных ответственных вещей по данной методике? (самолет, АЭС, ракетный двигатель, другое сложное инженерное сооружение)
                          0
                          Я думаю что при создании таких прорывных изделий как например буран использовались. Только называлось это программно целевое планирование и управление.
                          Но в том виде как сейчас это пытаются сделать вайти это конечно скорее напоминает упоминавшуюся недавно опубликованную на одном из штатовских официальных сайтах инструкцию для саботажа фашистской Германии авторства ЦРУ опубликованную по истечению срока секретности
                            +1
                            Очевидно, что АЭС строить или ракетный двигатель, лучше по другим подходам.
                            Почему?
                            Очевидно, из-за природы software и hardware.
                            В software ты можешь каждый день выкатывать релиз и проверять его пригодность на практике.
                            В hardware получать на сколько нибудь регулярной основе новую версию можно (в некоторых случаях) но периоды этой активности несколько больше.
                            +1
                            А ещё за десять лет до этого вышла монография Гермогена Поспелова Программно целевое планирование и управление. Вне зависимости от вопроса о приоритетах. Почему упоминание о скраме в нашем средечтатичтичесуом айти вызывает явную досаду у многих комментаторов этой статьи. Мне кажется что причина в том что наш менеджер в опять же среднестатистическом случае выбрасывает суть метода и концентрируется на внешних атрибутах, которые на самом деле не имеют никакого значения.
                          +2

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


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

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


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

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


                          SCRUM — это хорошо, но о стратегии и об архитектуре задумываться надо.

                          Но кто и когда это будет делать? Если потратить N итераций вначале на проектирование, то это ничем не отличается от водопада. А если, как обычно, сразу начать пилить, то потом никакой итерации не хватит на изменение архитектуры.


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

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


                          Резюмируя: скрам — методология, как посредственной командой достичь посредственного результата за долго и за дорого, растеряв по дороге всех талантливых людей.

                            0

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

                              0
                              рефакторинг архитектуры на техническом уровне постоянная и неотъемлемая часть процесса разработки

                              Рефакторинг кода. Изменение платформы, языка или хотя бы фреймворка — вещи неподъёмные.


                              При груминге задач иногда нужно специально поднимать вопрос

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

                                0

                                Есть приёмы, позволяющие даже язык менять малой кровью. Например, MSA.


                                Не всегда. Причём способы достичь этого есть разные.

                                  0

                                  А можно ссылочку на MSA? Я попробовал найти, но не получилось

                                    +2

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

                                +1
                                В lean есть такой принцип — «defer commitment» или «decide as late as possible» — откладывать решения (тяжелые, необратимые) как можно дольше. Это не значит, что не надо об этом думать, наоборот. Но есть масса вещей которые можно сделать до принятия необратимого решения.

                                Создавать техдолг идет вразрез с идеологией lean. Техдолг это inventory — «запас». Его надо уменьшать. (см. Applying Lean Thinking to Software Development by Steven Peeters, 2013)

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

                                Да, приходится думать как организовать работу так, чтобы был постоянный результат. Это часть подхода. И в моем понимании, в скраме это одна из компетенций скрам-мастера — обеспечивать «текучесть» проекта.

                                В техническом плане если мы хотим сначала сделать самокат, потом велосипед, потом мотоцикл, потом автомобиль — то рефакторинг архитектуры на каком-то этапе может понадобиться. Но если планировать изначально, что ты в конце концов собираешься делать автомобиль, то можно выбрать такие технические рамки (например фреймворк) которые будут позволять трансформировать продукт по ходу дела. На каком-нибудь высокоразвитом фрейворке типа spring можно делать и самокат, а можно и самолет. Просто в разные сроки. Ведь один из принципов agile это — design for change.

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

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

                                  Надо выделить жирным. Не быстро, не дешево, не качественно, а гибко.

                                  Еще важно отметить agile у носителей английского, это не столько гибкий (резиновый), а сколько ловкий. Ловкий в решении проблем, которые стоят перед бизнесом. Опять же, проблем бизнеса, а не проблем ИТ.
                                    0
                                    Я бы сказал «юркий» — т.е. ему легче остановиться и развернуться.

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

                                    Качественно оно должно быть в понимании «good enough quality» — достаточное качество. Стандартное качество, потребительское.

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

                                    Т.е нужно понимать какому клиенту нужна именно гибкая разработка, а кому нет, Пихать гибкую методологию во все дыры как это сейчас делают, это, конечно, в корне неправильно.
                                      0
                                      Хорошее сравнение:, например нужно сделать ремонт в квартире. При эстафетном подходе сначала приходит один мастер, делает свое дело и уходит, приходит другой, говорит что предыдущий свое дело не доделал и он не может начинать, снова вызываем первого, тот валит на второго. И так далее, картина всем знакомая. Как было бы удобно если бы они оба сразу пришли и договорились. Это и был бы аджайл. Пришли все мастера, договорились и начали делать работу.
                                      Будет это дешевле? Нет, не обязательно. Будет это качественней? Не обязательно. Но заказчик может прийти через два дня и внести поправки в работу. Вот и весь «фокус-покус», аккордная работа вроде бы это называется, и существовало еще до компьютеров.
                                        0
                                        Проверить опытным путем какие по какой из методик проект будет сделан быстрее невозможно! Т.к. один и тот же проект невозможно сделать дважды той же самой командой и в то же самое время. Если основываться на чисто умозрительных на суждениях то по аджайлу проект будет выпускаться гораздо дольше, хотя по идее он принесет больше пользы заказчику. Т.к. в аджайл предполагается на первое место ставить выполнение так сказать сверьхзадачи решение проблемы заказчика а не простое следование ТЗ и выполнение пунктов договора. Теперь вопрос знатокам, насколько фирмам разработчикам это выгодно затратить уйму времени, отклониться от ТЗ не выполнить условия договора? Здается мне что разговоры о том что мы работаем по аджайлу в большей степени носят маркетинговый характер.

                                        Когда эти методики примняются для себя например в Apple или в Пентагоне, то здесь ясно что для себя важен результат. Хотя конечно бюрократия есть всюду. А если это говориться что мы вам по аджайлу создадим что то то слабо верится
                                          0
                                          Теперь вопрос знатокам, насколько фирмам разработчикам это выгодно затратить уйму времени, отклониться от ТЗ не выполнить условия договора?

                                          Настолько, насколько это выгодно заказчику.
                                          Кого-то интересует следование ТЗ, кого-то решение конкретной проблемы.
                                            +1
                                            Но если вы выполните не по ТЗ, а по хотелкам, а результат заказчика не устроит, то ваша компания может оказаться в очень сложном положении. Так что решение конкретной проблемы путем, отличным от ТЗ, таки стоит тоже фиксировать допами.
                                              0
                                              Вы немного не туда…

                                              Исполнителю выгодны те приоритеты, которые озвучил заказчик.
                                              Если заказчик очень хочет работать строго по ТЗ, значит работаем строго по ТЗ.
                                                +1
                                                Да нет, заказчик очень хочет работать не по ТЗ, вы ж все его хотелки делаете. Потом вдруг оказывается, что результат не по ТЗ оказался фигней и вот вы уже не смогли закрыть договор и вам грозят штрафные санкции, ибо в договоре прописан ТЗ и то, чем должна соответствовать программа по нему. Удачи доказывать, что высказанные в личном разговоре хотелки клиента важнее прописанного в договоре ТЗ)
                                                  0

                                                  Не должно быть ТЗ в договоре, если заказчик вовлечён в аджайл.

                                              0

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

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

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