Чи можна зробити Agile без участі клієнта?

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

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

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

Як це могло? Сама природа методики диктує певний цикл зворотного зв’язку між замовником і розробником.

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

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

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

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

На мій досвід, водоспад не працює.

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

Клієнти не знають, чого хочуть, поки не бачать.

Це міф. Великий теж. Це може бути так у дизайні / макеті веб-сторінок, але для обробки даних бізнесу більшість користувачів хочуть, щоб це працювало. Деякі з цих користувачів все ще використовують екрани AS / 400 та 3270 моніторів CICS з RGB, і вони можуть розпочати свою діяльність за допомогою цих інструментів. Крім того, ті самі користувачі приймають системи SAP і ORACLE ERP, не маючи жодного слова в дизайні інтерфейсу (і в деяких випадках функціональності). Більшість бізнес-користувачів навіть адаптують свої робочі звички та потоки, якщо система виробляє правильну функцію. Напруга тут на функцію не виглядає. Ділові люди розуміють, як вони роблять свою роботу дуже добре 90% часу.

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

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

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

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

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

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

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

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

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

1. Вгадайте. Реалізовуйте, поки не зіткнетесь із чимось розпливчастим, а потім зробіть судження про те, як ви вважаєте, що функція найкраще буде реалізована. Це, очевидно, не ідеально, оскільки це призводить до "Чекай, це не те, про що я просив!" сценарій.

2. Надайте набагато більше уваги дизайну наперед. По суті, коли клієнт кидає на вас напівфабрикати специфікації у перший день, плануйте детально проаналізувати кожну хвилину, перш ніж щось втілити. Попросіть клієнта роз'яснити все ad nauseum до того моменту, коли ви знаєте кожну деталь реалізації всього проекту. Хоча це не ідеально, це краще, ніж варіант 1. Ви все ще можете стикатися з деталями, яких ви не очікували, і це може навіть надіслати клієнта, який біжить за пагорбами, але якщо вони дійсно не хочуть спілкуватися під час розвитку, і ви не психічні, це необхідність. Це в основному водоспад, і він пов'язаний з усіма пов'язаними з цим недоліками, в тому числі бути надзвичайно важкими для належного виконання.

3. Візьміть напівфабрикат, але попросіть роз'яснення, як і раніше. Працюйте, поки не досягнете невиразної частини специфікації, потім попросіть клієнта уточнити. Звичайно, клієнт це не просив, але якщо вони не хочуть, щоб програма була такою мутною, як специфікація, і відмовляються визначати специфікацію заздалегідь, це єдиний варіант. Він не має всіх переваг Agile (наприклад, регулярне схвалення клієнта, щоб переконатися, що всі знаходяться на одній сторінці), однак це дозволяє вам отримати необхідну інформацію. Оскільки варіант 1, ймовірно, залишить вам продукт з додатковою вартістю, варіант 2 для клієнта марнотратний і неприємний (вам, мабуть, доведеться витратити принаймні вдвічі більше часу на дизайн і збір спекуляцій в цілому, якщо ви будете робити це повністю наперед), це насправді не такий поганий варіант. Головне тут - бути ретельним у зміні часових ліній та цін з кожною зміною, яка з’являється. Якщо ви зробите це правильно, ви можете виявити, що більшість практик Agile сумісні з цією домовленістю, навіть якщо клієнт цього не знає. ІМХО, це дійсно відповідає духу Agile, оскільки ви повинні адаптувати методики до вашої конкретної домовленості.

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

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

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

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

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

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

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

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

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

Визначте замовника.

Це інша компанія? Ще одна людина?

Це ще одна команда у вашій компанії?

Це продукт-чемпіон у вашій компанії?

Це ви?

Все вищесказане можливо, і цілком розумно залежно від обставин. Ви не хочете робити жодного погляду вниз по тунелі щодо того, що це таке Agile, так що, скажімо, остаточний " НІ" був би невірним. ТАК, з іншого боку, вимагає трохи побічного мислення.

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

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

Я - замовник всіх намірів і цілей моїх сольних проектів. Я навіть іноді ношу справжню шапку, коли мені дуже хочеться змінити свою роль клієнта . Це робить мене не менш спритним, ніж я, коли я на роботі. За всім, що мені байдуже, моя кішка може бути менеджером. Він гарантує, що я раз на час перерву відпочиваю, і нагадує мені уникати занадто одержимих будь-яким одним завданням. Ви можете віддати перевагу використанню вашої фантазії "Pomadoro Technique", але я віддаю перевагу таймеру "Rascal" !! Вся справа в тому, що я працюю в суворо Agile процесі, коли пишу код для себе. Я не тип ковбоя-хакера, який живе життям нескінченних стрибків розвитку і нічого не досягає. Мені подобається розробляти своє програмне забезпечення, планувати розробки навколо моєї роботи та особистого життя та завершувати його таким чином, як я б очікував зробити, якби працював на справжнього замовника. Коли речі переривають мій графік, я відповідно коригую і визначаю пріоритетність своєї роботи над проектом. Я використовую всі стандартні методи Agile та методи, які я можу застосувати сольно, і я "доставляю" робочий код собі (або другові або колезі для тестування) якомога частіше. Якщо все це не спритно, я запитаю, що це?

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

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