Меню

Спритний маніфест: розуміння спритних цінностей та принципів

  • Головна
  • Інший
  • Спритний маніфест: розуміння спритних цінностей та принципів

agile manifesto understanding agile values

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

Запитання та відповіді на співбесіду informatica за 5-річний досвід

Вступний маніфест Agile:

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

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

У цьому підручнику ми глибше заглибимося в деталі agile та agile manifest. Ми побачимо, про що йдеться в маніфесті та які цінності та принципи закладені в ньому.

спритний маніфест

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

Вступ

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

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

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

Спритний маніфест

Маніфест був дуже ретельно сформульований, щоб висвітлити суть agile мінімальними словами, і він читається, як показано нижче -

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

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

Тобто, хоча в елементах справа є цінність, ми більше цінуємо елементи зліва ».

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

Воліє:

  • Люди
  • Продукт
  • Спілкування та
  • Чуйність

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

4 спритні цінності

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

Спритні цінності

# 1) Особи та взаємодія над процесами та інструментами

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

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

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

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

# 2) Робота програмного забезпечення над повною документацією

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

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

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

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

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

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

3. Співпраця клієнтів щодо переговорів про контракт

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

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

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

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

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

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

4. Реагування на зміни за планом

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

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

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

За допомогою коротких спринтів, запропонованих Agile, команди можуть швидко отримати зворотний зв'язок та змінити пріоритети за короткий термін. Нові функції можна додавати від ітерації до ітерації.

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

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

12 спритних принципів

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

Далі подано текст оригінальних 12 принципів, опублікованих у 2001 році Agile Alliance:

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

# два) Ласкаво просимо до зміни вимог, навіть на пізній стадії розробки. Швидкі процеси обробляють зміни для конкурентних переваг замовника.

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

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

# 5) Будуйте проекти навколо мотивованих людей. Забезпечте їм необхідне середовище та підтримку та довіряйте їм виконувати роботу.

# 6) Найефективнішим і найефективнішим методом передачі інформації до команди розробників та в рамках команди розробників є особиста розмова.

інструмент для завантаження навантаження для тестування продуктивності

# 7) Працююче програмне забезпечення є головним показником прогресу.

# 8) Спритні процеси сприяють сталому розвитку. Спонсори, розробники та користувачі повинні мати можливість постійно підтримувати постійний темп.

# 9) Постійна увага до технічної досконалості та гарного дизайну підвищує спритність.

# 10) Простота - мистецтво максимізувати обсяг невиконаної роботи є дуже важливим.

# одинадцять) Найкращі архітектури, вимоги та конструкції виникають у команд, що самоорганізовуються.

# 12) Через рівні проміжки часу команда розмірковує над тим, як стати ефективнішим, а потім налаштовує та регулює свою поведінку відповідно.

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

Іншим способом організації 12 принципів є розгляд їх у наступних чотирьох різних групах:

  • Задоволеності клієнтів
  • Якість
  • Командна робота
  • Управління проектами

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

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

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

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

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

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

# 5) Будуйте проекти навколо мотивованих людей. Забезпечте їм необхідне середовище та підтримку та довіряйте їм виконувати роботу - Ви повинні підтримувати, довіряти та мотивувати команди. Мотивована команда, швидше за все, буде успішною і забезпечить вищий продукт, ніж нещасні команди, які не бажають дати все можливе.

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

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

# 7) Робоче програмне забезпечення є основним показником прогресу - Працююче програмне забезпечення перевершує всі інші KPI і є найкращим показником виконаної роботи.

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

# 9) Постійна увага до технічної досконалості та гарного дизайну підвищує спритність - Команда повинна мати усі навички та хороший дизайн продукту, щоб впоратися зі змінами та виготовити високоякісний продукт, маючи можливість включати зміни

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

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

# 12) Через рівні проміжки часу команда розмірковує над тим, як стати більш ефективним, потім налаштовує та регулює свою поведінку відповідно - Самовдосконалення призводить до швидших результатів та меншої переробки.

Висновок

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

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

У нашому майбутньому підручнику з цієї серії буде розказано більше про команду Scrum разом із їх ролями !!

НАЗАД Підручник | НАСТУПНИЙ підручник

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

^