What is Agile Project Management? Explanation & How To Start

Какво е гъвкаво управление на проекти? Обяснение и как да започнете

Вашият екип току-що прекара шест месеца в разработването на точно това, което клиентът поиска. Демонстрацията минава перфектно. И тогава те казват: „Това вече не е това, от което се нуждаем. Пазарът се промени.“

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

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

По някое време софтуерните екипи осъзнаха нещо важно: ами ако спрем да се съпротивляваме на промените и вместо това започнем да ги очакваме?

Ето как да станете проектен мениджър, специализиран в изкуствения интелект →

В наръчника за управление на проекти, базиран на изкуствен интелект, ще получите:

  • 5 готови за внедряване системи за изкуствен интелект за седмичната ви работа по проектите
  • 30 агенти, проследени от началото до края на проекта
  • Реални мултиагентни работни потоци, които ще ви помогнат да проектирате свои собствени.

Тази промяна в мисленето се превърна в гъвкаво управление на проекти.

Ключови изводи

  • Аджилното управление създава стойност чрез итеративни, кратки цикли на разработка.
  • Аджилните проекти постигат значително по-добри резултати в сравнение с традиционните подходи за управление по модела „водопад“.
  • Scrum, Kanban и XP са основните гъвкави рамки за управление на проекти.
  • Успешното внедряване на гъвкави методи изисква истински промени в организационната култура.

Какво представлява гъвкавото управление на проекти?

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

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

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

Традиционното управление на проекти по модела „водопад“ фиксира изискванията в самото начало и преминава през линейни фази, при които всеки етап трябва да бъде завършен, преди да започне следващият.

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

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

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

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

Защо гъвкавото управление на проекти е важно

Организациите, които успешно осъществяват аджайл трансформации, отчитат около 30% ръст в ефективността, удовлетвореността на клиентите и ангажираността на служителите.

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

Видях как един клиент от списъка на Fortune 500 се мъчеше в продължение на девет месеца с планиране по метода „водопад“, преди да осъзнае, че пазарът му се е променил напълно.

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

Проучването на Standish Group показва, че гъвкавите проекти постигат 42% успеваемост в сравнение с едва 13% при проектите по метода „водопад“. В същото време проектите по метода „водопад“ се провалят в 59% от случаите, докато при гъвкавите проекти този процент е само 11%.

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

Търсите лесен начин да управлявате своя Agile екип на едно място? Изтеглете безплатно шаблона за Agile управление на ClickUp оттук!

Основните принципи на гъвкавото управление на проекти

През 2001 г. „Аджил манифестът“ формулира четири ценности, които и до днес ръководят съвременните екипи. Това не са абстрактни философски идеи, а практически приоритети, които определят ежедневните решения.

  • Хората и взаимодействията са по-важни от процесите и инструментите: Екипите дават приоритет на пряката комуникация и сътрудничеството, а не на стриктното спазване на процесите или сложните инструменти
  • Работещ софтуер вместо изчерпателна документация: Акцентът се измества към предоставянето на функционални инкременти, които потребителите могат действително да тестват, вместо към перфектна документация, която може би никога няма да отразява реалността
  • Сътрудничество с клиента вместо договаряне на условия: Непрекъснатото ангажиране на заинтересованите страни през целия процес на разработка е по-важно от стриктното спазване на първоначалните договори, които са били изготвени, преди някой да разбере реалните изисквания
  • Реагиране на промените вместо следване на план: Екипите приемат и се адаптират към променящите се изисквания с появата на нова информация, вместо да разглеждат всяка промяна като скъпоструващ проблем, който трябва да се избягва

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

Принципите на гъвкавото управление на проекти

Как работи гъвкавият подход [стъпка по стъпка]

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

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

1. Планиране на спринт

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

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

Заедно те определят цел за спринта, която придава смисъл на работата, излизащ извън рамките на простото попълване на списък със задачи.

Екипът също така разбива избраните елементи на по-малки задачи и изготвя план за изпълнението на работата.

2. Ежедневни събрания

Всеки ден по време на спринта екипът провежда петнадесетминутна среща за проверка, за да поддържа синхронизацията.

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

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

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

3. Изпълнение на спринт

Между церемониите разработчиците създават работещи инкременти, които отговарят на определението на екипа за „завършено“, като самостоятелно управляват работата си и адаптират плановете си ежедневно въз основа на наученото.

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

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

4. Преглед на спринта

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

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

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

5. Ретроспектива на спринта

Заключителната церемония приключва всеки спринт, като се анализира какво е минало добре, какви проблеми са възникнали и кои подобрения са най-важни за следващия спринт.

Екипът прави преглед на това как е преминал спринтът по отношение на отделните участници, взаимодействията, процесите и инструментите.

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

Този вграден механизъм за подобрение не позволява на екипите да повтарят едни и същи грешки спринт след спринт.

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

Най-разпространените гъвкави подходи

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

мъж, който взема книга и казва: „Как така си толкова бърз?“

Scrum

Scrum е най-популярната рамка с 63% степен на внедряване, и това не е случайно.

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

Структурата на спринтовете с фиксирана продължителност създава ритъм и предвидимост, като в същото време позволява адаптация в рамките на всеки цикъл.

Тази рамка работи най-добре при разработката на сложни продукти с екипи от 10 или по-малко души, където променящите се изисквания се възползват от адаптивното планиране.

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

Канбан

Kanban използва различен подход, като набляга на непрекъснатия поток, а не на фиксирани итерации.

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

Работата се преминава през системата, когато се освободи капацитет, което създава плавен и предвидим поток.

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

Ако вашият екип се занимава с заявки за поддръжка, отстраняване на грешки или заявки за инфраструктура, които не могат да изчакат следващата сесия за планиране на спринт, непрекъснатият модел на Kanban е идеалното решение.

Екстремно програмиране (XP)

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

При разработката, ръководена от тестове, първо се пишат тестове, които да дават грешка, а след това се пише кодът. Непрекъснатата интеграция тества кода веднага след добавянето му, за да се открият проблемите бързо.

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

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

Комбиниране на рамки

Екипите често комбинират различни рамки, за да извлекат най-доброто от всеки подход.

Scrum плюс XP представлява най-популярната хибридна комбинация, при която Scrum се използва за структурата на управлението на проекта, а XP гарантира техническото качество чрез дисциплинирани инженерни практики.

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

Кога гъвкавият подход е най-подходящ

Аджайл процъфтява, когато са налице определени условия:

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

Тези сценарии имат една обща черта: несигурност, която се преодолява по-успешно чрез итеративно откриване, отколкото чрез предварително планиране.

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

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

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

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

Преди да се ангажирате, три предварителни условия определят осъществимостта:

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

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

Как да започнете с гъвкавото управление на проекти

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

Преди да се впуснем в подробностите, това видео предоставя солидна основа за това как всъщност изглежда гъвкавият подход на практика:

  1. Стъпка 1: Оценете готовността си Преди да обявите аджайл трансформация, преценете дали средата ви действително може да я подкрепи. Първо разгледайте типа на проекта си и се уверете, че той има променящи се изисквания и се нуждае от честа обратна връзка. След това проверете дали членовете на екипа са склонни да променят начина си на работа или ще се сблъскате с упорита съпротива. Накрая се уверете, че заинтересованите страни и ръководството разбират, че ще трябва да участват активно през целия процес, а не просто да получават отчети за състоянието на проекта в края. Ако някой от тези елементи липсва, отстранете тези пропуски, преди да продължите напред. Аджилните трансформации се провалят много по-често поради липса на организационна подкрепа, отколкото поради проблеми с техническото изпълнение.
  2. Стъпка 2: Изберете своя фреймворк След като се уверите, че сте готови, изберете един фреймворк и се ангажирайте с него за поне три месеца. Scrum предоставя структура, която работи добре за екипи за разработка на продукти, докато Kanban е подходящ за работа с непрекъснат поток, като поддръжка и обслужване. Ако техническото качество е основната ви грижа, XP се фокусира върху инженерни практики като програмиране в двойки и разработка, ръководена от тестове. Ключът е да овладеете напълно един подход, преди да комбинирате рамки, защото трябва да разберете защо всеки елемент съществува, преди да започнете да го адаптирате към вашата ситуация.
  3. Стъпка 3: Проведете пилотен проект След като сте избрали рамката, изберете един проект, който е важен за бизнеса, но няма да погуби компанията, ако възникнат проблеми. Това ви дава възможност да се учите без катастрофални последствия. Планирайте два до три спринта (от четири до дванадесет седмици) като период за оценка, като поддържате екипа малък – от четири до пет души, за да не се загуби от координационните разходи дали самата гъвкава методология работи. Уверете се, че те могат да се посветят изцяло на пилотния проект, вместо да разпределят вниманието си между няколко проекта.
  4. Стъпка 4: Определете ясни роли Вашият пилотен проект се нуждае от три ключови роли, които да функционират правилно още от първия ден. Собственикът на продукта трябва да има правомощия да взема ежедневни решения за разходите, без да търси одобрение от висшестоящите, и трябва да бъде на разположение на екипа, вместо да изчезва за дни наред. Вашият Scrum Master трябва да улеснява процеса и да премахва препятствията, вместо да управлява хората в традиционния смисъл. Накрая, сформирайте мултифункционален екип за разработка, който разполага с всички необходими умения, за да завърши работата, без външни зависимости да го забавят. Тези роли не са допълнителни елементи, които можете да пропуснете. Те са структурни изисквания, за да може гъвкавият подход да функционира според замисъла.
  5. Стъпка 5: Стартирайте първия си спринт Започнете планирането на спринта, като собственикът на продукта обясни текущите приоритети, докато екипът избира задачите, които смята, че може да изпълни. Работете заедно, за да определите какво всъщност означава „завършено“ за вашия екип, така че всички да споделят един и същ стандарт, след което планирайте всички повтарящи се церемонии като ежедневната среща „standup“, прегледа на спринта и ретроспективата и запазете това време, като го предпазите от други срещи. След това започнете да разработвате и очаквайте първият спринт да ви се стори малко странен, защото винаги е така. Обикновено екипите се нуждаят от три до пет спринта, за да намерят своя ритъм и да установят надеждна скорост на работа.

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

След като се уверите, че сте готови, изберете една рамка и се придържайте към нея поне три месеца. Scrum осигурява структура, която работи добре за екипи за разработка на продукти, докато Kanban е подходящ за работа с непрекъснат поток, като поддръжка и обслужване. Ако техническото качество е основната ви грижа, XP се фокусира върху инженерни практики като програмиране в двойки и разработка, ръководена от тестове. Ключът е да овладеете напълно един подход, преди да комбинирате различни рамки, защото трябва да разберете защо всеки елемент съществува, преди да започнете да го адаптирате към вашата ситуация.

След като изберете рамката си, изберете един проект, който е важен за бизнеса, но няма да погуби компанията, ако възникнат проблеми. Това ви дава възможност да се учите без катастрофални последствия. Планирайте два до три спринта (от четири до дванадесет седмици) като период за оценка, като поддържате екипа малък – от четири до пет души, за да не се загуби от координационните разходи дали самата гъвкава методология работи. Уверете се, че те могат да се посветят изцяло на пилотния проект, вместо да разпределят вниманието си между няколко проекта.

Вашият пилотен проект се нуждае от три ключови роли, които да функционират правилно още от първия ден. Собственикът на продукта трябва да има правомощия да взема ежедневни решения за разходите, без да търси одобрение от висшестоящите, и трябва да бъде на разположение на екипа, вместо да изчезва за дни наред. Вашият Scrum Master трябва да улеснява процеса и да премахва препятствията, вместо да управлява хората в традиционния смисъл. Накрая, сформирайте мултифункционален екип за разработка, който разполага с всички необходими умения, за да завърши работата, без външни зависимости да го забавят. Тези роли не са допълнителни елементи, които можете да пропуснете. Те са структурни изисквания, за да може гъвкавият подход да функционира според замисъла.

Започнете планирането на спринта, като собственикът на продукта обясни текущите приоритети, докато екипът избира задачите, които смята, че може да изпълни. Работете заедно, за да определите какво всъщност означава „завършено“ за вашия екип, така че всички да споделят един и същ стандарт, след което планирайте всички повтарящи се церемонии като ежедневната среща „standup“, прегледа на спринта и ретроспективата и запазете това време, като го предпазите от други срещи. След това започнете да разработвате и очаквайте първият спринт да ви се стори малко странен, защото винаги е така. Обикновено екипите се нуждаят от три до пет спринта, за да намерят своя ритъм и да установят надеждна скорост на работа.

Често задавани въпроси

Колко време ще отнеме, докато видим резултати от прилагането на гъвкавите методи?

Веднага още през първия спринт се забелязват подобрения в комуникацията в екипа. Трансформацията в John Deere показа съкращаване на времето на цикъла с 79% в рамките на шест месеца. Средносрочните ползи достигат до 165% увеличение на производителността. Дългосрочната зрялост, постигната след дванадесет до двадесет и четири месеца, създава самоподдържаща се култура с максимална възвръщаемост на инвестициите.

Каква е разликата между „аджил“ и Scrum?

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

Могат ли малките екипи от двама до трима души да използват гъвкавите методи ефективно?

Да, често по-ефективно. Наръчникът за Scrum препоръчва трима души като минимален брой, но по-малките екипи се адаптират добре. Те комуникират постоянно, което елиминира необходимостта от формални ежедневни срещи. По-големите екипи струват три до четири пъти повече и имат повече дефекти. Провеждайте ретроспективи и обмислете прилагането на практики от Kanban или XP.

Заключение

Не е тайна, че гъвкавото управление на проекти е една от най-популярните методологии за управление на проекти в света.

Това е лесен и бърз начин да помогнете на екипа си да се справи с задачите и проектите за нула време!

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

Ако искате да внедрите гъвкави методи за управление на проекти, защо не опитате софтуер като ClickUp?

Тук има всичко необходимо, за да управлявате проектите и спринтовете си без усилие! Регистрирайте се още днес за безплатната версия на ClickUp, която ще ползвате завинаги