Як розробити чудове програмне забезпечення за допомогою спритних методів?

Модель Kano задоволеності покупців визначає різні класи особливостей товару. Серед них є

1. Обов'язкові якості: Якщо вони не виконані, замовник не прийме товар.

2. Привабливі якості (постачальники товарів): особливості, яких замовник часто навіть не сподівається, але викликають хвилювання та захоплення, коли їх виявляють.

Привабливі якості, очевидно, мають велику ділову цінність. Вони змушують людей купувати Ferrari за 500.000, коли вживаний Fiat за ціною менше 5.000 відповідав би усім необхідним вимогам.

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

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

Додавання: Як було зазначено в перших двох відповідях, має сенс надавати обов'язковим вимогам найвищий пріоритет. Але чи ми (і замовник) насправді завжди заздалегідь знаємо, які вимоги повинні бути. Я вже кілька разів зробив цей досвід, коли вимоги, яким на початку було надано високий пріоритет, виявилися набагато менш важливими, якщо не марними, то пізніше. Тому я вважаю, що не слід по-рабськи зосереджуватися на обов'язкових вимогах.

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

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

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

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

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

[редагувати]

Slebetman:

Іронічно було те, що спритний розвиток розвинувся з автоматизованої галузі (а саме Toyota).

Пам’ятаєте золоте правило автоматизації? "Спочатку організуйте, потім автоматизуйте". Якщо ви автоматизуєте порушений процес, найкраще, що може статися, - ви прискорите все, що піде не так. Люди в Toyota не були ідіотами.

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

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

Продажі, обслуговування клієнтів або власник, з іншого боку, можуть сприймати це як спосіб отримати (назад) контроль над цією чорною скринькою відділу, яка, імовірно, робить необхідні речі. Вони не бачать, що там відбувається, але вони впевнені, що серце проблеми поховано десь там. Тож вони представляють Scrum, встановлюють власник продукту за власним вибором і раптом у них все контролюється, всі струни у них в руці. Що тепер? ... Ехр ...

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

Іноді з часом між формальними лініями виникає неформальна організація. Потім це може частково компенсувати відсутність формальної структури. Деякі люди в кінцевому підсумку роблять те, у чому вони хороші, чи є у них візитна картка, щоб підтвердити це чи ні. Тупе введення Agile / Scrum це може миттєво зіпсувати. Тому що тепер від людей очікують грати за правилами. Вони вважають, що раніше вони не цінують, вони отримують жовті папірці з невеликими історіями, натомість буде повідомлення: "що б ви не робили, нікого не хвилювало". Потрібно говорити, що це не буде особливо мотивувати цих людей. Вони в кращому випадку почнуть чекати замовлень і більше не візьмуть на себе жодної ініціативи.

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

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

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

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

Те саме відбувається і в Agile. Якщо ваші вимоги зупиняються на обов'язкових місцях, ви отримуєте Fiat. Якщо у вас є історії для досконалості, ви отримуєте Ferrari. Все, що гнучкість насправді виконує, це те, що ви в першу чергу робите обов'язкові параметри . Не будуйте супер класний спойлер протягом двох років, а потім пропустіть термін дії двигуна.

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

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

Як слід - перегляньте свою модель Kano ще раз: якщо обов'язкові вимоги не будуть задоволені, замовник не прийме товар. І тоді ваші спокусники не мають значення.

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

Ніщо не могло бути далі від істини.

Агільні процеси зазвичай підкреслюють ці моменти:

• Часта доставка робочого продукту, про який можна отримати відгук.
• Розділіть функції на невеликі частини, які можна виконати за короткий час.
• Реалізуйте ці частини в порядку черговості.

Ніщо не заважає надати «захоплюючим» особливостям високий пріоритет. Це повністю залежить від людей, які відповідають за визначення пріоритетів.

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

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

Я працював як під процесом Agile, так і з BDUF (Big Design Up Front), і хоча ви, безумовно, можете отримати інноваційні, привабливі функції з обох процесів, в BDUF, не дивно, вам доведеться планувати їх наперед. Це означає, що нововведення, як правило, повинні бути запропоновані або принаймні спонсоровані людьми з чітким дизайном у процесі проектування.

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

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

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

Відмінне програмне забезпечення складається з двох речей:

• Давати замовнику те, що йому потрібно

• Бути професіоналом

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

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

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

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

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

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

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

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

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

Гаразд,

У Agile програміст може створити програмне забезпечення, але врешті-решт, власник продукту створює продукт. (за допомогою розробників програмного забезпечення.)

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

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

Крім того, програмне забезпечення настільки відрізняється від реальних фізичних продуктів, що, на мою думку, велика кількість моделі Kano не застосовується. Наприклад, чому я фейсбук? Єдина причина: тому що мої друзі. Як це зробити в наступному спринті ........ А також однією з найпривабливіших якостей програмного забезпечення є те, що він насправді робить те, що повинен робити. (І ось тут спритний дуже допомагає: P)

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

• Agile робить акцент на отриманні що - то працює як можна швидше; однак це означає спрощення припущень та скорочення кутів, особливо в інфраструктурі, не видимій для користувачів. У цьому немає нічого суттєво неправильного, якщо вартість виправлення припущень, що спрощуються, невисока; однак, занадто часто цей "технічний борг" не знімається до того, як продукт надійде у виробництво;
• Agile проповідує, що в кінці спринту у вас завжди має бути щось, наближене до розвантажуваного, наскільки ви зможете це зробити, щоб зацікавлені сторони та менеджери проектів могли вирішити, що "те, що вони мають", є достатньо гарним, щоб просуватися виробництво. Знову ж, нічого по суті в цьому немає, якщови очистили всю свою "технічну заборгованість" (або помирилися з тим, скільки у вас є і де вона є.) Однак, на мій досвід, занадто багато технічної заборгованості переходить у виробництво з обіцянкою менеджера, що "ми "Очистимо його, як тільки тиск на судно вимкне", що швидко перетворюється на "це у виробництві, ми повинні бути дуже обережними щодо того, що ми змінюємо зараз", що врешті-решт перетворюється на "Ви ніколи не говорили мені, що у нас було таке опромінення! Ми повинні зробити кращу роботу наступного разу! " Урок Бен Франкіна про "Гіркота низької якості залишається довго після того, як солодкість низької ціни буде забута", здається, ніколи не дізнається;
• Однак, навіть з довірливими менеджерами та добре дисциплінованими розробниками, існує загальна проблема, що просто занадто мало правильного аналізу, дизайну та перегляду дизайну відбувається перед початком спринту, в якому очікується ініціація та завершення реалізації. Нездатність продумати альтернативноМетафори та конструкції інтерфейсу є великими - зазвичай це занадто дорого переглядати це значно після запуску проекту; неспроможність молодших команд уважно вивчити продукцію своїх конкурентів або визначити пріоритет щодо визначення та впровадження таких інфраструктурних технологій, як I18N, рамки сповіщень, ведення журналів, безпека та версії API (наприклад), означає, що в кінцевому підсумку вони будуть мати більш високі помилки, нижча продуктивність і набере більше технічної заборгованості, ніж якби вони щойно витратили перші 2-5 спринтів вперед, роблячи необхідні навчання, аналіз, проектування та складання прототипів. Коротше кажучи, Agile команди повинні протистояти ліцензії на взлом;
• У мене був менеджер другого рівня (понад 100 розробників), який відштовхував його розробників від того, щоб записувати свої заплановані проекти, навіть на самому базовому рівні. Його міркування - "Я хочу, щоб люди спілкувалися один з одним" - що було іронічно, оскільки вони були в 5 різних часових поясах та 3 країнах. Потрібно сказати, що було багато вказівки пальцями на те, яка команда повинна буде працювати багато ночей і вихідних пізно в проекті, як тільки вони зрозуміли, що всі вважають, що інший хлопець несе відповідальність за реалізацію певної функціональності (або повторна реалізація, оскільки проекти постачальника та споживача просто не збилися.)

Насправді все зводиться до того, чи хочуть менеджер проекту та зацікавлені сторони доставити високоякісний продукт. Якщо вони зобов'язані це зробити, Agile це дозволить. ОТОГ, оскільки Agile передає рішення щодо розкладу виключно в руки учасника та менеджера проекту, Agile ускладнює команді розробників прекрасний проект без цієї підтримки. Коротше кажучи: відповідальність за якість продукції лежить майже виключно в ногах керівника (-ів) проекту.

TL; DR

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

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

Ключові значення спритного розвитку, визначені маніфестом agile (1) ,

• Особи та взаємодії над процесами та інструментами
• Робоче програмне забезпечення над вичерпною документацією
• Співпраця з клієнтами щодо узгодження договору
• Реагуючи на Зміни після виконання плану

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

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

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

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

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

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

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

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

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

Швидка розробка допомагає визначити неробочі або незадоволюючі вимоги на початку та змінити їх під час проекту.

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

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

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

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

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

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

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

Висновок

Як розробити чудове програмне забезпечення за допомогою спритних методів?

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

   > How to develop excellent software with agile methods?

• При виробництві індивідуального програмного забезпечення для клієнта :
  • знайти клієнта, де вартість не має значення, оскільки "чудова" функція коштує додаткових грошей, і замовник повинен вирішити, чи хоче він за це заплатити.
• При виробництві програмних продуктів :
  • "приємні" функції хороші для залучення нових клієнтів, а вартість впровадження "приємної" функції не настільки важлива, якщо товар продається більше 1000 разів.
• В умовах, коли "досить хороший (найдешевший) найкращий", ви не отримаєте грошей на реалізацію "чудових" можливостей

В команді Scrum Власник продукту несе відповідальність за вибір функцій. Тож саме від нього (і від його бюджету) слід визначити програмне забезпечення «доброго» або «відмінного»

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

Існують різні думки щодо того, що є суттєвим та несуттєвим. Щоб використовувати ваш приклад, хтось, хто купує авто, може розглянути увагу як найважливішу особливість, і тому вважає, що Fiat не відповідає цій обов'язковій вимозі.
Більш реально, програмний продукт, можливо, повинен мати певну функціональність для задоволення потреб своїх реальних кінцевих користувачів ..., але для того, щоб продатись, він може також мати певні інші функції. Оскільки особа, яка уповноважує покупку, часто не є кінцевим користувачем.
Таким чином, функція, яка є "несуттєвою" для кінцевого споживача (ів), може бути важливою для продажу товару ... а отже, також важливою для компанії, що створює продукт.

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

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

У власника (-ів) вашого продукту ви хочете інші речі ... один опис, який я чув, - це "CRACK" (спільний, представницький, уповноважений, відданий та знаючий). Власник продукту, якому бракує жодної з цих областей, може спричинити проблеми для проекту. Але я вперше почув цю абревіатуру в середовищі водоспадів, тому явно біль поганих клієнтів / власників товарів не обмежується спритними магазинами.

Що спритна може (допомогти) зробити, це вивести деякі з цих питань на поверхню.

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

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

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

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

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

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

1. Must-be qualitiesчасто важко визначити. Люди мають їх у підсвідомості. Швидкі ітерації та участь клієнтів допомагають знайти більшість необхідних. Це сила спритного, і нерозумно нехтувати нею .
2. One-dimensional qualitiesце означає, що обіцянки, які необхідно виконати, підтримуються водоспадом ОК, доки вони не змінюються. Тут спритність лише допомагає, але не настільки сильно.
3. Attractive qualitiesприємні риси. Вони можуть стати обов'язковими для наступного покоління. Але в нинішньому поколінні вони навіть не домовляються - інакше вони були б одновимірними якостями. Ті спритні методи, які передбачають участь представництва клієнтів, дуже добре підтримують ці якості. Бо ми можемо легенько змінити область застосування під час роботи. Ми можемо домовитися про поліпшення одного місця за певну компенсацію в іншому. У водоспаді це практично неможливо. Без великих організаційних затримок ми могли лише додавати функції безкоштовно. Це можливо, якщо раніше додатковий час закладений у бюджет.

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

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