Що робити з програмою "Невдача, що розвивається"?

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

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

У нашій команді є чудовий менеджер проекту, який прагне отримати критерії прийняття від замовника, але це не завжди можливо. З мого крісла розвитку, це пов’язано з тим, що замовник або не знає , чого саме хоче, або (а це - ударник) двох різних «таборів» в головному офісі замовника конфліктують з тим, як слід реалізувати історію. Табір А буде вільно визначати , що функція X працює як це , то табір B зазнає невдачі з - за його не функціонує , як , що . Звідси і термін "FDD". Процес рухається "невдачами".

Це призводить до мого запитання: чи стикався хтось із цим, і якщо так, якісь поради / пропозиції щодо вирішення цього питання?

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

Спасибі

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

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

Табір А буде втрачено диктувати, що Feature X працює так, тоді Camp B вийде з ладу через те, що не функціонує так.

Невідповідність між CampA та CampB - це політична проблема, а не проблема програмного забезпечення. Вирішення проблеми передбачає розмову з людьми та отримання одного явного переможця.

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

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

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

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

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

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

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

У всіх випадках досконалість - ворог досить добра.

Те, що ви описуєте, - це типово неправильна реалізація Agile. Ти не сприймаєш змін, ти є її рабом .

У вас є власник продукту? Чи можете ви поговорити з ними за потреби? Ви робите огляд спринтів з користувачами? Чи беруть участь користувачі в процесі (через власника продукту) у плануванні спринтів? У вас в основному колективі тестери?

Я настійно пропоную вам взяти на роботу тренера Agile та / або відправити свою команду на тренування.

Ще одне рішення - припинити робити Agile.

Якщо вони націлюють на пінг (A каже зробити x, B відхиляє, каже, y, тоді A відхиляє і повернеться до x), то ваші потенційні клієнти (PO або все, що у вас є) потрібно бити на них, щоб скласти свою думку .

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

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

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

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

Ведення детальних записів про витрати на час допоможе тут. (У моїй роботі написано легке додаток для тимчасового відстеження: простий у використанні та простий у звіті та звітує про час за 15 хвилин. Це дозволяє легко сказати "Я витратив п годин на функцію X.")

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одне, що допоможе, - це зробити форму якості щодо вимог, надавши користувачеві детальні приклади з очікуваною поведінкою системи. Наприклад, ви можете сказати: "Ось приклад випадку. Якщо ми реалізуємо X, то Y буде результатом, а Z - наслідком". Таким чином, ви можете перейти до "Зачекайте, це не вийде", перш ніж написати код замість після.