К основному контенту

Пост-релиз конференции Agile Base Camp: Киев

Автор:  Александр Белецкий.

16 Апреля 2011 года, прошла очередная встреча AgileBaseCamp, на которой мне посчастливилось побывать. Место было выбрано очень удачно, это база Пуща-Озерная, за Киевом, с красивейшими пейзажами и чистым воздухом. Время, также было не случайным - встреча посвящалась 10-летию подписания Agile Manifesto.

Все доклады были разделены на 4-ре потока Process, People, Practice, Mix (наверное многие "аджалисты" были возмущенны увидев Process в программе конференции, но я списываю это на тонкий юмор организаторов). Каждый участник мог выбрать поток, который наиболее близок к его интересам. В силу своих интересов, я больше присутвовал на докладах класса Practice & Mix.

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

Далее следовали интересные технические доклады, которые я с удовольствием полуслушал, а некоторые их них, законспектировал.

Меня не может ни радовать тот факт, что конференции посвященные Agile, перестали быть похожими на де-жа-вю с постоянно повторяющимися словами, типа "backlog, burn-down chart, sprint etc.", а включают в себя и более практические детали, как TDD, software design, best practices. Ведь многие, действительно, стали забывать, что разработке софта, сама разработка все еще играет ключевую роль.

Необычным для меня были 2 вещи - Lightning Talks & Open space.

Lightning Talks, короткие доклады, на различную тематику. Жалею, что опоздал на начало и пропустил речь Макса Ищенко.. судю по овациям она была интересной. Идея очень хороша, не дает докладчику стопорится на мелких и не важных деталях, а слушателю не уснуть от скуки). Перессказ "молниеносного" доклада Леши Кривицкого доступен в текстовом варианте: My Top Scrum WTFs. Другие доклады - в виде слайдов на сайте конференции.

Open space дает слушателям, возможность поговорить. Проблема с open space только одна - очень хочется клонироватся и присутсвовать сразу на 2-х или на 3-х встречах.

В завершении мероприятия, были розыграны призы, в виде футболок и скидок на Agile Eastern Europe 2011. Так что некоторые счастливчики ушли не с пустыми руками).

В целом, хотелось бы отметить высоту организации. Спасибо большое всем организаторам, докладчикам за интересный ивент!

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Ретроспектива спринта - эффективный формат

Автор: Майк Кон (Mike Cohn) Перевод с английского Неважно, насколько опытной является Скрам-команда, при этом всегда существует возможность для ее улучшения. Не смотря на то, что хорошая Скрам-команда будет постоянно искать возможности для своего улучшения, она должна выделять короткий период времени в конце каждого спринта для сознательного размышления над тем, как идут их дела, и для поиска способов их улучшения. Все это происходит во время Ретроспективы спринта.

Аджайл Менеджер Проектов – кто это?

Автор: Карлтон Неттлетон (Carlton Nettleton) Переведено с английского проектом Agile Translations . Несколько недель назад я получил сообщение от своего бывшего ученика с печальными новостями – его компания уволила всех Скрам-мастеров и заменила их на “Аджайл Менеджеров Проектов”. Теперь он остался без работы, а Cкрам потерпел серьезную неудачу в их организации. Это было довольно грустно :(

Какие проекты лучше всего подходят для применения Agile

Автор: Майк Кон (Mike Cohn) Переведено с английского проектом Agile Translations . Недавно меня спросили, для какого вида проектов больше всего подходит применение гибкого подхода разработки, и сейчас я хотел бы об этом поговорить. Мне кажется, самыми подходящими для использования гибких методик являются проекты с агрессивными сроками выполнения, высокой степенью сложности и так же высоким уровнем инновации (уникальности). Мы хотим использовать Agile, когда делаем что-то новое, по крайней мере, новое для конкретной команды разработки. Если команда делает то, что она уже делала не один раз, она, вероятно, не нуждается в гибком подходе. На мой взгляд, здесь было бы уместным привести аналогию с промышленным производством. День за днем, собирая один и тот же тип автомобиля, мы довольно быстро учимся всем нюансам сборки этой модели. Здесь нам не нужны гибкие подходы, потому что степень новшества данного процесса является довольно низкой. Однако, инновация сама по себе не означает, что