Меню

Agile Manifesto: Разбиране на пъргавите ценности и принципи

  • Основен
  • Други
  • Agile Manifesto: Разбиране на пъргавите ценности и принципи

agile manifesto understanding agile values

Опитайте Нашия Инструмент За Премахване На Проблемите

Agile Manifesto Въведение:

Нашият предишен урок на Agile Методология подробно ни обясни всичко за Agile модели и методологии.

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

В този урок ще навлезем по-дълбоко в детайлите на agile и agile manifest. Ще видим какво казва манифестът и какви са ценностите и принципите, залегнали в него.

пъргав манифест

Какво ще научите:

Въведение

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

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

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

Agile Manifesto

Манифестът е много внимателно формулиран, за да улови същността на пъргавината с минимални думи и гласи по-долу -

„Разкриваме по-добри начини за разработване на софтуер, като го правим и помагаме на другите да го направят. Чрез тази работа стигнахме до стойността по-долу:

най-добрата системна програма за Windows 10
  • Индивиди и взаимодействия върху процеси и инструменти.
  • Работещ софтуер върху изчерпателна документация.
  • Клиентско сътрудничество при договаряне на договор.
  • Отговаряне на промяна при изпълнение на план.

Тоест, докато има стойност в елементите отдясно, ние оценяваме повече елементите отляво. '

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

Предпочита:

  • Хора
  • Продукт
  • Комуникация и
  • Отзивчивост

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

4-те пъргави ценности

Четирите стойности заедно с 12-те принципа ръководят гъвкавата доставка на софтуер. Сега ще обсъдим подробно всяка от ценностите.

Пъргави ценности

# 1) Индивиди и взаимодействия над процеси и инструменти

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

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

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

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

# 2) Работещ софтуер върху изчерпателна документация

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

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

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

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

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

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

3. Сътрудничество на клиентите при договаряне на договора

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

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

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

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

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

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

4. Реагиране на промяна след изпълнение на план

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

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

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

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

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

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

12-те пъргави принципа

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

Следва текстът на оригиналните 12 принципа, публикувани през 2001 г. от Agile Alliance:

# 1) Нашият най-висок приоритет е да задоволим клиента чрез ранната и непрекъсната доставка на ценен софтуер.

# две) Добре дошли променящите се изисквания, дори късно в разработката. Agile обработва промените, използвани за конкурентно предимство на клиента.

# 3) Предоставяйте работещ софтуер често, от няколко седмици до няколко месеца, с предпочитание към по-краткия срок.

# 4) Бизнесмените и разработчиците трябва да работят заедно всеки ден по време на проекта.

добавяне на стойност към масив

# 5) Изграждайте проекти около мотивирани индивиди. Осигурете им средата и подкрепата, от които се нуждаят, и им се доверете, за да свършат работата.

# 6) Най-ефективният и ефективен метод за предаване на информация до и в рамките на екипа за разработки е разговорът лице в лице.

# 7) Работещият софтуер е основната мярка за напредък.

# 8) Подвижните процеси насърчават устойчивото развитие. Спонсорите, разработчиците и потребителите трябва да могат да поддържат постоянно темпо за неопределено време.

# 9) Непрекъснатото внимание към техническото съвършенство и добрият дизайн повишава пъргавината.

# 10) Простотата - изкуството да максимизираш обема на невършената работа е много важно.

# единадесет) Най-добрите архитектури, изисквания и проекти възникват от самоорганизиращи се екипи.

# 12) На редовни интервали екипът обмисля как да стане по-ефективен, след това настройва и коригира поведението си съответно.

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

Друг начин за организиране на 12-те принципа е разглеждането им в следните четири отделни групи:

  • Удовлетвореността на клиентите
  • Качество
  • Съвместна дейност
  • Управление на проекти

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

най-доброто приложение за скрийншот за Windows 10

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

# две) Добре дошли променящите се изисквания, дори късно в разработката. Променливите процеси се променят, за да се конкурират предимствата на клиента - Промените могат да бъдат включени без много закъснения в общите срокове.

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

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

# 4) Бизнесмените и разработчиците трябва да работят заедно всеки ден по време на проекта - По-добри решения се вземат, когато и двамата работят съвместно и има постоянна верига за обратна връзка между двете за корекция на курса и промяна на гъвкавостта. Комуникацията между заинтересованите страни винаги е ключът към пъргавината.

# 5) Изграждайте проекти около мотивирани индивиди. Осигурете им средата и подкрепата, от която се нуждаят, и им се доверете, за да свършат работата - Трябва да подкрепяте, да се доверявате и да мотивирате екипите. Мотивираният екип е по-вероятно да бъде успешен и ще предостави превъзходен продукт от нещастните екипи, които не са готови да дадат всичко от себе си.

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

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

# 7) Работещият софтуер е основната мярка за напредък - Работещият софтуер побеждава всички останали KPI и е най-добрият показател за свършената работа.

# 8) Подвижните процеси насърчават устойчивото развитие. Спонсорите, разработчиците и потребителите трябва да могат да поддържат постоянно темпо за неопределено време - Подчертава се последователността на доставката. Екипът трябва да може да поддържа темпото си по време на проекта и да не изгаря след първите няколко спринта.

# 9) Непрекъснатото внимание към техническото съвършенство и добрият дизайн повишава пъргавината - Екипът трябва да има всички умения и добър продуктов дизайн, за да се справи с промените и да произведе висококачествен продукт, като същевременно може да включва промени

# 10) Простота - Изкуството да максимизираш обема на неизвършената работа е от съществено значение и е достатъчно, за да отговориш на определението за свършено.

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

# 12) На редовни интервали екипът обмисля как да стане по-ефективен, след това настройва и коригира поведението си съответно - Самоусъвършенстването води до по-бързи резултати и по-малко преработка.

Заключение

Ориентираността към клиентите и фокусът върху комуникацията донесоха успех на пъргавия, който е видим днес.

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

Нашият предстоящ урок в тази поредица ще обясни повече за Scrum Team заедно с техните роли !!

PREV Урок | СЛЕДВАЩ урок

Препоръчително четене

^