пример хорошей юзер стори

[Ксения Кобрин]

Привет! хотелось бы показать команде пример хорошей юзер стори из
какого-либо проэкта. может у кого-то есть.
Спасибо.

[Katuknow]

Поддерживаю!! Очень сложно начать мыслить категориями историй, хочется увидеть примеры хороших юзер стори.

[Nataliya Trenina]

Привет.

1. Как scrum-master (роль) я хочу показать команде хорошую user-story (действие) чтобы обучить на примере их составлять (ценность).
   
   
2. Как читатель(роль), я хочу просмотреть рецензии о книге (действие), что бы решить буду ли ее читать (ценность).

Максимально простая конструкция, провоцирующая команду к диалогу вокруг фичи.

Но если вы пишите банковскую систему, могут возникнуть дополнительные вопросы) Приведите плз пример ваших текущих историй, или примеры спеки, и мы подумаем как их конвертировать.

Минимальная

27 февраля 2012 г. 16:11 пользователь Katuknow <k.iy...@gmail.com> написал:

Поддерживаю!! Очень сложно начать мыслить категориями историй, хочется увидеть примеры хороших юзер стори.

--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
 
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com

--

Nataliya Trenina

CEO & Agile coach      @ SCRUMguides
Founder & Facilitator   @ InnovationFriends
Conference Producer  @ Agile Base Camp
Conference Chair        @ Agile Eastern Europe

LinkedIn | FaceBook | Twitter | Skype nattrenina | +38 050 412 61 35

Join us for Stanford Club @ InnovationFriends!

[Borys Lebeda]

Вот отличный пример юзер-стори:
http://dilbert.com/strips/comic/2003-01-10/

Have fun :)

2012/2/27 Nataliya Trenina <nat.t...@gmail.com>:

--
Borys L.

[sergiy movchan]

помог, да :) 

2012/2/27 Borys Lebeda <borys....@gmail.com>

--
...dali bude...

[Katuknow]

Спасибо за пример, но не являются ли эти истории Epic?

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

On 27 фев, 18:13, Nataliya Trenina <nat.tren...@gmail.com> wrote:
> Привет.
>
>    1. Как scrum-master (роль) я хочу показать команде хорошую user-story

>    (действие) чтобы обучить на примере их составлять (ценность).
>

>    2. Как читатель(роль), я хочу просмотреть рецензии о книге (действие),

>    что бы решить буду ли ее читать (ценность).
>
> Максимально простая конструкция, провоцирующая команду к диалогу вокруг
> фичи.
>
> Но если вы пишите банковскую систему, могут возникнуть дополнительные
> вопросы) Приведите плз пример ваших текущих историй, или примеры спеки, и
> мы подумаем как их конвертировать.
>
> Минимальная
>

> 27 февраля 2012 г. 16:11 пользователь Katuknow <k.iyuk...@gmail.com>написал:

>
> > Поддерживаю!! Очень сложно начать мыслить категориями историй, хочется
> > увидеть примеры хороших юзер стори.
>
> >  --

> > Agile Software Development Group, Ukraine,http://www.agileukraine.org/

>
> > To visit the group online see:
> >http://groups.google.com/group/agile-ukraine/
> > To post to this group send email to agile-...@googlegroups.com
> > To unsubscribe send email to agile-ukrain...@googlegroups.com
>
> --

> *Nataliya Trenina *
>
> CEO & Agile coach      @ SCRUMguides <http://www.scrumguides.com/>

> Founder & Facilitator   @ InnovationFriends

> <http://innovationfriends.com.ua/>
> Conference Producer  @ Agile Base Camp <http://kiev.agilebasecamp.org/>

> Conference Chair        @ Agile Eastern Europe
>

> <http://agileee.org/>
> <http://kiev.agilebasecamp.org/>LinkedIn<http://ua.linkedin.com/in/nattrenina>|
> FaceBook<http://www.facebook.com/reqs.php#%21/profile.php?id=100000785299209>|
> Twitter <http://twitter.com/natatara> | Skype nattrenina | +38 050 412 61 35
>
> *Join us for Stanford
> Club<http://innovationfriends.com.ua/category/standord-club/>@ I
> nnovationFriends! <http://innovationfriends.com.ua/>*

[Alexander Burdun]

Я че ветка умерла? Я бы тоже посмотреть хотел на примеры адекватные, а то своих приучить к норм постановке задач и стори как-то не получается пока.

27 февраля 2012 г. 15:30 пользователь Ксения Кобрин <company...@gmail.com> написал:

Привет! хотелось бы показать команде пример хорошей юзер стори из
какого-либо проэкта. может у кого-то есть.
Спасибо.

--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/

To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com

--
Александр Бурдун

tel: +38 097 137 0443
skype:    a.burdun
AIM/ICQ: 307064073
http://burdun.com

[Dmitriy Efimenko]

для меня хороший сценарий - тот, кто отвечает на вопросы:
кто? когда? где? что? зачем?
иными словами - 5 параграфный приказ. очень удобные критерии качества
сценария :)

On 8 мар, 09:33, Alexander Burdun <a.bur...@gmail.com> wrote:
> Я че ветка умерла? Я бы тоже посмотреть хотел на примеры адекватные, а то
> своих приучить к норм постановке задач и стори как-то не получается пока.
>
> 27 февраля 2012 г. 15:30 пользователь Ксения Кобрин <

> company.neo...@gmail.com> написал:

>
> > Привет! хотелось бы показать команде пример хорошей юзер стори из
> > какого-либо проэкта. может у кого-то есть.
> > Спасибо.
>
> > --

> > Agile Software Development Group, Ukraine,http://www.agileukraine.org/

[Alexander Burdun]

Во первых отличный "пример" юзерстори.
Во-вторых стори вроде как не должна отвечать на вопрос "кто?".

//--------------------------

Вопрос в силе, покажите реальную нормально оформленную юзерстори.
Без философии. Но к самому примеру вполне можно приложить обоснование, почему именно так. Лишним не будет.

8 марта 2012 г. 21:52 пользователь Dmitriy Efimenko <d.efi...@gmail.com> написал:

Agile Software Development Group, Ukraine, http://www.agileukraine.org/

To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com

[Dmitriy Efimenko]

ну, мне пофиг шашечки, мне - ехать :)

On 8 мар, 20:07, Alexander Burdun <a.bur...@gmail.com> wrote:
> Во первых отличный "пример" юзерстори.
> Во-вторых стори вроде как не должна отвечать на вопрос "кто?".
>
> //--------------------------
>
> Вопрос в силе, покажите реальную нормально оформленную юзерстори.
> Без философии. Но к самому примеру вполне можно приложить обоснование,
> почему именно так. Лишним не будет.
>
> 8 марта 2012 г. 21:52 пользователь Dmitriy Efimenko

> <d.efime...@gmail.com>написал:

[Alexander Burdun]

Так вы ж в качестве ответа шашечки привели.
А мне бы ехать.

8 марта 2012 г. 22:09 пользователь Dmitriy Efimenko <d.efi...@gmail.com> написал:

Agile Software Development Group, Ukraine, http://www.agileukraine.org/

To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com

[Dmitriy Efimenko]

>> Во-вторых стори вроде как не должна отвечать на вопрос "кто?"

шашечки? ;)

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

On 8 мар, 20:12, Alexander Burdun <a.bur...@gmail.com> wrote:
> Так вы ж в качестве ответа шашечки привели.
> А мне бы ехать.
>
> 8 марта 2012 г. 22:09 пользователь Dmitriy Efimenko

> <d.efime...@gmail.com>написал:

[Alexander Burdun]

В любом случае это не пример.
Тут до "ехать" еще далеко.
Можно все-таки как-то без шашечек?

8 марта 2012 г. 22:20 пользователь Dmitriy Efimenko <d.efi...@gmail.com> написал:

[Alexey Krivitsky]

Верхушка реального беклого реального проекта:

• As a conference owner I'd like to create a new conference to start collecting submissions
  
• As a conference owner I'd to grant admin access so that other people can help me out
• As a conference owner I'd to invite reviewers to form a program committee
• As a conference owner I'd like to be able to start and stop call for paper when needed
• As a conference owner I'd like to configure submission statuses to setup a basic review workflow

• As a conference speaker I'd like to see a list of upcoming conferences to decide which to submit talks to
• As a conference speaker I'd like to have my profile reusable for future submissions to avoid having to refill it again
• As a conference speaker I'd like to see a list of existing submissions to come up with a relative one
• As a conference speaker I'd like to submit a talk to participate in a review process

• As a conference reviewer I'd like to see newly submitted papers to start reviewing them
• As a conference reviewer I'd like to comment on a submission so that other reviewers and a speaker react
• As a conference reviewer I'd like to mark a submission as being reviewed by me to avoid review collisions
• As a conference reviewer I'd like to change status of a submission to track and make review progress visible

2012/2/27 Katuknow <k.iy...@gmail.com>

Поддерживаю!! Очень сложно начать мыслить категориями историй, хочется увидеть примеры хороших юзер стори.

[Tanya Kobzar]

Пришел Леша и показал, как надо :)

2012/3/12 Alexey Krivitsky <alexeyk...@gmail.com>

--

Best regards,
Tanya Kobzar

skype: kontikime

tel: +380631098709

[Alexey Krivitsky]

Как надо решается внутри каждого проекта.

Мне надо было так как я написал )

Крв

2012/3/12 Tanya Kobzar <kont...@gmail.com>

[Alexander Burdun]

Это 13 штук стори?

12 марта 2012 г. 14:57 пользователь Alexey Krivitsky <alexeyk...@gmail.com> написал:

[Alexey Krivitsky]

Не уверен что понял вопрос.

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

2012/3/12 Alexander Burdun <a.bu...@gmail.com>

[Tanya Kobzar]

Да хорошо написал :-)

2012/3/12 Alexey Krivitsky <alexeyk...@gmail.com>

[Alexander Burdun]

Всё ты правильно понял)) Спасибо.
Можно еще одну стори расписанную на таски поглядеть?

12 марта 2012 г. 15:20 пользователь Alexey Krivitsky <alexeyk...@gmail.com> написал:

[Alexey Krivitsky]

As a conference owner I'd like to configure submission statuses to setup a basic review workflow

 - add new section to configuration for statuses (name, color, visibility)

 - add status control to submission index

 - add status control to submission details view

 - implement permission check: reviewers and admins can change statuses; guests and speakers see status in read-only

 - implement ajax status change behavior

 

2012/3/12 Alexander Burdun <a.bu...@gmail.com>

[Vasyl Keretsman]

Леша,

а как и где описываются приемочные критерии?

Такая короткая формулировка только говорит о том, "что" надо сделать.
Но мне кажется больше всего проблем возникает с "как" должно быть в
результате - например вплоть до цвета и расположения кнопки.

Не первы

2012/3/12 Alexey Krivitsky <alexeyk...@gmail.com>:

[Vasyl Keretsman]

Предыдущее письмо случайно улетело :)

Леша,

а как и где описываются приемочные критерии?

Такая короткая  формулировка только говорит о том, "что" надо сделать.
Но мне кажется больше всего проблем возникает с "как" должно быть в
результате - например вплоть до цвета и расположения кнопки.

Очень частая ситуация, кажды

[Vasyl Keretsman]

> Предыдущие 2 письма случайно улетели - кошмар какой-то с горячими клавишами. Извиняюсь.

 Леша,

 а как и где описываются приемочные критерии?

 Такая короткая  формулировка только говорит о том, "что" надо сделать.
 Но мне кажется больше всего проблем возникает с "как" должно быть в
 результате - например вплоть до цвета и расположения кнопки.

Очень частая ситуация - каждый разработчик понимает "как" надо сделать
по своему в зависимости от своего опыта и возможностей - в результате
важная фича очень некачественно сделана и в итоге никто ею не
пользуется. Особенно если это касается UX.

Кто должен формулировать приемочные критерии? Product Owner?
Какой уровнь детализации в таких случаях?

[Alexander Burdun]

Присоединюсь, я ожидал, что таски как-то более развернуто. Что-то более похоже на тз.

12 марта 2012 г. 15:39 пользователь Vasyl Keretsman <vas...@gmail.com> написал:

--

[Alexey Krivitsky]

Вася, держи себя и в руках - раскидался письмами :))

Отвечаю

- если вам нужно детальнее - пишем

- если вам помогают приемочные критерии - составляем

- если вам нужны скриншоты, мокапы, wiferframes - рисуем

Все понимают, что уровень детализации и формализации будет зависеть от отношений людей в проекте, их уровне профессионализма, опыта совместных и личных граблей.

Обычно:

- начальные критерии приемки составляются PO и его командой

- они дописываются и расширяются во время сессий груминга (регулярного ТО беклога)

- задачи разбиваются и детализируются

- дизайнерами дорисовываются мокапы

Леша

2012/3/12 Vasyl Keretsman <vas...@gmail.com>

[Alexander Rivkind]

Нужно понимать, что является требованием заказчика, а что - нет.

Если в требовании только функциональность, то дизайн - на усмотрение команды.

Но на практике всегда появляются хотелки.

Единственный правильный выход - выводить разработку дизайна отдельным спринтом (итерацией, фазой, чем угодно), дизайнить мокапы и из пожеланий заказчика по факту демо (ревью) формировать новый спринт.

Писать на элементы дизайна user stories imho overkill.

2012/3/12 Alexey Krivitsky <alexeyk...@gmail.com>

--
Best Regards, Alik.

[Vasyl Keretsman]

То есть если резюмировать - изначальная формулировка "As ... I'd like
to ... " просто повод для начала работы на фичей.
А дальше все индивидуально в зависимости проекта и команды.

> - они дописываются и расширяются во время сессий груминга (регулярного ТО)
Есть какие-то ссылки по теме?

Спасиб

2012/3/12 Alexey Krivitsky <alexeyk...@gmail.com>:

[Alexander Burdun]

Благодартсвую за конструктив в треде) Без философии)

12 марта 2012 г. 16:03 пользователь Alexey Krivitsky <alexeyk...@gmail.com> написал:

--

[Rostyslav Seniv]

лишь мое мнение) Вероятно, комманда понимает о чем говорит тот или
иной таск. часто нет смысла писать очень много. Для сложных вещей
возможно и надо писать "ТЗ", но всегда должен быть здравый смысл в
детализации. Как принцип Just in Time и Just Enough. Вы сами поймете
сколько деталей нужно вам, и в какой момент. Епики на несколько
месяцев, стори на несколько спринтов, полностью в деталях (с
критериями) для двух-трех спринтов, таски на один спринт.

Что кассается UX или UI или information architecture, то есть два
популярных способа. Не буду говорить какой правильный, каждый пусть
сам решает. С UX инженером который делает все немного наперед, и
другой когда UX есть результатом работы комманды над требованиями. в
первом способе UX инженер или как кто бы его не называл играет роль
какбы второго продакт овнера. Часто еще есть и внешний архитект
который имеет свое виденье идеального дизайна. Но часто бывает что
"идельный" UX-дизайн не стикуется с "идеальными" требованиями или
"идеальной" архитекторой. Или некоторые решения очень не выгодны (cost
effective). Эот как космическая ручка и карандаш. Поэтому я люблю
коммандный способ, когда принемаютясь еффективный решения и
максимизируется ROI. Но, еще раз, часто так не получается.

Но понятно что есть куча нюансов, как например технически слабый
коллектив. и это уже другая тема. Я бы например инвестировал время или
деньги в людей, чтобы они становились более граммотными и принимали
лучшие решения, и по ЮАй и по дизайну, вместо того чтобы пытаться это
менеджать. Немного спонтанного парного програмирования, пир код ревю,
даже джуниор-синьйор, коллективный код, статический анализ кода,
хороший CI и тд.

On Mar 12, 1:41 pm, Alexander Burdun <a.bur...@gmail.com> wrote:
> Присоединюсь, я ожидал, что таски как-то более развернуто. Что-то более
> похоже на тз.
>

> 12 марта 2012 г. 15:39 пользователь Vasyl Keretsman <vasi...@gmail.com>написал:

>
>
>
>
>
>
>
>
>
> > > Предыдущие 2  письма случайно улетели - кошмар какой-то с горячими
> > клавишами. Извиняюсь.
>
> >   Леша,
>
> >   а как и где описываются приемочные критерии?
>
> >   Такая короткая  формулировка только говорит о том, "что" надо сделать.
> >   Но мне кажется больше всего проблем возникает с "как" должно быть в
> >   результате - например вплоть до цвета и расположения кнопки.
>
> > Очень частая ситуация - каждый разработчик понимает "как" надо сделать
> > по своему в зависимости от своего опыта и возможностей - в результате
> > важная фича очень некачественно сделана и в итоге никто ею не
> > пользуется. Особенно если это касается UX.
>
> > Кто должен формулировать приемочные критерии? Product Owner?
> > Какой уровнь детализации в таких случаях?
>

> > >> 2012/3/12 Alexey Krivitsky <alexeykrivit...@gmail.com>:

> > >>> 2012/2/27 Katuknow <k.iyuk...@gmail.com>

>
> > >>>> Поддерживаю!! Очень сложно начать мыслить категориями историй, хочется
> > >>>> увидеть примеры хороших юзер стори.
>
> > >>>> --
> > >>>> Agile Software Development Group, Ukraine,
> >http://www.agileukraine.org/
>
> > >>>> To visit the group online see:
> > >>>>http://groups.google.com/group/agile-ukraine/
> > >>>> To post to this group send email to agile-...@googlegroups.com
> > >>>> To unsubscribe send email to
> > agile-ukrain...@googlegroups.com
>
> > >>> --
> > >>> Agile Software Development Group, Ukraine,
> >http://www.agileukraine.org/
>
> > >>> To visit the group online see:
> >http://groups.google.com/group/agile-ukraine/
> > >>> To post to this group send email to agile-...@googlegroups.com
> > >>> To unsubscribe send email to
> > agile-ukrain...@googlegroups.com
>
> > --

> > Agile Software Development Group, Ukraine,http://www.agileukraine.org/

[Kseniya Kobryn]

два месяца прошло, дискусси жаркие, а хорошей юзер стори все нет :)
Понеділок, 27 лютого 2012 р. 13:30:25 UTC+2 користувач Ксения Кобрин написав:

[Nataliya Trenina]

Приветы.

И я и Леша отправляли примеры рабочих юзер-стори. Но, видимо, они недостаточно великолепны для прихотливого читателя :)

Н

3 мая 2012 г. 13:25 пользователь Kseniya Kobryn <kobryn...@gmail.com> написал:

--

Agile Software Development Group, Ukraine, http://www.agileukraine.org/
 
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com

--

Nataliya Trenina

CEO & Agile coach      @ SCRUMguides
Founder & Facilitator   @ InnovationFriends
Conference Producer  @ Agile Base Camp
Conference Chair        @ Agile Eastern Europe

LinkedIn | FaceBook | Twitter | Skype nattrenina | +38 050 412 61 35

Join us for Stanford Club @ InnovationFriends!

[Vlad Savitsky]

Я не спец в этих вопросах, но вот моя история.

Exclude completed tasks from Task List by default

As a staff member I don't want to see completed tasks in task list so I can change state of task to completed and this task will disappear from task list.

Using filters I could select completed tasks if necessary and manage them. 

Acceptance criteria

1. Tasks List should exists (/admin/content/tasks/all).
2. Access to page should have only staff members with permission to edit/view FL.
3. Default value of filter 'State' at Task List page should be 'Open or In Progress'.
4. By default should be shown only Open or In Progress tasks (Completed tasks should be excluded).

Useful Links

• Link 1
• Link 2
• Link N

3 мая 2012 г. 14:40 пользователь Nataliya Trenina <nat.t...@gmail.com> написал:

--
 Vlad Savitsky
(Team Lead, Shvets Group)

+380965302712
ICQ: 205535814
Skype: vlad_savitsky
vlad.s...@shvetsgroup.com

[Kirill Klimov]

Ксения, 

On Thursday, May 3, 2012 2:25:43 PM UTC+3, Kseniya Kobryn wrote:

два месяца прошло, дискусси жаркие, а хорошей юзер стори все нет :)

ну давайте разбираться что такое хорошая юзер стори...

для меня это история которая:

• следует правилу 3C (card, confirmation, conversation)
  
• не содержит деталей реализации
  
• следует модели 
  

I ndependent

N egotiable

V aluable

E stimatable

S ized Right

T estable

Ну, понятно, следует формату

As a <persona>,

I want <feature>,

so that <business value>

Я прошёлся по историям, которые Лёша прислал - они подходят, как мне кажется.

А почему для вас они не хорошие? Какими критериями вы руководствуетесь?

Понятно что истории это не последний шаг в проработке "требований". Более того - первый. Тут уже касались приёмочных критериев, дизайна. Можно BDD сценарии добавить.

 

[Kseniya Kobryn]

Здравствуйте!

 

взоможно я не права, но как кпо мне для полной информации по истории не хватает приоритета, оценки и conditions of acceptance. На тренинге для скрам мастеров наш тренер сказал что в истории которую мы берем на спринт должно быть все на столько понятно, что остается 10 минут to delivery :)

 

Ксения.

Пʼятниця, 4 травня 2012 р. 15:31:58 UTC+3 користувач Kirill Klimov написав:

[Ilya Pavlichenko]

Как по мне, Кирилл в предыдущем посте дал почти исчерпывающий ответ. А вообще для кого интересно(и кто еще не читал) – User Stories Applied by Mike Cohn.

--

[Serhiy Yevtushenko]

Полная спецификация юзер стори со всеми фичами может делаться только для тех историй, которые идут непосредственно в спринт, и скорее на начальных этапах.

 

Когда команда становиться сработанной с заказчиком, то количеств обязательных артифактов будет уменьшаться

 

Далее - приоритет определяется ПО - то есть он выбирает те, которые будут планироваться на спринт, и приоритет может меняться в зависимости от оценок команды, зависимостей от других задач и так далее.

 

Conditions of acceptance - это скорее в интересах комманды иметь их хорошо специфицированными. Поэтому я бы не надеялся, что заказчик их будет выдавать полностью расписанными, если он еще не приучен к этому долгими усилиями команды.

Оценка - это опять ответственность команды - поэтому это не вопрос ПО их специфицировать.

 

А на наличие или отсутсвтие чего-то в юзер стори стоит смотреть с прагматичной точки зрения - какие будут последствия, если этого нет в текущей среде?

Сергей Евтушенко

 

14 мая 2012 г., 10:34 пользователь Kseniya Kobryn <kobryn...@gmail.com> написал:

--

[Kirill Klimov]

Ксения,

по пунктам.

приоритет нужен. Но это не свойство истории. Одна история в вакууме не имеет приоритета. Истории могут иметь приоритет только относительно друг друга, то есть приоритет они получают попадая в соответствующее место в беклоге. Про оценки - оценки могут быть нужны для приоритезации и долгострочного планирования. Если вам это не нужно, оценкаисторий - потеря времени

(учитывая что я пишу в очень публичяное место, пожалуй стоит заметить, что в большинстве случаев оценка нужна и что если вы не знаете нужно или нет - начинайте с оценками ...) 

conditions of acceptance - уже пару раз вспонимали acceptance criteria, BDD, definition of done...

ну и последнее - да, на начало итерации должно быть всё понятно. Не смотря на это, это не значит что критерии заморожены - во время работы у вас вполне всё может ещё поменяться :-)

[sergiy movchan]

чтобы безболезненно начать - так и должно быть. другое дело, что вы ПО задолбаете :) но команда не получит граблями по одному месту и не забьёт на скрам.

2012/5/14 Kseniya Kobryn <kobryn...@gmail.com>

--

Agile Software Development Group, Ukraine, http://www.agileukraine.org/
 
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com

--
...dali bude...