Все на 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, мартышки, папугаи, -- но одинаковые в числителе и знаминателе. Если выш процесс более специфический, то просто исходите из классики:

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

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

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

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

Как мотивировать наших людей

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

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