Гибкая методология разработки “Scrum”

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

    В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].

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

    Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии :)

    Авторами Scrum заявлены следующие особенности:
    -Легкий (англ. Lightweight)
    -Понятный, доступный
    -Сложный в освоении
    (практически взаимоисключающие параграфы)

    image

    Роли в Scrum

    В классическом Scrum существует 3 базовых роли:
    -Product owner
    -Scrum master
    -Команда разработки (Development team)

    Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды.

    Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).

    Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO

    Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:
    -Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде каким преобразовать Product Backlog в работающий продукт
    -Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта
    -За выполняемую работу отвечает вся команда, а не индивидуальные члены команды

    Рекомендуемый размер команды — 7 (плюс-минус 2) человека. Согласно идеологам Scrum, команды большего размера требуют слишком больших ресурсов на коммуникации, в то время как команды меньшего размера повышают риски (за счет возможного отсутствия требуемых навыков) и уменьшают размер работы, который команда может выполнить в единицу времени. [1]

    Процесс Scrum

    Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении все жизни продукта.

    Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.

    Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint'а.

    По окончанию Sprint'а производятся Sprint Review и Sprint Retrospective, задача которых оценить эффективность (производительность) команды в прошедшем Sprint'е, спрогнозировать ожидаемую эффективность (производительность) в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое.

    Схематическое изображение процесса приведено на следующем рисунке:
    image

    Важные, часто забываемые особенности

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

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

    2. Недооценена важность работы по обеспечению мотивации команды.
    Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения [2].
    Таким образом, лишь небольшая часть сотрудников способно эффективно работать в Scrum без существенных изменения в ролях Scrum master и Product Owner, что противоречит идеологии Scrum, и потенциально приводит к неверному или неполному использованию Scrum.

    3. Scrum применяется для продукта, требования к которому противоречат идеологии Scrum.
    Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла зарание планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. [3] Существуют и иные ограничения.

    Достоинства и недостатки

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

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

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

    Проблема является большей, чем кажется. Т.к. Scrum относится к семейству Agile, в Scrum не принято, к примеру, создание плана коммуникаций и реагирования на риски. [3] Таким образом, делая сложным или невозможным формальное (юридическое или административное) противодействие нарушениям правил Scrum.

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

    Список использованных источников

    [1] The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
    [2] Психология управления, учебное пособие. (А. А. Трусь)
    [3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)

    Заранее благодарю за указанные ошибки и неточности!
    Share post

    Comments 71

      +12
      Главным достоинством scrum'а в сравнении с другими методиками является малый оверхед. Команды, которые используют скрам, всего в 1.5-2 раза менее эффективны, чем команды, которые не используют ничего. Это выдающийся результат, потому что другие методологии замедляют команду ещё больше.
        0
        Методологии существуют совсем не для того, чтобы снизить «overhead», или только лишь повысить эффективность команды. Методологии созданы чтобы повысить управляемость, предсказуемость и эффективность управления проектом. Команда, работающая над продуктом — лишь часть любой методологии, и ее интересы отнюдь не на первом месте.

        В конце концов, какой смысл делать работу быстро, если эта работа не решит стояющую проблему? Можно быстро построить во дворе двадцатиэтажный гараж, но все равно жить будет негде :)
          +1
          Именно это я и сказал. А scrum любим за то, что ради «управляемости предсказуемости» тратится лишь половина энтузиазма и времени команды.
          0
          Оверхэд скрама зависит от многих факторов. У нас он составляет ~20% (редко 30%) рабочего времени.
          Команды, которые не используют ничего, также тратят время на постановку/разбор задач и т.п. Только его подсчитать сложнее.
            0
            А энтузиазм? Как любая бюрократия, оно угнетает. С одной стороны всё ровненько и гладенько, с другой стороны без особых всплесков энтузиазма в плохорешаемых задачах, вроде разработки архитектуры или продумывания всех аспектов проблем.
              +1
              Вам знакомы успешные команды без бюрократии? Мне нет.
                0
                Насколько я знаю, мозаик был написан Ли без использования бюрократии. Апач был создан без использования бюрократии. Каких-либо скрам-митингов в написании Линукса я тоже не видел.
                  +1
                  Вопрос был про команды и бюрократию, а не личности и скрам-митинги.
                    0
                    Как я сказал, апач был написан без какой-то бюрократии.

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

                    Но основной ресурс, который надо учитывать в накладных расходах на бюрократию, это не только время, но и энтузиазм. Причём он даже важнее времени, а как раз энтузиазм бюрократией портится с фантастической силой, так что если проект интересный, то лучше бюрократию минимизировать. Если это очередной интернет-магазин, биллинг или банк-клиент, то бюрократии можно побольше, потому что энтузиазма там всё равно не особо много.
                      0
                      От бюрократии не уйти, но минимизировать ее, имхо, стоит в любом проекте.
                      С этим полностью согласен.
          +1
          Господа, объясните по хардкору, зачем используют все эти методологии типа scrum, agile, %dozens of em%?

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

          Я просто не могу понять прикол :(
            0
            Я, похоже, ответил на ваш вопрос выше :)

            Методологии существуют совсем не для того, чтобы снизить «overhead», или только лишь повысить эффективность команды. Методологии созданы чтобы повысить управляемость, предсказуемость и эффективность управления проектом. Команда, работающая над продуктом — лишь часть любой методологии, и ее интересы отнюдь не на первом месте.

            В конце концов, какой смысл делать работу быстро, если эта работа не решит стояющую проблему? Можно быстро построить во дворе двадцатиэтажный гараж, но все равно жить будет негде :)


            Просумировать, ЦА методологий — не команда, а менеджмент проекта, которому нужны управляемость, предсказуемость, и.т.д
              +1
              Вы только что описали нормальный бизнес-процесс в it среде.

              Просто у меня порой создается впечатление, что все эти красивые названия не более чем фантики, на которых зарабатывают написанием книг, проведением семинаров и т.п. Хотя казалось бы, конфета внутри — обычная логика.
              +2
              Там всё сложно и пронизано болью. Кто вам задачи ставит? Почему они выполняются в таком порядке? Если кто-то из команды видит, что надо рефакторить нафиг, а вместо этого ему говорят «переделай формочку вывода» — что важнее, формочка или рефакторинг?

              Столь всеми поливаемый и ненавидемый ватерфалл подразумевает, что ТЗ спускается с небес и непогрешимо, и уж точно не будет меняться в течение ближайших двух тысяч лет. На практике это не так, и все методологии отвечают, как с этим нам теперь жить.
                0
                Ну в роли уравновешивателя может выступать тот же тимлид, который объяснит начальству на пальцах, что такое технический долг и как все скоро из-за этого огребут. На том же уровне решается приоритетность и прикидка по срокам. Не?
                  +2
                  Фактически вы уже используюте методологию, которую называете «нормальный бизнес-процесс в it среде».

                  Проблемы начнуться, когда, к примеру, вам обратятся стороние (зарубежные, или еще круче, государственные) заказчики ПО. Зарубежным подавай Agile (и обязательно c сертифицированными Scrum-мастерами). Государственным подавай по ГОСТ (есть и они :) )

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

                  Или, как выгодно «продать» текущий бизнес процесс потенциальному заказчику или инвестору.
                    +3
                    Очередное предположение, что тимлид спускается с небес и Точно Всё Знает. Не знает он всего, особенно, в новом коде. Кто-то что-то напридумывал, оно, вроде, работает, но до какой степени это халтура (и адаптировано под изменившееся ТЗ на лету) знает только его автор — он на митинге и комплейнится, мол, «в срок написали, а теперь у нас технический долг».

                    В описываемой вами схеме совершенно не понятно:
                    а) когда тимлид узнает про это
                    б) когда он это объяснит начальству
                    в) когда будет принято решение об исправлении дефекта.

                    scrum описывает процесс взаимодействия между членами команды такое, чтобы время между «обнаружили проблему» (получили feature request) до «приняли решение когда и как делать» было контролируемым и разумным.
                      0
                      К тому же, методология «призвана» снизить влияние человеческого фактора. В том же Скрам, ответсвенность тимлида «размазана» между скрам мастером, продукт оунером, и собсна командой. С одной стороны, это плохо — не пойми кто накосячил/молодец. С другой стороны, если тимлид забухал вдруг, все равно есть кто-то, кто пойдет защищать рефакторинг и отбиваться от формочки.

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

                      И вот подрались Петя с Васей из-за формочки и рефакторинга. А могли бы ретроспективу устроить. И звучит модно, и гораздо менее болезнено! :)
                        0
                        Там масса деталей, в частности, например прикидка по срокам может считаться статистически.
                        Кто оценивает — тим лид или команда? И т.д.
                      0
                      Есть очень большая тема про треугольник project-managmenta, работу с заказчиком, разделение ответственности заказчика и исполнителя и прочая прочая. Эта тема достойна пожалуй вереницы статей, потому что это тема про боль и страдания современного it бизнеса :)

                      Если из этой большой темы выдернуть маленький кусочек который как то коррелирует с вашим описанием рабочего процесса, то можно сказать следующее. В целом да, в идеале бы так оно и было, но практика и даже теория pm'та говорит о том что невозможно зафиксировать scope работ, бюджет проекта и время выполнения одновременно так, чтобы проект был завершен успешно. Оттуда вытекают платные чейндж реквесты, fail сроков, быстрая трата денег с несделанным продуктом, несоответствие продукта и ожиданиям и так далее.

                      Scrum не про то, чтобы сделать команде хорошо и всё. Scrum — не фреймворк разработки, это фреймворк создания продуктов. Scrum больше про то, чтобы делать проекты успешными и заказчика довольным жизнью, а также обеспечивать востребованность продуктом. Работа команды и с командой это малая часть.
                        0
                        затем же, зачем при разработке используется ide, сниппеты, библиотеки, и прочее.

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

                        Зачем все эти унылые и ненужные сборища? Есть тикеты, есть статус тикетов. Всё по ним видно. И время тратится на этих сходках, и нервы. К тому же, редко что новое там услышишь относительно своих тикетов.
                          +1
                          Когда нового мало то и daily занимает минут 10-15 обычно.
                          daily нужны чтобы команда была в курсе всех изменений которые происходят в коде. Очень плохо когда человек закрывается на несколько дней в и делает свой тикет, а потом выясняется что все можно было сделать проще или что изменения которые он сделал задевают работу других разработчиков. Обычно общаться голосом гораздо легче и эффективнее чем смотреть на доску в трекере.
                            0
                            Обсудить задачу можно и в процессе самой работы.
                            Когда нового мало то и daily занимает минут 10-15 обычно.
                            Встреча утром, как правило, происходит. Пока все соберутся и т.д., пройдёт час, предположим. Весь этот час я не могу нормально работать, так как давит ожидание встречи. Сама беседа минут 15. Туда-сюда и 2 часа в итоге выпадает из рабочего процесса. Может, правда, это только у меня такая проблема…
                              0
                              Ни кто ни кого не ждет.
                              Есть четко определенное время для митинга, и если кто-то к этому времени не успел, то он ССЗБ.
                              У нас, например, за каждый пропущенный митинг должен всем из команды по бокалу хорошего пива в пабе.
                                0
                                Это я к тому, что команда — саморегулирующийся механизм.
                                Если вы час собираетесь на митинг, то либо у вас команда разгильдяев, либо неудачно выбрано время митинга, либо все вместе.
                                  0
                                  Вот такие вещи и убивают всё и вся.

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

                                  И не только я один такой. Что делать с человеком, который не может заснуть до 5 утра, а скрам на 10 назначен? Заставлять просыпаться?

                                  Если раз в неделю подгадать время ещё можно, то каждый день — это просто мучение.
                                    0
                                    Вот такие вещи и убивают всё и вся.
                                    Какие такие?
                                    Время митинга устанавливает команда, это может быть 9 утра, 3 дня, 7 вечера, любое удобное для большинства.
                                    Если вы не можете вписаться, то командная работа не для вас.

                                    А что делать людям, которых не устраивает текущий code convention? Или которых бесят табы (пробелы) в репозитории?
                                    «Я тут весь такой великий гуру, быстренько подстраивайтесь под меня», так должно быть?
                                      –2
                                      Ну, начинается. Agile работает с правильными программистами. Дайте мне других программистов и на этот раз agile точно заработает.

                                      Я отлично работаю в команде, только на работе появляюсь неровно (иногда с утра, иногда с вечера).

                                      Такое ощущение, что соблюдение графика рабочих часов — это обязательное условие для agile.

                                      И никто не «великий гуру». Если человек вовремя с работой справляется, что к нему с графиком лезть?

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

                                      ЗЫ Совместные обеды неплохо заменяют собой стэндапы.
                                        +1
                                        Agile работает с правильными программистами.
                                        Не передергивайте.
                                        Agile потому и аgile — нет правил, высеченных в граните.
                                        Повторюсь: команда — саморегулирующийся механизм. Если ее устраивает ваша работа и ваше непоявление на митингах, то о чем вообще разговор?
                                          0
                                          Так и ватерфол можно назвать самоотрегулировавшимся agile'ом :)

                                          Я к тому, что ежедневные стэндапы воспринимаются как наиболее интрузивная и раздражающая составляющая любого scrum'а. Всё остальное воспринимается обычно позитивно и спокойно, т.к. всем понятно «зачем». Мотивация у стэндапов же звучит очень вяло.
                                            0
                                            Как по мне, митинги зависят от людей и самой работы.
                                            У меня был опыт работы в компаниях, где на митингах было все просто, весело и задорно (и они редко занимали более 10 минут), и в компаниях, где на получасовых митингах было охота блевать.
                                              0
                                              Я к тому, что ежедневные стэндапы воспринимаются как наиболее интрузивная и раздражающая составляющая любого scrum'а.

                                              Кем и когда воспринимается? Откуда статистика? 15 минутный проход по задачам — это не очень много.
                                            0
                                            Если у него настолько нестандартный график, что он не пересекается вообще с командой, то как с ним общаться по рабочим вопросам? Т.е. он убивает командую эффективность. Гибкий график это хорошо, но он должен иметь какое-то общее пересечение дающее какие-то гарантии на возможность пообщаться с другим участником команды.
                                            И чем совместный обед лучше стендапа? Так же нужно общее время и плюс еще привязывается общение к нерабочим факторам (ну не хочу я еще обедать, а чтобы быть в курсе надо идти со всеми). Стендап в середине дня вполне комфортен.
                                              0
                                              Пересекается, но в разное время.
                                                0
                                                Ну пусть тогда появляется не на всех стендапах, если это устраивает команду. Эффективность немного понизится, но если остальные к этому готовы (преимущества превышают недостатки), то вполне. Даже если 8 часовой рабочий день равномерно случайно распределен в сутках (надеюсь, что это не так, а то это уже лечить надо), то можно попадать на треть стендапов. У нас стендап занимает 5-10 минут в команде из 15+ людей.
                                          +1
                                          Я, например, с хроническим расстройством сна

                                          Вы ко врачам обращались? Не может быть такое, что это просто привычка?
                                            0
                                            Да ему надо в зал идти, 40 минут бега и еще 1.5 часа эффективных нагрузок и проблема со сном исчезнет =)
                                              0
                                              Не зная человека я бы не решился так утверждать — вдруг что-то медицинское, хотя спорт, умеренное употребление кофе и прочие рекомендации которые уже были на хабре, помогают обычно
                                          0
                                          А просто тупо постить ответы на 3 вопроса в специально отведенный для этого чат в начале каждого рабочего дня не поможет?

                                          Получаем, что мы не привязаны ко времени, достигаем практически тех же целей и теряем только обсуждения (а они нужны вообще во время стендапа?) и общение лицом к лицу (тоже, наверное, не проблема, если команда в одной комнате сидит).
                                            0
                                            Универсальных рецептов нет. Можно придумать множество различных способов.
                                            Главное, чтоб они подошли и были поддержаны остальными участниками.

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

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

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

                                        P.S. Статью можно уверенно назвать вбросом недели, комментарии читать не менее интересно чем саму статью. Вообще спорить тут не о чем: у тебя либо скрам работает либо нет, по разным причинам. Любо стоит исправить ситуацию и построить работу по нормальному либо отказаться от фреймворка. В конце концов есть очень много примеров где scrum не применим или не особо нужен.
                                          0
                                          Пожалуйста, уберите в статье слово методология отовсюду. Scrum — не методология, это framework. Методологий в Agile-mindset вообще дико мало. RUP, например.
                                            0
                                            Вы думаете стоит убрать? В самом начале я указал, что Scrum не является методологией, хотя (в обиходе) часто называется методологией.
                                              0
                                              Хотя…
                                              Убрал почти везде, кроме начальной части.
                                                0
                                                Во время работы это часто вызывает проблемы, потому что методология подразумевает встроенное решение любых проблем и вопросов. Я просто за то, чтобы сразу этого избегать, употребляя верные термины. Это мелочь, но каждое такое объяснение в рабочем процессе потихоньку стачивает мозг :)
                                                  0
                                                  в обиходе вообще Agile называют методолгией, а подразумевают Scrum :)
                                                0
                                                Все равно все заканчивается тем, что на стендапы никто не хочет ходить, никто не хочет говорить и все превращается в обременительную формальность. Зато менеджер доволен и есть иллюзия контроля над процессом. А потом случаются овертаймы. А потом надо писать заказчику, почему же все таки у нас проблемы и что мы будем делать, чтобы их решить. В рамках заданного бюджета, конечно же.

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

                                                Есть тикеты, есть время в них — у менеджера есть механизм постоянно контроля процесса — что еще нужно? Да всем плевать, что я вчера сделал и какие проблемы у меня возникли. А еще гигантское кол-во времени, которое тратят технические специалисты на всякие груминги, планирование, ретроспективу — я бы не назвал это «минималистичным».
                                                  0
                                                  Не у всех все так плохо
                                                    0
                                                    Ну так расскажите про свой положительный опыт.
                                                      0
                                                      Что рассказывать? Все с точностью до наоборот:
                                                      — митинги не обременительны
                                                      — оценки иногда врут, но в другую сторону
                                                      — овертаймов нет
                                                      — заказчику писать не надо
                                                      — менеджеры — вменяемые люди
                                                        0
                                                        Это единичный пример или вам так постоянно везет? Единичный удачный пример у меня тоже имеется.
                                                          0
                                                          Не постоянно. Но в большинстве.
                                                    0
                                                    А вы можете предложить годную альтернативу Скраму (канбану, рупу, вотерфолу), которая лишена всех этих недостатков, и к тому же менеджер доволен? :)
                                                      0
                                                      Да, она называется здравый смысл и вот это. Бывают случаи, когда «гибкая» разработка не работает, и нужно тщательно обозначить требования заранее и заняться архитектурой. Бывает наоборот. Бывают легаси-проекты, где есть трудновоспроизводимые баги, фикс которых ну никак ты не спланируешь в спринт. А зачастую получается скрам ради скрама. Третий раз переносим тикеты из спринта в спринт, ну не успели, а тут еще и тим хелс падает. А бывают маленькие команды по 3-4 человека на проект. Все проекты (ну, может кроме уж очень крупных типа банковских систем) очень сильно между собой отличаются и хорошо работающая команда всегда отличается здоровой головой (ПМ и клиент), а не строгим следованием некой методологии. Люди решают.
                                                        0
                                                        Вы смешали в одну кучу теплое с мягким.
                                                        Скрам — не методология, которая диктует «как жить», а фреймоврк, который должен быть адаптирован под существующие в компании реалии.
                                                        Что работает в одних случаях, не работает в других — универсальных рецептов нет.
                                                          0
                                                          Извините, но мне непонятен смысл понятия «фреймворк» в отношении организации процесса. И что такое в вашем понятии «адаптация»?
                                                            0
                                                            Извините, но мне непонятен смысл понятия «фреймворк» в отношении организации процесса.
                                                            Это стратегия, а не имплементация.

                                                            И что такое в вашем понятии «адаптация»?
                                                            Это уже имплементация (применение стратегии) в конкретной компании/команде.
                                                            Например, как ставить задачи и определение DoD.
                                                              0
                                                              Слишком общие фразы. Непонятно, насколько сильно ваш фреймворк нужно изменять под конкретные нужды, и с учетом объема правок — нужен ли он вообще.
                                                                0
                                                                Непонятно, насколько сильно ваш фреймворк нужно изменять под конкретные нужды, и с учетом объема правок — нужен ли он вообще.
                                                                Фреймворк не мой, и я без понятия что происходит в вашей компании и какая адаптация вам нужна или не нужна.

                                                                Слишком общие фразы.
                                                                На любые вопросы даю любые ответы.
                                                                Сейчас это выглядит как «Убедите меня что скрам хорош», а это, увы, не мой профиль.
                                                                Будут конкретные вопросы по конкретной теме, по мере своих возможностей дам конкретный ответ.
                                                                  0
                                                                  Понятно, желаю успешных адаптаций.
                                                                    0
                                                                    Спасибо. И вам меньше негатива и бестолковых менеджеров)
                                                          0
                                                          Вы, верно, меня не правильно поняли. Я ни в коем случае не утверждаю что азм есм скрам, и кто не скрам — неверный.

                                                          Я рассматриваю различные методологии (и подходы) и стараюсь проанализировать их достоинства и недостатки с организационной и психологической точки зрения.
                                                            0
                                                            о, кстати, а вы смотрели в сторону фреймворка Кеневин? он как раз рассказывает, когда какие методологии и подходы стоит использовать :)
                                                              0
                                                              Не смотрел, спасибо за совет!
                                                        0
                                                        Да всем плевать, что я вчера сделал и какие проблемы у меня возникли.

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

                                                          Каждый день — это вообще кошмар, потому что бывают дни, когда вообще «мысль не идёт».
                                                          Все мы люди, все мы человеки. Такие ситуации не редкость.
                                                          В скраме ежедневные «отчеты» не для того, чтоб шпинять «лентяев», а для выявления и решения проблем как можно раньше.
                                                          По нормальному такая ситуация разрешается коллективным разумом/отдачей таски другому участнику/выделением дополнительного времени.
                                                          Ну а если у вас «таких дней» 15 из 20, то следует задуматься о смене работы.
                                                            0
                                                            вот как раз из-за того, что люди боятся упреков за работу — такие инструменты и делают.

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

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