Меню

Agile Methodology: Посібник для початківців Agile Method and Scrum

agile methodology beginner s guide agile method

Спробуйте Наш Інструмент Для Усунення Проблем

Повний посібник з Agile методології: (20+ детальних навчальних посібників з Agile Scrum Methodology)

Це керівництво для розробників програмного забезпечення та тестувальників, щоб зрозуміти і почати працювати над дуже відомими Agile SCRUM методологія для розробки та тестування програмного забезпечення . Вивчіть основні, але важливі термінології, що використовуються в процесі Agile Scrum, а також реальний приклад повного процесу.

Для вашої зручності ми перерахували всі підручники з Agile цієї серії. Сподіваюся, вони вам дуже допоможуть.

Висвітлені теми: Що таке Agile, що таке Scrum, Agile методологія у розробці та тестуванні програмного забезпечення, Agile тестування, Agile Scrum процес, Scrum методологія з командою Scrum та Scrum Master.

вступ до спритного розвитку

Що ви дізнаєтесь:

Список підручників з гнучкої методології

Підручник No1: Методи Agile Scrum (Цей підручник)
Підручник No2: Спритний маніфест
Підручник No3: Команда Scrum та їх ролі та обов'язки
Підручник No4: Артефакти Scrum
Підручник No5: Події Scrum
Підручник No6: Випробування дефектів у сутичці
Підручник No7: Самодостатні Scrum-команди
Підручник No8: Три принципи аміго
Підручник No9: SAFe - масштабований гнучкий фреймворк
Підручник No10: Agile Scrum Quiz

БІЛЬШЕ Рекомендовані підручники з Agile Scrum:

Підручник No11: Найкращі спритні методи оцінки
Підручник No12: Гібридна модель Agile Waterfall
Підручник No 13: Канбан проти Скрама проти Аджилі
Підручник No14: Підручник JIRA Agile
Підручник No15: Спритні ретроспективні зустрічі
Підручник No16: Роль бізнес-аналітиків у SCRUM
Підручник No17: QA’s Role in Scrum

Інструменти та питання співбесіди:

Підручник No18: Швидкі інструменти тестування
Підручник No 19: Найкращі гнучкі інструменти управління проектами
Підручник No20: Найпопулярніші питання спритного інтерв’ю
Підручник No21: Найпопулярніші запитання щодо інтерв’ю у Scrum

Почнемо з першого підручника з серії - Agile Scrum Introduction.

Вступ до Agile Development

Спритний у розробці програмного забезпечення:

Agile - одна з найбільш широко використовуваних та визнаних у світі систем розробки програмного забезпечення.

Більшість організацій прийняли його в тій чи іншій формі, але ще потрібно пройти довгий шлях до зрілості своїх програм усиновлення. Єдиною метою цієї серії навчальних посібників є залучення спеціалістів із технологій та нетехнологій до Agile World.

Ми поетапно проведемо вас через маневрену подорож, поки ви не зрозумієте філософію використання Agile, її переваги та способи використання. Ця серія має на меті забезпечити читачам можливість застосовувати навчання Agile та Scrum у своїй роботі.

Цей підручник призначений для того, щоб пояснити вам, чому була необхідність у Agile та як він був створений. Основне тут полягає в тому, щоб ви зрозуміли концепцію Agile Adoption у галузях розробки програмного забезпечення.

Історія Agile

Agile народився, коли в один прекрасний день, коли 17 людей з різними методологіями розробки зібралися, щоб провести мозковий штурм, якщо існує можливе альтернативне рішення для розробки програмного забезпечення, яке може призвести до швидшого розвитку та меншої документації.

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

Таким чином, ці чемпіони різних технік програмної інженерії зібралися разом, і кінцевим результатом їхньої зустрічі було те, що вони назвали «гнучким маніфестом», який ми детально обговоримо в наступному уроці цієї серії.

Але спритний, що народився в той день, не те, що ми бачимо сьогодні в організаціях. Методологію, з якою погодились експерти, було описано як «легку» та швидку. Але головною перемогою на цій зустрічі була думка, що швидша доставка товару та постійний зворотний зв’язок є ключем до досягнення успіху у розробці програмного забезпечення.

Існуючі методи водоспадів були надто громіздкими і не забезпечували зворотного зв’язку, поки кінцевий продукт не був готовий до доставки. Це означало, що не було можливості для корекції курсу, і замовник не міг бачити прогрес, поки весь продукт не був готовий. І саме цього ці експерти хотіли уникнути.

Вони хотіли рішення, яке мало б можливість постійного зворотного зв’язку, щоб уникнути витрат на переробку на пізнішому етапі.

Спритні виклики

На той час існуючі методи водоспадів були надто громіздкими і не забезпечували зворотного зв’язку, поки кінцевий продукт не був готовий до доставки. Його називали водоспадною моделлю розвитку, оскільки команди спочатку повністю закінчили один крок, а вже після цього перейшли до наступного кроку.

Це означало, що не було можливості для корекції курсу, і замовник не міг бачити прогрес, поки весь продукт не був готовий. І саме цього ці експерти хотіли уникнути. Вони хотіли рішення, яке мало б можливість постійного зворотного зв’язку, щоб уникнути витрат на переробку на пізнішому етапі.

І тому спритний - це ще й адаптація та постійне вдосконалення, як і постійний зворотний зв’язок та швидкість доставки.

Що таке Agile Promises?

Спритні обіцянки

Agile - це не лише застосування встановлених практик при розробці програмного забезпечення. Це також вносить зміни у мислення Команди, що веде їх до створення кращого програмного забезпечення, спільної роботи та врешті-решт висадження щасливого Клієнта.

Спритні цінності та принципи дозволяють команді змінити свою увагу та змінити процес мислення для створення кращого програмного забезпечення.

Що саме Agile?

Agile - це не набір правил. Agile - це не набір настанов. Agile - це навіть не методологія. Швидше, Agile - це набір принципів, які заохочують гнучкість, адаптованість, комунікацію та робоче програмне забезпечення над планами та процесами. Це дуже лаконічно зафіксовано в тому, що називається спритним маніфестом.

Швидка розробка програмного забезпечення дозволяє команді ефективніше та ефективніше працювати над розробкою складних проектів. Він складається з практик, що застосовують повторювані та додаткові методики, які легко застосовуються та дають чудові результати.

Щоб застосувати Agile до дії, ми маємо різні методи та методології на основі Agile. Ці методи та методології задовольняють всі потреби галузі розробки програмного забезпечення, починаючи від проектування та архітектури програмного забезпечення, розробки та тестування до управління проектами та поставок.

Не лише це, гнучкі методи та методології також відкривають можливості для вдосконалення процесів як невід’ємної частини кожного постачання.

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

Як займатися спритно?

Існують різні Agile методології, які застосовуються на практиці в різних диверсифікованих галузях.

гнучкі методології

Однак найпопулярнішими методологіями серед усіх є:

  • Scrum
  • Канбан
  • Екстремальне програмування

Усі ці методології зосереджені на розробці ощадливого програмного забезпечення та допомагають створювати ефективніше та ефективніше програмне забезпечення.

Це все з Agile Introduction. Ця частина побудована так, щоб допомогти вам зрозуміти основні цінності та принципи, які слід прийняти, щоб команда працювала в режимі Agile та мислення.

Спритний Методологія

Вступ до Agile Models:

Спритна методологія

реалізація окремої ланцюгової хеш-таблиці c ++

Як ми всі знаємо, Agile - це методологія розробки програмного забезпечення.

Ми також дізналися про цінності та принципи, які були згадані в маніфесті Agile засновниками Agile. У наших перших дискусіях ми також обговорили відмінності між спритними та традиційними моделями водоспадів.

У цьому підручнику ми дізнаємось про переваги та недоліки гнучкої методології.

Ми побачимо, що таке скрам? і чим він відрізняється від спритного. Тоді ми зрозуміємо різні гнучкі методології, які використовуються різними організаціями, і як ми можемо реалізувати гнучкі, використовуючи їх.

Ви також зможете оцінити різницю, а також переваги / недоліки цих методологій.

Переваги Agile методології

Нижче наведено різні переваги Agile Methodology:

  • Клієнти постійно отримують уявлення про хід проекту в кінці кожної ітерації / спринту.
  • Кожен спринт надає клієнтові працююче програмне забезпечення, яке відповідає його очікуванням відповідно до визначеного ними завдання.
  • Команди розробників досить чуйно реагують на мінливі вимоги і можуть враховувати зміни навіть на просунутих стадіях розробки.
  • Існує постійний двосторонній зв’язок, який підтримує залучення споживачів, таким чином, всі зацікавлені сторони - ділові та технічні - мають чітку видимість прогресу проекту.
  • Дизайн продукту ефективний і відповідає бізнес-вимогам.

Недоліки Agile методології

Незважаючи на те, що методологія Agile має кілька переваг, у цьому також є певні недоліки.

Вони є:

# 1) Вичерпна документація не є кращою, що може спричинити за собою спритні команди, які неправильно трактують це як спритний не вимагає документації. Тож строгість втрачається в документації. Цього слід уникати, постійно запитуючи себе, чи достатньо цієї інформації для продовження чи ні.

# два) Іноді на початку проектів вимоги не є кристально зрозумілими. Команди можуть продовжити і виявити, що бачення споживачів змінилось, і в таких ситуаціях командам потрібно внести багато змін, і важко також оцінити кінцевий результат.

Типи гнучких методологій

На практиці у світі існує кілька гнучких методологій. Ми збираємось детальніше дізнатись про чотири найпопулярніші.

Типи гнучких методологій

# 1) Scrum

Scrum легко можна вважати найпопулярнішим гнучким фреймворком. Більшість практиків термін 'сутичка' вважає синонімом слова 'спритний'. Але це помилкова думка. Scrum - це лише одна з основ, за допомогою якої ви можете реалізувати гнучкість.

Слово scrum походить від спортивного регбі. Де гравці туляться разом у взаємозаблокованому положенні, штовхаючись проти суперників. Кожен гравець має певну роль у своїй позиції і може грати як в атаку, так і в оборону відповідно до вимог ситуації.

Подібним чином сутичка в галузі ІТ вірить у наділені повноцінними командами розробників із трьома конкретними і чітко визначеними ролями. Ці ролі включають - Власник продукту (PO), Scrum Master (SM) та команда розробників, що складається з програмістів та тестувальників . Вони працюють разом протягом багаторазового періоду, який називається спринтом.

Першим кроком є ​​створення відставання товару продуктом замовлення. Це список справ, які повинна зробити команда Scrum. Потім команда scrum вибирає найвищі пріоритетні предмети і намагається закінчити їх у часовому полі, який називається спринтом.

Більш простий спосіб запам'ятати все це - запам'ятати рамки 3-3-5. Це означає, що проект Scrum має 3 ролі, 3 артефакти та 5 подій.

Ось такі -

Ролі: PO, майстер Scrum і команда розробників.

Артефакти: Відставання товару, відставання від спринтуіПриріст продукту.

Події: Спринт, планування Спринту, Щоденний скрам, Огляд Спринту та ретроспектива Спринту.

3-3-5 рамки

Детальніше про кожен із них ми дізнаємось у наступних підручниках.

# 2) Канбан

Канбан - японський термін, що означає карту. Ці картки містять деталі роботи, яку потрібно виконати над програмним забезпеченням. Мета - візуалізація. Кожен член команди усвідомлює роботу, яку слід виконати за допомогою цих наочних посібників.

Команди використовують ці картки Kanban для постійної доставки. Так само, як Scrum, Kanban також допомагає командам ефективно працювати і сприяє самокерованим та спільним командам.

Але між цими двома також є відмінності - як під час спринтерського спринту, предмети, над якими працює команда, виправлені, і ми не можемо додавати елементи до спринту, тоді як у Канбані ми можемо додавати предмети, якщо є вільна ємність. Це особливо корисно, коли вимоги часто змінюються.

Подібним чином, ще одна відмінність полягає в тому, що, хоча у scrum визначені ролі замовника, ведучого Scrum і команд розробників, у Kanban немає таких заздалегідь визначених ролей.

Інша відмінність полягає в тому, що, хоча суперечка пропонує пріоритет відставання продуктів, у Kanban таких вимог немає, і це абсолютно необов’язково. Таким чином, Kanban вимагає меншої організації та уникає діяльності, що не додає вартості, і підходить для процесів, які вимагають реагування на зміни.

# 3) Худий

Lean - це філософія, яка зосереджена на скороченні відходів. Як це робиться?

Побіжно ви поділяєте процес на діяльність із додаванням вартості, діяльність, що не додає вартості, та основну діяльність, що не додає вартості. Будь-яка діяльність, яку можна класифікувати як діяльність, що не додає вартості, є відходом, і ми повинні спробувати усунути ці відходи в процесі, щоб зробити їх більш стрункими.

Більш тонкий процес означає швидшу доставку та менше витрачених зусиль на завдання, які не допомагають досягти цілей команди. Це допомагає оптимізувати кожен крок у циклі розробки програмного забезпечення. Ось чому принципи ощадливості були адаптовані від ощадливого виробництва до розробки програмного забезпечення.

Бережливу розробку програмного забезпечення можна використовувати в будь-якому ІТ-проекті, застосовуючи сім принципів ощадливості, які наведені нижче:

сім худих принципів

Це цілком зрозуміло, як випливає з їх назв. Усунення марнотратства - це перший і найважливіший бережливий принцип, і ми побачили, як це зробити, ми просто класифікуємо види діяльності як додану вартість та нецінність.

Діяльність, що не додає вартості, може бути будь-якою частиною коду, яка може зробити її менш надійною, збільшити зусилля та зайняти багато часу, не додаючи виправданої ділової цінності. Це також можуть бути розпливчасті історії користувачів або погане тестування або додавання функцій, які не потрібні в загальній картині.

Другий принцип, що посилює навчання, знову легко зрозуміти, оскільки команда потребує різноманітних навичок, щоб доставляти продукцію в швидко мінливих умовах із новими технологіями, що з’являються швидко.

Прийняття пізніх рішень може бути корисним у тих обставинах, коли це зменшує переробку, наприклад, якщо очікуються якісь зміни, то краще відкладіть їх, щоб команді не довелося переробляти роботу, оскільки бізнес потребує змін.

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

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

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

# 4) Екстремальне програмування (XP)

Екстремальне програмування - ще одна найпопулярніша спритна техніка. Що стосується extremeprogramming.org, перший проект XP був розпочатий 6 березня 1996 року. Вони також згадують, що XP впливає на розробку програмного забезпечення 5-ма різними способами - спілкуванням, простотою, зворотним зв'язком, повагою та мужністю. Вони називаються значеннями XP.

З них все починається із спілкування. Команди XP регулярно співпрацюють з бізнес-командами та колегами-програмістами і починають будувати код з самого першого дня. Тут основна увага приділяється особистому спілкуванню, наскільки це можливо, за допомогою інших наочних посібників.

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

Зворотній зв’язок допомагає команді вдосконалюватись та покращувати якість роботи. Це допомагає їм формувати повагу одне до одного, коли вони вчаться один у одного та навчаються ділитися своїми поглядами.

Це також додає їм сміливості, оскільки вони знають, що зібрали найкращі ідеї кожного та створили хороший продукт із відгуками інших. Таким чином, вони також не бояться включати зміни або отримувати подальший відгук про свою роботу.

Це особливо корисно в проектах, де вимоги часто змінюватимуться. Постійний зворотний зв’язок допоможе командам мужньо включити ці зміни.

Таким чином, ми бачили різні гнучкі методології, такі як Scrum, XP, Kanban та Lean, а також їх відповідні переваги та недоліки.

Тепер ми можемо легко розрізнити їх, а також оцінити більш тонкі відмінності між ними. Ми також вивчили основи кожної з цих методологій і побачили, як застосовувати їх у наших проектах, як і коли це потрібно.

У наступній частині давайте розберемось у всьому про Scrum.

Методика Scrum

SCRUM - це процес за гнучкою методологією, який є комбінацією ітеративної моделі та інкрементальної моделі.

Один з головних недоліків традиційного Модель водоспаду було те, що - доки перший етап не завершиться, програма не перейде до іншої фази. І випадково, якщо на пізнішій стадії циклу відбудуться якісь зміни, то реалізація цих змін стає дуже складною, оскільки це передбачає перегляд попередніх фаз та переробку змін.

Швидке тестування скраму

Деякі ключові характеристики SCRUM включають:

  • Самоорганізована та цілеспрямована команда.
  • Немає величезних вимог до документів, скоріше мають дуже точні та точні історії.
  • Міжфункціональні групи працюють разом як єдине ціле.
  • Тісне спілкування з представником користувача для розуміння особливостей.
  • Має визначений графік максимум один місяць.
  • Замість того, щоб робити всю “річ” за раз, Scrum робить трохи всього за певний інтервал.
  • Можливості та доступність ресурсів враховуються перед тим, як щось робити.

Щоб добре зрозуміти цю методологію, важливо розуміти ключові термінології в SCRUM.

Також читайте => Як за короткий проміжок часу надати високоякісні функції програмного забезпечення за допомогою Agile Scrum Process

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

1) Команда Scrum

Команда Scrum - це команда, що складається з 7 осіб із + або - двома членами. Ці члени є сумішшю компетенцій і складаються з розробників, тестувальників, співробітників баз даних, служб підтримки тощо, а також власника продукту та майстра scrum.

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

Команда Scrum

2) Спринт

Sprint - це заздалегідь визначений інтервал або часовий проміжок, протягом якого робота повинна бути завершена та підготовлена ​​до огляду або до розгортання виробництва. Цей часовий ряд зазвичай лежить від 2 тижнів до 1 місяця.

компанії, у яких працюють відеоігри

У нашому повсякденному житті, коли ми говоримо, що дотримуємося 1-місячного циклу спринту, це просто означає, що ми працюємо протягом місяця над завданнями і готуємо його до перегляду до кінця цього місяця.

3) Власник продукту

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

Він / вона повинні бути доступними, коли хтось сумнівається, що потребує роз'яснень. Власник продукту важливо розуміти і не висувати будь-які нові вимоги в середині спринту або коли спринт уже стартував.

4) Scrum Master

Scrum Master - фасилітатор команди scrum. Він / вона стежить за тим, щоб команда сутичок була продуктивною та прогресивною. У разі виникнення будь-яких перешкод, майстер сутичок стежить за ними та вирішує їх для команди. SCRUM Master є посередником між організацією та командою.

Він / вона інформує громадську організацію про хід Спринту. Якщо у команди є якісь перешкоди чи занепокоєння, обговорює з ГО та вирішує їх. Як і щоденний стендап команди, стендар SCRUM Master з PO відбувається щодня.

Рекомендуємо прочитати => Як стати хорошим наставником команди, тренером і справжнім захисником команд у спритному світі тестування?

5) Бізнес-аналітик (BA)

Бізнес-аналітик відіграє дуже важливу роль у SCRUM. Ця особа несе відповідальність за доопрацювання вимоги та її складання у документах вимог (на основі яких створюються історії користувачів).

Якщо в історіях користувачів / критеріях прийняття є якісь неясності, саме до них звертається технічна команда (SCRUM), а потім він передає його до замовлення або, якщо можливо, вирішує це самостійно. У великомасштабних проектах може бути більше 1 бакалавра, але в малих проектах майстер SCRUM може виступати і в якості бакалавра.

Це завжди хороша практика мати бакалавра, коли починається проект.

6) Історія користувача

Історії користувачів - це не що інше, як вимоги чи особливості, які необхідно впровадити.

У сутичці ми не маємо цих величезних документів з вимогами, швидше вимоги визначені в одному абзаці, зазвичай у такому форматі:

Як
я хочу
Досягати

Наприклад :

Як адміністратор я хочу мати блокування паролем на випадок, якщо користувач 3 рази поспіль вводить неправильний пароль, щоб обмежити несанкціонований доступ.

Існують деякі характеристики історій користувачів, яких слід дотримуватися. Історії користувачів повинні бути короткими, реалістичними, можуть бути оціненими, повними, обговорюваними та перевіряними. Історія користувача ніколи не змінюється і не змінюється в середині спринту.

Відповідальність SCRUM Master та BA (якщо є) відповідає за те, щоб гарантувати, що організація замовлення правильно склала Історії користувачів з належним набором Критеріїв прийняття ». Якщо будуть внесені будь-які зміни, які вплинуть на випуск спринту, тоді такі історії витягуються зі спринту або робляться відповідно до доступних годин.

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

Критерії прийнятності детально описують історію користувача, яка надає підтверджуючі документи. Це допомагає ще більше вдосконалити історію користувача. Будь-хто з команди може записати критерії прийнятності. Тестуюча група базує свої тестові кейси / умови на цих критеріях прийняття.

7) билини

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

Просто спробуйте пов’язати це з життям, уявіть, що ви їдете на канікули. На наступному тижні у вас є все на місці, як бронювання готелів, огляд визначних пам’яток, перевірка мандрівників тощо. Але як щодо плану відпусток на наступний рік? У вас є лише неясне уявлення, що ви можете поїхати до місця XYZ, але у вас немає детального плану.

Епічна подібна подібно до плану відпусток на наступний рік, де ви просто знаєте, що, можливо, захочете поїхати, але куди, коли, з ким, усі ці деталі ви на даний момент не уявляєте.

Подібним чином є функції, які потрібно впровадити в майбутньому, деталі яких ще не відомі. Здебільшого функція починається з «Епопеї», а потім розбивається на історії, які можуть бути реалізовані.

8) Відставання товару

Відставання товару - це своєрідний сегмент або джерело, де зберігаються всі історії користувачів. Це підтримується власником продукту. Відставання товару можна уявити як список бажань власника продукту, який надає йому пріоритети відповідно до потреб бізнесу.

Під час наради з питань планування (див. Наступний розділ) одна історія користувача береться із відставання продукту, потім команда робить мозковий штурм, розуміє його та доопрацьовує та колективно вирішує, які історії користувачів брати, за участю власника продукту.

9) Відставання спринту

Виходячи з пріоритету, історії користувачів беруться з відставання продуктів як одна за одною. Мозковий штурм команди Scrum визначає його доцільність та приймає рішення щодо історій для роботи над конкретним спринтом. Збірний список усіх історій користувачів, якими команда Scrum працює над певним спринтом, відомий як відставання від спринту.

Відставання спринту

10) Історія

Пункти сюжету є кількісним показником складності історії користувача. На основі сюжету визначається оцінка та зусилля щодо історії.

Історія моменту є відносною, а не абсолютною. Щоб переконатись, що наша оцінка та зусилля правильні, важливо перевірити, чи історія користувачів не велика. Чим точнішою та меншою є історія користувача, тим точнішою буде оцінка.

Кожна історія користувача призначається точці історії на основі серії Фібоначчі (1, 2, 3, 5, 8, 13 і 21). Вище число, складне - історія.

Якщо бути точним

  • Якщо ви даєте 1/2/3 сюжету, це означає, що історія невелика і має низьку складність.
  • Якщо ви даєте бали як 5/8, це середній комплекс і
  • 13 і 21 дуже складні.

Тут складність полягає як у розробці, так і в тестуванні.

Щоб вирішити сюжет, мозковий штурм відбувається в команді сутичок, і команда колективно вирішує сюжет.

Може трапитися так, що команда розробників надає історію 3 для конкретної історії, оскільки для них це може бути 3 рядки зміни коду, але команда тестування дає 8 історій, оскільки вони вважають, що ця зміна коду вплине на більші модулі, тому зусилля з тестування були б більшими. Яку б історію ви не давали, ви повинні її обґрунтувати.

Тож у цій ситуації відбувається мозковий штурм, і команда колективно погоджується на одну історію.

Кожного разу, коли ви вирішуєте сюжет, пам’ятайте про наступні фактори:

  • Залежність історії від іншого додатка / модуля.
  • Набір навичок ресурсу.
  • Складність історії.
  • Історичне навчання.
  • Критерії прийнятності історії користувача.

Якщо вам не відома конкретна історія, не розмірковуйте її.

Коли історія має = або> 8 балів, вона розбивається на 2 або більше історії.

11) Записати діаграму

Діаграма вигорання - це графік, який показує приблизні фактичні зусилля виконуваних завдань.

Це механізм відстеження, за допомогою якого за певним спринтом відстежуються повсякденні завдання, щоб перевірити, чи просуваються історії до завершення фіксованих очок історії чи ні.

Приклад : Щоб зрозуміти це, перевірте наведену нижче рисунок:

Записати діаграму 1

Я припустив:

  • 2 тижні Спринт (10 днів)
  • 2 ресурси, фактично працюють на спринті.

“Історія” -> Цей стовпець відображає історії користувачів, зроблені для спринту.

“Завдання” -> Цей стовпець відображає список завдань, пов'язаних із історією користувача.

“Зусилля” -> Цей стовпець відображає зусилля. Тепер ця міра - це сумарні зусилля для виконання завдання. Він не відображає зусиль, докладених будь-якою конкретною особою.

“День 1 - День 10” -> Цей стовпець (и) показує години, які залишились для завершення історії. Будь ласка, зверніть увагу, що година - це НЕ година, яку вже виконано, А годину, яка ще залишилася.

“Орієнтовні зусилля” -> Це загальна сума зусиль. Для «Пуску» це просто сума всього індивідуального завдання: SUM (C5: C15)

Загальна кількість зусиль, яку потрібно виконати за 1 день, становить 70/10 = 7. Отже, наприкінці першого дня зусилля повинні зменшитися до 70 - 7 = 63. Подібним чином вона розраховується для всіх днів до дня 10, коли передбачуване зусилля має становити 0 (рядок 16)

'Фактичні зусилля зліва' -> Як випливає з назви, чи справді залишаються зусилля для завершення історії. Також може трапитися так, що фактичні зусилля збільшуються або зменшуються, ніж передбачається.

Ви можете використовувати вбудовані функції та діаграму в Excel, щоб створити цю вигорнуту діаграму.

Кроки вигорання діаграми:

  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) Швидкість

Загальна кількість сюжетних точок, яку команда скраму архівує у спринті, називається швидкістю. Команда Scrum оцінюється або посилається на неї за швидкістю. Сказавши це, слід мати на увазі, що метою тут є НЕ досягнення максимальних очок історії, а наявність якісного результату, що відповідає рівню комфорту команди scrum.

Наприклад : Для конкретного спринту: загальна кількість історій користувачів - 8, що мають сюжетні очки, як показано нижче.

Швидкість Scrum

Отже, тут швидкість буде сумою очок історії = 30

Визначення Done:

Спринт позначений як 'Готово', коли всі історії завершені, всі розробники, дослідження, завдання контролю якості позначені як 'Виконані', всі помилки виправлені-закриті, інакше ті, які можна зробити пізніше (наприклад, не повністю пов'язані або менш важливі) витягуються та додаються до відставання, перегляд коду та модульне тестування завершуються, передбачувані години відповідають фактичним годинам, визначеним у завданнях, і найголовніше успішна демонстрація була надана організації замовлення та зацікавленим сторонам.

Заходи, здійснені в методології SCRUM

# 1) Планувальне засідання

Планувальна зустріч - це відправна точка Спринту. Це зустріч, на якій збирається вся команда scrum, SCRUM Master вибирає історію користувача на основі пріоритету з відставання продукту та мозкових штурмів на ньому.

На основі обговорення команда скрам вирішує складність історії та визначає її розмір відповідно до серії Фібоначчі. Команда визначає завдання разом із зусиллями (у годинах), які було б зроблено для завершення впровадження історії користувача.

Багато разів засідання з питань планування передує “засідання перед плануванням”. Це подібно до домашнього завдання, яке виконує команда сутичок перед тим, як сісти на офіційне планування. Команда намагається записати залежності або інші фактори, які вони хотіли б обговорити на зустрічі з планування.

# 2) Виконання спринтерських завдань

Як випливає з назви, це фактична робота, виконана командою сутичок для виконання свого завдання та переведення історії користувача в стан 'Готово'.

# 3) Щоденний стендап

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

  1. Що робив член команди вчора?
  2. Що планував зробити сьогодні член команди?
  3. Будь-які перешкоди (перешкоди)?

Саме Скрум-майстер сприяє цій зустрічі. У випадку, якщо будь-який член команди стикається з будь-якими труднощами, майстер схватки слідкує, щоб вирішити проблему. В Stand ups дошка також переглядається і сама по собі показує прогрес команди.

No4) Оглядова зустріч

В кінці кожного спринтерського циклу команда SCRUM збирається ще раз і демонструє впроваджені історії користувачів власнику продукту. Власник продукту може перехресно перевірити матеріали згідно з його критеріями прийнятності. Головуючим на цій зустрічі знову є відповідальність майстра Скрама.

Також в інструменті SCRUM Sprint закрито, а завдання позначено як виконані.

# 5) Ретроспективна зустріч

Ретроспективне засідання відбувається після оглядового засідання.

Команда SCRUM збирається, обговорює та документує такі моменти:

  • Що вдало пройшло під час спринту (найкращі практики)?
  • Що не вдалося у Спринті?
  • Вивчені уроки
  • Елементи дії.

Команда Scrum повинна продовжувати дотримуватися найкращих практик, ігнорувати 'не найкращі практики' та застосовувати уроки, отримані під час наступних спринтів. Ретроспективна зустріч допомагає здійснювати постійне вдосконалення процесу SCRUM.

Як відбувається процес? Приклад!

Прочитавши про технічні жаргонізми SCRUM. дозвольте спробувати продемонструвати весь процес на прикладі.

Приклад:

Крок 1 : Давайте створимо команду SCRUM із 9 осіб, до складу якої входить 1 власник продукту, 1 майстер Scrum, 2 тестувальники, 4 розробники та 1 DBA.

Крок No2 : Спринт вирішено пройти 4-тижневий цикл. Отже, у нас є 1-місячний спринт, починаючи з 5 червня по 4голипня.

Крок No3 : Власник продукту має пріоритетний список історій користувачів у відставанні продукту.

Крок No4: Команда вирішує зустрітися 4гоЧервень на зустріч «Попереднє планування».

  • Власник продукту бере 1 історію з відставання товару, описує його та залишає команді для мозкового штурму.
  • Вся команда обговорює та безпосередньо спілкується з власником товару, щоб чітко зрозуміти історію користувача.
  • Подібним чином беруться різні інші історії користувачів. Якщо можливо, команда може продовжувати і розмірковувати історії.

Після обговорення окремі члени команди повертаються до своїх робочих місць і

  • Визначте їхні індивідуальні завдання для кожної історії.
  • Обчисліть точну кількість годин, протягом яких вони будуть працювати. Давайте перевіримо, як учасник закінчує ці години.

Загальна кількість робочих годин = 9
Мінус 1 година на перерву, мінус 1 година на зустрічі, мінус 1 година на електронні листи, обговорення, вирішення проблем тощо.
Отже, фактичний робочий час = 6.
Загальна кількість робочих днів під час Спринту = 21 день.
Загальна кількість доступних годин = 21 * 6 = 126.
Член перебуває у відпустці протягом 2 днів = 12 годин (це залежить від кожного члена, деякі можуть взяти відпустку, а інші ні.)
Кількість фактичних годин = 126 - 12 = 114 годин.

Це означає, що учасник буде фактично доступний протягом 114 годин для цього спринту. Тож він розбиє своє індивідуальне спринтове завдання таким чином, що загалом буде досягнуто 114 годин.

Крок No5 : 5-гогоу червні вся команда Scrum збирається на “Планувальну зустріч”.

  • Остаточний вердикт історії користувача з відставання продукту зроблено, і історія переміщується до відставання Sprint.
  • Для кожної історії кожен член команди заявляє про свої визначені завдання, якщо потрібно, вони можуть обговорити ці завдання, можуть розмірити або змінити їх розмір (згадайте серію Фібоначчі !!).
  • Майстер Scrum або команда вводять свої інструменти та свої години для кожної історії в інструменті.
  • Після того, як всі історії закінчені, майстер Scrum відзначає початкову швидкість і офіційно запускає Спринт.

Крок No6 : Після запуску Sprint на основі призначених завдань кожен член команди починає працювати над цими завданнями.

Крок No7 : Команда збирається щодня протягом 15 хвилин і обговорює 3 речі:

  • Що вони робили вчора?
  • Що вони планують робити сьогодні?
  • Будь-які перешкоди (перешкоди)?

Крок No8 : Майстер Scrum щодня відстежує прогрес за допомогою 'Записати діаграму'.

Крок No9 : У разі виникнення будь-яких перешкод, майстер Scrum слідкує за їх вирішенням.

Крок No10 : 4гоУ липні команда знову збирається на оглядову нараду. Учасник демонструє впроваджену історію користувача власнику продукту.

Крок No11 : 5гоУ липні команда знову збирається на ретроспективу, де вони обговорюють

  • Що пройшло добре?
  • Що не вдалося?
  • Елементи дії.

Крок No12 : 6гоУ липні команда знову збирається на зустріч перед плануванням наступного спринту, і цикл продовжується.

процес гнучких методів scrum

Інструменти діяльності SCRUM

Існує декілька інструментів, які можна широко використовувати для відстеження скрам-діяльності.

Деякі з них включають:

У майбутньому навчальному посібнику ми будемо висвітлювати Agile Manifesto, який є поняттям, яке керує ефективними Agile Teams.

Наступний підручник

Про авторів: Ця серія написана такими членами команди STH: Шруті Шрівастава - Професійний майстер Scrum з 9-річним досвідом роботи у сферах BFSI, електронної комерції та B2B. Шруті є експертом у тестуванні автоматизації та провідником команд Scrum.

Аншул Кумар Шрівастава - орієнтований на результат професіонал у галузі управління продуктами та спритний практик із 7-річним досвідом роботи у секторах BFSI та телекомунікацій.

Рекомендована література

^