Украинский портал по Скрам

Конференция Agile Base Camp, Киев 23 января

noreply@blogger.com (Nat) — Thu, 24 Dec 2009 14:07:55 PST

Конференция Agile Base Сamp соберет профессионалов в сфере разработки программного обеспечения, интересующихся подходами Agile Software Development.

Тематика докладов подобрана для специалистов с разными областями интересов и уровнем опыта:

• Mainstream • New to Agile • Java Craftsmanship • Experience Reports • Agile Soft Skills • Open Space Discussion

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

Кроме стоимости участия, Вас ждет еще несколько приятных сюрпризов :) Будем рады видеть Вас в числе участников нашей конференции!

Узнать больше и зарегистрироваться>

Certified ScrumMaster Class, Киев 11-12 января

noreply@blogger.com (Nat) — Tue, 22 Dec 2009 00:54:25 PST

Официальный сертификационный тренинг Scrum Allance готовит Скрам-мастеров (Scrum Master) - лидеров проектов, следующих гибкому подходу управления Скрам (Scrum)

Двухдневная программа состоит из лекций, практических занятий и обсуждений. По окончании курса участники получают сертификат Certified Scrum Master от Scrum Alliance.

Тренер:
Робин Даймонд, сертифицированный Scrum-тренер

Ознакомиться с деталями и зарегистрироваться>

Certified Scrum Product Owner

noreply@blogger.com (Alexey Krivitsky) — Fri, 21 Aug 2009 23:04:14 PDT

16-17 сентября в Украине впервые проводится сертификационный класс Certified Scrum Product Owner. Класс проводится в рамках конференции Agile Eastern Europe.

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

Двудневный тренинг включает следующие аспекты:

Структура Скрам подхода глазами бизнеса;
Суть роли Product Owner в Скраме;
Советы и паттерны эффективного Product Owner-а;
Работающие практики составления и приоритезации списка требований продукта (беклога продукта);
Ключевые переменные успешного управления разработкой продуктов;
Как предсказывать дату завершения проекта и объем завершенной работы;
Как успешно масштабировать проект для многокомандной среды в сотни разработчиков;
И множество других аспектов Скрам проектов.

Тренинг проводится Сертифицированным скрам тренером Робином Даймондом 16-17 сентября.

Ознакомиться с деталями и зарегистрироваться...

Agile Eastern Europe: опубликована программа конференции

noreply@blogger.com (Alexey Krivitsky) — Sun, 09 Aug 2009 01:07:48 PDT

Автор: Алексей Кривицкий

Программа конференции Agile Eastern Europe, которая пройдет в Киеве 18-19 сентября готова.

Знакомьтесь:

Введите при регистрации ключ "agile-ukraine" и получите 5% скидку.

Следующие Scrum сертификации

noreply@blogger.com (Alexey Krivitsky) — Fri, 07 Aug 2009 08:58:54 PDT

В рамках конференции Agile Eastern Europe будут проводиться две сертификации:

Certified Scrum Product Owner (CSPO) 16-17 сен
Certified ScrumMaster (CSM) 21-22 сен

Успейте зарегистрироваться.

Agile Podcast: Роли в Agile команде

noreply@blogger.com (Alexey Krivitsky) — Tue, 07 Jul 2009 12:48:37 PDT

Подкаст на тему "Роли в Agile команде"

Участники:
Алексей Кривицкий, Асхат Уразбаев, Денис Миллер, Кирилл Медведев

Обсуждалось:

Scrum-команда
Понятие ролей, соотношение с должностями
Кроссфункциональность и узкая специализация
Синергия команды: 1 + 1 = 11
Тестировщик и разработчик в Team
Менеджер проекта
Product Owner
Мотивация, индивидуальные поощрения
Scrum Master – вымирающий динозавр

Слушать!

Тяжелые последствия проектов с фиксированной стоимостью

noreply@blogger.com (Alexey Krivitsky) — Mon, 20 Jul 2009 06:18:16 PDT

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

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

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

Из Dr Dobb's, автор Скотт Амблер.

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

заранее написанные спецификации: мы подробно описываем функциональные требования к продукту на раннем этапе жизненного цикла;
управление изменениями: мы стараемся удержать "расползание границ проекта" (scope creep) на протяжении всего проекта;
заранее разработанный дизайн системы: мы подробнно описываем архитектуру приложения до начала собственно разработки;
последовательный цикл разработки продукта.

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

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

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

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

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

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

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

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

Из Dr Dobb's, автор Скотт Амблер.
Перевел Артем Сердюк для scrum.com.ua.

Ежедневный митинг у доски

noreply@blogger.com (Alexey Krivitsky) — Sat, 13 Jun 2009 01:36:45 PDT

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

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

Оно выглядит так:

или так?

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

Существует очень простое указание для того, чтобы убедиться, что вы не забудете поговорить о чем-то важном каждый день: проводите ежедневное собрание стоя напротив доски и проверяйте, чтобы все задания в средней колонке ("выполняется", "in progress") были обсуждены.

Из Visual management, автор Xavier Quesada Allue.
Перевел Павел Юров для scrum.com.ua под редакцией Алексея Кривицкого.

Ярлык "DONE"

noreply@blogger.com (Alexey Krivitsky) — Sat, 13 Jun 2009 01:36:13 PDT

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

Ярлык состояния DONE - это идея, относящаяся к процессу. Это креативный способ визуализировать поток, дать командам время отпраздновать свои достижения, и обеспечить выравнивание и общение команды; и это все ежедневно.

Концепция проста. В течение дня члены команды работают над задачами, которые находятся в колонке "in progress" (выполняется) на доске задач. Когда они заканчивают задачу, вместо того, чтобы немедленно перенести ее в колонку "Finished" (Закончено), они клеят на нее ярлык DONE. И там он остается до конца дня, провозглашая на весь мир, что команда завершила некоторую работу. Это часть о потоке: бросив быстрый взгляд в конце дня на доску вы можете "видеть поток", поискав глазами ярлыки DONE. Чем больше голубого, тем больше поток. Это нравится менеджерам и Product Owners.

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

Что насчет выравнивания и общения? Перенося все ярлыки DONE на ежедневном собрании вы, по существу, обеспечиваете то, что все в команде осведомлены о том, кто и что заканчивает. Фактически, так появилась эта идея. Члены команды переносили задачи в колонку Закончено в течение дня, и потом на ежедневном собрании они могли забыть рассказать об этом. Имея много задач в колонке "Закончено" становилось тяжело запомнить, которые из них были новыми, а не вчерашними. И поверьте мне, если у вас много однодневных задач, то это случится, особенно с наиболее производительными девелоперами, которые делают много вещей.

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

Итак, основное указание для использования ярлыка DONE следующее:

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

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

Можете ли вы быстро обнаружить ярлыки DONE?

Почему ярлык голубого цвета?

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

(Для интереса: я узнал это в очень длинной беседе с Кошуке Кавагучи, автором Hudson CI engine. Хадсон показывает голубой экран вместо зеленого экрана, когда конструкция в порядке.)

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

Экспериментируйте!

Из Visual management, автор Xavier Quesada Allue.
Перевел Павел Юров для scrum.com.ua под редакцией Алексея Кривицкого.

Дао Скрам

noreply@blogger.com (Alexey Krivitsky) — Mon, 25 May 2009 13:10:41 PDT

Автор: Игорь Тамащук

Много бумаги исписано и и мегабайтов перекачано в процессе, когда одни пытаются понять, что же такое Scrum, а другие пытаются это объяснить. Главное достоинство Scrum в этом смысле заключается в том, что для того, чтобы начать его применять не нужно многого – бери готовые несложные правила, минимум артефактов, и колесики закрутились. Но понимание глубокой сути этого процесса наступает далеко не сразу.

Как известно, центром любого scrum-проекта является product backlog. Это место, куда product owner записывает свои пожелания, оценивая их значимость и вместе с командой планирует итерации. Казалось бы, что может быть проще? Но чем же этот подход оказался лучше других? Чем он отличается, скажем, от случая, когда заказчик просто заводит тикеты, например, в JIRA? Что делает этот проект столь эффективным?

Читать дальше...

CSM

noreply@blogger.com (Alexey Krivitsky) — Wed, 04 Mar 2009 11:20:45 PST

В Киеве в апреле состоится очередной класс Certified ScrumMaster: детали.

Extended SCRUM simulation with LEGO

noreply@blogger.com (Alexey Krivitsky) — Mon, 23 Feb 2009 11:02:48 PST

Author: Alexey Krivitsky

Эта статья написана на английском, так как она будет интересна более широкому кругу, чем украинские Scrum-мисты.

Over the last couple of years I’ve participated in and facilitated several CSM classes run by different trainers. All of those classes had (what they used to call it) an “XP game” done during the second part of the second day. During this game people blew balloons, sorted decks of cards, built card houses, and other funny stuff like that.

Though it was nice and entertaining activity, I think there should be other games that illustrate better the things we try to teach.

So I started to think of better simulations and have come across the idea of using LEGO bricks (thanks to William Wake, Jurgen De Smet, Yves Hanoulle, Mykola Gurov and other folks for opening my eyes).

Lego For Extended Scrum Simulation - DOWNLOAD

View more documents from krivitsky. (tags: scrum games)

Планирование спринтов

noreply@blogger.com (Alexey Krivitsky) — Tue, 10 Feb 2009 09:38:31 PST

Автор: Алексей Кривицкий

"Скажите, как вы планируете спринты,
и я скажу, на сколько успешен ваш проект."

(древнее высказывание)

Шутка, конечно. Но на самом деле планирование спринта - это сердце Скрама.

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

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

Давайте начнём с цели спринт планирования:

Определиться со списком историй (от англ. "user stories"), которые команда верит, что может реализовать (в полном объёме и ожидаемом качестве), которые временно удовлетворят жажду заказчика по новой функциональности.

Другими словами мы пытаемся найти компромисс между желаниями заказчика и возможностями команды (при чём компромисс, который бы не компрометировал наш профессионализм!).

Существуют следующие основные варианты проведения спринт планирования:

Планирование на основании велосити.

В ходе такого планирования команда набирает истории на новый спринт в соответствии со своим ожидаемым велосити (velocity - скорость работы команды, измеряемая в единицах функционала, которые команда реализовывает за спринт).

То есть, если за прошлый спринт команда выполнила историй на сумму 20 единиц, то можно смело предположить, что и в этот раз команда выполнит столько же (при условии равной длины спринтов и той же доступности членов команды).

В eXtreme Programming этот подход называется "вчерашняя погода" (yesterday's weather).
Планирование, базируемое на обещаниях.

Другой (более скрупулёзный) вариант планирования - пройтись детально по историям беклога (начиная с наиболее приоритетных и идя вниз).

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

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

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

Какой же подход выбрать?

Молодым командам я бы однозначно посоветовал комбинированных подход.

Со временем, когда у вас выработается "командное шестое чувство" можно будет идти по укороченному варианту с велосити. Но это приходит не сразу. Так что не торопитесь. Чем детальнее вы выполните ваше "домашнее задание" по планированию спринта - тем проще вам потом будет в спринте. Не все углы стоит срезать.

Будьте бдительны!

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

В этом случае варианты у вас следующие:

переговорить размер историй - упростить что-то;
заменить одну историю другой - заменить что-то на что-то;
разбить историю на более простые - оставить что-то на потом.

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

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

В Скраме только команда решает какой объём работы она готова взять. Наполнение же этого объёма остаётся на усмотрение заказчиков.

Удач!

Скрам тренинги

noreply@blogger.com (Alexey Krivitsky) — Fri, 06 Feb 2009 04:07:10 PST

Автор: Алексей Кривицкий

13 и 14 февраля в Киеве пройдёт серия Scrum-тренингов:

На 6 февраля к каждом классе есть по 5 мест.

Будем рады видеть всех желающих.

Время переосмысления

noreply@blogger.com (Alexey Krivitsky) — Fri, 06 Feb 2009 04:13:00 PST

Автор: Алексей Кривицкий

Сегодня многие говорят и пишут об особенностях работы (и её поиске) в кризисное время. Мне не нравится слово "кризис", поэтому я его использую только в начале этого поста, и только ради индексации в поисковиках по этому ключу :)

Больше ни слова про слово на "К" ;) Дальше только про новые возможности!

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

Все что-то переваривают, о чём-то усиленно думают. Сегодня появился повод сослаться на "К" и под этим предлогом сменить условия сотрудничества.

Мне хочется назвать это время "временем переосмысления". Что за прекрасное время! Давайте же использовать его потенциал!

Основная часть

Сегодня как никогда важно быть эффективным. Продуктивным быть уже недостаточно. Недостаточно писать много кода. Недостаточно повышать метрики производительности команд. Недостаточно часто выпускать релизы.

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

Давайте рассмотрим суть происходящего по порядку.

Удовлетворение найценнейших потребностей бизнеса

Отчёт Standish Group за 2002 год (так называемый"Chaos Report") утверждает, что в любом программном продукте общего пользования порядка 2/3 функционала не используется либо используется редко и лишь 1/5 используется всегда или часто.

С трудом верится. Но если вы подумаете о своих продуктах (если вам приходилось участвовать в разработке ПО), то вы легко сможете идентифицировать ряд фич, без которых ваш продукт остался практически таким же полезным как и с ними...

Я проводил на тренингах подобное упражнение с участниками, большинство с лёгкостью в течение 7 минут выписывает 5-10 относительно больших фич, которые можно было не реализовывать. На вопрос, почему они говорили об этом заказчикам, половина отвечала: "а зачем?"...

Если верить этому же отчёту, более половины проектов в 2004 году переиспользовала свой бюджет и при этом более 80% проектов не уложились в срок. И всё это при том, что в этих проектах было в среднем 2/3 неиспользуемых фич.

(пауза)

...В наикратчайшие сроки

Это не означает выпустить полную версию уже завтра или послезавтра. Нет. На столько быстро мы писать вряд ли сможем писать код (there is not silver bullet...).

Но посмотрите на эту иллюстрацию:
Производительность обоих проектов одинакова: обе команды за одинаковое время выпускают 100 единиц ценностей (business value, BV).

Но при каком из этих подходах выпуска BV заказчик более спокоен? Что заказчик понимает под найкратчайшими сроками? Выход финальной версии (когда-нибудь) или выход ранних рабочих версий (уже сейчас)?

При каком подходе заказчик раньше начинает получать (видеть) выгоду от вложений?

Так уж важны ли заказчику финальные сроки, если он каждые две недели может получать готовую к поставке версию продукта?

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

Выпускать в найкратчайшие сроки не означает отгружать рабочий продукт быстро. Это означает возвращать инвестиции заказчика постоянно.

С наивысшей адаптивностью

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

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

Итог

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

Не бойтесь! Вперёд!

Удач

Харьков, тренинг "Базовые концепции Agile и SCRUM"

noreply@blogger.com (Alexey Krivitsky) — Tue, 23 Dec 2008 12:01:31 PST

Автор: Алексей Кривицкий

С субботу 10 января 2009 в Харькове пройдёт полнодневный тренинг по программе "Базовые концепции Agile и SCRUM".

Вопросы, рассматриваемые на тренинге:

Что значит Agile? Что такое SCRUM?
Что нужно для внедрения Agile подходов? С чего начать?
Как объяснить своим заказчикам и руководителям выгоды от применения этих подходов?
Как подготовить проектную среду для запуска проекта?
Как запустить SCRUM?
Как построить эффективную комманду?
Что нужно для перевода запущенного проекта на SCRUM?
Как собрать и подготовить требования для SCRUM проекта?
Как планировать и отслеживать релизы и итерации?
Как построить свой Agile процесс?
У вас будет возможность задать любые интересующие вас вопросы.

Детали тренинга и регистрация.

A tool for time boxing

noreply@blogger.com (Alexey Krivitsky) — Fri, 07 Nov 2008 15:07:32 PST

Автор: Алексей Кривицкий.

Многие, наверное, уже видели приложение, которое я использую для обратного отсчёта времени. Очень удобная вещь. Практически незаменимая.

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

Есть online версия, есть версия для выкачивания:
http://www.online-stopwatch.com/

Энджойте!

Чеклист СкрамМастера

noreply@blogger.com (Alexey Krivitsky) — Mon, 25 Aug 2008 10:33:09 PDT

Переводчик: Кривицкий Алексей

От переводчика:

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

Я решил перевести статью "A ScrumMaster's Checklist", опубликованную на сайте Danube, Майкла Джеймса (Michael James), так как по-моему мнению, она может помочь СкрамМастерам (начинающим и не только) разобраться в том, что же входит в сферу их обязанностей.

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

"Адекватный СкрамМастер может работать с двумя или тремя командами одновременно. Если вы готовы ограничить вашу роль до организации митингов, напоминания тайм-боксов и разгребанию препятствий, которые члены ваших команд в явной форме репортят вам, вы можете справиться с вашей ролью, работая в part-time режиме. Команды, скорее всего, в этом случае будет превышать свою продуктивность в сравнении с тем, как они работали до перехода на Скрам, и в проектах не случится ничего катастрофического...

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

Великий СкрамМастеру под силу справиться только с одной командой.

Мы рекомендуем одного выделенного СкрамМастера на команду (из семи человек), особенно на начальной фазе.

Для того, чтобы найти весь спектр работ, которыми стоит заниматься СкрамМастеру, попробуйте взглянуть на работу вашего Product Owner, вашей команды, на их инженерные практики и также на вашу компанию вне команды и проекта. Нельзя точно описать роли и задачи СкрамМастера, но я выписал вещи, которые на моём опыте СкрамМастеры по ошибке упускают из вида:

Как поживает мой Product Owner?
Вы можете повысить эффективность работы вашего Product Owner’а, помогаю ему управлять Product Backlog и планом релиза. (Помните, что только Product Owner может приоритезировать беклог)
- Приоритезирован ли беклог в соответствии с последними пожеланиями Product Owner’а?
- Все ли требования и пожелания от всех заинтересованных в продукте сторон записаны в беклоге? Помните, что беклог обновляется постоянно.
- Управляемого ли размера беклог? Для поддержания управляемого количества элементов в беклоге, храните его элементы более гранулярными кверху, с более крупными (эпическими) элементами книзу. Зачастую непродуктивно детально анализировать беклог, делаю это далеко вниз от его верха. Требования будут часто изменяться во время обсуждений между разработчиками и заказчиками.
- Могут ли элементы беклога (особенно те, что ближе к верхушке) быть выражены как независимые, обсуждаемые, полезные, оцениваемые, мелкие и тестируемые истории?
- Объяснили ли вы вашему Product Owner суть технической задолженности и то, как её избегать? Одним из решений этой головоломки может быть добавление автоматизации тестов и рефакторинга в определение готовности элементов вашего беклога.
- Является ли беклог радиатором информации, который доступен и виден всем заинтересованным сторонам проекта?
- Если вы используете автоматические средства для управления беклогом, все ли знают, как ими эффективно и просто можно пользоваться? Средства автоматического управления беклогом могут стать информационными холодильниками (information refrigerators), если СкрамМастер не пытается превратить беклог в коллективный легкодоступный инструмент.
- Можете ли вы помочь коммуницировать беклог, раздавая распечатки?
- Можете ли вы помочь коммуницировать беклог, создавая большие видимые настенные диаграммы?
- Можете ли вы помочь вы вашему Product Owner'у организовать элементы беклога по релизам, адекватного размера?
- Все ли стороны проекта (включая команду) знают, отвечает ли план релиза текушему прогрессу проекта, основан ли он на текущей велосити (сумме оценок завершаемых историй за спринт)?
- Обновил ли Product Owner план релиза после последней демонстрации результатов спринта? Вы можете показать всем Product/Release Burndown Charts, которые рекомендует Mike Cohn, это может помочь выявить отставания о на ранних фазах."

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

C чего начать изучение SCRUM?

noreply@blogger.com (Alexey Krivitsky) — Mon, 25 Aug 2008 10:37:49 PDT

Терминология и базовые принципы SCRUM

Неплохие статьи-обзоры:

Видео

Часовое видео от Кена Швабера

Материалы Кена Швабера

Материалы с тренинга Certified ScrumMaster:
http://www.controlchaos.com/quickstart.pdf

Другие материалы на сайте
http://www.controlchaos.com/about/index.php)

Выжимки из первой книги Кена:
http://www.controlchaos.com/download/Book%20Excerpt.pdf

wiki о Scrum:

http://c2.com/cgi/wiki?ScrumOverview

Бесплатные книги

Хенрик Книберг и его практические советы в книге
"Scrum and XP from the Trenches"

Гибкий подход разработки ПО – Scrum

noreply@blogger.com (Alexey Krivitsky) — Fri, 18 Jul 2008 02:11:18 PDT

Автор: Кривицкий Алексей

И как всё это касается меня – разработчика?

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

Я пишу это для тех, кто отрицательно ответил на перечисленные вопросы.

Читать дальше...

Certified ScrumMaster video

noreply@blogger.com (Alexey Krivitsky) — Thu, 02 Oct 2008 13:48:37 PDT

Видео с CSM классов, которые провёл Mark Pushinsky и его коллеги из компании Innovel в Украине и Бразилии.

У вас есть шанс попасть в CSM, который будет проведён в Киеве в сентябре.

SCRUM митинг и культ карго. С чего не стоит начинать внедрение SCRUM

noreply@blogger.com (Alexey Krivitsky) — Mon, 09 Jun 2008 16:21:17 PDT

Автор: Кривицкий Алексей.

Ежедневные SCRUM (или Standup) митинги - одна из практик SCRUM. Многим кажется, что это самая простая практика, и следовательно, с неё, стоит начинать внедрение Agile и SCRUM.

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

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

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

Вот примеры условия, когда Daily SCRUM митинг, внедрённый в команду, может не принести ожидаемого результата:

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

Подобные ситуации можно перечислять ещё долго... Не суть.

Я хочу лишь показать, что без решения корневых проблем (построение общей цели, налаживания безопасной и доверительной среды, устранение пороков команд) Daily SCRUM если и будет полезен, то далеко не на 100%.

Хуже, если после подобных проб команда и её менеджер скажут: "Мы использовали SCRUM и он нам не подошёл". Или ещё что-то в этом роде. Такое к сожалению случается.

Если же вы уже проводите ежедневные митинги, убедитесь в том, что они приносят пользу и что вы не стоите не месте:

Время от времени устраивайте открытые дискуссии на эту тему.

Пытайтесь всей командой понять, когда ваш недавний ежедневный митинг был полезен, чем именно, и как этот успех можно перенести на все подобные митинги. Хорошее групповое упражнение.
Если вы ScrumMaster, время от времени не приходите на Daily SCRUM - если команда видит необходимость в этом митинге - она его проведёт и без вас.

Этот приём я почерпнул от Марка Пушински на тренинге Certified ScrumMaster. Как по мне - отличный инструмент SCRUM мастера.
Экспериментируйте и пересматривайте формат митинга. Иногда переформулирование одного из трёх вопросов ("что я сделал? что я буду делать? что мне мешает?") или добавления нового может помочь вашей команде по-другому взглянуть на митинг.

К примеру вместо вопроса "что я сделал?" можно ввести "что я делал?". Разница на первый взгляд незначительна, но как показывает опыт Асхата Уразбаева такая постановка вопроса открывает дополнительный источник информации.

Удач! И следите за признаками возникновения культов карго в вашей команде.

Unfinished work in sprints

noreply@blogger.com (Alexey Krivitsky) — Sat, 24 May 2008 01:41:11 PDT

Автор: Алексей Кривицкий.

Я когда-то написал об использовании user stories. До сих пор время от времени получаю отзывы и вопросы.

Вот к примеру вопрос, который я слышу довольно часто:
"Что делать с историями, которые не полностью сделаны за итерацию?"

На мой взгляд есть такие варианты:

1. История не полностью сделана, и сделанная часть НЕ несет выгоды для заказчика
= Business value not delivered

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

2. История не полностью сделана, но сделанная часть несёт выгоду для заказчика
= Business value delivered (but partially)

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

3. История сделана, но после найдены дефекты
= Business value delivered (but the quality/level of details is not acceptable)

В этом случае вопрос чаще стоит так - "как трекать баги, найденные после сдачи истории, и что делать с историей - переоткрывать ли или нет"?

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

Обсудить в группе дискуссий Agile Ukraine?

Следующий класс Certified ScrumMaster

noreply@blogger.com (Alexey Krivitsky) — Wed, 21 May 2008 07:51:51 PDT

С апреля 2007 мы регулярно проводим классы сертификации по программе "Certified ScrumMaster".

Два класса было проведено в 2007 году в Киеве. Минимум два класса мы планируем на текущий год. Первый уже был проведён в апреле. Второй планируется на осень.

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

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

CSM class Kyiv, April 2008

noreply@blogger.com (Alexey Krivitsky) — Mon, 09 Jun 2008 17:55:52 PDT

В апреле в Киеве прошёл очередной класс сертификации СкрамМастеров.

16 человек пополнили ряды украинских CSM.

Тренер Марк Пушинский (Mark Pushinsky) провёл класс на очень высоком уровне. Не менее половины времени тренинга было посвящено дискуссиям, симуляциям, упражнениям.

Наш веб-альбом

Видео из классов

Регистрация на следующий класс.