Книгообзор: Джефф Сазерленд «Scrum. Революционный метод управления проектами»

Этой записью я открываю новую рубрику в своём блоге, посвящённую книгам. И открывает её обзор книги Джеффа Сазерленда «Scrum. Революционный метод управления проектами». Взялся я за неё, чтобы разобраться в методологии управления Scrum, которая используется на моей новой работе.

Сазерленд - Scrum - ОбложкаСразу оговорюсь – книги подобного жанра я никогда не читал, при прочтении ниже написанного это надо учитывать.

И так, почему для ознакомления со скрамом я выбрал именно эту книгу? Я подумал, что лучше создателя методики её вряд ли кто опишет, поэтому и выбрал её. Первое, что нужно знать об этой книге – в ней не рассказываются методы внедрения скрама, поэтому, если нужно найти ответы на вопросы «Как внедрить?» и как «Какие подводные камни на пути внедрения могут быть?», то читать эту книгу не стоит. Как работает скрам кратко описано в конце книги в приложении, так что, если нужно развёрнутое, подробное описание процесса, то опять-таки, эта книга не для вас. Так про что же она тогда?

А она про то, почему методология скрам работает. Здесь подробно описано, что применяется, зачем и почему. Всё это щедро приправлено примерами из практики автора. Так вот, если вам хочется знать, почему методика работает, по мнению её автора, то ознакомиться с этим произведением однозначно стоит.

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

Я надеюсь, все понимают, что мир разработки огромен, спектр встречающихся задач широк, а люди настолько разнообразны, что вряд ли скрам везде и всегда (пусть даже с применением административных мер, вроде увольнения неподходящих людей) будет работать. Да и вообще, если следовать общепринятому научному методу, если хочешь подтвердить гипотезу, нужно попытаться её достаточное количество раз опровергнуть, причём не для вида, а серьёзно, проверяя её в тонких местах и теоретических пределах применимости. Здесь же этого нет и в помине. В качестве примера приведу покер планирования. Его суть в том, что команда оценивает объём задачи путём итеративного процесса, состоящего из следующих шагов:

  1. скрытого оценивания сложности задачи по какой-либо шкале, для этого используются карты, отсюда и присутствие слова «покер» в названии;
  2. вскрытие карт-оценок;
  3. если оценки более-менее сходятся, то за оценку сложности задачи берётся, например, среднее арифметическое, оценивание заканчивается;
  4. если оценки не сошлись, то проводится обсуждение того, почему не сошлись;
  5. возврат к пункту 1.

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

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

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

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

Метки: , , ,
Google Bookmarks Digg Reddit del.icio.us Ma.gnolia Technorati Slashdot Yahoo My Web News2.ru БобрДобр.ru RUmarkz Ваау! Memori.ru rucity.com МоёМесто.ru Mister Wong

Напишите комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *