Меню

Agile Methodology: A Beginner's Guide to Agile Method and Scrum

agile methodology beginner s guide agile method

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

Пълно ръководство за Agile методология: (20+ подробни урока за Agile Scrum методология)

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

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

Обхванати теми: Какво е Agile, какво е Scrum, Agile методология в разработването и тестването на софтуер, Agile тестване, Agile Scrum процес, Scrum методология със Scrum Team и Scrum Master.

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

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

Списък с уроци за пъргава методология

Урок # 1: Agile Scrum методологии (Този урок)
Урок # 2: Agile Manifesto
Урок № 3: Scrum Team и техните роли и отговорности
Урок № 4: Scrum Артефакти
Урок № 5: Scrum събития
Урок # 6: Дефект триаж в скрам
Урок № 7: Самодостатъчни Scrum екипи
Урок № 8: Принцип Три Амиго
Урок № 9: SAFe - Мащабирана гъвкава рамка
Урок № 10: Agile Scrum Quiz

ОЩЕ Препоръчани Agile Scrum уроци:

Урок # 11: Топ гъвкави техники за оценка
Урок # 12: Хибриден модел на пъргав водопад
Урок № 13: Kanban срещу Scrum срещу Agile
Урок # 14: Урок за JIRA Agile
Урок # 15: Ловки ретроспективни срещи
Урок # 16: Роля на бизнес анализаторите в SCRUM
Урок # 17: QA’s Role in Scrum

Инструменти и въпроси за интервю:

Урок # 18: Agile Инструменти за тестване
Урок № 19: Най-добрите гъвкави инструменти за управление на проекти
Урок № 20: Топ пъргави въпроси за интервю
Урок # 21: Топ въпроси за интервю за Scrum

Нека започнем с първия урок от поредицата - Agile Scrum Introduction.

Въведение в пъргавото развитие

Подвижен в разработването на софтуер:

Agile е една от най-широко използваните и признати рамки за разработка на софтуер в света.

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

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

Този конкретен урок е посветен на това да ви обясни защо е имало нужда от Agile и как е създаден. Основното тук е да ви накара да разберете концепцията за Agile Adoption в индустриите за разработка на софтуер.

История на Agile

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

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

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

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

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

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

Пъргави предизвикателства

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

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

И затова гъвкавостта е свързана и с адаптивност и непрекъснато усъвършенстване, както и с постоянна обратна връзка и скорост на доставка.

Какво представляват Agile Promises?

Agile Promises

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

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

Какво точно е Agile?

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

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

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

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

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

Как да практикувате пъргаво?

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

пъргави методологии

Въпреки това, най-популярните методологии сред всички тях са:

  • Scrum
  • Канбан
  • Екстремно програмиране

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

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

Пъргав Методология

Въведение в пъргавите модели:

Agile методология

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

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

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

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

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

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

Предимства на Agile методологията

По-долу са дадени различните предимства на Agile Methodology:

  • Клиентите непрекъснато получават представа и усещане за напредъка на проекта в края на всяка итерация / спринт.
  • Всеки спринт предоставя на клиента работещ софтуер, който отговаря на очакванията му според определението за извършено, предоставено от тях.
  • Екипите за разработка са доста отзивчиви към променящите се изисквания и могат да приемат промени дори в напредналите етапи на развитие.
  • Постоянната двупосочна комуникация поддържа клиентите ангажирани, като по този начин всички заинтересовани страни - бизнес и технически - имат ясна видимост за напредъка на проекта.
  • Дизайнът на продукта е ефективен и отговаря на бизнес изискванията.

Недостатъци на гъвкавата методология

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

Те са:

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

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

Видове гъвкави методологии

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

Типове гъвкави методологии

# 1) Scrum

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

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

По същия начин скрупата в ИТ вярва в упълномощени самоуправляващи се екипи за разработка с три специфични и ясно определени роли. Тези роли включват - Собственик на продукта (PO), Scrum Master (SM) и екипът за разработка, състоящ се от програмисти и тестери . Те работят заедно в итеративно времетраене, наречено спринтове.

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

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

Това са -

Роли: PO, Scrum master и екип за разработка.

Артефакти: Натрупване на продукти, Спирнт изоставанеиПрирастване на продукта.

Събития: Спринт, Планиране на Спринт, Ежедневен скрам, Преглед на Спринт и Ретроспектива на Спринт.

3-3-5 рамка

Ще се запознаем по-подробно с всеки от тях в следващите ни уроци.

# 2) Канбан

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

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

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

По същия начин друга разлика е, че докато scrum има определени роли на PO, master scrum и екипи за разработка, в Kanban няма такива предварително определени роли.

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

# 3) постно

Lean е философия, която се фокусира върху намаляването на отпадъците. Как се прави това?

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

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

Лекото разработване на софтуер може да се използва във всеки ИТ проект, като се прилагат седемте принципа на щадящото развитие, които са показани по-долу:

седем постни принципа

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

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

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

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

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

Да имаш упълномощени екипи също е много често в днешно време и това е нещо, което дори пъргавият предполага. Оправомощените екипи са по-отговорни и могат да вземат решения по-бързо. Чувството за собственост в овластен екип води до по-добри резултати. За да овласти екип, трябва да им се позволи да се организират и да вземат решения сами.

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

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

Екстремното програмиране е друга най-популярна пъргава техника. Както се съобщава от extremeprogramming.org, първият проект за XP стартира на 6 март 1996 г. Те също така споменават, че XP влияе върху разработването на софтуерни проекти по 5 различни начина - комуникация, простота, обратна връзка, уважение и смелост. Те се наричат ​​стойностите на XP.

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

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

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

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

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

По този начин видяхме различните гъвкави методологии като Scrum, XP, Kanban и Lean заедно със съответните им предимства и недостатъци.

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

В следващата част нека разберем всичко за Scrum.

Scrum методология

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

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

Agile scrum тестване

Някои от ключовите характеристики на SCRUM включват:

  • Самоорганизиран и фокусиран екип.
  • Няма огромни изисквания за документи, по-скоро има много точни и точни истории.
  • Междуфункционалните екипи работят заедно като едно цяло.
  • Тясна комуникация с представителя на потребителя, за да се разберат характеристиките.
  • Има определен срок от максимум един месец.
  • Вместо да прави цялото „нещо“ наведнъж, Scrum прави по малко от всичко в даден интервал.
  • Възможностите и наличността на ресурсите се вземат предвид преди да се извърши каквото и да било.

За да разберете добре тази методология, е важно да разберете ключовите терминологии в SCRUM.

Прочетете също => Как да предоставите висококачествени софтуерни функции за кратък период от време, използвайки Agile Scrum процес

Важни терминологии SCRUM

1) Scrum екип

Scrum екипът е екип, състоящ се от 7 с + или - двама членове. Тези членове са смесица от компетенции и се състоят от разработчици, тестери, хора от базата данни, хора за поддръжка и т.н., заедно със собственика на продукта и scrum master.

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

Scrum Team

2) Спринт

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

кое е най-доброто безплатно премахване на вируси

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

3) Собственик на продукта

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

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

4) Scrum Master

Scrum Master е фасилитаторът на scrum екипа. Той / тя се уверява, че скрам екипът е продуктивен и прогресивен. В случай на някакви пречки, scrum master следи и ги разрешава за екипа. SCRUM Master е посредникът между PO и екипа.

Той / тя информира ПО за напредъка на Спринта. Ако има някакви препятствия или притеснения за екипа, обсъжда с организацията на поръчките и ги разрешава. Подобно на ежедневния Standup на екипа, standup на SCRUM Master с PO се случва всеки ден.

Препоръчително четиво => Как да бъда добър наставник на отбора, треньор и истински защитник на отбора в гъвкав свят на тестване?

5) Бизнес анализатор (BA)

Бизнес анализатор играе много важна роля в SCRUM. Това лице е отговорно за финализирането и изготвянето на изискванията в документите за изискванията (въз основа на които са създадени потребителските истории).

Ако има някакви неясноти в потребителските истории / критериите за приемане, той / тя е този, към когото се обръща техническият екип (SCRUM) и след това той го отвежда до поръчката или, ако е възможно, решава сам. При мащабни проекти може да има повече от 1 BA, но при малки проекти SCRUM Master може да действа и като BA.

Винаги е добра практика да имате BA, когато стартира проектният удар.

6) Потребителска история

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

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

Като
искам да
Да постигне

Например :

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

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

Отговорността на SCRUM Master и BA (ако е приложимо) е да се уверят, че организацията на поръчки е изготвила правилно потребителските истории с подходящ набор от критерии за приемане “. Ако трябва да се направят някакви промени, които ще повлияят на освобождаването на спринта, тогава такива истории се изтеглят от спринта или се правят според наличните часове.

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

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

7) Епични

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

Просто се опитайте да го свържете с живота, представете си, че отивате на почивка. Докато отивате следващата седмица, имате всичко на място, като резервациите за хотели, разглеждане на забележителности, проверка на пътници и т.н. Но какво ще кажете за вашия план за почивка за следващата година? Имате само неясна представа, че можете да отидете на мястото XYZ, но нямате подробен план.

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

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

8) Натрупване на продукти

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

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

9) Спиране на спринта

Въз основа на приоритета, потребителските истории се вземат от Натрупването на продукти като една по една. Мозъчните щурми на екипа на Scrum определят възможността и решават историите, които да работят върху определен спринт. Колективният списък на всички потребителски истории, които екипът на scrum работи за определен спринт, е известен като Sprint backlog.

Спиране на спринта

10) Исторически точки

Историческите точки са количествен показател за сложността на потребителската история. Въз основа на историческата точка се определят оценката и усилията за една история.

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

Всяка потребителска история се присвоява на историческа точка въз основа на поредицата на Фибоначи (1, 2, 3, 5, 8, 13 и 21). По-високо е числото, комплексът е историята.

За да бъдем точни

  • Ако дадете 1/2/3 историческа точка, това означава, че историята е малка и с ниска сложност.
  • Ако дадете точки като 5/8, това е средно сложно и
  • 13 и 21 са силно сложни.

Тук сложността се състои както от разработката, така и от усилията за тестване.

За да се реши сюжетната точка, мозъчната атака се случва в рамките на скрам екипа и екипът колективно решава сюжетна точка.

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

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

Винаги, когато решавате дадена история, имайте предвид следните фактори:

  • Зависимостта на историята с друго приложение / модул.
  • Наборът от умения на ресурса.
  • Сложността на историята.
  • Историческо обучение.
  • Критерии за приемане на историята на потребителя.

Ако не сте наясно с конкретна история, не я оразмерявайте.

Когато историята е = или> 8 точки, тя се разделя на 2 или повече истории.

11) Изгорете диаграмата

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

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

Пример : За да разберете това, проверете фигурата по-долу:

Изгори диаграма 1

Предположих:

  • 2 седмици спринт (10 дни)
  • 2 ресурса, действително работещи на спринта.

'История' -> Тази колона показва потребителските истории, взети за спринта.

„Задача“ -> Тази колона показва списъка със задачата, свързана с потребителската история.

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

„Ден 1 - Ден 10“ -> Тази колона (и) показва часовете, които са останали за завършване на историята. Моля, вижте, че часът НЕ е часът, който вече е свършен, НО часовете, които все още са останали.

„Очаквано усилие“ -> Е общият обем на усилията. За „Старт“ това е просто сумата от цялата индивидуална задача: SUM (C5: C15)

Общият брой усилия, които трябва да бъдат изпълнени за 1 ден, е 70/10 = 7. Така че в края на ден 1 усилието трябва да се намали до 70 - 7 = 63. По подобен начин се изчислява за всички дни до ден 10, когато очакваното усилие трябва да бъде 0 (ред 16)

„Реално усилие вляво“ -> Както подсказва името, дали всъщност са оставени усилия за завършване на историята. Може също така да се случи, че действителните усилия се увеличават или намаляват от очакваното.

Можете да използвате вградените функции и Chart в Excel, за да създадете тази изгорена диаграма.

Стъпките на Burn Down Chart ще бъдат:

  1. Въведете всички истории (Колона A5 - A15).
  2. Въведете всички задачи (колона B5 - B15).
  3. Въведете дните (Ден 1 - Ден 10).
  4. Въведете началните усилия (Сумирайте задачите C5 - C15).
  5. Приложете формулата, за да изчислите „Очакваните усилия“ за всеки ден (ден 1 до ден 10). Въведете формулата на D15 (C16- $ C $ 16/10) и я плъзнете за всички дни.
  6. За всеки ден въведете действителните усилия. Въведете формулата на D17 (SUM (D5: D15)) за обобщаване на действителните оставени усилия и я плъзнете за всички останали дни.
  7. Изберете го и създайте диаграмата, както следва:

Изгори диаграма 2

12) Скорост

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

Например : За определен спринт: общият брой на потребителските истории са 8, имащи сюжетни точки, както е показано по-долу.

Scrum скорост

Така че тук скоростта ще бъде сумата от историческите точки = 30

Определение на Done:

Спринтът е маркиран като Готово, когато всички истории са завършени, всички разработчици, изследвания, QA задачи са отбелязани с „Завършени“, всички грешки са фиксирани-затворени, останалите, които могат да бъдат направени по-късно (като не са напълно свързани или са по-малко важни) са изтеглени и добавени в изоставането, прегледът на кода и тестването на модулите са завършени, очакваните часове са изпълнили действителните часове, определени в задачите и най-важното е дадена успешна демонстрация на организацията на поръчки и заинтересованите страни.

Дейности, извършени в методологията SCRUM

# 1) Среща за планиране

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

Въз основа на дискусията, скрам екипът решава сложността на историята и я оразмерява според поредицата на Фибоначи. Екипът идентифицира задачите заедно с усилията (в часове), които биха били направени за завършване на изпълнението на потребителската история.

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

# 2) Изпълнение на спринт задачи

Както подсказва името, това е действителната работа, извършена от скрам екипа, за да изпълни задачата си и да отведе потребителската история в състояние „Готово“.

# 3) Ежедневен Standup

По време на спринтьорския цикъл всеки ден екипът за скрам се среща за не повече от 15 минути (може да бъде обаждане в изправяне, препоръчително е да се проведе в началото на деня) и да посочи 3 точки:

  1. Какво направи вчера членът на екипа?
  2. Какво е планирал да направи днес членът на екипа?
  3. Някакви пречки (блокади на пътя)?

Учителят на Scrum улеснява тази среща. В случай, че всеки член на екипа се сблъсква с някакви трудности, капитанът на скрама проследява, за да го реши. В Stand ups бордът също се преглежда и сам по себе си показва напредъка на отбора.

# 4) Преглед на срещата

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

Също така в инструмента SCRUM Sprint е затворен и задачите са маркирани като изпълнени.

# 5) Ретроспективна среща

Ретроспективната среща се случва след срещата за преглед.

Екипът на SCRUM се среща, обсъжда и документира следните точки:

  • Какво мина добре по време на Спринта (Най-добри практики)?
  • Какво не се получи добре в Спринта?
  • Поуки
  • Екшън елементи.

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

Как се извършва процесът? Пример!

След като прочетох за техническите жаргони на SCRUM. нека се опитам да демонстрирам целия процес с пример.

Пример:

Етап 1 : Нека имаме SCRUM екип от 9 души, състоящ се от 1 собственик на продукта, 1 Scrum master, 2 тестера, 4 разработчици и 1 DBA.

Стъпка 2 : Спринтът е решен да следва 4-седмичен цикъл. Така че имаме 1-месечен спринт, започващ от 5 юни до 4тиот юли.

Стъпка # 3 : Собственикът на продукта има приоритетен списък с потребителски истории в изоставането на продукта.

Стъпка # 4: Екипът решава да се срещне на 4тиЮни за срещата „Предварително планиране“.

  • Собственикът на продукта взема 1 история от изоставането на продукта, описва го и го оставя на екипа да премисли върху него.
  • Целият екип обсъжда и комуникира директно със собственика на продукта, за да разбере ясно историята на потребителя.
  • По подобен начин се вземат различни други потребителски истории. Ако е възможно, екипът може да продължи да оразмерява и историите.

След цялата дискусия отделните членове на екипа се връщат на работните си станции и

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

Общ брой работни часове = 9
Минус 1 час за почивка, минус 1 час за срещи, минус 1 час за имейли, дискусии, отстраняване на неизправности и т.н.
Така че действителното работно време = 6.
Общ брой работни дни по време на Спринта = 21 дни.
Общ брой на наличните часове = 21 * 6 = 126.
Членът е в отпуск за 2 дни = 12 часа (Това варира за всеки член, някои може да вземат отпуск, а други не.)
Брой на действителните часове = 126 - 12 = 114 часа.

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

Стъпка # 5 : На 5тиот юни целият екип на Scrum се среща за „Планираща среща“.

  • Окончателната присъда на потребителската история от изоставането на продукта е направена и историята е преместена в Sprint Backlog.
  • За всяка история всеки член на екипа декларира своите идентифицирани задачи, ако е необходимо, може да проведе дискусия по тези задачи, може да я оразмери или преоразмери (не забравяйте поредицата Фибоначи !!).
  • Scrum капитанът или екипът въвеждат своите индивидуални задачи заедно с часовете си за всяка история в инструмент.
  • След като всички истории са завършени, Scrum капитанът отбелязва първоначалната скорост и официално стартира Sprint.

Стъпка # 6 : След като Sprint стартира, въз основа на задачите, всеки член на екипа започва да работи по тези задачи.

Стъпка # 7 : Екипът се среща ежедневно в продължение на 15 минути и обсъжда 3 неща:

  • Какво направиха вчера?
  • Какво планират да направят днес?
  • Някакви пречки (блокади на пътя)?

Стъпка # 8 : Scrum master ежедневно проследява напредъка с помощта на „Burn down chart“.

Стъпка # 9 : В случай на някакви пречки, Scrum капитанът проследява, за да ги разреши.

Стъпка # 10 : На 4тиЮли, екипът се среща отново за срещата за преглед. Един член демонстрира внедрената потребителска история на собственика на продукта.

Стъпка # 11 : На 5тиЮли, Екипът се среща отново за Ретроспектива, където обсъждат

  • Какво мина добре?
  • Какво не мина добре?
  • Екшън елементи.

Стъпка # 12 : На 6тиЮли, екипът отново се среща за предварителна среща за следващия спринт и цикълът продължава.

scrum пъргав процес на методология

Инструменти за активност SCRUM

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

Някои от тях включват:

В предстоящия урок ще хвърлим светлина върху Agile Manifesto, което е идея, която движи ефективни Agile екипи.

Следващ урок

За авторите: Тази поредица е написана от следните членове на екипа на STH: Shruti Shrivastava - Професионален Scrum Master с 9 години опит в BFSI, електронна търговия и B2B домейни. Шрути е експерт по автоматизирано тестване и ръководи скрам екипи.

Аншул Кумар Шривастава - ориентиран към резултатите професионалист по управление на продукти и пъргав практикуващ със 7 години опит в секторите на BFSI и телеком.

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

^