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

agile newsletter, выпуск 1: новости и ссылки

Agile newsletter: новости, ссылки

Выпуск 1, 13 марта 2007 (архив новостей)

Эта страница содержит набор полезных ссылок на различные материалы по темам, связанным с agile разработкой ПО. Если у вас есть интересные ссылки, поделитесь ими, и мы включим их в следующий выпуск новостей.

Agile в Украине:

31 марта в Киеве состоится сбор agile движения.
Детали мероприятия описаны тут. Ждите открытия регистрации.


Видео-материалы:

1. Scrum et al. - 1 hour talk of Ken Schwaber on Scrum for Google folks
English, ссылка
Очень интересная презентация про суть Scrum, сделанная одним из основателей Scrum движения - Кеном Швабером (Ken Schwaber) для команд из Google, сентябрь 2006.
Дает хороший обзор процесса с различных точек зрения - программистов, менеджеров, заказчиков.

2. Running Tested
English, ссылка
Интервью с одним из основателей XP - Роном Джеффриз (Ron Jeffries) про суть agile, ноябрь 2006.

Статьи:

1. Как найти нужных людей для agile-проектов.
Русский, ссылка
Полезные советы по подбору команды в agile-проекты. Как определить подходящих людей. Советы по проведению телефонных и очных собеседований.

2. Внедрение agile
Русский, ссылка
Общий подход, на что надо обращать внимание при переходе на agile.

3.Велик и могуч... термин "agile"
Русский, ссылка
Статья про суть термина "agile" и сложность его перевода на русский

4. Scrum: From the Top
English, ссылка
Откуда приходит Scrum - от менеджмента к командам или наоборот? Статья основателя Scrum - Кена Швабера (Ken Schwaber) про его наблюдение о сегодняшних тенденциях зараждения Scrum в проектах.

5. Scrum: Leader of the Band
English, ссылка
Статья Майка Кона (Mike Cohn) о шести качествах, которыми должен владеть потенциальный ScrumMaster.

6. When Scrum is not Scrum
English, ссылка
Короткая но полезная статья Тобиаса Мейера (Tobias Meyer) о том, что может пойти не та в проекте, следующему Scrum, с набором советов по решению проблем.

7. The Six Step Approach to Heartbeat Retrospectives
English, ссылка на PDF
В этой статье Борис Глорер (Boris Gloger) описывает суть такой важной практики любой agile команды как проведение ретроспективных митингов. Простые но мощные советы.

Утилиты:

1. Planning Poker: agile planning tool
ссылка на web-приложение, разработанное командой Майка Кона (Mike Cohn), которое может быть полезным распределенным командам для оценки проектов при помощи метода "planning poker", описанного в последних книгах Майка по использованию user stories и agile planning.


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

ПОПУЛЯРНОЕ

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

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

Основополагающие принципы Agile-манифеста

Мы следуем таким принципам: Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. Работающий продукт — основной показатель прогресса. Инвесторы, разработчики и пользователи должны иметь возможность поддержив

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

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

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

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

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

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