О жизни

Ура, новый проект! Заказчик говорит – «Ребята, я много слышал про Agile разработку. Я хочу Scrum на проекте». Все просто в восторге. Эйфория полная. Начинается разработка.

- Мы готовы к работе. Где можно найти product backlog?

- Guys, ну вы понимаете, я сейчас очень занят. Давайте попозже.

Команда ждет, пытается что-то предугадать, делает стандартные технические вещи – создает инфраструктуру, выбирает потенциальные framework’и. Через некоторое время разговор повторяется.

- Все, мы уже создали всю инфраструктуру. Мы не знаем, что делать дальше.

- У меня столько дел…

В конце концов кратко рассказывается, что заказчик хочет видеть. Естественно, ни о каких user stories речь не идет. Но хоть что-то, чтобы начать работать.

По самым оптимистичным оценкам работы как минимум на несколько человеко-лет.

- А какие приоритеты?

- Вся функциональность должна быть сделана. Причем, как можно быстрее!

Нда, начальная эйфория куда-то пропала…

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

Сделали. Sprint demo (как оказалось, в данном проекте feedback во время спринта – недостижимая роскошь).

- Мы завершили итерацию. Готовы показать то, что получилось.

- Ребята, ну вы понимаете, вы же умные люди… Я уверен, что вы все делаете правильно – я же вам все рассказал.

Упс. Команда начинает понимать, что какой-то уж очень странный Scrum получается. И даже совсем не Scrum. Но проект-то есть. И делать его надо.

Посовещались. Пришли к выводу – product owner проекту необходим. Если эту роль не может выполнять заказчик, значит, должен выполнять кто-то из команды (или из компании).

Выбрали. И начались нелегкие будни proxy product owner’a.

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

Дальше. Product backlog. User stories. Proxy product owner разбил весь продукт на отдельные user stories. Отправил заказчику. Как ни странно, заказчик даже внес некоторые изменения. Значит, не все еще потеряно! Команда становится веселее и продуктивнее прямо на глазах!

Приоритеты. Proxy product owner интуитивно понимает, что сейчас начнется самое интересное. Что делать, если для заказчика все самое важное? Попробовать подойти с другой стороны.

- Представьте, что мы не успеваем сделать одну историю. Какую вы бы предпочли выкинуть?

- Вот эту.

- А если еще одну?

- Эту.

- А если еще?…

Ух ты, даже начальные приоритеты удалось получить. Все, жизнь налаживается.

Остался feedback. Как быть, если заказчик действительно очень занят? И тут команда предлагает гениальную идею – найти реальных пользователей. С большим трудом у заказчика выбиваются контакты реальных пользователей. Что удивительно, пользователи рады, что их к этому привлекают.

Sprint demo. Судя по реакции со стороны пользователей, здравый смысл нас сильно подвел – сделали не совсем то и совсем не так. И тут приходит осознание, что Scrum начинает работать!

Во время очередного спринта, как обычно, возникают вопросы по истории. Происходит неожиданное – не нужно ждать несколько дней, proxy product owner может ответить прямо сейчас.

Еще через несколько спринтов скорость команды стабилизируется. Теперь уже можно предоставить заказчику примерный объем функционала на конкретную дату. Заказчик в восторге.

Команда тоже.

Happy end.

Proxy product owner – когда, зачем и что должен делать

Если есть человек, который успешно выполняет роль product owner’a, то вводить proxy product owner’a абсолютно нет смысла. По сути, proxy product owner – это локальный product owner. И если существующий product owner не предоставляет user stories, product backlog, priorities и feedback – нужно задуматься о введении такой роли.

Второй вариант, когда команда использует Scrum (и для этого проекта он подходит), но заказчик не хочет брать на себя обязанности product owner’a. В этом случае proxy product owner просто необходим.

Что должен делать proxy product owner? По сути, то же, что и product owner:

1. Vision
2. Product backlog с приоритетами
3. Быть готовым ответить на вопросы по проекту
4. Организовать получение feedback’a

Есть несколько вариантов того, кто должен стать proxy product owner’ом.

Один из самых хороших вариантов – когда эту роль берет на себя кто-то из компании, но не из команды:

1. Это не нагружает команду
2. Не вносит больших помех со стороны видения команды (оно часто слишком техническое)
3. Позволяет ставить реальные бизнес-приоритеты
4. А если человек является экспертом в домене проекта, так и вообще отлично.

Второй вариант – Scrum master становится proxy product owner’ом. Есть несколько минусов у этого решения:

1. Scrum master может стать слишком перегруженным
2. Scrum master может стать представителем заказчика в глазах команды,
3. Так как Scrum master плотно взаимодействует с командой, то она может повлиять на него в плане приоритетов.

Третий вариант – proxy product owner’ом становится кто-то из команды. Также ряд минусов:

1. Скорее всего, будет преобладать технический vision
2. Приоритеты будут тоже больше техническими
3. Это человек получит определенную власть, что может привести к расколу команды
4. Он может быть слишком перегруженным
5. Эта роль может вызывать раздражение (особенно у программистов).

Заключение

Вы знаете, что Scrum для этого проекта и вашей команды подходит просто идеально? Но не хватает такого же идеального product owner’a? Создайте его!

Автор: Dmitry Zdanovich

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

- Пал Палыч, я считаю, что нам обязательно надо перейти на самоуправление в цеху! Я считаю, что мы вполне дозрели до того, чтоб самим определять рабочий распорядок!

- Сева, вы вот просили туалет рядом с цехом построить, чтоб не бегать за проходную. Вот мы вам построили, специально для вас. А вы его загадили до потолка… Понимаешь? Туалет - специально для вас, а вы его загадили. Сами загадили, понимаешь? И стоит он загаженый - уже два месяца.

- Пал Палыч, а какое это отношение это имеет к нашему самоуправлению?!!

- Сева, ты что, серьезно не понимаешь?

- Нет, Пал Палыч, не понимаю!!!

- Тогда точно про демократию говорить рано…

Не удержавшись, пожал Пал Палычу руку. Молодой рабочий меня явно не понял.

Что такое и зачем нужно?

Что такое task board? В общем случае это визуальное отображение историй пользователя и задач на этот спринт с разделением по статусу (и с различными дополнительными индикаторами).

В простейшем случае это выглядит так:

Как видим, основное поле разбито на несколько колонок – story, to do, in process, to verify, done. Каждая задача представлена отдельным стикером (это важно, не стоит писать несколько задач на одном листке). В колонку story помещаются листочки с user story, в to do помещаются задачи, которые планируется сделать в этом спринте, в in process – те, над которыми в настоящий момент идет работа, to verify – задачи, ожидающие проверки, в done – то, что полностью сделано.

Преимущества

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

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

Выявление проблем с помощью task board

С помощью task board можно выявить некоторые проблемные ситуации.

Очень много задач в to do. Если это не начало спринта, то это может сигнализировать об одной из следующих проблем:

1. Отставание от графика (нужно смотреть burn-down chart для точного анализа)
2. Некорректное разбиение задач, когда некоторые задачи занимают много времени (например, неделю). Но при этом burn-down chart покажет, что все в порядке.
3. Очень много задач в in progress. Это может свидетельствовать о:
4. Rоманда сильно распыляет свои силы, работая одновременно над очень большим количеством задач параллельно
5. Задачи не доводятся до конца, а остаются в in progress. Это может привести к сложностям в конце спринта. Скорее всего, вызвано отсутствием четких критериев, когда задача считается сделаной.

Внедрение

Как и с большинством новых инструментов, с внедрением task board возможны проблемы. Основная из них – нежелание команды его использовать. Тут сложно посоветовать конкретные подходы к решению. Один из вариантов - можно использовать авторитет Scrum Master’a и вначале просто требовать использовать task board, опираясь на мировой опыт успешного использования этого инструмента. Если и спустя некоторое время команда все еще против task board’a, то необходимо тщательно обдумать, нужен ли он в данной команде. Без поддержки со стороны команды task board лишен смысла.

Виды task board’ов

Базовый

Базовый task board содержит только самую необходимую информацию. Для организации такого task board’a можно использовать:

• поверхность, на которую можно наклеивать стикеры (кусок ДСП, школьная доска и т.д.)
• магнитную поверхность, листочки с задачами крепятся с помощью магнитов
• деревянная поверхность, листочки с задачами прикалываются с помощью кнопок

Task board разбивается на несколько колонок. В простейшем случае их всего 3 – to do, in progress, done. Задачи, относящиеся к одной user story, располагают на одной линии). Задачи пишутся на листочках. На этом листочке есть смысл написать:

1. Название задачи
2. Estimation
3. Название user story, если нет отдельной колонки для user stories

Примеры

Электронный task board

Электронный task board можно реализовать с помощью различных утилит. Но он имеет несколько недостатков:

1. Его тяжело повесить на видное место (если финансы позволяют, то можно использовать проектор)
2. Отсутствует факт физического изменения статуса задачи
3. Невозможно демонстративно подойти к доске и переместить задачу в done

Заключение

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

Как и большинство других инструментов Agile процессов, task board не требует больших затрат, так что если ваша команда еще не использует task board, то есть смысл его попробовать. Уверен, понравится!

Ссылки

• http://www.mountaingoatsoftware.com/task-boards 

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

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

Дело было так.

В аэропорту Барнаула мы получили свои рюкзаки. Пыхтя взгромоздили их на спины: 120 литров рюкзака набитых под завязку - это тяжело. В рюкзаках - сменка, аптечки, непромокайки, теплая одежа и вообще всякое. Почему? Перед отъездом я сел и отработал карту - снег на перевалах, реки и сплав, дожди в этой время в этой местности, наличие-отсутствие комаров и прочее. В результате - список снаряги, 120 литров. Подогнав лямки, бодро чешу к ожидающему нас автобусу. Возле автобуса вижу чудное виденье - группа товарищей с “школьными” рюкзачками удивленно распрашивает “зачем мы погрузили в рюкзаки столько водки”. На вопрос где их снаряга отвечают, что они памятку гидов “что брать с собой даже не читали” - а зачем, аптечки наверняка с собой другие взяли, если что поделятся. Тут я напрягся, и как выяснилось - не зря. Дальше - больше.

Закинуть арчемаки на коней - это не к ним, это конюхи должны делать. Готовить обед - снова не к ним, это инструктор должен организовать. Если при организации инструктор послал их собрать дров или порезать морковки - он опять не прав. Дождь пошел - как же так, дождь пошел, а мы  сухой одежды не взяли, почему нас не предупредили?! На перевале снег - как же так, почему снег? Как две с половиной тысячи метров?! А почему нам не организовали теплые вещи? Ах в памятке было написано? Так мы ее не читали! Как так наши проблемы?!! Из палаток - всегда последние, на обед - всегда первые, за шашлыком или стаканом - всегда на месте.

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

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

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

- Это как? - спросил я и посмотрел туда, куда он махнул. Ничего там особенного не было, чисто пирамидка из камней. Вот на эту пирамидку он мне и показывал.

- У нас есть такое правило - в особо трудных местах надо делать пирамидку из камней. И каждый, кто проходит, должен положить камень. Тогда тем, кто пойдет следом, помогут духи ущелья.

- Андрей, где же камень найти! - удивился я. - Голая скала, не рубить же!

Андрей улыбнулся и достал из кармана камень. И положил на вершину пирамидки. Принес снизу! - догадался я! И тут же понял, что он имел в виду под правильным отношением к жизни. Это было как откровение, как японское сатори!

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

Так было и с камрадом - с которым расставились. Когда он впервые произнес “на самом деле” - я напрягся. Когда он завел волыну что “должно быть разделение труда…”  - я уже все понял и знал что будет дальше.

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

Коллеги, если вы увидели в описанном выше паттерне себя - не надейтесь, что вас “полюбят такими, какие вы есть”. Какие бы уникальные вы не были и как бы не были глубоки ваши знания. Почему - ответ на картинке слева.

Обнаружили таких - кто знает как оно должно быть, но делать ничего не хочет - гоните их в шею, толку от них не будет.

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

P.S. Вот чего бы я хотел на самом деле - чтоб существовал иной тест, кроме совместных испытаний проектами и походами, для выявления этих людей на ранних этапах. Никто случайно не знает такого?

Еще докладов можно посмотреть на сайте itv.by в разделе “акции”Остальное - coming soon…

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

Доклады.

Начало было за Павлом Габриэлем и его докладом про то, как правильно внедрить Agile.

From Agile Summer 2008

Презентация у Паши была просто отличная и совсем не напрягала аудиторию - одна картинка - одна фраза - абсолютно верно заданная ассоциация. (more…)

Почему менеджеры любят Agile

View SlideShare presentation or Upload your own.

(more…)

(more…)

http://mourk.com/blog/2008/05/05/scaling-agile/

Рекомендации по масштабированию Agile для удаленных команд. Да, agile сложно, а может быть даже и невозможно полностью масштабировать для большой, а тем более удаленной команды. Но тем не менее представленный процесс помог избежать ряда проблем, описанных автором в предыдущей публикации.