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

agile newsletter 4

Agile newsletter: новости, материалы

Выпуск 4,
9 июля 2007 (архив новостей)

Agile в Украине

19 июня состоялась вторая встреча украинского
agile сообщества т.н. "Agile Gathering". Отчет можно найти здесь. Следующая встреча планируется на октябрь. Мы ждем желающих выступить с презентациями. Также спонсоров.

21-22 июня Майк Виздос (
Michael Vizdos) при поддержке Agile Ukraine провел Certified ScrumMaster класс - первый трейнинг в Украине. Отчет и материалы вы можете найти здесь. Будущие классы в процессе планирования на 2007 год. Пишите нам, если желаете посетить.

Общие материалы по
Agile

Видео лекции
Alistair Cockburn на BayXP Meeting, Jan 2007. Элистер знакомит с концепциями, представленными в своей книги Agile Software Development: The Cooperative Game (2nd Edition) .

Перевод глав книги Dean Leffingwell Scaling Software Agility: Best Practices for Large Enterprises: (спасибо Agile Russia)

Agile Offshoring : It's hard work but it works!
Статья, которая подняла много шума. Работает ли agile в оффшоре? Читайте здесь.

Ретроспективы (retrospection meetings)

В предыдущих выпусках уже встречались материалы по ретроспективам. Но мы бы хотели почеркнуть важность этих активностей в agile проектах, подделившись интересными ссылками по этой теме.

Часовой видео-трейнинг по ретроспективам, проеведённый в
Google авторами одной из самых популярных книг по ретроспективам в agile проектах - "Agile Retrospectives: Making Good Teams Great " - Diana Larsen и Esther Derby

Хорошая подборка статей по ретроспективам
в том числе со статьями
Esther Derby

How To: Live and Learn with Retrospectives
Обширная статья про ретроспективы.

Книга Norman L. Kerth Project Retrospectives: A Handbook for Team Reviews . Тут можно прочеть главу: An anatomy of a retrospective

------------------------------------------
У вас есть замечания или пожелания - пишите, мы будем рады.
Agile-Ukraine

ПОПУЛЯРНОЕ

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

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

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

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

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

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

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.

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

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