понедельник, 30 августа 2010 г.

Все на 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. Спонсор поста магический пинок от Саши Орлова

четверг, 5 августа 2010 г.

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

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

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

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