Какво е толкова страхотно в Agile? Пример за Agile методология
Agile Определете като Agile системи за управление, които съществуват от известно време, но в последно време печелят валута. Всъщност Agile Management последователно присъства в топ тенденциите за управление на проекти на почти всеки блог за управление на проекти в ИТ всяка година.
Приложенията на Agile в проекти, базирани на ИТ, са безспорни, тъй като намира приложение не само в проектите за ИТ софтуер, но и в разработването на продукти и иновациите.
И така, какво е толкова страхотно в Agile? Попитайте служители, които са преминали от традиционната система към Agile, и те могат да запомнят постоянните срещи и „срещите за срещите“.
Оказва се, че Agile има много повече от просто срещи и обратна връзка. Той се фокусира върху овластяване на екипи и премахване на последователни начини за разработване на проекти, така че да има повече гъвкавост и иновации. Докато това означава срещи и резултати по-често, отколкото при традиционните системи, това също означава, че има по-малък шанс за повторения и промени по-късно в цикъла на проекта.
Той се рекламира като лек за общи проблеми, които пораждат проекти, свързани с ИТ. Какво точно е това и как е по-добро от традиционните системи?
Необходимост от гъвкава методология - практики на управление
Всеки, който е работил по гъвкава методология в проекти за разработка на софтуер, ще има някаква представа за някои от обичайните проблеми, които възникват по време на проекта: промяна в обхвата, срокове, които изглеждат невъзможни за изпълнение, и претоварени ресурси.
Традиционните гъвкави методологии в управлението на проекти имаха много недостатъци, поради които те не успяха да се справят с непрекъснато променящата се бизнес среда, особено в разработването на софтуер, а горните ситуации бяха, за съжаление, твърде често срещани. Това не означава, че традиционните методи не са приложими никъде. Те все още са най-добрият залог за проекти, в които идеята е напълно оформена от самото начало.
Практиките на Agile Management станаха нужда от час, защото задоволиха следните нужди на продукт, пуснат в динамична среда:
- Необходимост от скорост за достигане на продукта до пазара
- Необходимост от гъвкавост за приспособяване на множество промени в спецификациите
- Пропуски в сценария „разделение на труда“
- Дилема на клиента
- Нужда от намаляване на разходите
Нужда от скорост за достигане на продукта до пазара:
Ние живеем в бърза среда, където гъвкавостта и бързината са от ключово значение за успеха.
Технологиите са един от най-бързо променящите се сектори в индустрията. Всяка минута има по-нова идея, продукт или иновация. В този фон традиционният подход за управление на проекти не успява да постигне. Последователният проект непременно зависи от стъпките на гъвкавата методология, които се изпълняват задоволително, за да могат. Сроковете в традиционно управляваните проекти винаги са кост на спора.
Организации и екипи, които не са динамични, ще загубят състезанието за онези, които се преобразяват в съответствие с променящата се среда.
Необходимост от гъвкавост за приспособяване на множество промени в спецификациите:
Очакванията и изискванията на клиентите често се променят в хода на разработването на продукта. Преди системите за управление на Agile да бъдат основни, проектите в ИТ често се проваляха, тъй като традиционната система за управление на проекти е построена така, че да се „задвижва“. Ако имаше някакви промени, клиентите често усещаха прищипването към портфейлите или сроковете си. Традиционният модел за управление на проекти, адаптиран от други индустрии, просто не работеше за динамична индустрия като ИТ.
Разделение на труда:
В традиционния модел има отделни фази, като се започне с анализ на системните изисквания и се стигне до пускането и поддръжката на продукта. Това води до разделение на труда и етикетиране на членовете като „дизайнери“, „програмисти“ или „тестери“. Но в действителност днешните ресурси са изключително многофункционални и такова ясно разграничаване на ролите не е възможно в повечето проекти.
Дилема на клиента:
В нестабилните проекти много често клиентите не са напълно сигурни какъв трябва да бъде крайният им продукт с всички спецификации. Функционалностите и изискванията често се променят, когато се правят части от работата. Традиционните модели като водопадния модел подчертават яснотата по отношение на крайния продукт, а отклоненията в плановете поставят огромен стрес върху системата. Това ни извежда до последния фактор, довел до развитието на Agile системи.
Нужда от намаляване на разходите:
Традиционно промените в изискването по всяко време след стартирането на проекта бяха обезкуражени. По-скоро разходите за всеки допълнителен компонент бяха високи, понякога прекалено много. Поради това беше наложително всички възможни сценарии да бъдат включени в самия етап на планиране. Това означава, че всички сценарии са разгледани и се предлага решение. Но тъй като е почти невъзможно да се знае със сигурност коя част от продукта предпочита потребителят, екипите често разработваха „раздути версии“ на продукта. Това съдържаше всички възможни сценарии, от които типичният потребител би използвал не повече от 20%. Това доведе до ненужни разходи и развитие.
Излишно е да казвам, че това означаваше, че всички проекти са глобални в своето планиране.
И когато се появи изцяло нов непланиран сценарий, така или иначе имаше допълнителни разходи, въпреки цялото планиране.
Група хора се срещнаха през февруари 2001 г., за да обсъдят точно това: необходимостта от гъвкав и гъвкав модел на разработка на софтуер, който да помогне за разработването на продукти, които реално работеха за клиента и разработчика. Резултатът беше „манифестът на Agile“, който беше предимство на разработването на гъвкав софтуер за методология, т.е. набор от четири принципа, които са толкова прости, колкото са описателни. Бяха разработени и дванадесет „Agile принципи“, обясняващи как действително системите Agile ще работят в проектна среда.
Чрез тази работа сме оценили:
- Индивиди и взаимодействия върху процеси и инструменти
- Работен софтуер над изчерпателна документация
- Сътрудничество с клиенти при договаряне на договор
- Отговор за промяна в следване на план
Тоест, докато има стойност в елементите отдясно, ние оценяваме елементите отляво повече.
12-те пъргави принципа
12-те Agile принципа са набор от ръководни концепции зад Agile Manifesto, които подкрепят екипите на проекти при изпълнението на Agile проекти. Те са:
- Нашият най-висок приоритет е да задоволим клиента чрез ранна и непрекъсната доставка на ценен софтуер.
- Приветствайки променящите се изисквания, дори в късния етап на развитие. Agile методология обработва промяната на ремъци за конкурентно предимство на клиента.
- Доставяйте работещ софтуер често, от няколко седмици до няколко месеца, като предпочитате по-късата времева скала.
- Бизнесмените и разработчиците трябва да работят заедно всеки ден по време на проекта.
- Изграждайте проекти около мотивирани индивиди. Дайте им средата и подкрепата, от която се нуждаете, и им се доверете да свършат работата.
- Най-ефективният и ефикасен метод за предаване на информация до и в рамките на екип за развитие е разговорът лице в лице.
- Работният софтуер е основната мярка за напредък.
- Agile методологичните процеси насърчават устойчивото развитие. Спонсорите, разработчиците и потребителите трябва да могат да поддържат постоянен темп за неопределено време.
- Непрекъснатото внимание към техническите постижения и добрият дизайн повишава пъргавината.
- Простотата - изкуството да се увеличи максимално количеството незавършена работа - е от съществено значение.
- Най-добрите архитектури, изисквания и дизайни възникват от самоорганизиращи се екипи.
- На редовни интервали екипът разсъждава как да стане по-ефективен, след това настройва и коригира поведението си съответно.
Пример за проект, изискващ пъргаво управление
Представете си стартиране, което разработва мобилно приложение за клиент. Замразяването на целия дизайн на приложението преди началото на разработката може да бъде катастрофално. Също така има ограничено време за провеждане на пазарно проучване, изготвяне на подробен план, решаване на вариантите, които искат да предложат, и след това разработване на продукта. Освен огромните разходи, свързани с този подход, те рискуват, че някоя друга компания може да разработи приложението, преди да го направи.
Agile методология в управлението на проекти помага да се преодолеят тези проблеми. При тази система приложението се разработва на етапи, като всеки ден взаимодействат с клиенти и се определят постижения или етапи на проекта, да речем, за всяка седмица.
Няколко екипа могат да работят и върху едно и също приложение, така че времето за разработка да се намали драстично.
Функционалностите се усъвършенстват с всяка среща и крайният продукт отразява крайната нужда. Те научават стъпка по стъпка какво работи за клиента и импровизират предложенията, докато получат желания продукт.
При традиционния подход за управление на проекти човек би помислил за всички ревизии, преди да пусне продукта. Това би довело до пропуснати крайни срокове, увеличено натоварване и инфлация на разходите. Освен това продуктът може да е загубил своята актуалност към момента на пускането му.
Как точно работи Agile Management?
Въпреки че Agile Management се нарича най-вече като концепция за ИТ, използването му не е ограничено до ИТ индустрията. Например търговецът на верижно облекло Zara използва принципите на Agile Management, за да трансформира своя бизнес.
Използвайки принципите на Agile, Zara произвежда продукти на малки партиди, вместо да се фокусира върху голямото производство преди новия сезон. По този метод компанията избягва разходите, свързани с висок инвентар и непредвидими оферти за отстъпки.
Някои от основните аспекти на Agile Project Management са:
- Agile Project Management следва гъвкав подход.
Agile Management приветства допълнения и промени по време на разработката на продукта, вместо да го съобрази с оригиналните спецификации.
- Agile проекти обикновено се разделят на отделни парчета работа, като екипите участват в разработването на един или повече от тези „парчета“ работа.
Така че е възможно например да има четири екипа, които работят едновременно по различни части на проекта, така че сроковете на проекта да бъдат съкратени. Екипите ежедневно се координират помежду си и с клиента.
- Ежедневно се провеждат срещи за напредъка или пречките в проекта с постоянна обратна връзка.
След получаване на обратна връзка от клиентите, промените са включени и екипите преминават към следващата част. Този процес продължава да доставя продукт, който е по-динамичен и по-подходящ за нуждите на клиента.
- Има по-голямо участие на членовете на екипа, отколкото подход отгоре надолу.
В рамките на жизнения цикъл на разработката на софтуер членовете на екипа участват във всички етапи: изискване, проектиране, разработка и гъвкаво тестване на методологията. Тъй като има редовен преглед на ефективността на задачите, членовете на екипа съответно коригират поведението и процедурите.
- Профилът на ръководителя на проекта в Agile проект ще се промени от традиционна роля.
Той / тя вече не отделя много време за планиране или наблюдение на ресурсите, но сега прекарва повече време в сътрудничество с екипи и гарантиране, че цялостната картина е винаги в полезрението. Това не е лесен преход и мениджърите, преминаващи към Agile системи, трябва бързо да се адаптират, за да успее проектът.
Няколко думи за Scrum:
Scrum е една от най-популярните рамки за прилагане на Agile методологията. Какво е Agile методология? Той е предшествал Agile и е бил предложен за първи път през 1986 г. и е приложен в автомобилната и принтерната индустрия.
Agile методология с scrum не са синоними; има други рамки, които могат да се използват за изпълнение на Agile, но Scrum е една от най-ефективните и вероятно най-популярните. Какво е scrum? Обикновено Scrum има само три роли: Собственик на продукта, Екип и Scrum master. Магистърът по методология на Scrum не е ръководител на проекти. Отговорностите на традиционната ръководител на проекти са разделени между трите роли за управление на проекти на Scrum. Проектът е вграден в серия итерации с фиксирана дължина, наречени спринти. Успехът на всеки пъргав методологичен спринт създава усещане за осезаем напредък и непрекъснато вдъхновение. Целта на всяко повторение е да се създаде работещ продукт, който да бъде демонстриран на заинтересованите страни. Agile методологията Scrum master работи със собственика на продукта и екипа, за да улесни постигането на целите, като премахва пътните блокировки. Екипът за разработка на гъвкава методология е многофункционален и в допълнение към разработчиците включва тестери, дизайнери и ops инженери.
Традиционно управление на проекти: водопадът
Една от най-известните традиционни системи за управление на проекти е водопадът. Често се използва от 70-те години. Има няколко добре познати и широко прилагани методологии за водопад в ИТ проектите. Те включват PRINCE2, който беше създаден от правителството на Обединеното кралство за неговия публичен сектор.
Както и името му подсказва, това е последователен работен процес. Крайният продукт е фиксиран в началото на проекта. Тогава различните етапи на работния процес се изпълняват последователно (иницииране на концепцията, анализ, проектиране, изграждане, тестване, внедряване и поддръжка). След като предишната стъпка приключи, разработчиците преминават към следващата стъпка. Планът на проекта трябва да е безумно доказателство; след като етап от последователността е завършен, разработчиците не могат да го посетят отново, без да започнат отначало. Това е статичен подход към гъвкавата методология в управлението на проекти. Няма място за промени или грешки и проектният план за методология трябва внимателно да се спазва.
Може да се направи аналогия между управление на водопад и рисуване на шедьовър. Образът на финалния шедьовър вече е в съзнанието на художника и той стабилно работи към него. Ако по някаква причина крайният продукт се различава от визуализирания, той не може да го модифицира лесно.
Пъргав или водопад?
- Какво е Agile? Agile е по-подходящ за малки екипи, които работят по постепенни и еволюционни проекти, докато водопадът е подходящ за големи схеми или проекти за развитие. Управлението на водопадите може да бъде по-подходящо за индустрии като строителната индустрия. Agile се използва в по-динамични проекти като тези на ИТ индустрията.
- Agile системите изискват висококвалифицирани членове на екипа, които могат да се справят във всички фази на проекта. Това изисква драматична промяна в ролята на ръководител на проекта. Процесът на водопад е структуриран по по-традиционен начин, е линеен и е може би по-лесен за разбиране за непрограмистите и тези, които са нови в разработката на софтуер.
- Много организации намират методологията на водопада за успокояваща, тъй като тя е по-добре документирана. Agile е известен с това, че не подчертава обширната документация. Той е по-зависим от хората, което може да бъде неудобно в организациите, където степента на изнемощаване е висока.
- По-малките директни проекти може да не изискват Agile методологична рамка и поредният модел на водопада може да работи също толкова добре.
Къде отива всичко това?
Методиката на Agile Development представлява повече от две трети от всички ИТ проекти в САЩ, според проучване на HP през май 2015 г.
Но Agile не винаги е „перфектното“ решение. Това не е решение "едно за всички" и в резултат на това много организации (24% според проучването на HP) вече са приели хибриден подход.
Хибрид на методите Agile и Waterfall може да използва предимствата и на двата. Този хибриден подход може да работи за сложни проекти с външни клиенти и големи екипи. Този подход е описан от Ерик Бергман и Анди Хамилтън. Това е компромис между двата метода, позволявайки на софтуерните екипи да работят „пъргаво“, докато екипите за разработка на хардуер и продуктовите мениджъри използват традиционния метод.
Марк Форсън, дигитален консултант посочва още един начин, по който хибридът може да работи:
Разбиване на проекта във фази, подобни на водопад, за да се даде възможност за фиксиране на оферти и дефиниран обхват в по-малка фаза, но запазване на проектната течност като цяло.
Независимо от формата, която ще заемат бъдещите екипи, ясно е, че Agile разработката на методология е тук, за да остане. Той даде възможност за гъвкавост, време и разходи предимства, заедно с най-важния фактор от всички: даване на чувство на удовлетворение и мотивираща атмосфера на хората, които работят по тези проекти.
Източник:
За манифеста на Agile и 12-те Agile принципа - www.agilemanifesto.org
Свързани курсове: -
Agile Project Management - Научете Agile методологии