Krivitsky on Agile

Interviewed by Bill Wake

noreply@blogger.com (Alexey Krivitsky) — Sun, 13 Dec 2009 06:11:47 PST

Некоторое время назад на Agile Coach Camp 2008 у меня брал интервью Bill Wake.

Его теперь можно почитать здесь (на английском).

Scrum is ... или Карта мозга Скрам коуча

noreply@blogger.com (Alexey Krivitsky) — Sat, 12 Dec 2009 15:04:56 PST

С чего все началось

В течение последней недели в группе дискуссий AgileUkraine активность била тема, посвященная такому весьма философскому вопросу как:

Чем является Скрам - инструментом или чем-то большим?

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

Обсуждение началось с поста статьи Тобайаса Мейера (Скрам-тренера, фасилитатора и анархиста) под названием The People's Scrum, где автор утверждает, что он не согласен с теми, кто ставит Скрам на равне с такими инструментами как Канбан. И что (дословно):

To reduce it to “a tool” is to completely miss its magic, and to bring us back into a world of best practices and repeatable process.

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

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

Поясню.

Что я понимаю под Скрам

Когда я начал в рассылке объяснять, что понимаю под Скрам, я в порыве перечислил такие вещи как:

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

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

Это меня встревожило. И заинтересовало.

"Что же я - человек, который читает тренинги, лекции и ведет активную пропаганду, - понимаю на самом делел под Скрам?"

Выплеск подсознательного

Я проделал небольшую домашнюю работу, составив ассоциативную карту (mind-map) того, что я вкладываю в понятие "Скрам". И вот что вышло:

Что это значит?

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

совокупность ценностей (таких как Working Software, Ongoing Improvements и т.д.)
принципы (Face-to-face Collaboration, Frequent Deliveries, Motivated Individuals и т.д.)
разнородные хорошие практики гибкой разработки (Sustainable Pace, User Stories, Planning Poker, Pairing, Personas и т.д.)
в совокупности с правилами самого каркаса Скрам (Sprint Planning Meeting, Product Backlog, ScrumMaster и т.д.)
плюс целый ряд аспектов командности и прислужливого лидерства (Shared Vision, Early Wins, Facilitation и т.д.)
плюс личный опыт (Testers Drive Planning, Not Just a Demo, Personal Coaching, и проч.)

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

Что из этого следует?

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

Мне же лично все это кажется позитивным положением дел.

My take-away points from ITJam

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Вчера на ITJam на втором из наших докладов мы просили всех подумать над вопросом:

"Какие две вещи вы для себя вынесли с конференции?".

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

У же меня, похоже, "вынеслось" больше, чем две вещи.

Они не связаны с содержанием конференции, скорее со внутренними ощущениями атмосферы и собственными переживаниям-пережёвываниями.

Вещь №1: Конференция должна быть платной

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

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

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

Вещь №2: Цензура в твиттере - не такая уж и плохая идея

Шутка конечно. Но культура "украинских масс" оставляет желать лучшего. И твит-деск джема тому яркое подтверждение. Айтишники - это не интеллигенция, это рабочий класс. Это грубое обобщение. Но когда вы проводите массовые мероприятия - вам нужно ориентироваться на массы.

Недавно читал, что на какой-то конференции, по-моему это был Agile Benelux, ребята завели доску для оффлайновых "твиттов". Говорят, работало хорошо. Верю, что сообщений типа "джем - @#$%" в этом случае было бы намного меньше, чем вчера.

Вещь №3: Вы всегда можете рассказывать базовые вещи и быть на высоте

Популярность Тимофея Евграшина и его доклада, где Тим объяснял основы и базовые понятия Скрама - яркое подтверждение того, что всегда найдется аудитория, готовая послушать о чем-то базовом. И это ведь здорово!

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

Вещь №4: Технические проблемы могут угробить 10 дней работы

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

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

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

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

Вещь №5: На конференциях всегда есть с кем поговорить о важном

Вчера я встретил и качественно пообщался как минимум с десятком прекрасных человек. За это время я узнал кучу всего ценного и важного. И это всецело сгладило воспоминания и микро-проблемы, которые всплыли во время наших выступлениях. Спасибо вам!

До скорых конференций от AgileUkraine и SCRUMguides. Ждите ближайшую конференцию по Agile уже в январе.

Заводные апельсины нынче не в моде

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Или как управлять своим вниманием во время работы.

У вас бывает такое чувство, что вы делаете одновременно десяток дел?

Пару дней назад, будучи рассерженным на свое расфокусированное внимание во время работы, я спросил в твиттере, один ли я такой или ещё есть пара человек во Вселенной, которым тяжело удерживать внимание на одном деле?

Среди ответов (ура, я такой не один!) был ответ от Deborah Hartmann - известной в узких кругах Agile коучей и фасилитаторов. Ответ был прост: "pomodoro? :-)".

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

"Вот же оно. Помодоро!"

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

Agile Alliance Board

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Luke Hohmann мне предложил стать членом Agile Alliance Board - советом, который в рамках Agile Alliance реализует стратегию распространения Agile движения, его стабилизацию, собирает отзывы рынка, улучшает внутренние процедуры и материалы. Работа бесплатная.

Пришлось задуматься. Готов ли я уделить этому важному делу свое время? Есть ли мне чем поделиться с миром? Готов ли я стать членом супер команды?

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

На agile2009 станет известно отобрали ли меня...

My name is Alexey Krivitsky.

I am from the new generation of developers. Started to love coding at the age of 15. In 2003 got a master degree in CS. Since 1999 I had worked as a Delphi/VB/Java/.NET developer, then a team lead, then a ScrumMaster, now as an independent Agile coach.

One long cold winter evening of 2007 I started the Agile Ukraine user group which now consists of more than 500 members. Since we had started, we managed to run a dozen of local conferences (Agile Gatherings) and Agile clubs.

Currently my focus lies in the start-up IT market that is being emerged in Ukraine and calls to be facilitated in terms of establishing transparent and lightweight processes and effective and open people collaboration. The current year of 2009 is going to be the hit in terms of Agile expansion in Ukraine and the overall Eastern Europe that we're trying to make by giving birth to the first Agile Eastern Europe (agileee.org) conference to be held in my homelands in September.

I see two directions of my application in the Board.

Firstly, the mission of the Agile Alliance which is I believe to spread and support Agility in the World has a lot of common to what we have been doing so far in my region. Here where I am from, Agility is steps behind the US and other developed markets. Here it needs to be seeded and grown. It needs to get some sun, shadow and water. There are mosaic of regions in the World which do their own relatively small (but locally huge) effort in terms of evangelizing Agility. I believe those communities are to be supported and connected altogether to produce a stronger large ecosystem. We need to set up conditions where Agility can grow and naturally evolve, changing people daily habits and spreading out the new way of building products.

Secondly, during my daily work as a coach and evangelist I meet many people that have no idea what Agile means and what other ways of work are rather than commanding and controlling. My latest work proves that commanding and controlling is the root cause of waterfall thinking, cubic corporate cultures, functional teams and other indicators of inefficiency. Such unawareness is killing funds, good initiatives, relationship and natural human motivation. This is happening now, at the moment of writing. And there are a LOT to do in this regard.

As a member of the Board I am eager to share my knowledge, skills and vision for the sake of the new awareness Agile can bring to people work and lives.

Agile Labs

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Отчёт о конференции

Agile Labs, Moscow

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Собираюсь выступить на http://agile-labs.ru/.

Расскажу про

то, как решить проектные челенджи с Agile
проведу часовую Скрам симуляцию с Lego

My submissions for Agile2009

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Наконец-то дошли руки опубликовать две сессии для конференции Agile2009:

Осталось, чтоб их теперь отобрали :)

Repeatable vs effective

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Вчера, провёв отличный весёлый вечер с двумя CTO харьковских IT компаний, мы горячо обсуждали evolutionary design vs. design upfront.

Или по-русски: что лучше:

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

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

Тема стара как мир (новый IT мир, я имею в виду).

В итоге дискуссия свелась к теме повторяемости результата.

Поясню позицию моих коллег. Если я CEO большой компании, то мне естественно хотеть повторяемости результатов успешных проектов.

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

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

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

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

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

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

Это моё IMHO на сегодняший день, 7 ноября 2008 года.

Читать обсуждения этой темы в группе AgileUkraine

Неделя коучинга или море общения и креативности

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Вот практически и завершилась неделя коучинга в Харькове.

Диалог на выходе из комнаты, где работает команда:
- Они это сделали!
- Кто они?
- Конечно же команда!

Фотоальбом

Что же мы успели:

обсудить концепции Agile и Scrum;
сойтись на главных плюсах, которые этому проекту может дать гибкая разработка;
посимулировать анти-командность на примере "фабрики" по производству бумажных самолётиков конвейерным способом (push/pull системы);
поиграть в симуляцию Scrum
(ребята проявили недюжую креативность, создав настольную игру и за 2 итерации удовлетворив своего PO);
поиграть в игру ball points (которую я увидел впервые на прошлом CSM у Робина Даймонда) - цель игры дать возможность команде улучшить свой процесс; оказывается всего 3 минуты коллективного общения команда может улучшить свою эффективность почти вдвое; и предела этому нет (Kaizen mind);
научиться писать user stories;

Но это не всё!

ребята оговорили и описали product vision (теперь, это лист формата A2, который висит на стене и напоминает цели проекта, основные фичи, конкурентов, риски);
ребята помогли своему PO сгенерировать беклог историй (который оказался полнее и лучше структурированным, чем изначальный беклог, подготовленный РО);
оценить беклог, уловив прелесть от использования planning poker;
сойтись на критерии done" для своего проекта;
выполнить планирование первого спринта.

Демо - не за горами. Но надежд много!

Увидимся.
Харьков, 1:42 am, уже пятница! :)

Смелость vs. профессионализм

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

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

Я не на столько смел. Я использую Agile, который предоставляет мне контейнер для понижения проектной сложности - итерации фиксированной длины и фиксированного объема работ. Это даёт мне уверенность на ежедневном уровне.

"И главное - сухо!"

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

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

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

Смелость - отсутствие профессионализма.

Impossible is nothing или конференции, конференции, конференции

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

В этом году посетил 3 крутейших ивента по agile, не считая тех, которые организовал сам (гы!):

Agile Coach Camp, Мичиган
Agile 2008, Торонто
Scrum Gathering 2008, Стокгольм

Если бы мне кто-то сказал в начале года , что это случится, я бы не поверил. Удалось увидеть воочию пять подписчиков Agile Manifesto. Отличные ребята! :) C тремя (Ron Jeffries, Brian Marick, Ken Schwaber) познакомился лично, пропиарил Agile Ukraine (как полагается).

Это всё произошло благодаря другу из Индии Naresh Jain, которого я пригласил в Украину в апреле для участия в конференции Agile Gathering IV и проведением классов по XP.

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

Лучший вариант, однако, попасть туда бесплатно - это провести сессию (доклад, воркшоп, прочее). Что ж, будем работать и над этим. Всё постепенно. Стоит увидеть доклады как зритель перед тем, как решаться выступать.

Думал поехать на QCon в Сан Франциско и посмотреть на Кента Бека и Мартина Фаулера. Но решил отложить. Зато пристроил друга в волонтёры. Крутизна.

Хотелось бы в следующем году привезти на Agile 2009 (Чикаго!) с собой группку из Agile Ukraine. Буду над этим работать!

Agile Gathering 5

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Планирую очередную конференцию по Agile: Agile Gathering 5.

Уже зарегистрировалось более 60 человек. Отлично!

Похоже, но не agile

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Вспоминал недавно один из своих первых проектов:
- Маленькая команда - два человека
- Локальные заказчики доступные практически в любое время
- Последняя стабильная версия всегда у них под рукой
- Регулярные демонстрации достижений последней недели или двух
- Открытое обсуждение новых фич, быстрая смена курса

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

Попробую понять в чем же дело:

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

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

2. Несмотря на короткие циклы разработки (от недели до двух) в проекте не было четкой стратегии и планов ближайшего релиза. Все двигалось в бесконечном маятнике от демонстрации к демонстрации.

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

3. В течение 10 месяцев разработки проект часто демонстрировался спонсорам проекта для обсуждения состояние проекта, качества, выяснение и открытия скрытых требований. За это время проект ни разу не был показан потенциальным пользователям.

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

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

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

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

Не торопитесь делать скоропостижные выводы.

Об agile по-русски: User Stories, часть 1

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Это одна из статей серии «Про agile по-русски» , идея которых поделиться опытом использования agile принципов в разработке программного обеспечения. Основная суть этих подходов – кооперация между всеми членами проекта и адаптивность процесса разработки к неизбежным изменениям. Также эти подходы выделяются тем, что принимают человеческий фактор в проекте как неотъемлемую его часть и более того – как наиважнейшую причину прогресса, акцентируя важность поддержания человеческих отношений и человеческих особенностей для успеха проекта.

Эта статья рассказывает о применении «user stories» («пользовательские истории» в переводе на русский) - одной из практик agile...

Полный текст статьи тут.

что составляет грунт для agile проектов? попытки анализа

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Обсуждая с коллегами по agile движению, что означает для программистов "agile" (сообщения дискуссии доступны здесь), я пришёл для себя к следующим выводам:

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

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

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

Если же хорошие отношения не гарантируют наличие agile среды, то должно быть значит что-то ещё, что выделяет эти проекты из ряда других. Я делаю предположение, что это -

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

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

----
Таковы мои мысли на сей счет на сегодняшний день.
Есть другие мысли? идеи? комментарии? - давайте общаться.

Велик и могуч...

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Из серии «Об agile по-русски».

Велик и могуч... термин «agile».

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

Но начнем пока с «начала».

"Начало начал". Притча.

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

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

Таким образом ситуация пошла против природной нестабильности требований к ПО.

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

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

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

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

Прошло 20 лет, технологии усложнились на порядки; толерантность к стабильности требований уменьшилась и стала измеряться неделями; глобализация 21-го века заставила команды стать распеделенными... Эти и прочие факторы повлияли на увеличение популярности подходов, которые в противовес контрактам, спецификациям, долгосрочному планированию, сложным метрикам оценки качества и прогресса ставили во главу угла кооперацию, профессионализм, доверие к людям и конечный результат труда - сам программный продукт.

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

В поисках крепкого словца...

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

Если попробовать охарактеризовать разные стороны этих подходов, то выйдет нечто следующее:

«Облегченность» (или «Легковесность»)

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

«Гибкость»

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

«Адаптивность»

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

«Прозрачность»

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

«Проворность»

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

«Осмысленные»

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

Итого

«Облегченногибкие адаптивнопроворные прозрачныеосмысленные методологии разработки программного обеспечения»...

Похоже тяжело найти подходящий термин в русском языке (я не говорю, что это невозможно), который бы передал все ценности и значения, вкладываемые в слово «agile» в контексте подходов к разработке ПО.

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

Вы хотите помочь команде, которая тонет в бюрократии и бумагообороте, не сдвигаясь с места в разработке ПО? Попробуйте объяснить преимущества agile-подхода, базируясь на аспекте «облегченности».

Вам жалуются на то, что команда отклоняет изменения в требованиях, ссылаясь на контракт и указывая на утвержденную процедуру change request management, из-за чего разрабатываемых продукт не будет максимально полезен заказчикам и пользователям? Поговорите с ними об аспекте «гибкости».

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

У заказчиков проблемы с пониманием прогресса проекта - команда говорит, что разрабатывает какой-то «каркас» и сможет перейти к запрошенной функциональности только к концу квартала? Проворность подхода, пожалуй убедит заказчиков попробовать что-то другое.

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

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

P.S.

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

agile planning (planning over plans)

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

i had experience using deterministic old-school approached (like MS
Project's Gantt charts), which i was keeping in my tool set for quite
a long time,

i did task decomposition, resource assignment and leveling,
milestone definition...

this all was quite useful while i was doing that because it made me think
of the project risks, complex dependencies, the team's capabilities
and other topics important for project success.

but as soon as i published my plans and tried to stick to them - they
quickly became obsolete and useless. it appeared i just couldn't predict everything and eventually the projects went a bit different direction.

......

since i've been doing agile i don't have this problem anymore.
why? simply because i never stop planning.

i highly recommend Mike Cohn's masterpiece Agile Estimations and Planning this book is not about plans, rather it is about planning once you start using user stories as your main requirements media, you will gain even more flexibility in planning and hence obtain more control over the project. planning will become a solid practice being done by the whole team during the coarse of the project. also the user stories will foster idea sharing between product managers and engineers, will provoke creative and positive thinking

......

visit the discussion thread

Scrum trainings and other events in 2007

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

This is to announce, that I am currently working on a plan of trainings and various other common activities on agile topics, to be held in Kiev in 2007.

The main goal is to organize CSM (Certified ScrumMaster) certifications in Kyiv (Kiev).

Watch for the upcoming announcements at the agile-ukraine
(subscribe for the mailing list if you're not a member yet).

Currently I am conducting a survey (5 shortquestions) to find out the possible number of attendees, their level of familiarity to Scrum/agile concepts.
Your answers to the survey will help me a lot.

Have good ideas on the subject? Contact me directly by e-mail.

agile-ukraine community was started

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Congrats!

Agile-Ukraine community is registered at Agile Alliance.
Visit the home page.

For now it is a Google group with forum and file sharing.

We plan to invite World agile gurus and help them organize trainings in Ukraine.

Stay with us.

Rethinking Sprint Length

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Again I've proven my previous experience: two-week sprints are just good enough.
Just because

the next demo is always soon: simply it is this or the next week - no time to be wasted
the story set selected for the sprint is never too long and - can be kept comprehensible
the demos held often enough keeping - the stakeholders are interested and willing to spent 1-2 hours each second week
ScrumMaster is stressed enough to become a better ScrumMaster :)

More on this is in the article published in Agile Magazine's Fall issue, four months ago: link.

The whole issue in PDF can be downloaded from here.

we produce both: code and knowledge

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

Being a product owner recently I had a discussion with one of the key developers in my team: I reported back an issue (as a user story) and he claims that previously we had agreed on a different solution and now I am changing my mind, and these changes will take quite a big effort.

I understand his concerns, developers don't like to re-work. Who likes?
But my reply is that the time spent on this curve is not wasted, rather it is spent on producing the knowledge.

We produce both: code and knowledge, and this is what software is.

The waste is when no knowledge, no code or no other useful artifacts are produced, otherwise it is investment.

Catalog of Scrum smells

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

User Stories for scrumsmells.com project

Users

SP - Scrum practitioner
Admin - Site administrator

Backlog

MUST

As an SP, I can see an intro to understand why this site is useful
As an SP, I can view the list of smells
As an SP, I can select a particular smell and see its details
As an SP, I can add a new smell
As an SP, I can get a permanent link to a particular smell to share it with other people

SHOULD

As an SP, I can see the area(s) that the smell related, e.g. "Meetings", "Spring Planning", etc
As an SP, I can see smells grouped by areas
As an SP, I can see links related to a smell that I am watching

COULD

As an Admin, I get notified when a user posts a new smell
As an SP, I can provide more links to an existing smell
As an Admin, I get notified when a user adds new a link to a smell

Links

Published scrum smells on the web:

Scrum gathering in Kiev 2007.

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST

The 1st Scrum gathering in Kiev is to be held at the office of Ciklum in January-March
(the exact date is to be defined)

The agenda should be defined as we get results from the survey of the attendees.
The preliminary agenda is

Scrum start-up

why Scrum ? introduce Scrum for people who are new to it, define benefits why for team, why for customers
how to start Scrum? provide patterns of starting the 1st sprint
why Scrum is difficult? provide a set of examples to let better understand why it is not that easy to do Scrum
Scrum and requirements management provide different patterns including the approach with user-stories
case study: play a Scrum project
... to be extended

Scrum complex topics:

effective planning meetings
effective Scrum retrospectives
...to be extended

contactform

noreply@blogger.com (Alexey Krivitsky) — Sun, 06 Dec 2009 14:03:48 PST