A G I L E - AGILE GROUP UKRAINE: статья

Showing posts with label статья. Show all posts

2008/06/09

Диаграммы Ганта и Agile проекты. Так уж они несовместимы?

Автор: Алексей Кривицкий.

"Планы бесполезны, планирование необходимо".
Ейзенхауэр

Диаграммы Ганта – это традиционный механизм визуального планирования, который получил свою популярность благодаря артефакту традиционных проектов, который назывался Work Breakdown Structure (WBS), и продуктам Microsoft Project и Microsoft Project Server, которые позволяли конструировать и хранить WBS.

Пропоненты Agile принципов много внимания уделяют визуализации и открытости планирования. Так почему же так часто в контексте Agile мы слышим критику в адрес диаграмм Ганта?

Давайте разберёмся.

Пару слов о терминологии.

В данной статье "традиционными подходами" к управлению проектами (или просто традиционными проектами) называются те подходы или проекты, которые противопоставляются Agile проектам. Я не использовал термин «водопадных проектов», так как во-первых на практике настоящих водопадных проектов не так много, а во-вторых по мимо водопадных и Agile проектов есть ещё множество других, которые тяжело классифицировать.

При помощи диаграмм Ганта при традиционных подходах к планированию и управлению проектами выполняются начальное препланирование, определяя работы, которые необходимо выполнить, зависимости между ними, распределяя проектные ресурсы. Это препланирование обычно выполняется руководителями проектов, и иногда ещё до того, как набрана команда. Знания, которые генерируются в ходе таких активностей несомненно полезны для любых проектов. В том числе и Agile. Так почему же диаграммы Ганта не рекомендуют использовать при Agile планировании?

Давайте рассмотрим, как выполняется планирование в идеальном Agile проекте:

Для того чтобы получить наиболее полную картину, вся команда вовлечена в процесс планирования.

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

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

Планы уточняются по мере того, как команда и заказчики узнают больше о разрабатываемом продукте, технологиях, возможностях команды. Это непрерывный процесс, "agile planning" - это действие, не артефакт.

Такой подход постепенной детализации планов позволяет экономить время на планирование, за счёт того, что более далёкие аспекты проекта, которые с большей долей вероятности подвержены изменениям, не прорабатываются с такой же степенью детализации, как те аспекты, которые будут пущены в работу в ближайшее время. Зачем тратить время на то, что ещё не факт войдёт ли в проект?
Механизмы управления требованиями в Agile проетках (к примеру product backlog, user stories) позволяют уменьшить зависимости между единицами требований, таким образом Agile проекты не нуждаются в таком детальном отслеживании зависимостей в требованиях, как единицы требований, используемые в традиционных проектах.

При помощи отслеживания зависимостей и задержек выполнения плана WBS
традиционного проекта помогает предсказать дату завершения фазы проекта. В Agile проектах для предсказания дат и объёма работы, используется метрика Velocity, для использования которой нет необходимости в отслеживании зависимостей между требованиями и работами.

Зависимости же между задачами в Agile проектах осуществляются командой благодаря ежедневной синхронизации на т.н. standup митингах.

Таким образом не столько графики Ганта противоречат сути Agile, как методики их использование, применяющиеся в традиционных проектах.

Что можно посоветовать:

Я думаю, что рисовать WBS стоит всей командой, а не отдельному человеку - менеджеру. В этом случае WBS становится достоянием команды и его можно использовать в виде настенного постера - WallGantt. Смотрите ссылки ниже.
Стоит обновляйте WallGantt как только вы узнаете нечто, что влияет на планы. Скорее всего не реже, чем раз в итерацию. Это позволит содержать Гант up-to-date и избежать ложности планов, к которой многие из нас так привыкли при традиционном планировании.
Если рисовать WBS не по задачам, а по требованиям (элементам product backlog), то это позволит избежать микроменеджмент команды, но всё-таки позволит сгенерировать информацию, полезную для команды. В противном же случае вы рискуете заменить ежедневное живое планирование артефактом. Это точно не то, чего мы добиваемся в Agile проектах.

Полезные ссылки:

2008/05/15

Agile: Иллюзии и реальность

Александр Якима

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

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

1. Самоорганизованная команда. Буквальное понимание этого принципа – верный путь к нервному расстройству. Любая команда нуждается в лидерстве и управлении. Это необходимо для реализации двух основных целей: эффективного решения локальных проблем сегодня и успешного достижения глобальной задачи в широком масштабе. То есть, всегда необходим кто-то, кто берет на себя ответственность в принятии "сегодняшних" решений и делится общим видением так, что все понимают, почему "сегодняшнее" решение является именно таковым. Это не обязан быть один человек - формальный лидер команды либо менеджер команды (хотя очень желательно, чтобы менеджер обладал лидерскими качествами). В реальности "самоорганизованной" можно назвать ту команду, в которой:
- Почти все члены команды являются носителями адекватного видения того, что они делают;
- Почти все хорошо мотивированны;
- Почти все возможные управленческие функции (управление другими и собой) по максимуму делегированы членам команды;
- Хотя бы раз в месяц они добиваются успеха вместе;
- Посидеть с кем-то в паре и помочь ему с решением задачи почти так же важно, как и решать свою задачу.

2. Бизнес и Инжиниринг работают как одно целое. Это случается очень редко. Часто между Бизнесом и Разработчиками царит непонимание, недоверие, дефенсивность. Опять-таки, "одно целое" следует понимать как иллюзию. Но, как и в предыдущем случае, имеет огромный смысл к этому идеалу приблизиться. Это с позиции Инжиниринга возможно, если:
- Если у команды нет видения, то она добивается его у Бизнеса. Часто Бизнес сам страдает близорукостью и не может или не считает нужным четко определять, к каким глобальным целям двигаться. Тогда Инжиниринг не просто требует видения, но принимает участие в его формировании, предлагая к рассмотрению не только вопросы, но и решения.
- Инжиниринг исходит из того, что существует только Win-Win исход для них и Бизнеса. Даже когда Бизнес, по мнению разработчиков, ведет себя похабно, поведение команды стабильно конструктивное.
- Инжиниринг делает все, чтобы идеи Бизнеса сработали в разрабатываемом продукте/сервисе и из этого постепенно зарождается доверие между Бизнесом и командой по Разработке.

3. Приветствуются любые изменения требований, в частности самые поздние. Вот это "самые поздние" - неприятный и опасный момент. Правильное понимание этого принципа покоится в одном склепе с видением различия между исходом итерации и релиза. Да, действительно, при гибкой разработке команда способна делать частые релизы с продакшн-качеством. Также правильно и то, что каждая итерация заканчивается рабочим билдом продукта, а не спецификациями, дизайном или еще чем-то. Но "рабочий билд" и "релиз-версия" - это разные вещи. Вкратце, отличает их качество. Для того, чтобы последний релиз-кандидат стал полноценной релиз-версией, необходимо время на стабилизацию. К примеру, вся однонедельная итерация посвящена стабилизации версии - фиксание багов, дополнительное ручное тестирование, финальное тестирование конфигураций и деплоймента и т д. Если времени на это не будет, то на выходе получится просто "рабочий билд" и ваши пользователи найдут много дефектов вместо вас. Правильное понимание принципа таково - изменение требований является необходимой реальностью, при которой обе стороны (Бизнес и Разработка) имеют возможность вносить изменения на протяжении всего релиза, кроме периода стабилизации (последние 10%-15% графика релиза). Речь идет не только о серьезных изменениях логики системы - жизнь изобилует примерами, когда за несколько дней до релиза Бизнес присылает 50-70 безобидных изменений (там текст поменять, там выравнивание переорганизовать и т.д.) и полностью съедает время на стабилизацию.

Примеры и обсуждение:

- Видение, необходимо для "самоорганизации" как воздух. Организовать можно только для достижения очевидной цели. В противном случае вся автономная активность членов команды будет бессмысленной. Под видением я понимаю общую картину всех релевантных фактов связанных с разрабатываемым продуктом, компанией, стейкхолдерами. Важно понимать, что это видение само по себе у команды не появится. Нужно проводить достаточно времени, общаясь со стейкхолдерами, чтобы понимать ситуацию достаточно глубоко. Особенно важно для случая, когда Продуктовая команда и команда Разработчиков разделены географически (тем более, при различных временных поясах). Когда следующий релиз? Какое значение для компании имеют определенные фичи? Откуда берутся приоритеты? Как они соотносятся с миссией компании? Подобные вопросы очень важны и их понимание критично для успешной разработки и развития команды. Но стандартным вопросником вроде этого ситуацию не опишешь. Нужен неформальный подход. На одном из проектов мы очень долго и безуспешно работали с продуктовой командой в Америке по определению UI-части следующей версии продука, которая должна была кардинально отличаться от текущей. Планирование релиза непонятно затягивалось и изрядно нервировало. В конце концов оказалось, что Продуктовая команда и не собиралась в ближайшее время финализировать этот план, так как разработкой UI-концепции должен был заняться новый человек, естественно, только после выхода на работу.

- Делегация управления - одно из самых серьезных испытаний для менеджера проекта. Делегировать работу вообще - это одно. Делегировать управление значительно сложнее. Но это делает управление намного эффективнее - больше точек зрения и углов, а проект один. А также служит серьезным мотивационным моментом. Не стоит бояться экспериментировать и нужно культивировать неформальное лидерство в команде. Причем, при ситуативном проявлении лидерства следует его всячески поддерживать, развивать и корректировать в нужном направлении. Пример из жизни: человек проявляет сильное лидерство в плане бизнес-анализа - видит "насквозь" требования, эффективно шлифует их с продуктовой командой, очень хорошо эстимирует разработку. Но никогда не хотел браться за полновесное управление проектом, поскольку не видит себя эффективным менеджером именно в плане управления людьми. Когда в команде много неформальных лидеров: бизнес-аналитиков, тестировщиков, архитекторов, конфиг-менеджеров и т д - это очень близко к идеалу "самоорганизации".

- Много воды утекло с того момента, когда я познакомился с Дином Леффингуэлом и начал работать на его проекте. Он решил поэкспериментировать с однонедельными итерациями, поскольку видел в этом потенциальные плюсы. Подход оказался удивительно эффективным. Много точек для принятия решений, изменения тактических целей и т д. Но в отношении развития команды - просто супер! Каждую неделю (в случае успеха) команда выкатывает функционирующий билд с новым функционалом. Каждую неделю - маленькая победа, достигнутая вместе. Через определенное количество итераций это входит в привычку. Кстати, на основных проектных задачах ограничиваться не стоит - можно играть в футбол, Unreal Tournament - вообще что угодно. Важно только чувствовать как все вместе добиваются результата.

- "Изменения последнего дня". Это когда в течении последней итерации перед релизом приходит длинный экселевский чек-лист с необходимыми изменениями. Все нужно немножко подправить во многих местах. Или прямо перед релизом оказывается, что запланированный UI не является интуитивно понятным (как может показать запоздалый user testing) и все откладывается на две недели. Есть много примеров, о которых я знаю и от коллег. Общая черта - как ни крути, а Продакт тим живет своей жизнью, а Инжиниринг - своей. В этом ничего фатального нет, важно только это хорошо понимать и стараться максимально сблизить ритм тех и других за счет полной открытости, работы на успех продукта. Продакт тим должен чувтсвовать, что их команда разработчиков нацелена на наиболее быстрое и качественное воплощение их идей в жизнь.

Подведем итог.

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

2007/10/23

QA in SCRUM

На семинарах, которые я провожу, часто от представителей отделов качества раздается один и тот же вопрос: «Что SCRUM думает про QA?».

Я написал небольшую статью, в которой попробовал подробно ответить на этот вопрос. Как оказалось QA в SCRUM сталкивается с конфликтом, который в состоянии решить только команда вцелом.

2007/07/05

Offshore software development

I wrote down some thoughts I was having about offshore development,
which I though might be interesting from an agile perspective. I'll
follow up with another post that deals with how this stuff is related
to being "agile" in an offshore situation. But, it would be nice to
hear how people are using agile approaches to achieve the things that
are mentioned below.

--------------------------------------------------------------

Offshore software development is motivated by two factors, (i) the
lack of local knowledge workers, and (ii) apparent cost savings.

There are many different models for doing offshore development. It
can, for example, be done on a project basis, or as a long standing
leasing of a dedicated team. I will mostly discuss things related to
the latter scenario, where the offshore team is leased to maintain a
product for a long period.

Having an offshore team is for most companies a journey into the
unknown. There are many practical issues that need to be resolved. In
most cases the top priority is to staff the team, and train the team
members so that they can become productive.

Most organizations are process oriented, and will therefore, quickly
focus on implementing some process to govern the offshore development.
However, there are some more "soft" issues that arise and require some
attention.

Some of the questions that quickly arise are:

* How do we position us with respect to these new team members?
* Can we trust them?
* How much effort should we spend on integrating them into our
company?

But, the real question that you should ask is:

"How do we achieve a productive, long-lasting, relationship with the
offshore team?"

The key elements in having a long-lasting and productive relationship
are:

* Trust
* Open communication
* Integration
* Sponsor support

Getting these key elements into place is essential for success. It's
necessary to discuss these things right from the start, and before you
start implementing some kind of a "process". However, the selection of
a process can highly influence how easily you can achieve these.
Later, I will discuss how an agile process can help in creating an
environment based on these four cornerstones. For now, let's discuss
these key elements: trust, open communication, integration, and
sponsor support.

TRUST

Trust is a fragile and complicated element in all human interactions.
Trust is built on transparency, honesty, and a commitment to matching
your words and actions.

In an offshore situation, an essential part of transparency is to
communicate decisions and their underlying causes. In a transparent
organization there are no "secrets". Information should not be
filtered for different audiences. That is, certain information should
not be exclusively communicated to local team members. Transparency
also means that expectations and results are clearly communicated.
Failing to balance and communicate expectations will almost always
lead to disappointment among some of the stakeholders.

In an offshore situation it's important to communicate the company's
intentions. Why did it move things offshore, and what are its plans in
the long run? In addition, shorter term plans, such as staff changes
and a product roadmap are valuable.

Despite the best of efforts, the offshore team is always at a slight
disadvantage when it comes to information flow. They don't have the
chance to listen in on the daily chatter. This makes it even more
important to keep them up-to-date on what is going on.

Trust is essential for being able to give the offshore team the
necessary freedom. The offshore team should be as autonomous and self-
organizing as possible. Enabling that requires a solid trust
relationship.

Ultimately, trust, is based on face-to-face communication. It's very
hard to build a strong trust relationship with someone you have never
met in person. This is one of the reasons why limiting face-to-face
meetings, between offshore and other employees, to a select few is
always a bad idea.

INTEGRATION

It's vital to integrate the offshore team into the company. This goes
much further than the occasional on-site visit from both parties. The
offshore team needs to feel that it is an equal partner. A preference
for the local employees is harmful for the trust relationship, and
isolates the offshore team. Would you apply preferential treatment if
you had two teams that where located on different floors in you
building?

In order to integrate the offshore team it is important to apply free
flowing communication, where everybody can communicate on an even
level. In many cases communicate channels are much more fixed. One or
more liaisons are selected to handle all the communication. This
isolates a large part of the organization from the offshore team. It
also introduces a lot of waste in the form of slower communication
channels, and the inherent noise that comes from passing messages
between people.

The fact that the offshore team members are not explicitly contracted
to your company should not detract from ensuring you get the best out
of the relationship. Integrating and accepting the offshore team as an
equal partner is necessary for maximizing the companies return on
investment.

OPEN COMMUNICATION

Software development is much more about communication than any
technological or process aspect. It is therefore one of the weak
points for offshore development. In an offshore setting, you need to
communicate frequently and personally. The more personal your
communication paths are the better. People have a tendency to
communicate electronically, sending large amounts of emails. Unless
there are some time-zone aspects that prevent you from communicating
in a more interactive way, email will always introduce waste. The same
applies for communicating what the offshore team needs to produce.

Electronic communication in the form of specifications is less
effective than personal and interactive communication. It's good to
document decisions, but starting off with a detailed description
invites misunderstandings. This is of course, the opposite of what
detailed descriptions are supposedly good for. Making sure there is a
clear contract of what is required. What really happens is that the
product may well end up representing one interpretation of what the
written documentation conveys, but it's unlikely to be match all the
different possible interpretations of various stakeholders. The need
for rigid written specifications is one of the myths that surrounds
offshore development. When you have people in different locations it
will always be more difficult to communicate, but this barrier is much
lower than most think.

Personal communication, where ideas and cooperation are valued,
results in a new level of openness. Open communication means being
able to communicate ideas, thoughts, and differences irrespective of
the forum. It is also tightly related to the free flowing
communication mention in the previous section.

THE SPONSORS VIEW

Ultimately, it's the sponsor that shapes the environment that an
offshore team works in. Without his support it is not possible to
achieve the things that where discussed above: a communicative and
integrated team that has a solid trust relationship with the
organization.

The sponsor, in this context, is the entity that is responsible for
allocating funds for the offshore team. It can be the company CEO,
board members, department head, etc.

The sponsor needs to understand that it's in his interest to keep a
good long-term relationship with the offshore team. In particular,
understanding the cost-benefit aspect of maintaining this relationship
is key. When an offshore effort is started people tend to focus on the
cost aspect. It is one of the driving factors, and it can therefore be
difficult to accept changes to the original cost expectations. In most
cases, the "hidden" costs of moving development offshore are much
higher then expected. But, that is mostly because the expectations
where off in the first place. Expecting that you can come away with
spending less money on the "softer" issues of your offshore team than
your local team is an illusion.

The sponsor needs to understand the cultural aspects that can prevent
the offshore team's integration. He needs to set an example of support
for the offshore team. At the same time he needs to communicate
clearly to the existing employees with respect to the companies
plans.

Irrespective of their geographical location everybody associated with
the company should be treated equally, and given the same attention.
The company should invest in its offshore team members by making sure
they receive the necessary trainings and courses. Team building
activities are just as important for your offshore and local team
members.

Some may argue that it's the offshore vendor's responsibility to
handle these "soft" issues. It's is in the vendors interest to nurture
their staff, and this is one of the criteria that should be taken into
account when selecting a vendor. However, relieving yourself of all
responsibility in this area, and taking a passive stand, is harmful to
your organization in the long run. Being an active partner in shaping
and motivating your team can only enhance and protect the intellectual
capital that you will accumulate in the offshore team.

It's important that to have a more personal relationship between the
sponsor and the offshore team. The trust and openness that are
described above need to flow down from the sponsor. You cannot install
these as foundations of your organization unless it is equally
embraced by all.

EPILOGUE

The need for dedicated offshore teams of qualified knowledge workers
will increase. This offers companies the chance to recruit long-term
team members, and thereby, indirectly increasing their intellectual
capital. This is in contrast to the more "drone" based mindset that
sometimes is associated with offshore enterprises. However, for this
to be possible, it is necessary to align your offshore efforts so that
they support long-term, trust based relationships. The geographical
barriers should not distract from applying the same principles for
nurturing people located offshore or "on location". Most global
corporations archive this every day, it is only an incorrect mindset
and distorted expectations that prevent many companies from doing the
same for their offshore teams.

Cultural differences are an important parameter, and many of the
things I have discussed are not easily applied in cultures where a
command-and-control model is deeply integrated into society. In the
search for cheaper knowledge workers, the industry tends to shift from
one region to another. New offshore markets, such as China and Africa
will become mainstream in the near future. It's important to realize
that the apparent cost savings of these new regions are somewhat
offset by not being able to integrate these knowledge workers in the
same way.

Ragnar Birgisson for Agile Ukraine, June 2007, see the discussion thread

2007/05/26

User Stories: a mindmap and a quick overview

Below is a simple mindmap for "Stories"

It gives a quick overview of the user story "concept" and how we used
it in our project. In short we:

Write small, deliverable, user stories ( 3-5 days )
Store them in Jira and on sticky notes
Include in each story a brief summary that highlights what it does,
why its valuable, and several tests
Evolve them from simple reminders, to placeholders for our
understanding, and finally an agreement on when we are "done".

This gives us some advantages:

(1) We are able to be more flexible since the details can be fleshed
out when the time is right
(2) We are able to collaborate and focus on verbal communication
instead of passing on written documents

I'll elaborate a bit on of each of these points.

Writing small, deliverable stories

Finding the "right" size for your stories is somewhat tricky. Since
people have very differnet ways of specifing "size" you are likely to
have to experiment and go with what fits your team. For us, it seems
that we have had most success with stories that a single developer
would use 3-5 days on.

Storing in Jira and on sticky notes

The simplest storage method is just to write things on a sticky note
and place it on your wall. It's quick, easy, and visible. Using some
software to store them can also be quite useful. In an offshore
situation that kind of becomes necessary.

Even if you use some software place to store your stories, I have
found that it's good to keep writing those sticky notes and getting
them up on the wall. This way the stories are always visible to
everybody, and there is also just a "feel good" factor in "physically"
taking them down when you are done.

Include in each story a brief summary that highlights what it does,
why its valuable, and several tests

One of the more tricky things is finding out how much to put into a
story. Again, this depends on how your team feels about it.
Before we started using stories we have some small "specifications".
These where typically a few pages with some text and screenshots.
Switching to user stories can be a slight shock to the system. The
most common question I got was, "Where are the details?".
Well, we do actually have a lot of "details" in our stories. These are
represented by the tests and an a GUI prototype. User stories are not
about masking out details. In order to deliver the story you need to
flesh out these details ( as it becomes necessary ), and in most cases
write them down as tests. In my world, the difference between user
stories, and some kind of "specification" is not really that big. It's
how you get there that counts. It's the collaborative, lightweight
"process" of going from an idea to an understanding of when a story is
"done".

In my experience, one of the biggest challenges is to make sure we
actually do the things necessary to make stories work. If you don't
discuss them properly, sincerly write down the tests, and collaborate
during them whole process, then your stories become more of a problem
than a solution.

Evolve them from simple reminders, to placeholders for our
understanding, and finally an understanding of when we are "done"
The reason why stories work is that they are flexible and demand that
you collaborate. A story starts out just as a simple reminder of a
discussion with the client. It evolves as you discuss it with other
people in the team, and you flesh out some details. In the end it
guides you towards aswering that simple question, "when are we
done?".

Ragnar Birgisson, Mar 07, for Agile-Ukraine Google group,
see the discussion thread

2007/05/24

War room или настенная живопись

Большая комната.
Неисчерпаемый запас sticky notes для каждой новой истории или бага.

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

Во время утреннего митинга (или в любое другое время) стики переклеиваются в соответствии с обновленным состоянием, двигаясь от сектора "not started" до "accepted".

На стене практически у всех на виду постер с sprint burndown - обновляется маркером в соответствии с обновленными оценками по историям, которые ведутся в Jira.

На торце стены - "коллекция" закрытых историй и багов из предыдущих спринтов и релизов.

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

Недалеко маркерная доска, поставленная на стул на колесах. На ней можно писать, не вставая из-за столов для совещаний.

Поотдать - flip chart с отрывающимися и переворачивающимися листками A2.

Куча маркеров.

Алексей Кривицкий для Agile Ukraine, May 07

2007/04/07

2007/04/04

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

«Разработка ПО - это игра изобретательности и кооперации»
Элистер Коуберн (1)

О чем эта статья?

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

Эта статья рассказывает о применении «user stories» («пользовательских историй») - одной из практик agile. Далее для краткости я буду называть их просто «историями».

Для кого эта статья?

Эта статья для профессионалов по разработке программного обеспечения: менеджеров продуктов, менеджеров верхнего и среднего звена, лидеров команд, аналитиков, программистов, инженеров по качеству – всех тех, кто понимает важность тесного взаимодействия заказчиков и команды и ищет более эффективные способы взаимодействия. Для всех тех, кого интересуют agile подходы.

Понимание agile принципов весьма приветствуется при прочтении этого материала, хотя это необязательно: вы можете выбрать для себя принцип «от частного к общему», начав с этой статьи. Ссылки в конце статьи могут быть полезны для дальнейшего ознакомления с Agile подходами.

Как структурирован этот материал?

В первой части (которая начинается буквально через пару абзацев) речь пойдет о принципах, стоящих за историями, и тем, какие преимущества получит проект от их применения.

В следующих частях я попробую изложить такие важные моменты, как планирование проектов с использованием историй, оценки стоимости и длительности проектов, также коснусь некоторых более сложных и тонких ситуаций с использованием историй, в частности таких как: возможность использования историй в аутсорсных проектах; варианты хранения историй; сложности, с которыми вы можете столкнуться (и дай Бог столкнетесь), начав использовать истории в своих проектах; также поделюсь своим личным опытом от использования историй.

Ваши комментарии помогут мне определить другие важные моменты, которые я обязательно постараюсь описать.

Email: alexey@krivitsky.com

Как я познакомился с User Stories

Скажу честно, пока я не прочел книги Майка Кона (3), я не верил в то, что этот подход жизнеспособен. Я читал книги по экстремальному программированию (4), про то, как заказчики высказывают требования в виде коротких фраз и обсуждают их с командой, - но все это было далеко от моего понимания, в прочем, как и другие особенности XP... И мне кажется, я был не одинок.

К тому моменту, когда мне попались книги Майка, мой проект уже работал по Scrum (5), и я, видимо, уже созрел для восприятия более «крутых» тем из agile. Одной из таких тем для меня стали пользовательские истории.

User stories: экстремальный подход

Как и все другие идеи из agile, идея историй (если отбросить все предубеждения) весьма прозрачна и логична, как говорят: «it’s about common sense» (5).

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

Итак, вместо того, чтобы тратить время на написание, согласование и обновление спецификаций о требованиях к будущему продукту, заказчик (см сноски внизу) делает короткие высказывания о том, как пользователь будет пользоваться будущей системой. Будучи собранными в том или ином виде, эти высказывания используются для последующих обсуждений с проектной командой. В ходе обсуждений начальные идеи, заложенные в первоначальных высказываниях, обрастают деталями. Такими деталями является все, что поможет команде во время реализации истории помнить о нуждах пользователя – это различные уточнения, ограничения, немаловажные критерии готовности.

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

Почему же обсуждение требований так важно?

Заказчик не может учесть всех аспектов продукта самостоятельно, так как требования должны «лечь» на технологии. Только совместные усилия заказчика и команды в поиске решений и компромиссов дают оптимальные результаты;
Детализация требований посредством обсуждений дает возможность всем участникам понять суть требований и, так образом, обзавестись базой для принятия оптимальных решений;
Изначально упуская некоторые аспекты историй и оставляя тем самым место для дискуссий, заказчик расширяет область поиска решений. Это приводит к расширению кругозора участников проекта и, как следствие, к предпосылкам нахождения более приемлемых решений;
Свобода поиска решений является отличным мотивирующим механизмом, что делает повседневную работу команды более интересной.

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

Какой заказчику от этого плюс? Кроме преимуществ перечисленных выше, - это отсутствие необходимости описывать детали до того момента, когда без них просто нельзя обойтись, что является хорошим способом сэкономить время. И вправду – зачем продумывать до мелочей то, что может существенно измениться, или что ещё хуже – вообще перестать быть необходимым.

Довольно тяжело объяснить сходу все аспекты и плюсы от использования историй – динамичной и легковесной базы для хранения требований. Давайте лучше попробуем разобрать некоторые из них на примере.

Как это работает на практике? Пример написания историй

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

Это короткое предложение – ничто иное как видение (vision) системы. Его вполне достаточно для того, чтобы начать описывать истории. Но сначала, давайте идентифицируем группы пользователей – истории будут рассказаны от их имени. Знание о будущих пользователях поможет нам сфокусироваться на нуждах каждого из них, не упустив важные моменты в требованиях к системе. И так, разными аспектами системы будут пользоваться такие обобщенные пользовательские роли:

Те, которые хранят и обмениваются своими фотографиями – назовем их «пользователи».
Те, кто размещают свою рекламу, ориентированную на «пользователей» системы – назовем эту группу «рекламодатели».
Хотя видение системы явно и не обговаривает задачи по администрированию системы, но так или иначе у системы будут «администраторы», которые будут обеспечивать поддержку системы для блага других пользователей

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

Так, имея роли пользователей и их основные задачи, попробуем описать самые важные истории, которые могли бы нам рассказать о будущей системе. Истории предлагается писать в таком формате:

Как <пользователь>, я могу <действие>, для того, чтобы <цель>
где
<пользователь> - одна из обобщенных пользовательских ролей;
<действие> - действие, выполняемое пользователем посредством взаимодействия с системой;
<цель> - конечная цель текущей задачи, выполняемой пользователем посредством взаимодействия с системой.

Этот формат себя хорошо зарекомендовал – он поможет нам во время продумывания и последующего обсуждения историй персонализировать себя с тем или иным пользователям, помогая лучше представить детали их взаимодействия с системой. Последняя часть <цель> может быть опущена, если цель истории и так ясна. Формат – не догма. В будущем вы сможете придумать для себя тот формат, который для вас будет лучше работать, пока что предлагаю использовать предложенный Майком Коном.

Итак, истории:

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

2 Как рекламодатель я могу помещать свою рекламу в системе, ориентированную на пользователей.

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

Во время обсуждения первой истории, заказчик и команда приходят к тому, что пользователи системы должны быть авторизированны системой перед выполнением каких-либо действий с фотографиями. Это приводит к появлению новой пользовательской роли «гостя» - группе людей, которые неавторизированны системой или вообще пока не имеют пользовательской учетной записи.

4 Как гость я могу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы.

5 Как гость я могу войти в систему под ранее созданной учетной записью, для последующей работы.

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

6 Как пользователь я могу удалить свою учетную запись и перестать быть пользователем системы.

Обсуждая концепцию учетных записей, рождаются также следующие истории:

7 Как пользователь я могу изменить данные своей учетной записи.

8 Как пользователь я могу сделать некоторые поля своей учетной записи видимыми для других пользователей.

Просто? Достаточно. По крайней мере, не сложнее, чем писать спецификации. Но дальше - интереснее.

Вопросы?

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

Куда делись детали?

Первый вопрос, который задает человек, который привык работать с более тяжеловесным подходом к требованиями (основанным к примеру на подходе Software Requirements Specifications из RUP), это «куда подевались детали?»

Это вопрос затрагивает ключевой аспект использования историй. Попробую коротко объяснить.

Конечно, детали есть, и их никто не отменял – как без понимания деталей программист может написать адекватный код, а тестировщик его принять? Детали необходимы. Но использование историй смещает суть и время выработки деталей.

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

Пример детализации.

Рассмотрим одну из историй, идентифицированную выше:

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

К истории дописывается этой комментарий. Теперь история выглядит так:

Нужен проверенный email и выбранные пользователем имя и пароль.

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

Нужен проверенный email и выбранные пользователем имя и пароль.

Тест 1: пользователь не может ввести пароль меньше 6 символов

Тест 2: пользователь не может ввести имя меньше 3 и больше 20 символов

Тест 3: пользователь должен иметь уникальное имя в системе

Тест 4: после регистрации пользователь должен получить имейл для активизации своей учетной записи

Тест 5: пользователь не может войти в систему, если учетная запись не была активизирована

Тест 6: при успешном входе система приветствует пользователя текстом «Добро пожаловать, <имя пользователя>»

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

Таким образом истории пополняются деталями по мере необходимости, эволюционируя от коротких высказываний до детализированных и согласованных требований со встроенными критериями готовности.

Мощные инструменты работы с историями: упорядочивание, разбиение и группировка

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

Если же истории независимы, да к тому же их достаточно много, то можно смело предположить, что их ценность с точки зрения вклада в систему различна. А значит, варьируя порядком историй, можно выставить их в таком порядке, что первые «n» историй будут играть ключевую роль в полезности системы, в то время как другие истории будут скорее необязательными добавками, привлекающими пользователей или облегчающими их работу.

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

Вот пример, как могли бы быть отсортированы истории вышеописанного проекта (это всего лишь один из вариантов, конечно, есть и другие):

4 Как гость я могу зарегистрироваться в системе для получения пользовательской учётной записи и последующей работы.

5 Как гость я могу войти в систему, имперсонализируясь с ранее созданной учётной записью, для последующей работы.

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

7 Как пользователь я могу изменить данные своей учетной записи для корректировки измененных или неверных данных.

2 Как рекламодатель я могу помещать свою рекламу в системе, ориентированную на пользователей.

8 Как пользователь я могу сделать некоторые поля своей учетной записи видимыми для других пользователей.

6 Как пользователь я могу удалить свою учетную запись и перестать быть пользователем системы.

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

Конечно, порой не так легко и очевидно принять правильное решение о порядке историй, но в этом и состоит мастерство быть заказчиком (это отдельная, неисчерпаемая тема...)

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

В этом случае заказчик и команда могут попробовать разбить ее на несколько более мелких историй, каждая из которых может получить свой приоритет:

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

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

При этом нужно учесть, что начальная история не разбивается на две «под-истории», а замещается двумя новыми. Это не разбиение историй на подзадачи для постановки их программистам, это всего лишь переформулировка требований для более эффективного управления ими.

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

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

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

Как вы до сих пор справлялись с подобными задачами?

Динамика знаний

Программный продукт – это не только код и документация. Это также знания о пользователях, рынке, особенностях продукта, технологиях и прочее. Если же проект – это развитие продукта, то тогда в нем должны гармонично изменяться все его составные части: код, документация и знания. А, следовательно, знания динамичны. Таким образом, что вчера казалось фактом, сегодня в свете новоприобретенных знаний таковым может уже не быть. Для историй это значит, что порядок приоритезации историй, сделанный вчера, уже сегодня, возможно, должен быть изменен.

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

Вот ещё один плюс хранения требований в виде списка относительно независимых историй. Его в любой момент можно пересортировать, добавить новые или удалить ненужные истории. Хранение требований в виде историй не препятствует динамичности знаний, а наоборот, базируется на том, что наши знания будут и должны меняться, иначе продукт �