Похоже, но не agile

Вспоминал недавно один из своих первых проектов:
- Маленькая команда - два человека
- Локальные заказчики доступные практически в любое время
- Последняя стабильная версия всегда у них под рукой
- Регулярные демонстрации достижений последней недели или двух
- Открытое обсуждение новых фич, быстрая смена курса

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

Попробую понять в чем же дело:

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

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

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

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

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

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

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

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

Последний год-полтора использование термина agile стало мощной рекрутинговой стратегией. Объявления о поиске программистов так и хлещут agile терминологией. Будьте бдительны - пойдите на интервью, поговорите с непосредственным лидом проекта, зайдите в проектную комнату (если таковая вообще имеется!), поговорите с будущими коллегами, расспросите про заказчиков, про процесс разработки, узнайте, когда последний раз продукт показывался пользователям и есть ли в проекте какая-то информация об этом, попросите показать вам план релиза, над которым работает команда в настоящий момент. Проведите как минимум полчаса в проектной обстановке, следите за атмосферой, проблемами и вопросами, которые обсуждают члены команды - имеют ли они общие цели, знают ли они над чем следует работать в настоящий момент.

Не торопитесь делать скоропостижные выводы.

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

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

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

Полный текст статьи тут.

что составляет грунт для agile проектов? попытки анализа

Обсуждая с коллегами по agile движению, что означает для программистов "agile" (сообщения дискуссии доступны здесь), я пришёл для себя к следующим выводам:

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

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

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

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

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

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

----
Таковы мои мысли на сей счет на сегодняшний день.
Есть другие мысли? идеи? комментарии? - давайте общаться.

Велик и могуч...

Из серии «Об agile по-русски».

Велик и могуч... термин «agile».

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

Но начнем пока с «начала».

"Начало начал". Притча.

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

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

Таким образом ситуация пошла против природной нестабильности требований к ПО.

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

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

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

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

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

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

В поисках крепкого словца...

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

Если попробовать охарактеризовать разные стороны этих подходов, то выйдет нечто следующее:

«Облегченность» (или «Легковесность»)

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

«Гибкость»

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

«Адаптивность»

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

«Прозрачность»

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

«Проворность»

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

«Осмысленные»

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

Итого

«Облегченногибкие адаптивнопроворные прозрачныеосмысленные методологии разработки программного обеспечения»...

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

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

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

Вам жалуются на то, что команда отклоняет изменения в требованиях, ссылаясь на контракт и указывая на утвержденную процедуру change request management, из-за чего разрабатываемых продукт не будет максимально полезен заказчикам и пользователям? Поговорите с ними об аспекте «гибкости».

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

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

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

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

P.S.

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

agile planning (planning over plans)

i had experience using deterministic old-school approached (like MS
Project's Gantt charts), which i was keeping in my tool set for quite
a long time,

i did task decomposition, resource assignment and leveling,
milestone definition...

this all was quite useful while i was doing that because it made me think
of the project risks, complex dependencies, the team's capabilities
and other topics important for project success.

but as soon as i published my plans and tried to stick to them - they
quickly became obsolete and useless. it appeared i just couldn't predict everything and eventually the projects went a bit different direction.

......

since i've been doing agile i don't have this problem anymore.
why? simply because i never stop planning.

i highly recommend Mike Cohn's masterpiece Agile Estimations and Planning this book is not about plans, rather it is about planning once you start using user stories as your main requirements media, you will gain even more flexibility in planning and hence obtain more control over the project. planning will become a solid practice being done by the whole team during the coarse of the project. also the user stories will foster idea sharing between product managers and engineers, will provoke creative and positive thinking

......

visit the discussion thread

Scrum trainings and other events in 2007

This is to announce, that I am currently working on a plan of trainings and various other common activities on agile topics, to be held in Kiev in 2007.

The main goal is to organize CSM (Certified ScrumMaster) certifications in Kyiv (Kiev).

Watch for the upcoming announcements at the agile-ukraine
(subscribe for the mailing list if you're not a member yet).

Currently I am conducting a survey (5 shortquestions) to find out the possible number of attendees, their level of familiarity to Scrum/agile concepts.
Your answers to the survey will help me a lot.

Have good ideas on the subject? Contact me directly by e-mail.

agile-ukraine community was started

Congrats!

Agile-Ukraine community is registered at Agile Alliance.
Visit the home page.

For now it is a Google group with forum and file sharing.

We plan to invite World agile gurus and help them organize trainings in Ukraine.



Stay with us.

Rethinking Sprint Length

Again I've proven my previous experience: two-week sprints are just good enough.
Just because

• the next demo is always soon: simply it is this or the next week - no time to be wasted
• the story set selected for the sprint is never too long and - can be kept comprehensible
• the demos held often enough keeping - the stakeholders are interested and willing to spent 1-2 hours each second week
• ScrumMaster is stressed enough to become a better ScrumMaster :)
  

More on this is in the article published in Agile Magazine's Fall issue, four months ago: link.

The whole issue in PDF can be downloaded from here.

we produce both: code and knowledge

Being a product owner recently I had a discussion with one of the key developers in my team: I reported back an issue (as a user story) and he claims that previously we had agreed on a different solution and now I am changing my mind, and these changes will take quite a big effort.

I understand his concerns, developers don't like to re-work. Who likes?
But my reply is that the time spent on this curve is not wasted, rather it is spent on producing the knowledge.

We produce both: code and knowledge, and this is what software is.

The waste is when no knowledge, no code or no other useful artifacts are produced, otherwise it is investment.

Catalog of Scrum smells

User Stories for scrumsmells.com project

Users

• SP - Scrum practitioner
• Admin - Site administrator
  

Backlog

MUST

• As an SP, I can see an intro to understand why this site is useful
  
• As an SP, I can view the list of smells
• As an SP, I can select a particular smell and see its details
• As an SP, I can add a new smell
• As an SP, I can get a permanent link to a particular smell to share it with other people

SHOULD

• As an SP, I can see the area(s) that the smell related, e.g. "Meetings", "Spring Planning", etc
• As an SP, I can see smells grouped by areas
  
• As an SP, I can see links related to a smell that I am watching

COULD

• As an Admin, I get notified when a user posts a new smell
• As an SP, I can provide more links to an existing smell
• As an Admin, I get notified when a user adds new a link to a smell
  

Links

Published scrum smells on the web:

• a page of Scrum alliance on smells
  
• toward a catalog of Scrum smells, Mike Cohn

Scrum gathering in Kiev 2007.

The 1st Scrum gathering in Kiev is to be held at the office of Ciklum in January-March
(the exact date is to be defined)

The agenda should be defined as we get results from the survey of the attendees.
The preliminary agenda is

Scrum start-up

1. why Scrum ? introduce Scrum for people who are new to it, define benefits why for team, why for customers
   
2. how to start Scrum? provide patterns of starting the 1st sprint
3. why Scrum is difficult? provide a set of examples to let better understand why it is not that easy to do Scrum
   
4. Scrum and requirements management provide different patterns including the approach with user-stories
5. case study: play a Scrum project
   
6. ... to be extended

Scrum complex topics:

1. effective planning meetings
2. effective Scrum retrospectives
3. ...to be extended