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

Вторая конференция: Agile Gathering

This event is in the past.
Please refer to our Events page for further Gatherings and other group events.


First of all let me thank everyone who was able to come and participate in our second gathering. Though it was a working day, about 40 people were able to attend. We appreciate your interest in the topic and tried to make sure your time was properly spent.

We very much thank to Mike Vizdos, Alexander Laszlo Ross and Alexey Maslov who made shared their visions and experience. It was you who made the gathering, guys!

We thank to Ciklum and GlobalLogic companies who helped us to organize the event and took over the expenses. We thank particularly to Lena Terioshina from Ciklum who helped a lot in solving organization questions.

Again about the topics

  1. Michael Vizdos (http://www.michaelvizdos.com/, http://implementingscrum.com/) made 90 minute intro on Scrum basics which we believe was useful for the newcomers to agile as well as for the more experienced audience

  2. Alexander Laszlo Ross (risingstarpartners.com) shared his experience in refactoring (transforming) a problematic distributed project into more agile-oriented environment. Presentation will be uploaded here.

  3. Alexey Maslov from GlobalLogic made a unique presentation on Offshore Agile sharing common problems, pitfalls, ideas. This was extremely interesting for the audience as the majority of Ukrainian IT people participate in outsourced projects.
    Power point presentation is available here.


Here is the link to our Picasa album.
Have more photos? Send them to us please.


According to the feedback - the second gathering was more effective that the first one which we did in April 2007. Good news! We are happy to keep on improving. Here is what we’ve learned this time:

  1. Environment:
    1. we need to pay attention to air-conditioning
    2. having a place which is located closer to metro station is always a good thing, it will also make it simpler for non-Kiev easier people locate the meeting place

We will do our best to satisfy these needs.
Recommendations on a place that we can use the next time are welcomed.

  1. Audience was mixed, that’s why about a half of the attendees called for more advanced topics to be covered with more real life examples and discussions on problems and solutions.

    We can reach this goal by focusing our next gatherings on more practical aspects and real-life project cases. Below is the list of topics people find interested

Backlog of topic to be covered during our next gatherings (in order of interest):

  1. Offshore agile. Reality and practices.
  2. QA role in agile project. Communicating with customers. Place of QA in the agile team.
  3. Planning and estimating.
  4. Requirements management, user stories.
  5. Self-managing teams and place of seniors in them.
  6. Make team communicate, developer’s focus on communication.
  7. Risk management in agile.
  8. Implement agile in non-agile teams.
  9. Retrospective meetings.

Please contact us if you have a chance presenting any of the listed topics. It is very much appreciated by our community. Languages: Russian, Ukrainian or English.

Next Gathering

Yes, it is time to plan our next gathering. What about October 2007?

Let's discuss it here. Feel free to subscribe to our Google calendar, Google group or just visit our site to watch for the upcoming events.

We start looking for presenters and sponsors. Email us if you can assist.

Refreshing our mission

Being “Agile Ukraine” our mission is to help spreading out of agility in the Ukrainian software development market. We are happy to help your company and project teams learn more about any aspects of agile software development, and finally adapt agile. Stay connected with Agile Ukraine.

Agile has been working for us, so why it cannot work for you as well?


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

Автор: Richard Lawrence
Переведено с английского проектом Agile Translations

Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Об agile по-русски: User Stories, часть 1

«Разработка ПО - это игра изобретательности и кооперации»
Элистер Коуберн (1)
О чем эта статья? Это одна из статей серии «Про agile по-русски» (см. сноску внизу про значение термина «agile»), идея которых поделиться опытом использования agile принципов (2) в разработке программного обеспечения. Основная суть этих подходов – кооперация между всеми членами проекта и адаптивность процесса разработки к неизбежным изменениям. Также важным аспектом Agile является принятие человеческого фактора в проекте как неотъемлемой части и более того – как наиважнейшей причиной прогресса. Agile акцентирует важность поддержания человеческих отношений и учета человеческих особенностей для успеха проекта.Эта статья рассказывает о применении «userstories» («пользовательских историй») - одной из практик agile. Далее для краткости я буду называть их просто «историями». Для кого эта статья? Эта статья для профессионалов по разработке программного обеспечения: менеджеров продуктов, менеджеров верхнего и среднег…

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

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

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

Автор: Майк Кон (Mike Cohn)
Перевод с английского

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

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

Автор: Илья Павличенко.

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

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