А вы играете по правилам?

Опубликовано Marianna Almakaieva 17 Май 2010

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

Итак, знакомьтесь — Марианна Алмакаева, Project Manager, Харьков.

А вы играете по правилам?

Вы знаете правила игры в шахматы? Конечно, да! Кто же их не знает? Ничего сложного – черные, белые, кони, слоны, т.п. Но делает ли знание правил нас хорошим игроком? Ответ-нет, согласны? :-) Я, например, знаю правила игры в шахматы с самого детства, но играть совсем не умею. Так и с методологиями разработки программных продуктов, в частности, со SCRUM’ом.

Сколько времени надо менеджеру проекта, чтобы изучить основные принципы методологии SCRUM? А сколько месяцев уйдет на внедрение методологии и ее понимание?

Как говорят в Одессе: это уже две большие разницы. Главное правило для тех, кто решил внедрять SCRUM – не опускайте руки и не нарушайте правил.

Распространенные ошибки, которые мы делаем внедряя SCRUM (из личного опыта :-) ):

- нарушаем «правила игры», отступая от методологии, и потом говорим «SCRUM не работает»;

- неправильно понимаем/игнорируем правила. Например, очень часто SCRUM мастером является менеджер проекта. Как следствие, команда на Daily Meetings отчитывается не друг другу, а менеджеру. Другие распространенные отступления от правил: добавление незапланированных задач в течение итерации (надо сделать поскорее, быстро сделаем и дальше по плану. Знакомо? :-) ). Список можно продолжать. Пожалуй, интересная тема для другого поста.

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

- что еще?

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

Статьи по теме

Рубрика: Управление проектами Метки: , , ,
«
»
Вы можете оставить комментарий, или отправить trackback с Вашего собственного сайта.
  • http://yura-silver.livejournal.com/ Yuriy Silvestrov

    «Не человек для субботы, а суббота для человека». Жизнь сложнее шахматной партии, и её невозможно играть по правилам :)
    Всякий раз нужно думать — а подходит ли это правило Скрама нам? Именно нашему проекту, именно в нашей ситуации?

    «Ну как я скажу клиенту, что на ближайшие две недели приоритеты расставлены, задачи расписаны и мы не можем сделать вот эту срочную задачу?»
    А что должен ответить мне клиент, если я на его замечание, что каждый день он теряет на этом неисправленном баге $100 000 — предложу ему подождать две недели, потому что «задачи распланированы»? Я бы, на месте клиента, уволил бы менеджера и в следующий раз 10 раз бы подумал, связываться ли мне со скрамом.

    «Например, очень часто SCRUM мастером является менеджер проекта. Как следствие, команда на Daily Meetings отчитывается не друг другу, а менеджеру.» Абсолютно друг из друга не следует. Может отчитываться менеждеру, даже если он не скрам-мастер. Может отчитываться скрам-мастеру, даже если он не менеджер. А всё потому, что команда не сфокусирована и не самомотивирована — вот и ищет кого-то извне для отчёта. В нашем проекте я и скрам-мастер, и менеждер — но команда отлично проводит дейли-митинги, даже если меня на них нет, и отчитывается друг другу.

    Я бы сформулировал лозунг по-другому: «Нарушайте правила. Но только если абсолютно уверены в необходимости этого.»

  • http://tim.com.ua/ Tim Yevgrashyn

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

    Взять хотя бы тот пример с багом за $100 000. Понятно, что никто не призывает команду игнорировать такие потери денег. С другой стороны и Владелец Продукта со своей стороны должен быть готов пойти на встречу и «вынуть» из текущего спринта работы на соответствующее количество поинтов (времени), чтобы хватило на исправление этого супербага. А если он не идет на уступки?

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

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

  • Marianna Almakaieva

    Юрий, абсолютно согласна с вами, иногда просто необходимо отходить от правил, особенно когда речь идет об Agile проектах. Ведь ключевое слово «Agile» :-)
    Речь шла скорее не о редких и оправданных отступлениях, а о систематическом не следовании методологии. В этих случаях получается Scrum Butt, о чем пишет Асхат Уразбаев в начале своего поста http://blog.scrumtrek.ru/2010/03/waterfall-wate….