Съдържание на статията
Agile – ключът към управлението на проекти в динамична среда
2 стр. - Практиките
3 стр. - Extreme programming (XP)
4 стр. - Scrum
5 стр.- Feature-Driven Development
6 стр.- Crystal
7 стр. - Dynamic System Development Methodology
8 стр. - Заключение
Всички страници

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

Най-динамично развиващи се обаче, безспорно са телекомуникациите и информационните технологии. За тези области класическата теория на управление на проекти просто е твърде статична. Тя не позволява ефективно и икономично управление на постоянните промени в изискванията и обхвата на проектите, причинени от непрекъснатия поток от нововъведения.

Не случайно именно в една от тези области, софтуерното производство, възникна и се разви принципно ново направление в управлението на проекти, наречено Agile Software Development. В предишната статия (CIO 6/2007) цитирахме краткото и изразително описание на ценностите, които Agile изповядват в своя Манифест от 2001 година (www.agilemanifesto.org ):

  • специалисти и комуникации, а не процеси и инструменти
  • работещ софтуер, а не изчерпателна документация
  • взаимодействие с клиента, а не придържане към договори
  • реакция на промените, а не следване на плана

Методологията Agile „възстава“ срещу:

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

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

В тази статия ще се опитаме да дадем повече информация за различните конкретни Agile методологии и тяхната практическа реализация.


Практиките

Вместо единен процес Agile методологиите са комбинация от отделни методики, наричани „практики“, които могат да се комбинират произволно.

Практиката е начин на решаване на конкретен аспект от даден технически или организационен проблем. Практиката има три компонента:

  • как да идентифицираме и опишем проблема
  • стратегии как да решим проблема
  • метод да проверим дали решението е добро

Въпреки абстрактната формулировка, добре описаните и усвоени практики са чисто практическо оръжие за ежедневна употреба.

Различаваме четири типа практики:

  • технологични - свързани с процеса на разработване на продукта: например архитектурни шаблони, test-driven development, domain models...
  • социални - свързани с работната среда, взаимодействието на участниците в проекта и споделянето на отговорностите: например самоорганизиращ се екип, споделена отговорност, обща стая, бяла дъска...
  • организационни - свързани с организацията на работния процес: например ежедневни срещи, работа по двойки, user stories, backlog...
  • процесни - характеризиращи процеса на разработка - например къси итерации, постоянна интеграция, приоритизация на разработката от клиента, принцип „MoSCoW“...

Agile методологията позволява свободно комбиниране на различни практики в зависимост от нуждите, опита и вкусовете на екипа. В това е основната разлика с класическите методики за управление на проекти.

Публикувани са огромен брой практики от всеки вид (често авторите самохвално ги наричат „best practices“). Някои от тях се комбинират добре, други – не толкова. Големият избор е едновременно и полезен, и вреден – не е лесно да комбинираме „нашата“ селекция от практики. За щастие съществуват над 10 „преконфигурирани“ Agile методологии, чиито автори обикновено са най-изявените пропагандатори на Agile.

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

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

  • разработването се прави на къси итерации
  • клиентът итеративно получава работещи версии на системата
  • качеството е приоритет номер едно
  • обикновено целият екип е събран на едно място – в една зала, за улесняване на неформалната комуникация
  • информацията за развитието на проекта е на общодостъпно място – на стената в работната зала
  • постоянно взаимодействие с клиента и постоянен поток на информация към и от него
  • промяната дори и на работеща подсистема се възприема като нещо нормално

Ще опишем накратко най-популярните Agile методологии и най-характерните практики в тях.


EXTREME PROGRAMMING (XP)

XP е безспорният флагман на Agile философията. Както личи от името, тука всичко е „екстремално“. Авторът Кент Бек прави простото разсъждение: „Щом нещо е добро, да го усилим в максимална степен“ и от това създава работещи ХР практики:

  • щом общуването е добро, да го правим постоянно – общо помещение и др.
  • щом взаимодействието с клиента е добро, да го правим постоянно – представител на клиента като част от екипа
  • щом тестването е добро, да го правим постоянно – автоматизирано тестване, тестване преди кодиране
  • щом интеграцията е добра, да я правим постоянно – ежедневна интеграция (и нощни автоматизирани интеграционни тестове)
  • щом внедряването е добро, да го правим всяка седмица – седмична инсталация на работеща система
  • щом преглеждането на кода (code review) е добро, да го правим постоянно - програмиране по двойки
  • и т.н.

ОТ ТАКИВА РАЗСЪЖДЕНИЯ СЕ РАЖДАТ ОСНОВНИТЕ ПРАКТИКИ НА ХР. НАЙ-ИНТЕРЕСНИТЕ ОТ ТЯХ СА:

Постоянен представител на клиента в разработващия екип

Интересно и доста трудно за изпълнение изискване, но така се решава почти напълно проблемът с комуникацията. Всички недоразумения се откриват и дискутират на възможно най-ранен етап. Освен това така се засилва и отговорността на клиента към развитието на проекта.

Събиране на спецификациите във формата на "истории" (user stories)

Обикновено се очаква изискванията към системата да бъдат максимално пълни и подробни. Не и в ХР! Тук подробните спецификации се заменят с user stories – кратки описания на функционалността, не повече от няколко изречения, само най-важното без подробности. Знаем, че подробности има, както има и специални случаи, обработка на изключения и т.н. Но не искаме в самото начало всички те да са подробно описани, просто защото не винаги е възможно. Подробностите се уточняват в процеса на разработка – нали имаме представител на клиента подръка във всеки момент! Блестящ пример за рационално отношение към документацията!

Споделена отговорност за кода

Всички членове на екипа отговарят за всеки аспект на кода, няма архитекти, разработчици на база данни, на интерфейс и т. н. Знанието за проекта се споделя между членовете на екипа и се намалява риска при напускане на някой от тях „да се оголи някой фронт“. Всички могат компетентно да участват в обсъждането и решаването на всеки възникнал технологичен проблем. За реализацията на тази практика се окуражава ротацията на задачите между членовете на екипа. Необходими са обаче много добри, широко профилни софтуерни специалисти

Програмиране по двойки

Окончателният код се пише като програмистите се разделят по двойки. Единият пише, другият контролира като постоянно тече обсъждане. В даден момент ролите могат да се разменят. На пръв поглед това изглежда много странна практика. В действителност обаче така много силно се намалява възможността за логически грешки. В крайна сметка рязкото повишаване на качеството на кода многократно компенсира двойно по-голямата загуба на работно време. Между другото, лично съм наблюдавал как при кодирането на някой особено проблемен епизод програмистите сами се събират по двама или трима на един компютър и след решаване на задачата се разделят.

Минимална архитектура, максимална простота

Основна ценност на ХР е максималната простотата. Всяко усложняване на архитектурата с оправданието, че „това може да ни потрябва по-нататък“ е неуместна – ние не знаем какво ще поиска клиентът по-нататък!

Предварително писане на тестове

Още един „бисер“ на ХР е писането на тестове преди писането на самия код. Кент Бек, авторът на ХР, казва: „Напишете фрагмент как бихте искали да използвате кода. Това е вашият тест. После напишете кода така, че тестът да мине“. Лично мога да гарантирам, че така се проектира много по-удобен и качествен код.

Самодокументиращ се код

Още един цитат от Бек: „Тестовете са най-добрата документация на работещия код. Няма нужда от друга.“ И наистина, за какво е нужна документацията на кода? За да може този код да се поддържа във времето дори и от други програмисти. За нищо друго! Тогава каква по-добра документация от тестовете (които по същество са примери за използването на кода) заедно с коментарите в самия код.

Това са най-ярките практики от колекцията на ХР.

Повечето от практиките в тази методология са от групите на технологичните и социалните. Организационни и проектни практики екипът трябва да избере сам. От друга страна, останалите Agile методологии почти не дефинират технологични и социални практики (или те се покриват с ХР). Това позволява ХР практиките да се използват свободно в останалите Agile методологии.

Успелите да внедрят ХР в своята организация твърдят, че „са се родили отново“. Това обаче не е лесна работа. Първо, трябва да разполагаме с екип от равностойни по качества добри специалисти. Второ този екип трябва да възприеме някои непривични начини на работа. Ето защо ХР в чист вид рядко се прилага. По-често тази методика се използва като „извор“ на добри технологични и социални практики за попълване на слабите страни на другите Agile методологии.


Scrum

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

Scrum процесът се състои от отделни итерации, наречени спринтове. Обикновено дължината на спринта е един месец. В края на всеки спринт се инсталира версия на системата. Провежда се среща с клиента и се преминава приемателен тест.
На последващото обсъждане с клиента се оценява резултата от разработката и се набелязват целите за следващия спринт. На отделна среща на разработващия екип целите се разбиват на задачи, всяка задача се оценява като време и се разпределя на някой от разработчиците. Задачите се записват в специална таблица, наречена backlog, която се обновява всеки ден и показва количеството оставаща работа до края на спринта.

По време на спринта всеки ден се провеждат т.нар. правостоящи срещи (standing meetings). Тези срещи продължават от 5 до 15 минути и се провеждат всеки ден в определен час. На срещата всеки от екипа абсолютно неформално разказва за три неща:

  • какво е работил предишния ден
  • какво планира за предстоящия ден
  • какви проблеми е срещнал, които му пречат да работи
На срещата се обновява и backlog-ът като се отбелязва свършената работа. Ако се идентифицират някакви проблеми, те се решават колективно. Важно е да се отбележи, че това не са срещи за отчет пред ръководството, а за синхронизация (самоорганизация) на екипа и разкриване на потенциални пречки в работата. Специфичните практики на Scrum са:
  • Ежедневни правостоящи срещи (Standing meetings)
  • Backlog: списък със задачите за текущия спринт и тяхното състояние
  • Burndown chart: графичен еквивалент на backlog, показващ оставащата работа в проценти или работни часове
  • Самоорганизиращ се екип: екипът не следва предварително раздадени задачи, а всеки негов член се стреми да допринася за постигне целите на спринта – всеки ден всеки си взима задачи, за които отговаря
  • Работни срещи и обсъждания с клиента и с екипа след всеки спринт

Scrum е добре развита и документирана методология. Има и сертифицираща процедура.


Feature-Driven Development (FDD)

Тази методология поставя акцента върху разбиването на общия проект на множество по-малки, всеки от които се занимава с едно свойство (feature) на системата. На първоначалния етап системата се декомпозира на отделни компоненти (subject areas), които съдържат групи свойства (feature sets), които от своя страна се състоят от множество свойства (features). Всяко свойство се описва функционално с израз от типа (on\for\to\over\from), например „add task to project“. По-нататък цялата разработка се групира в итерации, като за всяка итерация клиентът избира свойствата, които да се реализират. Спецификациите на отделните свойства се детайлизират в същата итерация, в която те се разработват, а не по-рано.

FDD дефинира пет специфични процеса:

  1. Разработка на общ модел
  2. Изготвяне на списък със свойства
  3. Планиране по свойства
  4. Дизайн на свойства
  5. Разработка на свойства

Първите два процеса се изпълняват в началото на проекта, а последните три се изпълняват в цикъл през всяка итерация и за всяко свойство.

Фокусът на FDD е в максимизирането на стойността за клиента чрез приоритизацията, която той прави на свойствата на всеки етап. Друго много важно качество на FDD е възможността за паралелна работа на много екипи. Това е възможно понеже на ранен етап на проекта имаме създаден списък от свойства и по-нататък всяко свойство се разработва самостоятелно.


Crystal

Под това име всъщност се крие не една, а цяла фамилия методологии. Коя от тях е най-удачна за конкретния случай зависи от това доколко голям е екипа и доколко критичен е продуктът.

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

Размерът на проектния екип е втората класификационна характеристика. Това е една от малкото Agile методологии, която осигурява мащабиране: промяна на методологията при промяна на критичността на проекта и на разработващия екип. Crystal се отличава и с други характерни практики. Например фокусиране – всеки член на екипа има максимум 2-3 задачи в текущия си списък, с ясен приоритет между тях (това допринася за елиминирането на мултитаскинга, което винаги е добра обща практика). Итерациите на разработка могат да са по-дълги – два до три месеца.


Dynamic System Development Methodology (DSDM)

DSDM е методология, развита през 90-те години в Англия. Тя предлага развита структура от управленски практики. Заедно с това е независима от прилаганите практики за разработка и контрол. Това е единствената Agile методология, която се развива от отделен консорциум като цялостна управленска методология.

Ключовият момент в DSDM е приемането, че проектите са с фиксиран срок и бюджет. Така единствената променлива величина остава обемът на работата. Разработката се провежда така, че да се максимизира текущата полза за клиента. Това е фокусът на тази методология.

Специфичните използвани практики са следните:

Приоритизация на изискванията по принципа MoSCoW. Това съкращение означава Must-Should-Could-Would изисквания. Всички изисквания се класифицират в една от четирите категории:
  • Must - задължителни за реализация
  • Should - изисквания, които не са критични за работата на системата, но са много полезни
  • Could - тука попадат изискванията, които на жаргон наричаме "глезотии"
  • Would - идеи за бъдещи разширения.

Класификацията се извършва от клиента - той решава кое колко е важно. Интензивно се използва принципа на Парето (правилото 80/20) във вида "20% от функционалността покрива 80% от нуждите на клиента".

Timeboxing

Този общ термин за срока на итерацията тука има допълнително значение. За всяка итерация времето и бюджетът са фиксирани. Така единствената променлива остава обемът работа. За итерацията се избира група от функционалности, които де се реализират. Те се подреждат по MoSCoW принципа. Абсолютно задължително е всички задължителни ("Must") изисквания да са изпълнени, както и повечето от групата "Should". От там нататък до края на итерацията се изпълняват по-малоценните изисквания (тъй като срокът и бюджетът са фиксирани). По такъв начин на всяка итерация се гарантира, че за срока и парите си клиентът получава най-полезната за него функционалност (тъй като той задава приоритетите). Това е интересен начин да се елиминира понятието закъснение на проекта.

Прототипи

Практически всяка итерация се състои от създаване и оценка на прототипи на системата.

Workshops

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

Всеки DSDM проект преминава през три фази:

  • предварителен (pre-project)
  • жизнен цикъл (life cycle)
  • финален (post-project).

Предварителната фаза е организационна: идентифицира се проектът, целите, какви проблеми трябва да се решат, екипът, финансирането и т.н. Финалната фаза включва внедряване, обучение и последваща поддръжка. В тези фази няма никаква специфика. Жизненият цикъл на проекта е подчинен на главното предположение на метода: срокът и бюджетът са фиксирани, променливи са спецификациите.

Жизненият цикъл включва:
  • Етап "Оценка на изпълнимостта (feasibility study)": изпълнимост, полезност, рискове
  • Етап "Бизнес планиране (Business study)": приоритизация на функционалностите (метод MoSCoW)
  • Общо планиране на системата, планиране на етапите, допълнителни рискове и т.н.
  • Цикъл от итерации - всяка итерация има строго определена продължителност - timebox.
Итерацията включва:
  • Определяне на изискванията за итерацията и тяхната категоризация по принципа MoSCoW
  • Функционален модел (Functional model iteration)
  • Дизайн и реализация (Design and build iteration) - преминава се през създаване на няколко прототипа (мини итерации), реализиращи исканата функционалност и техните оценки и модификации. Всеки прототип е преминава през дизайн, кодиране, тестване и обсъждане (workshop) заедно с клиента. Всеки следващ прототип включва нови функционалности и коригира вече направените, в съответствие с изводите от обсъждането.
  • Внедряване (Implementation) - окончателният прототип се кодира и тества "официално" и се пуска в експлоатация.

DSDM е изцяло изградена от практики за управление на проекта. Тя не дефинира и не ограничава използването на практики от останалите типове. Всяка организация може да избере собствен набор от инструменти, например backlog и "правостоящи срещи" от Scrum, програмиране по двойки от XP и т.н.
Ремонтът на вече реализирани функционалности не е повод за безпокойство. Приема се, че "нищо не може да бъде направена перфектно от първия път".
DSDM е най-формалната и „най-церемониалната“ методология от семейството на Agile. Това я прави най-предпочитаният кандидат когато формалната страна е от значение, например при държавни и държавно-финансирани проекти.

Жизненият цикъл на проекта според DSDM

  • Оценка на изпълнимостта
  • Бизнес планиране
  • Итерация на функционалния модел Планиране, Идентифициране на функционален прототип, Разглеждане на прототипа, Създаване на функционален прототип
  • Имплементация – Внедряване, Обучение на потребителите, Одобрение от потребителите, Преглед за нови бизнес потребности
  • Итерация на дизайн и реализация - Планиране, Идентифициране на функционален прототип, Разглеждане на прототипа, Създаване на функционален прототип


Има и много други Agile методологии, например

  • Agile Unified Process (AUP) – модификация на класическият UP в Agile стил
  • Domain Driven Development – моделно – ориентирана методология
  • Lean Software development – по аналогия с концепцията Lean в производството, която акцентира на елиминирането на загубите и постоянното оптимизиране на процесите

В заключение...

  • Agile методологиите за управление на проекти отдавна са превзели софтуерната индустрия. Те стават все по-популярни и в други сектори, където класическото управление на проекти изостава от динамиката на развитието.
Йордан Николов
Виж оригинала