Остался ровно месяц до четвёртой ежегодной конференции Agile Eastern Europe 2012! В этом году 6-7 октября конференция снова соберет сторонников и практиков Agile с Восточной Европы. За последние несколько лет ее посетило более 1100 человек из 32 стран мира, которые каждый год имели возможность посетить 4 потока докладов с 93 докладчиками за все время! В этом году Вас ожидает 2 дня докладов, 3 дня мастер-классов, более 30 выступлений и тренингов в рамках конференции.
Ключевыми событиями конфренции в течение двух дней будут четыре потрясающих доклада:
Автор “заметок с передовой” о Scrum и XP книги представит Вам практические уроки о трансформации enterprise-scale Lean и Agile, изложенные в его книге “Lean from the Trenches”.
Хендрик Книберг (Henrik Kniberg) бросает вызов вашим достижениям! Он презентует основные уроки, вынесенные им при трансформировании Lean и Agile, основываясь на материалах его книги “Lean from the Trenches”.
Создатели The Agile Coaching Institute поделятся с Вами богатым опытом командного коучинга в своей дискуссии, которая вовлечёт в диалог всех присутствующих.
The Dude возвращается! Дэвид Хассман, всемирно известный Agile консультант, исполнит перед аудиторией настоящее представление. Сомневаетесь? Вы не обязаны в это верить. Просто прийдите и убедитесь в этом лично!
Выдающийся оратор, инвестор и преподаватель разожжёт в Вас предпринимательскую искру.
Впервые на AGILEEE 2012 русскоговорящие экперты и практики. Они готовы и хотят поделиться своим опытом, раскрыть вам свои идеи и рассказать об успехах. Среди них уже известные Вам:
С более детальной информацией о программе конференции Вы можете ознамкомится на сайте AGILEEE 2012.
Как вы видите, в списке есть и мое имя. 🙂 Я буду выступать с докладом “Эволюция Agile или погоня за идеальным процессом”. Agile подходы уже достаточно плотно вошли в жизнь многих компаний в качестве основного направления в управлении проектами. Большинство взяло за основу Scrum по причине простоты и широкого распространения этой методологии. И действительно, из хаоса, в котором пребывали многие проекты, легче всего переходить к адекватному процессу через Scrum. Scrum внешне прост и понятен, о нем много говорят и пишут, хватает тренингов и специалистов в этой области.
Но вот проходит полгода, год, два и ваша команда начинает замечать, что в уже устоявшемся процессе некоторые практики из Scrum перестают приносить свою пользу. Команда уже достаточно долго работает вместе и от хаоса не осталось и следа. Вы начинаете замечать, что команда переросла Scrum. Не переживайте, это совершенно нормально!
Но куда двигаться дальше? Agile подходы тоже не стоят на месте и эволюционируют. Появляются новые методологии и практики. Может быть отказаться от итераций? Kanban? Может быть изменить процесс разработки и поставки новых фичей? Continous Delivery? Может быть больше внимания уделить инженерной части? XP?
В докладе мы поговорим о том, как и почему стоит развивать свой Agile процесс, когда стоит начинать эволюционировать и как не потеряться на этом пути. Ну и конечно же, мы затронем тему идеального Agile процесса и каким он может быть. Приходите, будет интересно!
Традиционно перед AGILEEE каждый сможет пройти один из сертификационных курсов и мастер-классов. 3-4 октября Вы сможете посетить:
5 октября пройдет тренинг Introduction to Advanced Agile с Алистером Коуберном.
Спешите приобрести билеты по самым выгодным ценам заранее. До 10 сентября билеты можно будет приобрести за 399 USD (3232 UAH), а после 10 сентября – за 499 USD (4041 UAH).
Кроме того, действуют скидки для групп:
Нашему “Клубу анонимных разработчиков” обещана скидка 15%!!! Если Вы являетесь членом клуба и хотите сэкономить, обращайтесь!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
В эти выходные прошло одно из самых больших IT мероприятий Украины – IT-Jam. В Киев приехали IT-шники из всех уголков Украины. И собралось их действительно великое множество. 🙂 В этом году организаторы решили попробовать новый формат проведения – community spots, где были представлены все IT сообщества Украины.
Как мы уже сообщали, “Клуб анонимных разработчиков” также был представлен своим спотом, на котором мы рассказывали о клубе, собирали новые идеи для встреч, искали докладчиков и даже разыгрывали призы. В самом конце я решил выступить с мини-докладом, посвященным современным подходам к хранению данных. Доклад нашел свою аудиторию и вылился в почти часовое обсуждение. 🙂
Очень приятно было встретить столько знакомых лиц на IT-Jam. К нам на спот приходили участники встреч клуба, докладчики и просто знакомые. Формат был несколько своеобразный, но главное чтобы людям нравилось. Что получилось в итоге:
В ближайшее время мы планируем провести встречи по следующим темам:
Если вы хотите стать докладчиком по одной из перечисленных тем, предложить свою тему, дать нам советы по деятельности клуба или подписаться на анонсы встреч, заполните форму идей и мы обязательно свяжемся с вами.
В завершение, небольшой фотоотчет от нашего спота:
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Прочитал статью Тима Евграшина “Когда подстилать соломку или планирование Спринта с учетом вашей реальности” и понял, что в этом вопросе наши мнения и опыт сильно расходятся. 🙂 Мои комментарии были слишком большими и я решил вынести их в отдельную статью.
Разделение элементов бэклога по типам и комбинирование их в спринте – это классная техника, которую я всем советую попробовать. Это помогает визуализировать бэклог и на ранней стадии увидеть перекосы, не позволяя разрастись технической задолженности или списку дефектов. Визуализация – наше все в Agile подходах!
А вот по поводу буферов я категорически не согласен. На мой взгляд, данная техника является чуть ли не самой опасной. Во-первых, это попытка не учиться на своих ошибках, а обложиться буферами, чтобы минимизировать их влияние. Вспомните как раньше делали оценки – менеджер закладывал буфер в магические X% от оценки команды, чтобы “обезопасить себя от этих имбицилов”. Мы же в Scrum пытаемся научиться давать надежные оценки на короткий срок. Спрятавшись за буферами, трудно будет найти свои ошибки и их исправить. Для этого понадобится анализ использования буфера, что приведет к дополнительной работе над сбором и анализом метрик.
Во-вторых, буфер на исправление ошибок в спринте – одна из самых нелогичных вещей в IT. Вводя такой буфер, мы как бы говорим: “Мы заранее знаем, что напишем код с багами!”. А как же критерий готовности, забота о качестве (quality assurance), инженерные практики и надежная поставка? Неужели кто-то может оценить с такой позиции сколько займет фикс багов для задач в спринте? Это же оценки пальцев в небо! Нельзя оценить то, объем чего тебе неизвестен. Зато можно попытаться оценить усилия на предотвращение багов и включить их в изначальную оценку задачи. Ведь на планировании мы все задачи разобрали в деталях и знаем о них все!
Еще любой буфер приводит к усилению действия закона Паркинсона, который гласит: «Работа заполняет время, отпущенное на неё». Так как в спринте использование буфера размазывается по всей итерации (ведь баги же постепенно появляются), то буфер будет использован целиком в любом случае. Даже если багов не будет, его найдут чем заполнить, причем явно не дополнительными задачами из бэклога.
Буфер на выплату технического долга также противоречит идее “разноцветному бэклогу”. Для выплаты технического долга должны создаваться такие же задачи на спринт как и для других элементов бэклога. И их тоже нужно оценивать. Фиксированный буфер приведет к тому, что работа может быть недоделана либо занята часть времени из основного времени спринта. Ни один из этих исходов не является позитивным.
Последний тип буфера (у Тима он упоминается первым) – время на погрешность в оценках. У него практически те же минусы, что у предыдущих буферов, но существует подход, который действительно может обезопасить вас от неверных оценок безвредно. Просто выбросите последний день итерации из доступного времени, введя правило “никакой работы над задачами в последний день итерации”. Если в итерации что-то пошло не так, то это критическая ситуация и данный день послужит буфером. Но это нарушение правила команды и ставит вопрос на ретроспективу для обсуждения. Если же все нормально, то в этот день можно будет качественно подготовить демо, закрыть мелкие дефекты по задачам в итерации, отдать часть технического долга или даже начать работать над новыми задачами из бэклога.
Еще один способ обезопасить себя с оценками – “принцип 80 на 20”. Но применять его стоит только если вы уж так неточно делаете оценки и хотите выделить несколько спринтов на адаптацию. Для этого на митинге по планированию выделите 80% задач, для которых вы на 100% уверены в готовности к концу спринта. Оставшиеся 20% задач будут вашим буфером на случай неудачного стечения обстоятельств. Но тем буфером, о котором будет знать заказчик и который вы сможете обсудить на ретроспективе.
А вообще, Agile подходы несут в себе прозрачность, предсказуемость и постоянный самоанализ в качестве основных ценностей. Любой буфер идет в разрез с этими принципами и пытается “замазать” проблемы и скрыть их. Поэтому будьте осторожны и не используйте их в своей работе!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
