Як впоратися із "зовнішніми" залежностями в scrum?

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

Ви знаєте, що скоро ".

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

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

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

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

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

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

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

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

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

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

Звучить різко, але я хочу переконатись.

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

• Усі зовнішні API, необхідні для історії, повинні бути доставлені та протестовані.

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

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

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

Зв'язок та угоди

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

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

Як менеджер проектів може управляти залежністю від зовнішньої команди?

/pm/1400/how-can-a-project-manager-manage-a-dependency-on-an-external-team

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