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

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-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.
Читать далее »

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

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

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

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

Конференция: Agile Gathering 3

The 3rd Agile Gathering done! First of all, let me thank everyone who came. Seems Agile techniques are becoming more and more popular, we are very happy to play an active part in the Ukrainian Agile movement. Visit our photo album . Below you can find the agenda with the links to the materials where available. What Certified ScrumMaster is NOT - by Alexey Krivitsky, pdf Agile for Business - by Gleb Arshinov, pdf Agile experience of Code Sprinters: How to build a company you would like to work in - by Adam Byrtek, pdf Pragmatic Agile Adoption - by Askhat Urazbaev, pdf We hope that Naresh Jain from Agile India and Danny Kovatch from Agile Israel who were not able to get to Ukraine this time will visit our next gathering in Spring 2008. Watch for upcoming announcements on our web site ( feed available ) and in our discussion group . And let me thank our great sponsors again, without them this event would not have happened: Co-organizer and general partner General and media partner Pa
Читать далее »

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

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