У 66666 дьяволят логины везде одинаковы

Цифры продолжают меня преследовать.

После подсчета общего количества активных пользователей системы, у которых логин и емейл имя строго соответствуют наша БД выдала фееричное число в 66666 пользователей.

Рейс #666

Ничего не предвещало беды. Сидим вечером в офисе и готовим демо заказчику, которое должно было пройти 3 часа назад: как всегда в планируемых фичах начали обнаруживаться всякие блокеры.
И тут ко всему прочему падает билд. Что?! Как?! Оракл?! Где он?!
Вот так вот билд #666 лихо вырубил Оракл на тестовых средах и гордо смотрит на нас сквозь красную иконку "Build Failed"

P.S. Что было с билдом #13 я не знаю

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

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

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