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

agile newsletter 3: новости и ссылки

Это третий выпуск agile newsletter.
http://www.agileukraine.org/2007/04/agile-newsletter-3.html

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

Предыдущие выпуски agile newsletter можно найти здесь:
http://www.agileukraine.org/2007/04/newsletter-archive.html

Новости agile в Украине
31 марта в Киеве была проведена первая встреча группы Agile Ukraine.
Встреча прошла в плодотворных дискуссиях, посвященных ключевым темам agile: ценностям agile, обзору agile подходов, адаптивному планированию, user stories, Scrum и Scrum сертификациям. Детали можно найти здесь:
http://www.agileukraine.org/2007/04/agile-gathering-april-2007.html

В июне в Киеве будут проведены классы Certified ScrumMaster.
С условиями и деталями можно ознакомиться здесь:
http://www.agileukraine.org/2007/03/scrummaster.html
Здесь также идут обсуждения этого события:
http://groups.google.com/group/agile-ukraine/browse_thread/thread/94a449a21006c22a/ca79317dd52c1adf#

Следите за анонсами событий на нашем сайте
http://www.agileukraine.org/2007/02/events.html
или в нашем Google календаре.

Статьи

О User stories просто и на русском
http://www.agileukraine.org/2007/04/user-stories-part-1.html

Популярность Scrum http://www.agileukraine.org/2007/04/scrum.html

From Idea to Feature to launch in 48 hours
Хороший пример от 37signals как сделать то, что нужно избавляясь от лишней функциональности.
http://www.37signals.com/svn/posts/348-highrise-public-contact-cards-from-idea-to-feature-to-launch-in-48-hours

Scrum room = Fun room
Работать должно быть весело.
Пример проектной комнаты Scrum команды:
http://weblogs.asp.net/bsimser/archive/2007/04/03/scrum-room-fun-room.aspx

Обширная статья про суть stand-up митингов
http://martinfowler.com/articles/itsNotJustStandingUp.html

Свод правил Scrum митинга
У вас могут быть свои условия проведения утреннего митинга,
но важно, чтобы их знали все члены команды. Пример таких правил: http://groups.google.co.in/group/scrumnet/web/daily-scrum-meeting-rules

Holacracy: A Complete System for Agile Organizational Попытка обобщения agile принципов с целью вынесения их на уровень больших организаций.
http://www.holacracy.org/downloads/CutterHolacracyArticle.pdf

Web ресурсы

AgileDev.ru
Российский проект и форум, посвященный гибкой разработке ПО
http://agiledev.ru/

Англоязычный ресурс-блог по agile
http://kw-agiledevelopment.blogspot.com/

Англоязычный ресурс по agile с набором статей об интеграции MSF и RUP c agile
http://www.agilelogic.com/resources.html

Коллекция шаблонов Scrum артефактов, большинство в Excel формате:
http://agilesoftwaredevelopment.com/2006/11/scrum-backlog-templates-and-examples

Форумы

Scrum Master Certification debates
Различные точки зрения на полезность и целесообразность сертификации по Scrum и agile в общем
http://www.infoq.com/news/2007/03/Scrum-CSM-debate

Также дискуссии на тему сертификаций в нашей рассылке:
http://groups.google.com/group/agile-ukraine/browse_thread/thread/0abbfcbf25413973/#

Горячие дискуссии Agile Ukraine:

 ScrumMaster as a team member
http://groups.google.com/group/agile-ukraine/browse_thread/thread/0a58d75818da28ee/#
Eliminate warehouse: спор на тему сути багов и product backlog:
http://groups.google.com/group/agile-ukraine/browse_thread/thread/d75a91d4df150a38/#

Tracking actual efforts for unexpected tasks: нужно ли вести отчеты по потраченному времени?
http://groups.google.com/group/agile-ukraine/browse_thread/thread/2e3bb0527f610214/#



У вас есть замечания, пожелания, интересные ссылки - пишите,
и мы будем рады включить их в следующий выпуск.

Редактор выпуска: Алексей Кривицкий.

ПОПУЛЯРНОЕ

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

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

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

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

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

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

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...
Читать далее »

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

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