Як Agile можна застосувати до програм, що включають складну обробку?

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

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

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

• Компілятори
• Системи аналізу зображень автомобілів, що керують самостійно
• Системи моделювання потоку рідини

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

Це виявилося довше, ніж я планував (це почалося як коментар), але я сподіваюся, що додаткова довжина / деталі корисні, і ви вважаєте їх виправданими.

Agile не характерний для програм CRUD

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

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

Історії користувачів! = Вимоги

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

Історія користувача не те саме, що вимога. Правда, може бути певне перекриття залежно від того, наскільки вимога "високого рівня", але, як правило, не однаково. У мене складається враження, що ти стикаєшся з тим самим підводним каменем, що впало багато моїх колишніх менеджерів: думати про історії користувачів просто як синоніми "вимог", що схоже на те, коли користувачі SVN намагаються перейти на Git, але тримай мислення з точки зору СВН. (Потім вони стикаються з проблемами через погані початкові припущення.)

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

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

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

Приклад

Я приблизно згадую США, над яким працювали роки тому, коли користувачам потрібно було призначити тестові випадки, щоб усі в колективі знали, над якими ТС вони працюють, щоб уникнути дублювання зусиль; інтерфейс користувача був (n внутрішнім) веб-додатком. Користувач бачив лише кнопку, але історія була розділена на кілька завдань, які включали деякі деталі технічної реалізації тощо.

Видимість користувача

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

Чи можна зробити його видимим для користувача певним чином?

Розглянемо GPS. Якщо ви пропустили свою чергу, ви не побачите фактичний процес перерахунку маршруту, але користувач отримує корисні відгуки (наприклад, "Перерахунок ...").

Компілятори можуть відображати попередження або помилки або включати нові налаштування / параметри в графічний інтерфейс, щоб користувачі бачили, що додано щось нове. Я думаю, що користувачі компіляторів будуть програмістами, правда? Хіба вони не бачать підтримку нового стандарту?

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

Аналіз зображень на автомобілі можна сформулювати таким чином, що дає змогу користувачеві знати, що шанси потрапити в автомобільну катастрофу знижені. Наприклад:

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

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

Однак вимога може бути детальніше про систему; наприклад:

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

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

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

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

Зв’язок між історіями та завданнями

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

Наш підхід полягав у тому, щоб розповіді користувачів зосереджувались на тому, який запит був, чому він був зроблений та які речі повинні бути правдивими, щоб вважати США "виконаними". , Як завжди залишилося з США і зліва розробника (ів).

Розробники (і) розбили б проблему, описану в США, на набір завдань, над якими вони працюватимуть.

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

Залежно від того, що мені потрібно було зробити, я іноді використовував AJAX для показу простої "завантаження ..." анімації / gif, щоб користувач знав, що потрібно трохи почекати, щоб щось ще завершити, не отримуючи неправильного враження. Іноді це було так просто, як це. Завдання для цього було б доречним.

Різна парадигма, практика і досвід

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

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

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

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

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

Навчання зі своїх спринтів - ретроспектив

Що я не можу наголосити достатньо - це ретроспектива між Scrum Master та Developers в кінці кожного спринту. Саме там вони чесно / прозоро обговорюють речі, які "пройшли добре" або "не пішли добре", і які можливі зміни будуть впроваджені для наступного спринту для вирішення питань "не пішли добре" .

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

Агільні принципи, безумовно, можуть бути застосовані в цих випадках. Як?

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

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

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

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

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

tl; dr не дозволяйте scrumnazi зробити ваше життя надзвичайно складним просто тому, що вони занадто багато площі для адаптації. Адаптивність - це головне поняття спритного. Суворе дотримання Scrum або Agile зазвичай летить в обличчя або прагматизм і практичність (що насправді працює найкраще).

Я думаю, що проблема полягає у наданні розповідям користувачів сенсу, якого вони не мають. Scrum використовує термін PBI або Product Backlog Item, що, на мою думку, нескінченно краще. PBIS буде часто слідувати формату розповідь користувача, наприклад, ви можете мати PBI як «Абоненти повинні мати можливість переглядати свої підписні дані», але ви також можете так само легко мати PBI як «Створити процедуру, що зберігається , щоб отримати детальну інформацію передплатника ".

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

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

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

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

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