Agileee 2010 accomplished!

Два дня Agileee 2010 прошли даже не как один, а даже быстрее. 4 потока, более 30 докладов и даже не знаю какое число участников. По моим ощущениям близкое к 400, но организаторы знают точно.
Началось все для меня в четверг, когда я все-таки решил поехать, и обнаружил для себя, что регистрация была закрыта. Да уж люблю я легкие пути :) Но где наша не пропадала. Я там побывал и не жалею.

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

Beyond Agile

View more presentations from Andrea Provaglio.

Она не техническая. Не касается ни методологий разработки, ни практик работы с Agile. Автор говорит о том, что важная составляющая Agile это команда, и Agile manifesto говорит нам "Individuals and interactions over processes and tools", но мы продалжаем говорить о процессах и инструментах, и на практике часто забываем о команде.
Следующее выступление я не буду коментировать. Скажу только, что автор Mary Poppendieck, вставлю тут анонс к выступлению и продолжу. Это надо просто просмотреть и подождать видео выступления.

"There is nothing so useless as doing efficiently that which should not be done at all." ~ Peter Drucker
If you look at the history of software failures, the vast majority can be attributed not to technical mistakes, but mistakes in understanding what should be built, what customers will buy, what the system needs to do in order to be successful. The bottom line is this - if we don't build the right thing, we may as not build anything at all. Because customers don't want software - they want a problem solved. And if they could get that problem solved without software - they would be delighted.

Mary Poppendieck “It’s Not About Software”

View more presentations from Agileee.

Еще принимал участие в игровом тренинге François Bachmann "The Art of the Retrospective".  Отметил про себя и для себя варианты визуального представления информации о проекте от Anda Abramovici “Making Feedback Visible” (ничего очень нового и революционного сказано не было, но при должном уровне абстракции восприятия, можно взять на вооружение). Послушал J.B. Rainsenberg'a и мне кажется, что меня скорее впечатлила его манера рассказывать, формат подачи материала и устройство рисования к iPad (или у него просто планшетник и Paint). Т.е. да он прямо по ходу рисовал свои слайды, как будто-бы рассказывал всей аудитории на бумажке как необходимо правильно писать интеграционные тесты. И не могу не отметить ребят из Англии, которые в конце представили свой подход к пониманию и использованию Agile-практик в виде небольшого театрализованного представления

Все на Agileee 2010!

8-9 октября в Киеве пройдет Agileee2010. Для тех кто не знает и еще не перешел по ссылке, чтобы узнать - это самая крупная в Восточной Европе конференция для приверженцев Agile, а также сочувствующих, приглашенных, неопределившихся и противников. Если вы не попадаете в это множество, то это не значит, что сюда вам ход заказан :) Заходите.

Для затравочки вставлю ролик

Agileee is calling you! from Agile Eastern Europe on Vimeo.

 и дам просто ссылки на видеоролики с ключевыми спикерами

1. Мери Поппендик
2. Хенриком Книбергом
3. Робином Даймондом
4. Сергеем Дмитриевым
5. J.B.

Детали по регистрации можете прочитать на сайте или по ссылке.
Если не решили, то идите.

P.S. Спонсор поста магический пинок от Саши Орлова

Итеративный подход 2

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

• есть такое понятие "окно срочности". Я слышал о таком и раньше из психологии. Но понятно для менеджеров описано у Орлова на его happy-pm.ru. Cуть: человек начинает работать над чем-то усерднее и ставит приоритеты выше, если это что-то попадает в это самое окно.
• процесс по которому сейчас работает команда похож на то, что можно назвать Event Driven Development. Релиз обычно раз в месяц, но может и полтора. Т.е. 5-6-7 недель. Но это не правило, а скорее статистическое среднее. Такие итерации обусловлены это тем, что система уже оченьбольшая. Очень-очень большая. Каждая докручиваемая фича как дополнительный отсек на авианосце, котрый надо встроить по всей вертикали. И чтобы сынтегрировать такое необходимо немалое количество времени. Вот и получается что зависим не от сроков, а от объемов, а сроки большие. Изредка ряд мелких изменений может занимать и пару недель. Но окно срочности у людей обычно горааздо меньше месяца-полутора. Неделя в лучшем слуае. И само собой сложностей по ходу возникает много
• малыми итерациями, которые все советуют при использовании scrum мы позволяем команде работать в одном ритме и находится в постоянном тонусе. Естесственно, если все расчитано правильно и мы делаем работу, а не совершаем подвиги каждую итерацию.

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

Жду пока мы это внедрим в ближайшем будущем и на опыте будет видно. Потом отдельно напишу

"Все мое, мое!"

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

Мотивация собственников и эгоистов.
Необходимо заставить человека думать, что работа, которую он делает относится непосредственно к нему, это его.
Например, не сказать человеку что необходимо сделать, а объяснить что хочется получить (не конечный ожидаемый результат, а цель), зачем это необходимо и какие могут быть последствия. А главное делегировать ему ответственность за то, что он будет делать. И это не означает только обязанности, но и права и полномочия, т.е. всю полноту власти, необходимую для выполнения порученной работы. Естественно, только в том случае, если мы уверены, что человек сможет этим воспользоваться ;)
По-моему это нормально и очевидно. Важно сделать это не со словами "не мог бы ты" или "я тебя попросил бы". А "я отдам тебе", "твоя часть .... это нужно затем-то и потому-то". Это будет его(ее).

Реальность субоптимизации

Помнится мне что-то такое еще с университетских времен. А тут посмотрел и понял конкретное применение в управлении проектами и командами в ИТ. И это точно надо "заложить" себе и тому кто прочтет.

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

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

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

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

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

Гармония важна в любом аспекте жизни. :)