Статьи, объясняющие шаблоны анти-AGILE

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

Я ищу комиксы/статьи, которые помогают объяснить, почему SCRUM плохо, или поговорить о тематических исследованиях о реализации BAD scrum.

Мне лично нравится эта белая бумага Agile Method and Other Fairy Tales (pdf)

И это, безусловно, лучший Dilbert alt text http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/1000/000/1051/1051.strip.gif comic

Edit

Ниже приведено несколько ссылок на Scrum Alliance, для тех, у кого нет учетной записи, есть ссылки на кеш статья Talking Chickens, Отсутствующие свиньи

ОТВЕТЫ

Ответ 1

Это самое замечание было сделано ранее и широко обсуждено (в том числе статья о "Вялость Scrum" Мартина Фаулера и многие разговоры и статьи о ScrumBut от Ken Schwaber и Jeff Sutherland).

В принципе есть две причины для этого: каждый со своим набором "запахов":

  • без культурных изменений - слишком часто под знаменем Scrum, гибким, а в последнее время главным образом Kanban у нас все еще есть старая команда и контроль, при этом менеджеры все еще используют технику управления "point and tell" (укажите на кого-то и скажите им, что они должны делать, и когда он должен быть закончен). Agile должен принести культурный сдвиг от этого к ситуации, когда команды берут на себя ответственность за работу, которую они выполняют, и управляют технической частью, а менеджеры концентрируются на устранении препятствий и управлении всей компанией/проектом в правильном направлении. В тех случаях, когда этот сдвиг отсутствует, так это преимущества гибких методов, даже если на бумаге они соблюдаются.

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

Стоит отметить, что Кен Швабер, по-видимому, единственный мыслитель Scrum, который обратил внимание на эту ситуацию и пытается что-то сделать с этим. Его ответ заключается в улучшении обучения в Scrum Master в основном через курсы Scrum in Depth, но также заставив разработчиков понять, что им нужно использовать хорошие технические практики для Scrum, чтобы действительно пометить. Именно поэтому были созданы курсы для разработчиков. Разработчики Certified Scrum Developer и Professional Scrum Developer создаются Кеном, чтобы улучшить вторую проблему выше. Конечно, тренинги - независимо от того, насколько хорошо они подготовлены и доставлены - не решит ее полностью, но, по крайней мере, это показывает, что Кен действительно признает, что проблема существует и пытается что-то сделать.

BTW - Кен только что опубликовал статью в своем блоге о некоторых "запахах": Слон в комнате. Стоит прочитать.