Сегодняшний пост не о Scrum, или, вернее, не совсем о Scrum. Я хочу проанализировать 2 вопроса и сделать вам всем, кто интересуется Scrum, предложение от которого, как я надеюсь, вы не сможете отказаться :) Надеюсь заинтриговал. Но если нет — все равно прочтите последнюю часть статьи Предложение.

Вопрос #1: Зачем я веду этот блог?

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

Вопрос #2: Зачем вы читаете этот блог?

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

А в чем проблема?

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

Предложение

Я предлагаю еще один способ делиться опытом. Я предлагаю всем желающим создать Skype-группу, где все желающие могут задавать вопросы которые интересуют их и ответить на вопросы, ответы на которые вы знаете!

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

Конечно же, и в этом подходе есть свои недостатки, но я и не говорил, что он должен заменить все средства, которыми вы пользовались до этого — я просто предлагаю еще одно :)

А потому всем желающим предлагаю стучаться ко мне в Skype: alexlaway или подключайтесь непосредственно к чату (для подключения по ссылке понадобится Skype 3.8). Если не получается — стучитесь ко мне, я вас подключу.

Давайте попробуем быть еще ближе, общаться чаще и получать больше нужной и интересной нам информации!

P.S. Я очень надеюсь, что Тим Евграшин и Алексей Кривицкий меня поддержат ;)

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

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

Как вы, наверное, уже догадались из названия статьи я хочу продолжить разговор о карте проверок Scrum (Scrum checklist) за авторством Henrik Kniberg. В первой части статьи я прокомментировал раздел «Основа», а теперь хочу приняться за раздел «Рекомендовано, но не всегда обязательно». Начнем, пожалуй.

Команда обладает навыками для реализации всего PBL

Вполне естественно, что это желаемое, а не обязательное условие. Уверен, что вы, как и я, чуть ли не каждый день встречаетесь с проблемами и задачами с которыми не встречались раньше. Это нормальная часть работы и, более того, думаю, что если бы этого не было наша с вами работа не была бы такой интересной. Тем не менее, если команда УЖЕ обладает всеми навыками разработка пойдет быстрее и будет менее рискованной.

Нет жесткого распределения по ролям

Этот пункт заслуживает отдельного большого обсуждения в отдельной статье. Частично я обсуждал этот аспект в серии статей «Подкоманды: делить или не делить» (часть 1, часть 2, часть 3). Если в кратце, то команда должна быть cross-functional, т.е. в ней не должно быть выделенных SQL-программистов, верстальщиков, backend-разработчиков и пр. и каждый член команды имеет право заняться тем, чем он хочет заняться. Кроме того, что это способствует развитию членов команды и в конечном итоге положительно влияет на ее производительность, это является и неплохим мотивационным фактором: люди постоянно учатся (конечно только те, кто этого хочет) и получают интересные задания. Ну и, само собой, команде будет проще справиться с ситуацией, когда из нее на время или на совсем уходит человек.

Итерации, которые обречены на провал, обрываются рано

Есть такой принцип в Scrum — «fail early». Он в каком-то смысле является частным случаем более общего принципа всеобщей видимости и доступности, ранней диагностики проблем. Если провала нельзя избежать, по лучше если он случиться раньше, чем позже. Это справедливо для любого момента жизненного цикла проекта. Это справедливо как для всего проекта в целом, так и для отдельных итераций и даже для отдельных задач. Видите проблему — сразу скажите всем о ней.

Все члены команды участвуют в оценке

В первой части статьи я уже говорил о важности этого момента. Команда подписывается на выполнение всего объема задач запланированного на спринт. Иногда звучат вопросы вроде "должны ли новые члены команды участвовать в оценке? ". Категоричный ответ — ДА. Даже если они не обладают знаниями о вашем продукте или даже не обладают всеми необходимыми техническими знаниями — пусть участвуют: вам не помешает лишнее мнение. Просто играйте в planning poker. По правилам игры нужно обязательно спросить людей, проголосовавших минимальной и максимальной оценкой почему они так проголосовали. Может же быть ситуация, когда новый человек со всежим взглядом видит проблему которой не видите вы? Или наоборот, знает решение которого вы не знаете.

Product Owner доступен когда команда проводит оценку

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

Оценивайте относительный размер (story points), а не время

Раньше я уже писал на эту тему в статье «Story points vs Ideal hours vs man/hours». В ней, с помощью моего коллеги Тима Евграшина, детально описана разница между story points и ideal hours, рассказано что и в каких случаях должно использоваться. А потому, если эта тема вам интересна — прочитайте эту статью.

У команды есть Scrum Master

Естественно у команды должен быть Scrum Master, иначе кем бы я сейчас работал! :) А если серьезно, о роли Scrum Master'а написаны сотни книг и тысячи статей. Может быть вскоре не блоге «Лучшие реализации Scrum-практик» появится еще одна, но пока хочу напомнить только одно: Scrum Master — это НЕ МЕНЕДЖЕР. Он не управляет командой (команда сама собой должна управлять), он просто создает условия, в которых эта команда может работать с наибольшей производительностью и обспечивает команду всем необходимым. Некоторые сравнивают Scrum Master'а со сторожевыми псами, но лично мне это сравнение не очень нравится :)

---

Я вижу, что в секции "Рекомендовано ... " есть еще несколько пунктов, которые я здесь не прокомментировал. Я не делаю это либо потому, что не хочу заниматься повторением уже неоднократно мною написанного (в том числе и в этих двух статьях), например, пункты «Измеряется скорость» или «команда строит Burndown Chart», либо потому, что эти пункты требуют отдельной большой и умной статьи каждый (например, «У Product Owner есть видение продукта») и как по мне не имеет смысл ограничиваться одним-двумя предложениями. Ну либо потому, что мне просто нечего сказать по этому поводу :)

Вот и все на сегодня. Всегда рад видеть ваши комментарии и отвечать на любые ваши вопросы.

До встечи!

Неделю назад я опубликовал статью под названием «Карта проверок Scrum». Мало того, я еще и пообещал, что не ограничусь простым переводом карты проверок, но и прокомментирую ее содержимое. Обещал — получайте!

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

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

Посмотрите на 3-й пункт раздела «Основа». Он гласит «Процесс постоянно улучшается» и в этом сейчас одна из ваших целей. Не революция, но эволюция.

Вообще, Хенрик не зря вынес 3 пункта в раздел «Общее» и сказал, что если эти требования выполнены то не имеет смысла проверять все оставшиеся. Смысл и цель Scrum в том, чтобы вы:

1. Часто релизили качественное ПО, которое потенциально можно сразу же начать продавать
2. Релизили наиболее важный для заказчика функционал. Помните правило «80/20», оно еще известно как Принцип Парето? Оно гласит, что первые 80% функционала реализовуются за 20% всего времени. Это отлично, но проблема в том, что оставшиеся 20% реализовываются за 80%. А еще есть статистика, что порядка 30% функционала программ либо вообще не используются пользователями, либо используются крайне редко. Понимаете о чем я? ;)
3. Процесс постоянно улучшается. Существует довольно много упражнений, которые показывают как команда безо всякий финансовых вложений может сама улучшить свою производительность в несколько раз! Просто шаг за шагом улучшая то, как она работет. Звучит как спам, да? Но нет, я не продаю виагру :)

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

А теперь если не так. Хочу пройтись по основным пунктам и сделать 1-2 комментария.

Четко определен Product Owner

Кто такой Product Owner? Это человек, который должен обладать всей необходимой для работы команды информацией и должен представлять интересы компании. Он является связующим звеном между stakeholder'ами (кто бы подсказал правильный русский термин, а то пишу как иммигрант из Штатов) и командой. Кстати, заметьте, командой, а не менеджером или техническим лидером. Product Owner представляет интересы stakeholder'ов устанавливая приоритеты задачам в backlog'е, тем самым решая что будет реализовано в первую очередь, а что может и подождать. Ну и думаю, что понятно, что у product owner'а должен быть только один голос, иначе получится как в известной басне про лебедя, рака и щуку.

У команды есть Sprint Backlog

Другими словами команда четко знает свои задачи на ближайший спринт. Более того, это не просто задачи: это задачи, которые команда подписалась, ну или обязалась выполнить. А если команда подписалась — она должна сделать все от нее зависящее, чтобы выполнить свои обещания. Но для этого никто не имеет право ей мешать и Sprint Backlog принадлежит только команде. В реальном мире это значит, что если появилась очень срочная и важная задача и ее необходимо впихнуть в текущий спринт из Sprint Backlog'а убирается наименее приоритетная задача примерно такого же размера. Но таких ситуаций лучше избегать. В Scrum есть хорошее правило, позволяющее Product Owner'у оборвать ход спринта и начать новый, естественно заново проведя митинг планирования. Если у вас возникнет вышеописанная ситуация попробуйте объяснить заказчику, что изменять список задач в то время, как команда над ними уже работает — это плохая идея. Но если ему ОЧЕНЬ НУЖНО — он имеет полное право объявить досрочное завершение текущего спринта и начать планирование нового. Заодно проверите так ли уж заказчику важна эта функциональность. Единственное НО — не совершайте профессионального самоубийства. Если заказчик ОЧЕНЬ настаивает, наверное, следует пойти ему на встречу.

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

Daily Scrum проводится

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

1. Чем я занимался вчера
2. Чем я буду заниматься сегодня
3. Какие у меня есть проблемы

Demo Meeting проводится

Цель — показать новую версию продукта всем заинтересованным лицам и собрать отзывы. Stakeholder'ы вообще и Product Owner в частности всегда должны быть в курсе всего, что происходит с его продуктом.

Есть Definition of Done

Это способ сохранять требуемое качество продукта, вернее даже ОПРЕДЕЛЯТЬ требуемое качество. Задача считается реализованной только в том случае, когда она соответствует ВСЕМ пунктам в Definition of Done.

Ретроспектива проводится после спринта

Ретроспектива — это основное и чуть ли не единственное средство для постоянного улучшения процесса разработки. Это короткий митинг, в котором вся команда (желательно вместе со Product Owner'ом) обсуждает события, достижения и неудачи с момента последней ретроспективы и пытается найти пути для:

1. Сохранения и приумножения положительных событий и достижений
2. Избежания или уменьшения негативного влияния неудач в будущем

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

У Product Owner'a есть Product Backlog

Product backlog, в первом приближении, это тот же Sprint Backlog, только он включает в себя задачи для всего продукта вцелом и принадлежит Product Owner'у. Кроме очевидных целей Product Backlog'a таких как «не забывать о каких-нибудь требованиях» Product Backlog служит еще нескольким менее очевидным, в частности с помощью Product Backlog'а Product Owner может планировать даты релизов или предоствлять информацию о том, когда примерно будет реализована та или иная задача. Для этого задачи в Product Backlog должны быть приоритизированы и оценены. А для того, чтобы даты, которые называет Product Owner на основе Product Backlog были правдой, оценки должна давать команда. Вне зависимости от авторитета Product Owner'a, размера его зарплаты или его технических знаний: задачи будет реализовывать команда, а значит она и должна оценивать. Редко Product Owner более подкован технически, чем команда, так что может быть, что задача, «оцененная» Product Owner'ом в 4 недели будет оценена командой в 2 дня ;) Шучу :)

Проводятся митинги планирования

Еще один способ убедиться в том, что даты релизов, рассчитываемые Product Owner'ом на основе Product Backlog верны. И еще один способ дать команде работать спокойно, а значит — с наибольшей продуктивностью. Поскольку в Product Backlog должны содержаться истории пользователя, а не задачи (обсуждение и аргументация этого момента выходит за рамки данной статьи, но если вы так уж хотите аргумент, то вот вам: как минимум, для того, чтобы Product Owner имел возможность приоритизировать список он должен понимать все, что там написано. А потому лучше, если элементами Product Backlog'а будут не_технические описания требуемого функционала, а описание с точки зрения обычного пользователя:  другими словами там должно описываться ЧТО должно быть реализовано, а не КАК).

В результате этого митинга (или, если хотите, его артефактом) должен быть составлен Sprint Backlog. С ним должен быть согласен и Product Owner, и команда. Все в команде должны быть уверены в том, что смогут выполнить все задачи из Sprint Backlog за время спринта.

Итерации ограничены по времени

Все в Sсrum ограничено по времени: итерации, митинги... Тому есть много причин, но основными являются увеличение производительности и контролируемости процесса и прогресса.

Члены команды сидят в одной комнате

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

На этом раздел Основы Scrum заканчивается. Остался в принципе не менее интересный раздел "Рекомендовано ... ", но я пока хочу остановиться. Возможно, я еще вернусь к этой части.

А пока что спасибо Вам всем за внимание и за комментарии и, как всегда прошу еще больше и того, и другого!

До скорых встреч!

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

Вот представьте себе: вы работаете, как вы считаете, по Scrum, вроде все нормально, но как вы можете быть уверены, что у вас действительно Scrum и что все настроено и работает правильно? Есть несколько вариантов. Недавно Тим написал статью «На сколько вы Agile» — это один из вариантов получения количественной и качественной оценки вашего процесса.

Второй вариант несколько проще и быстрее, хотя, конечно, результат не такой точный (если вообще в этом случае может быть точный результат). Несколько дней назад Henrik Kniberg опубликовал вторую версию своего Scrum Checklist. Вашему вниманию представляется переведенная на русский язык версия. Скачать русскую версию Scrum Checklist.

Сразу хочу оговориться (коротко, более детальный разбор карты проверок появится на этом блоге в ближайшем будущем), что не нужно быстренько бежать печатать 10 копий карты и раздавать всем членам команды, чтобы посмотреть «на сколько вы Scrum».  Не так. Его нужно использовать к случаю. Например, вы собираетесь проводить ретроспективу. Загляните в карту и посмотрите, а все ли перечисленное вы делаете и что из того, чего вы не делаете может оказаться для вас полезным.

Еще одним применением карты может быть старт команды, которая еще не работала по Scrum. Ведь фактически, в карте кратко перечислены все основные практики Scrum! Это ли не то, что нужно для начала?!

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

Update: на блоге появились 2 статьи с детальными комментариями к карте проверок Scrum: часть 1 и часть 2.

Знаю, что довольно значительное время этот блог не обновлялся и нет мне оправдания, но тем не менее сегодня я хотел бы не столько поделиться с вами своим опытом, сколько попросить у вас помощи :)

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

Начинаем :)

Итак, основные треования к бонусной схеме следующие:

Бонус должен быть командным, а не индивидуальным

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

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

1. Решение о распределении или использовании бонуса принимается только в том случае, если ВСЕ члены команды согласны с решением. Мне кажется, что вариант с большинством голосов в данном случае работать не будет, т.к., например, в случае команды из 10 человек меньшинство — это аж 4 человека, т.е. довольно много. Если у вас совсем нет никаких идей о том, как можно достичь такого всеобщего соглашения смотрите как выбирают папу римского (хотя там требуется 2/3 голосов + 1 голос) :)
2. В случае, если команда решает разделить деньги, то единственный доступный вариант — это просто деление всей суммы бонуса на количество человек. Варианты «я дольше работаю», «это ОН сломал билд», «так она же весь спринт проболела» не принимаются. Обсудите это с командой заранее и см. п. 1
3. Часто случается, что в команде есть отличный специалист и замечательный товарищ, но этот товарищ всегда  работает очень медленно, например потому, что всегда старается сделать свой код идеальным, или потому, что всегда до байта оптимизирует свой код. Во всех придуманных нами схемах есть фактор времени или фактор объема выполненных работ, и в случае, если у вас в команде есть такой человек, могут возникнуть проблемы. Не думаю, что стоит напрямую обсуждать эту тему с командой или с этим человеком. Просто оговорите, что никогда и никто из команды не будет обвинен в срыве релиза или недополучении бонуса. В этом случае виноваты все: товарищ, что делал слишком медленно и слишком идеально, команда, что недосмотрели. Опять же, все должны принять это простое правило. У вас же на ретроспективах никто никого не обвиняет в проблемах, надеюсь?!

Сумма бонуса должна основываться на числах, а не на чувствах

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

Схема расчета суммы бонуса должна быть простой и понятной всем

В нашем случае это означает:

1. На собственно расчет суммы бонуса должно тратиться минимум времени, расчет должен быть прост и очевиден
2. Очень желательно, чтобы сумма бонуса рассчитывалась на основе той статистики и тех данных, которыми команда уже владеет или которую несложно и недолго собирать. Например, бонусные схемы, основанные на количестве написанных строк, количестве возвратов из code review и из QA, количество открытых багов и пр. представляются нам излишне сложными

Бонусы должны начисляться на основе результатов одного спринта

Поскольку основной единицей времени, за которую заказчик получает свое бизнес-value, является спринт кажется разумным привязать бонусы к каждому спринту. Чем раньше вы найдете и высветлите проблему, тем раньше ее можно будет решить.

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

1. Выставление оценок или принятие решения о сумме бонуса может приниматься исключительно Product Owner'ом, Product Owner'ом и Scrum Master'ом, Product Owner'ом и командой со сравнением результатов и т.д. 
2. Может допускаться обсуждение суммы бонусов в случае, если какая-то сторона считает, что бонус рассчитан неправильно/несправедливо. Да, нам всем нужны деньги, но в данном случае смысл не только в них. Если вы не проводите ретроспективные митинги, или постоянно их откладываете, то бонусы могут быть как раз тем, что вам нужно, потому, что ретроспективы очень важны для постоянного улучшения процесса работы и для обмена мнениями между Product Owner'ом и командой. Проблема, о которой знают все — это уже наполовину решенная проблема
3. Бонусы могут аккумулироваться или выплачиваться сразу после начисления

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

Схема, основанная на прибыльности команды

Размер бонуса — это процент от прибыли, полученной от реализации продуктов, реализованных командой. С данной схемой есть несколько проблем:

1. Расчет прибыльности, да еще и каждые 2 недели (длина нашего спринта) может превратиться в большую головную боль
2. Собственно, сам расчет прибыльности не очевиден: кроме команды над проектом наверняка работают менеджеры по продажам, консультанты, служба поддержки, системные администраторы и пр.
3. Реализация схемы может быть проблемой для заказчика, особенно если заказчик не из «цивилизованной Европы», где ежемесячно всем сотрудникам высылается полнейший отчет о финансовых достижениях компании
4. Допускаю, что этот вариант может оказаться меньшим мотивирующим фактором, чем остальные схемы, поскольку команда (если только в ней нет менеджеров по продажам) скорее всего лишь косвенно влияет на чистый доход от проекта. С другой стороны, если команда может активно влиять на ход проекта или на его функционал (например, предлагая собственные идеи), эта схема становится одним из лучших вариантов
5. Допускаю, что этот вариант не лучший для заказчика, т.к. у него нет прямых рычагов стимулирования и мотивации команды

С другой стороны, если возложить расчет суммы дохода на финансовый отдел компании и изменить временной промежуток, за который выплачивается бонус так, чтобы он совпадал по времени, например, с подготовкой ежемесячных отчетов финансовым отделом компании, то схема может оказаться вполне интересной и работоспособной. Например, чистая прибыль компании от реализации продуктов за месяц составила $300000, команда получает 1%, что в данном случае составит $3000 на команду в месяц. Тут возможны подварианты с зависимостью процента, получаемого командой от самой суммы прибыли.

Схема, основанная на уменьшении от максимальной величины бонуса

Допустим, команда договаривается о максимальной сумме бонуса за спринт в $1000. Реальная сумма бонуса рассчитывается по следующей формуле:

$Реальная = $Максимальная * Фактор_1 * Фактор_2 * ... * Фактор_N

В самом простом случае каждый из факторов_N — это дробное число от 0 до 1, оценивающее достижение той или иной цели. Например, у нас есть следующие факторы:

 
• Скорость
 
• Качество
• Объем работ
 
• Дисциплина

Если product owner совершенно удовлетворен скоростью работы команды в течении спринта, то этот фактор становится равным 1, если у него есть лишь небольшие замечания — 0.9, если заказчик скорее недоволен, чем доволен — 0.2 и т.д. Точно также определяется значение для остальных факторов. Для примера, Скорость = 1, Качество = 0.6, Объем работ = 1, Дисциплина = 0.8. Получаем, что командный бонус будет равен $1000 * 1 * 0.6 * 1 * 0.8 = $480.

Мне кажется, что в случае этой схемы, оценки должны выставляться:

1. Product Owner'ом
2. Scrum Master'ом отдельно от команды (особенно если он не принимает непосредственного участия в разработке, т.е. не пишет код)
3. Каждым членом команды

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

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

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

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

Сама схема проста: заказчик определяет сумму бонуса на основе того, насколько он удовлетворен работой команды и ее результатами. У этого подхода множество минусов, но несомненным плюсом является то, что такой подход может стимулировать диалог между product owner'ом и командой, что, опять же, приведет к высветлению и обсуждению существующих проблем, а значит так или иначе к их решению.

Схема с фиксированной оплатой

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

Еще одним плюсом данной схемы, кроме ее простоты, является возможность для заказчика регулировать финансовые вложения в команду. Если финансы не позволяют заказчику провести очередной пересмотр заработной платы, то данная бонусная схема может быть идеальной. С одной стороны она-таки позволяет повысить доход членов команды при наличии такой возможности, с другой стороны, в случае, если такой возможности нет, лично я предпочел бы потерять бонус, чем члена команды или часть своей заработной платы. Вобщем, такой себе бюджетный вариантик :)

К сожалению, на данный момент это все, на что мы оказались способны. И к сожалению, ни одна из схем в чистом виде не подходит.

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

Всем заранее большое спасибо! До встречи в комментариях :)

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

Ранее писалось, что экзаменовать по окончании классов начнут с 1-го октября 2009 года и обещали вскоре выложить вопросы. Вот оно и случилось.

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

1. Scrum

1.1 Укажите основные принципы Scrum, которые заложенные в основу эмпирического контроля процесса и которые реализуются частыми ревизиями и адаптированием прозрачных (transparent) артифактов.

Если проще, какие основные принципы Scrum лежат в основе идеи Inspect and Adapt? Честно говоря не припомню, чтобы на CSM-классах упоминались слова «эмпирический контроль процесса» или «прозрачные артефакты». По смыслу можно догадаться, что имеется ввиду ввиду опытный путь постоянного улучшения процесса и избавления от проблем. Первое, что приходит в голову — это ретроспективы: в конце спринта собрались всей командой (а если пригласите еще и представителей команды заказчика вообще супер будет), обсудили, какие задачи, которые ставились на прошлой ретроспективе были выполнены, обговорили и выписали на доску все положительные и отрицательные события с момента последней ретроспективы, для каждой записи вместе выработали меры, которые должны позволить развить успех и избавиться от найденных проблем, запланировали выполнение наиболее важных задач на следующий спринт. Примерный roadmap для ретроспективы.

1.2 Опишите фреймворк Scrum, который реализует эмпирический контроль процессов с помощью timeboxing (ограничение по времени), совещаний и артефактов. 

Все описывать долго, а потому опишу кратко. В Scrum все ограничено по времени: выполнение отдельных задач, спринты, митинги и пр. Все совещания должны быть максимально короткими и эффективными: daily scrum, планирование, ретроспектива, демо. Главнейшими артефактами, позволяющими следить за ходом проекта являются burndown chart, sprint backlog и product backlog.

1.3 Укажите элементы (практики) Scrum, реализованные в time-box'ах, совещания и артефакты, и то, как они используются различными ролями.

Daily scrum, ретроспектива, планирование, ревью (демо) — это митинги. Бэклоги и burndown chart — это артефакты.

2. Артефакты

2.1 Укажите назначение, процесс производства и использования трех артефактов Scrum

Артефакты — это product backlog, sprint backlog и burndown chart.

Product backlog постоянно содержится в порядке и пополняется/исправляется Product Owner. Элементами являются истории пользователя (user stories). Все элементы приоритизированы и, желательно, оценены в story points командой.

Sprint backlog — заполняется командой на основе скорости (velocity) команды и приоритетов. Берутся наиболее важные по оценке Product Owner'а задачи из Product Backlog. Содержит задачи.

Burndown chart служит для отслеживания прогресса спринта. Содержит идеальный и реальный графики времени, необходимого для завершения всех целей спринта по дням.

2.2 Укажите содержимое и способ заполнения Product backlog и как он приоритизируется.

См. комментарий к п.2.1.

2.3 Укажите техники работы с Product Backlog

Вносить истории в product backlog могут все, но приоритеты расставляются только product owner'ом. На каждом планировании спринта желательно оценить в story points размер всех историй, которые еще не имеют оценки с тем, чтобы product owner имел возможность рассчитать даты релизов.

2.4 Опишите роль product backlog в митинге планирования спринта

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

2.5 Укажите сожержимое и способ заполнения sprint backlog, и то, как он обновляется и поддерживается командой в течение спринта

См. п.2.1.

2.6 Опишите роль sprint backlog в daily scrum

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

2.7 Опишите способ создания burndown chart на основе sprint backlog и product backlog

Рассчитывается сумма часов/story point всех задач/историй для sprint и product backlog соответственно. Это первая точка. Дальше в качестве точек на оси Х берутся дни или спринты и по оси Y отмечается новое значение суммы оставшихся часов/story points.

2.8 Укажите 2 оси burndown chart

Время по оси Х, количество оставшейся работы в часах или story point по оси Y

2.9 Опишите, как на основе burndown chart можно построить тренды или прогнозы

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

3. Митинги

3.1 Опишите как 4 scrum митинга реализуют проверку и адаптацию эмпирического процесса контроля

3.1.1 Опишите механизмы sprint review (demo митинг) в проверке прогресса на пути к релизу или цели проекта

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

3.1.2 Опишите роль митинга планирования в процессе инспектирования и адаптации в демо митинге  и оптимизации ценности релиза или проекта

Хм...

3.1.3 Опишите роль daily scrum в процессе инспектирования прогресса и принятии изменений для того, чтобы выполнить все цели спринта.

Не жертвуем качеством. Если видим, что не успеваем (реальный burndown идет выше идеального) мы должны выбрать задачи, которые будут исключены из спринта.

3.1.4 Опишите, как ретроспективный митинг реализует Inspect and Adapt принцип для постоянного улучшения процесса

См. п.1.1

3.2 Опишите как различные артефакты Scrum предоставляют прозрачность, необходимую для того, чтобы 4 основных митинга Scrum работали

Все артефакты уже описаны в секции 2.

3.2.1 Опишите как Product Backlog и Sprint Backlog используются в митинге планирования

см. п.2.1

4. Роли

4.1 Опишите обязанности Product Owner и то, как Product Owner использует Product Backlog для выполнения этих обязанностей.

Задача Product Owner — представлять интересы stakeholder'ов и предоставлять информацию команде. Несмотря на то, что все могут вносить задачи в product backlog, только product owner имеет право расставлять приоритеты, тем самым обеспечивая то, что в первую очередь будут реализованы наиболее важные для проекта задачи.

4.2 Опишите как Product Owner использует Sprint Planning и Sprint Review для оценки ценности релиза или проекта и ее оптимизации

На планировании, заказчик сможет поменять приоритеты в случае, если для выполнения задачи нужно слишком много времени. На Sprint Review команда демонстрирует Product Owner'у и stakeholder'ам результаты своей работы с тем, чтобы они могли сразу предоставить комментарии по проделанной работе и направить проект в нужном направлении если проект отклонился от него или если цели проекта поменялись.

4.3 Опишите обязанности Scrum Master, включая обязанность «агента по изменениям» и механизмы реализации этих изменений. Опишите, как Scrum Master взаимодействует с командой и product owner'ом.

Одна из главнейших задач Scrum Master'а — это обеспечить спокойную работу команды на протяжении спринта с тем, чтобы команда могла реализовать все, что было запланирована. В частности, Scrum Master должен препятствовать внесению изменений в Sprint Backlog после того, как спринт уже начался. Если изменения срочные, то они должны быть внесены в Product Backlog с высоким приоритетом. Если изменения очень срочные, то product owner имеет право оборвать спринт и начать новый, но это обязательно включает в себя новый митинг планирования.

4.4 Опишите обязанности команды и то, как команда взаимодействует со Scrum Master'ом и Product Owner'ом

Основная задача команды — приносить бизнесc-value stakeholder'ам. Она вправе требовать информацию от Product Owner'а.

4.5 Опишите влияние самоорганизованности и кросс-функциональности на команду и как эти принципы могут быть реализованы

И самоорганизация, и кросс-функциональность необходимы для увеличения производительности команды. Достичь этих целей непросто и тут много факторов, особенно человеческих. Как минимум нужно иногда позволять команде ошибаться и позволять людям браться за задачи из области, где они не являются лучшими специалистами. И нет — Scrum Master не Project Manager, и он не должен управлять командой. Скорее он должен следить за тем, чтобы команда выполняла разработанные ею же правила.

4.6 Объясните, как команда использует Sprint Backlog и Daily Scrum в процессе Inspect and Adapt чтобы увеличить вероятность выполнения всех целей спринта

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

Вот и все, вопросы закончились.

Насколько я знаю, это не первый вариант экзамена на получение CSM. Scrum Alliance уже несколько лет пытается ввести экзамены, но каждый раз вопросы подвергаются жесткой критике со стороны общественности. Так что нет никакой гарантии, что ситуация не повторится и в этот раз. Тем не менее, эти вопросы формируют roadmap для изучения Scrum и позволяют вам понять, что и где вы упустили (например, я что-то упустил в пункте 3.1.2, и это только как минимум).

Всегда рад вашим комментариям и обещаю ответить на все! До новых встреч на блоге!

Update 14-09-2009: Как я и подозревал, 11 сентября 2009 года на сайте http://scrumalliance.com появилась информация о том, что введение экзамена на звание Certified Scrum Masters в очередной раз отложено на неопределенный срок. На этот раз причиной называется то, что Scrum Alliance не успел завершить перевод/локализацию текста вопросов.

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

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

1. В начале работы мы должны в общих чертах продумать архитектуру
2. Пока пишем код пишем и юнит-тесты
3. Как только встречаем что-то, что написано не красиво или просто не получается сделать в рамках текущей архитектуры — сразу рефакторим: при наличии юнит-тестов проблем возникнуть не должно.

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

1. Основная идея проекта, на которую была рассчитана ваша архитектура изменилась и теперь всякое изменение дается с трудом. Пример: сначала хотим очень гибкую систему, которая могла бы служить единой платформой для всех заказчиков. Со временем понимаем, что пожелания этих заказчиков настолько различны, что  нет никакого смысла пытаться делать эту самую единую систему и куда проще (Keep It Simple Stupid — KISS) для каждого из заказчиков сделать отдельную систему.
2. Со вторым пунктом все ясно: хоть в теории только команда и может ставить сроки, на практике кроме команды есть еще куча людей, которые прямо-таки рвутся установить свои сроки, причем еще ни разу не встречал, чтобы настаивали на сроках бОльших, чем говорит команда. Обычно наоборот. Если у вас в компании есть хоть один сейлз вы 100% встречались с такой ситуацией, хотя, допускаю, что вы смогли отмахаться :) И хоть в теории мы и не должны жертвовать качеством, на практике и карьерой не хочется жертвовать, а потому из двух зол выбираем меньшее — отказываемся от юнит-тестов.
3. Этот пункт тоже связан с нехваткой времени. Поставлю золотой памятник тому, кто расскажет как в 100% случаях убедить заказчика отложить релиз. А если уже запустили рекламу или заказчики уже договорились с субподрядчиками? И если та задача, которую вы ну никак не успеваете сделать, нужна кровь из носу и без нее проект никому вообще не нужен? Какие тут варианты, кроме как кроме юнит-тестов начать жертвовать и качеством (злорадно предупредив заказчика, что ничего путного из этого не выйдет).

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

1. // Костыль
2. // Hardcode :(
3. // Пусть пока будет так — потом исправлю ;)

И с каждым таким комментарием растет цена на внесение изменений, что, рано или поздно заметит заказчик. Например, когда реализация истории по созданию странички FAQ по вашим оценкам займет половину всего времени, отведенного на спринт просто потому, что ваша CMS держится на честном слове и 80% времени уйдет на то, чтобы все перетестировать.

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

Уверен, что в 90% случаев у product owner'а (или у его босса или у босса его босса :)) возникнет вопрос: зачем тратить неделю [хотя бы]работы команды на что-то под названием рефакторинг, если «... и так все работает».

В этой статье мы поговорим как раз о бизнес-обоснованиях сессии рефакторинга. Оговорюсь, что задача не только в необходимости убеждения product owner'а в том, что такая сессия необходима, но и в том, что не должно быть работы просто ради работы — все должно приносить бизнес-value. Это тот самый критерий, по которому команда должна отбирать идеи для рефакторинга. В любой задаче, даже в задаче по рефакторингу системы, должно быть business-value. Если business value есть — задачу можно рассматривать для включения в сессию рефакторинга, если его нет — тогда и смысла в этом немного, и заказчика будет сложно убедить. Итак, 7 вариантов обоснования необходимости рефакторинга:

Вариант №1: уменьшение стоимости внесения изменений

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

1. Вряд ли стоит рассматривать эту идею, если не предполагается никаких изменений в той части, которую вы хотите рефакторить.
2. Всегда нужно примерно сравнивать стоимость самих работ по рефакторингу и вероятность и частоту внесения изменений в ту область, с которой вы планируете работать. Если рефакторинг займет 5 человеко-недель, а за все время разработки проекта изменения в эту часть вносились лишь один раз... в общем вы поняли :) И да — в идеале всеми этими просчетами должен заниматься заказчик, но вы облегчите ему и себе жизнь, если сами подумаете об этом перед тем, как вызывать заказчика на 2-х дневное совещание для обсуждения 257 идей для рефакторинга.

Вариант №2: поддержка новой функциональности

Одним из основных принципов Scrum и Agile вообще в том, что сам заказчик никогда не может знать все, что ему нужно на самом деле. Например, он может попросить вас реализовать «простую систему отчетности», а к концу проекта (мы говорим про после_авральную фазу,   помните? Жертвовать качеством можно только в том случае, если альтернативой являются только потеря рабочего места или заказчика) выяснится, что простая она для него, а вы таких графиков и в глаза никогда не видели, и даже предположить не могли, что такие вообще бывают. А потому, оглянувшись назад и заглянув вперед вы можете обнаружить, что рефакторинг системы отчетности даст вам, кроме всего прочего, возможность легко добавлять новые типы графиков. По-моему мнению, если задача по рефакторингу попадает под это условие ее нужно делать в 90 случаях из 100. Особенно если вы уверены, что эта новая функциональность рано или поздно появится.

Вариант №3: оптимизация системы

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

Вариант №4: создание возможности для автоматизации

Долго пытался сформулировать понятно и тем не менее не уверен, что получилось :) А потому объясню. Этот вариант можно рассматривать как симбиоз вариантв «поддержка новой функциональности» и «уменьшение стоимости внесения изменений». Под этот вариант могут подойти все изменения, связанные с вынесением отдельных параметров в конфигурацию, реализация поддержки собственных простеньких скриптов или XML для описания последовательностей, правил и т.п. как альтернатива жесткому хардкоду. Например, если у вас есть набор правил, по которому рассчитывается дата рассылки почты, то, возможно, имеет смысл реализовать более гибкий механизм, который позволил бы вам легко добавлять и изменять правила, а может даже позволил бы делать это самому заказчику. Они хоть и очень заняты, но часто любят собственноручно поучаствовать в работе. В качестве еще одного примера можно привести реализацию описания отчетов с помощью XML с тем, чтобы позже можно было позволить заказчикам самим составлять отчеты через пользовательский интерфейс.

Вариант №5: вынесение общих частей систем в отдельную подсистему

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

Вариант №6: улучшение пользовательского интерфейса

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

Вариант №7: переход на новую технологию/версию

В случае желания перейти на новую технологию или новую версию этой же технологию всегда нужно задаться двумя вопросами:

1. Что команду не устраивает в данной версии и не проявится ли это что-то и после изменения
2. Какие проблемы сулит собственно переход

Эти вопросы помогут выяснить необходимость перехода со стороны команды, но, что более важно, должно быть что-то, что будет иметь ценность для клиента. Вот только несколько вариантов:

1. Безопаснее. Например, использовать последнюю версию нужно потому, что в старой найдены критические уязвимости. В наш век, когда существует понятие «вечной бета-версии» (практически все продукты Google, например), это может оказаться серьезным доводом
2. Быстрее. Редкий релиз новой версии не сопровождается словами «теперь это работает в N раз быстрее». Это связано с вариантом «оптимизация системы»
3. Возможность использовать функционал, который отсутствует в текущей версии/технологии. Что важно — этот функционал должен быть востребован в первую очередь заказчиком. Под это подходят все перечисленные выше и ниже варианты

Как и все статьи на этом блоге, эта статья не претендует ни на энциклопедичность, ни на полноту изложения, ни на работоспособность во всех возможных случаях. Все эти варианты использовались мной в личной практике (правда, слава Богу не для того, чтобы аргументировать product owner'у необходимость рефакторинга, а для убеждения боса боса product owner'а :)) и все имели ценность для моей команды и для моего заказчика.А потому, если у вас есть вопросы, мнения, критика и пр. прошу высказываться в комментариях!

До новых встреч!

Сегодня хочу поговорить вот о чем. Когда мы говорим о практиках Scrum мы часто подразумеваем, что все они необходимы и упаси боже что-то упустить — и Scrum уже не такой уж и Scrum, и другие Scrum-мастера уже коситься начинают, ну и прочие не очень приятные вещи происходят. Есть замечательная статья под названием «Когда Scrum не похож на Scrum», в которой автор бегло пробегается по некоторым принципам, описанным в классической литературе по Scrum и показывает, что без некоторых из них вполне можно обойтись. В этой статье (и возможно в последующих статьях) я хочу более детально посмотреть на основные принципы Scrum с точки зрения «а что если без этого». Зачем это нужно? Ну, я вижу несколько применений подобным знаниям:

1. Если вы только начинаете работать по Scrum вам следует сосредоточиться на самых важных принципах, без которых Scrum не просто не Scrum, а без которых основные идеи Scrum просто перестают работать.
2. Если вы уже работаете по Scrum, но кризис (да, опять о кризисе) уже затронул вашего заказчика, то наверняка ваши действия будут так или иначе направлены на повышение производительности и, может быть, с помощью этой статьи (или этих статей) вы сможете найти способ оптимизации процесса.
3. Если вы уже работаете по Scrum, но какие-то из практик вы посчитали не нужными или не применимыми, то возможно эти статьи заставят вас пересмотреть вашу точку зрения и сделать еще один виток в вечно кружащемся Inspect & Adopt :)

Здесь я хочу кое-что оговорить. Обещаю, это последнее лирическое отсупление от темы данной статьи, сразу после него я перейду непосредственно к рассмотрению поднятого вопроса. Оговорка следующая: сейчас, когда я пишу эти строки я, как и вы, еще не знаю, что будет написано дальше и к каким выводам я приду. Просто мне стало интересно (а еще показалось важным) разобраться в том, что в Scrum наиболее важно, а чем можно пренебречь. Можете назвать это расстановкой приоритетов. Я сейчас делаю то, что, возможно, делали бы вы если бы всерьез занялись поднятым вопросом: просматриваю блоги и форумы, обращаюсь к своей практике, советуюсь с другими CSM и т.д. А потому хочу подчеркнуть, что все сказанное есть лишь мое мнение и вы вправе согласиться или не согласиться с ним. И, вообще-то, будет очень классно, если вы сделаете это в комментариях :) Зачем мы часто релизим наши продукты? Для того, чтобы часто получать отзыв заказчика, чтобы, в свою очередь, заказчик получил то, что ему действительно нужно. Так что даже если вам нечего сказать в комментариях на блоге действует система рейтингов (угу, вооон те звездочки в конце статьи и под каждым из комментариев) и я был бы очень признателен даже за такой бессловный отзыв :)

Вот. Итак — основной вопрос: Может ли Scrum работать, когда нет самоорганизующейся команды?

В статье я рассмотрю несколько точек зрения на вопрос, а под конец постараюсь сделать вывод.

Для начала давайте расставим приоритеты. Давайте возьмем 3 принципа Scrum, о которых обычно упоминают в первую очередь:

1. Частые релизы и итеративный процесс разработки: нужны для того, чтобы часто получать отзывы пользователей и, соответственно, подправлять направление развития проекта. Корректировка курса развития проекта.
2. Фиксируем качество, позволяя заказчику изменять только scope: делаем для самих же заказчиков, ибо часто они не понимают, что исправление ошибок в проекте, который уже активно используется намного дороже, чем сохранения отличного качества продукта на всех итерациях разработки. Высокое качество продукта.
3. Самоорганизующаяся команда: скорее всего, именно такая команда сможет работать наиболее эффективно и качественно, будет быстро приспосабливаться к меняющимся условиям и будет способной быстро реагировать на новые и изменяющиеся требования. Быстрая реакция на изменения.

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

1. Вы быстро и с высоким качеством получите то, что вам не нужно
2. Вы быстро получите то, что вам нужно, но при этом о качестве продукта говорить не приходится
3. Вы получаете то, что хотите и с отменным качеством, однако не так быстро, как может быть могли бы получить

Мое мнение, что несмотря на то, что идея самоорганизовующейся команды (СК) и входит в TOP-3 идей Scrum, она находится на последнем 3-ем месте. И еще. Навскидку, скажите, что еще можно использовать для того, чтобы быть увереным в том, что проект развивается в нужном направлении, кроме как постоянно спрашивать мнение заказчика? Как минимум на вскидку я не скажу. А как можно сохранять высокое качество продукта, кроме как запретить жертвовать им? Тоже не тривиальная задача. А как можно повысить эффективность работы команды? МИЛЛИОН вариантов! Начиная от бесплатного кофе, через новую технику и софт и оптимизацию процесса и до треннингов и курсов. Как минимум есть выбор.

Следующий вопрос: давайте рассмотрим команду из 10 человек. Можно ли назвать эту команду самоорганизовующейся, если в самоорганизации принимают участие только 9 человек? А если только 8? А 7? Как мне кажется (и гугл говорит, что мне не одному кажется:), что полностью самоорганизовующаяся команда — это красивый и на практике очень редко достижимый миф. Это отличная идея и, скорее всего, нужно стремиться к тому, чтобы команда сама собой управляла, но скольким мы готовы пожертвовать ради этого? Ну например, готовы ли вы уволить отличного программиста, который знает все ваши продукты просто потому, что он не желает самоорганизовываться. А если у вас отличная команда из 10 человек и ни один из них не может или не хочет организовывать работу предпочитая, чтобы это делали за них? Можно ли говорить, что производительность будет низкой?

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

Я бы хотел сделать следующий вывод. Реализация идеи самоорганизовывающейся команды замечательна, но ее очень нелегко реализовать на практике. Более того, во многих случаях цель принципа самоорганизации — высокая производительность — может быть с большим успехом достигнута другими средствами. Другими словами: если у вас самоорганизовывающаяся команда — у вас высокая производительность, но если у вас высокая производительность — это еще не значит, что у вас самоорганизовывающаяся команда. Мое мнение — Scrum может оставаться Scrum'ом и без самоорганизовывающейся команды. И, будучи поставленным перед выбором, я бы выбрал цели №1 и №2, пожертвовав целью номер 3. Хотя идеалы и нужны на то, чтобы к ним стремиться :)

Жду вашего мнения в комментариях! До скорых встреч.

Тема сегодняшней статьи навеяна долгой дискуссией с коллегами по поводу нужности, важности и вообще применимости такого инструмента планирования, как story point.

В частности, спор велся о том, что лучше и легче использовать — story points, идеальные часы или реальные человеко-часы. Давайте начнем сравнение с того, что дадим определение каждому из инструментов.

Человеко-час:  это количество работы, выполняемой средним работником за один час.

Идеальный час: количество часов в день, которые работник тратит на непосредственное выполнения задач перед ним поставленных. В эти часы не входят всякого рода чаепития, совещания, игры в Quake3 и прочие, не очень относящиеся или совсем не относящиеся к работе занятия. В очень хорошем случае у вас в одном рабочем дне будет 7 идеальных часов. Нижней границы нет: в некоторых особо запущенных проектах хорошо, если их 3-4.

Story point: единицы относительного размера, используемые в оценке требований как альтернатива единицам времени. Story points — единицы измерения сложности или размера требования, а не количества времени, требуемого для реализации требования.

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

Для тех, кто не понял, к чему я клоню скажу прямо: story point нельзя сравнивать ни с человеко-часами, ни с идеальными часами — это совершенно разные инструменты. Идеальные часы и часы — сравнивайте на здоровье, даже формула есть для конвертации одного в другое. Но поскольку блог о Scrum, далее мы поговорим об идеальных часах и story point, о том, как они могут и должны использоваться в одной и той же команде.

Если вы хоть раз принимали участие в Scrum-треннинге, вам наверняка приводили такой пример: вам показывали ближайшее здание и спрашивали ваши соображения насчет его высоты. После сравнительно небольшой паузы вы наверняка выдавали число, причем понятия не имели насколько оно соответствует действительности. А потом вам показывали второе здание и спрашивали, насколько первое здание выше или ниже второго. Тут вы наверняка быстро и уверенно отвечали на вопрос.

В этом, собственно, и заключен основной принцип story point. Человеческий мозг устроен таким образом, что ему легче сравнивать, чем оперировать абсолютными величинами.

Теперь об идеальных часах. Оценка в идеальных часах делается следующим образом: сначала делается оценка в идеальных часах, а потом вы умножаете полученное значение на определенный коэффициент в итоге получая оценку в реальных часах. Коэффициент рассчитать просто — посчитайте сколько времени из 8 рабочих часов в день вы тратите непосредственно на работу, а потом разделите 8 на это значение. Пример:

Допустим, за день я успеваю:

1. Daily scrum — 15 минут
2. 2 партии в Quake3 по 15 минут каждая
3. Каждый час выхожу покурить по 5 минут каждый из перекуров
4. В среднем меня отрывают от работы 5 раз за день, каждый раз на 5 минут

Итого:  15 + 30 + 40 + 25 = 110 минут ~ 2 часа. Т.е. в моем случае коэффициент пересчета будет равен 1.333. Таким образом, если я считаю, что на задачу нужно потратить 12 часов, на ее выполнение я планирую 16.

Если у вас возник вопрос зачем же все-таки нужны story points, если есть идеальные часы, то именно сейчас вы получите ответ на этот вопрос.

В проекте, который разрабатывается по Scrum есть несколько видов детализации задач: user stories и, собственно, задачи или task'и.

User stories — это большие и концептуальные описания требований на очень высоком уровне. Пример:

В качестве пользователя системы Google Reader я могу импортировать все свои RSS-ленты с использованием OPML для того, чтобы я мог читать их с использованием этой системы.

Story points используются для оценки именно user stories. И тому есть несколько причин:

1. Поскольку user stories обычно очень велики их долго точно оценить в часах
2. Поскольку user stories специально не содержат всех деталей их очень сложно точно оценить в часах.

Story points — это инструмент для планирования релизов — как окончательных, так и промежуточных. Для этого вам нужно собрать статистику, сколько story points «сжигает» команда за один спринт — вы получите так называемую velocity. Далее, просуммировав story points во всем product backlog и разделив это значение на velocity вы получите количество спринтов, необходимое для того, чтобы реализовать все требования в product backlog на текущий момент (!!!). Вот это «на текущий момент» очень важно. Дело в том, что Scrum не только не запрещает вносить новые требования и изменять существующие, но и поощрает это. А потому и даты релизов могут меняться, а значит вам нужен быстрый и относительно точный инструмент для этих расчетов. Конечно, вы можете потратить неделю составляя детальный Gaant chart и оказаться очень разочарованным когда неделя вашей работы пойдет на смарку из-за отклонений ваших оценок от действительности и из-за изменений требований проекта.

После того, как релизы спланированы можно переходить к планированию спринта, и тут нужны уже идеальные часы: Story points могут оказаться для вас слишком грубым инструментом для планирования на такой непродолжительный срок как 1-4 недели.

Здесь хотелось бы оговориться особенно: лично я использую story points и для планирования спринтов. Уже минимум полгода команда показывает приблизительно постоянную velocity, все привыкли и прочувствовали понятие story point и, как показывает практика, это работает, как минимум для моей команды. Planning meeting для нас в первую очередь необходим для получения деталей историй, которые мы хотим реализовать и для разбиения этих историй на задачи, которые мы так же оцениваем в story points.

Честно говоря, я несколько раз слышал от различных тренеров о том, что так делать неправильно, но пока не могу ни понять причин этого, ни найти какой-нибудь материал, который бы объяснял почему нельзя планировать спринт использую story points. Жду ваших комментариев!

Во время, когда в стране, да и во всем мире, бушует кризис, я не мог пройти мимо этой темы. Тем более, что мне на глаза попалась отличная статья Rafael Sabbagh Armony и Marcos Garrido. А потому сразу же было решено заняться ее переводом. Что получилось смотрите ниже по тексту. А еще ниже текста статьи форма для комментирования, куда я вас и приглашаю после прочтения

Мир столкнулся с самым тяжелыми финансовым кризисом в истории. Многие европейские страны, США и Япония уже в состоянии рецессии. Международный Валютный Фонд недавно заявил, что рецессия еще продолжает развиваться и что восстановление будет более медленным, чем в это было в прошлом. Как следствие, страны с развивающейся экономикой, такие как Индия и Бразилия, пострадают от массивного оттока капитала. МВФ в своем прогнозе также заявил, что мировая экономика сократится на 1.3 процента в 2009 году.

Forrester и Gartner предсказали, что объем инвестиций в 2009 году уменьшится на 3% или 4% соответственно. В частности, затраты на IT-сервисы упадут в этом году. Такие компании, как Toshiba и Nokie недавно отчитались об убытках или значительном снижении прибыли и о своих планах уволить тысячи сотрудников. Резко упала цена на акции Intel. Даже такой гигант как Google, который до этого казался непоколебимым, отчитался о первом за всю историю снижении прибыли за квартал и сократил сотни рабочих мест.

Новый сценарий для Проектов

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

• Качественная работа в быстро изменяющихся условиях, позволяющая частое перепланирование
• Курс на максимальное увеличение возврата инвестиций
• Помощь в уменьшении time-to-production и time-to-market
• Избегание затраты усилий и времени на подпродукты и функциональность, которые никогда не будут использоваться
• Постоянная доставка ценностей клиенту, даже если проект должен быть приостановлен перед тем, как он окончится
• Увеличение и улучшение коммуникации и обратной связи между stakeholder'ами, чтобы люди знали что должно быть сделано и что делается сейчас

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

Почему Scrum?

Давайте взглянем на игроков на рынке проектов в контексте финансового кризиса:

1. Организация или группа, которая предоставляет сервис. Она должна усилить конкурентоспособность с тем, чтобы не потерять клиентов: как внутренних, так и внешних
2. Директор или менеджер должен сократить операционные расходы, чтобы его организация могла выжить. Он выбирает внутренние проекты, сфокусированные на получение лучших результатов
3. Клиенту нужно аутсорсить, но ему также нужно сократить расходы, чтобы поддерживать их жизнеспособность

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

Нет растратам!

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

В своей книге «The enterprise and Scrum» Schwaber утверждает, что в среднестатистическом проекте порядка 50% времени (и денег) тратятся на требования, архитектуру, спецификации, и все это делается до того, как функциональность начнет реализовываться. Однако 35% запросов на изменение требований и 65% функционала, описанного в требованиях, либо используются очень редко, либо вообще не используются. Во время кризиса такая растрата времени и усилий неприемлема.

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

Самое важное — в первую очередь!

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

С другой стороны, в случае Scrum возврат инвестиций увеличивается в конце каждого спринта. Одна из главных ролей Product Owner'а в том, чтобы максимизировать возврат инвестиций с помощью постоянного обновления и приоритизации Product Backlog'а. Это позволяет наиболее ценным требованиям быть реализованными в первую очередь. Приоритизация product backlog на основе ценности того или иного требования позволяет организации оставаться конкурентноспособной, поставляя результат клиентам быстрее, чем конкурирующие организации, вводя в строй новый наиболее важный для их бизнеса функционал быстрее, или запуская проекты или выпуская новые версии чаще, так, что они постоянно соответствуют неизбежным изменениям рынка.

Да придут изменения!

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

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

Scrum следует утверждению Agile Manifesto, что ответ на изменение более важно, чем следование плану. Scrum принимает, что изменение — это естественная часть процесса разработки. В Scrum есть механизмы, позволяющие нормально работать с изменениями. Динамическая природа Product Backlog позволяет реализовать новые требования клиента в ближайшем же спринте. Такой быстрый ответ на изменение становится отличным конкурентным преимуществом, позволяющим превратить кризис в возможность.

Группа или Партнеры?

За все время разработки типичного waterfall-проекта, участие клиента требуется лишь дважды: в начале проекта для анализа требований и в его конце для приемочных тестов. В таком случае проект воспринимается клиентом как большая посылка со штампом "Не Открывать До ... ", чье содержимое будет доступно только в самом конце. Единственное впечатление о будущем продукте может быть полученно только из проектных документов, большинство которых уже не соответствуют действительности из-за изменения требований. В случае быстро и постоянно изменяющегося рынка, который мы имеем сегодня, то, что клиент хотел в начале проекта не всегда будет соответствовать тому, что ему нужно в конце.

В проекте, который использует Scrum, Product Owner постоянно находится в контакте с клиентом с тем, чтобы определить насущные требования и всегда держать Product Backlog обновленным и приоритизированным. Клиент часто получает новые версии и, соответственно, в состоянии чаще давать отзыв о проекте. Клиент чувствует себя вовлеченным в процесс, делящим ответственность на проекте со всей командой. Отношения с клиентом перестают походить на отношения между заказчиком и исполнителем и становятся более похожими на отношения между партнерами, проявляя соучастие, удовлетворение и почтительность. С клиентом устанавливаются долгосрочные отношения, которые могут преодолить тяжелый кризисный период.

Общение происходит не только между Product Owner'ом и клиентом. Все люди, воволеченные в проект, получают ежедневную возможность взглянуть на то, чем занята команда. Ежедневные совещания позволяют членам команды показать другим, что они сделали за время, прошедшее с момента предыдущего митинга и чем они собираются заниматься до следующего. Spring backlog или kanban показывает всем уже совершенные действия, те, которые вот-вот совершатся и те, что уже совершаются. Совместная работа в одном помещении стимулирует членов команды общаться между собой.  Burndown chart'ы показывают прогресс проекта. Частые демонстрации показывают Product Owner'у то, что было произведено и предоставляют возможности составить отзыв. В заключение, ретроспективы позволяют всем увидеть что работало в спринте, и что может быть улучшено.

Поддержание открытой связи между stakeholder'ами — это лучший способ убедиться, что все знают, что должно быть сделано и что делается. Это увеличивает продуктивность, что является обязательным для выживания в кризис.

Что, если проект приостанавливается?

Во времена кризиса часто случается, что бюджет иссякает или что поставщих уходит с рынка во время разработки проекта. Когда это происходит в не-agile проекте, что заказчик может предложить клиенту?

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

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

Что, если вам приходится сокращать Команду?

Вр время кризиса может возникнуть необходимость уволить или передислоцировать членов команды. В случае waterfall-проекта, все роли в проекте четко оговорены. Например, в случае IT-проекта, программист программирует, тестер тестирует и т.д. Таким образом, если из проекта уходит дизайнер, то новые окна останутся без графического оформления; если уходит тестер — проект окажется неоттестированным; и, что хуже всего, если уходит менеджер, проект остается без руководства. Таким образом, потеря члена команды угрожает успеху всего проекта.

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

Важно указать, что увольнение членов команды никогда не должно быть пунктом №1 при сокращении расходов. Сокращение команды также сокращает ее возможности по поставке ценностей для заказчика. Как следствие, клиент будет менее доволен и будет искать поставщиков, способных предоставить лучший сервис. Это ухужшает ситуацию в организации, создавая порочный цикл потерь.

Выводы

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

Оцените, пожалуйста, статью: 

Title	Votes	Rating	Review
Story points vs Ideal hours vs man/hours	4	9.5	-1.0