У компанії, над якою я зараз працюю, ми помітили, що іноді деякі історії пов'язані між собою (як у занадто поєднаних). Це може бути те, що вони належать до однієї і тієї ж загальної риси, або що вони різні функції, але є деякі з них, які потрібно закінчити спочатку, щоб продовжити наступні тощо.
Як ви вирішуєте ці випадки, не зупиняючи робочий процес ітерації? Ми щось робимо не так?
Відповіді:
Це чудове питання. Теорія говорить, що історії користувачів повинні бути незалежними, але я ніколи не зміг цього досягти повністю.
На мою думку, найважливішим є повідомлення залежності, щоб і команда, і власник продукту про це знали. Це змусить власника продукту або переосмислити історії користувачів, щоб усунути залежність (наприклад, шляхом об'єднання історій користувачів), або відповідно визначити діловий пріоритет, щоб перша історія користувача була реалізована першою.
Виходячи з пріоритету та рішення ПО, ви або реалізуєте обидва в одному спринті, або залежний буде впроваджено пізніше без жодних проблем, оскільки головне вже буде виконано.
Найгірший випадок, якщо A залежить від B, а B залежить від A. У такому випадку розповіді користувачів, ймовірно, неправильно визначені і повинні бути, ймовірно, переписані на A і B (здебільшого незалежні або лише з однією стороною залежності) і C залежать від А і Б.
Плануйте їх відповідно.
Помістіть їх у той самий спринт, і оскільки історії користувачів також мають пріоритет у відставанні спринту, у вас не виникне жодних проблем.
Оскільки ваша команда бере участь у цьому, вони усвідомлюють залежності, тому нічого не варто боятися. Вони дорослі, і якщо ви поясните їм залежність (зазвичай вони вам це пояснять), все пройде гладко.
У Agile, як і у Водоспаді, ви можете робити лише одне. А ви зазвичай робите A перед B, якщо B потрібен А. Це здоровий глузд.
Залежності можуть бути запахом, який ви нарізаєте свої історії горизонтально, а не вертикально через систему. Розробка конкретної функції повинна включати все, від зміни дизайну бази даних аж до користувальницького інтерфейсу. Якщо ви виявите, що витрачаєте всі свої зусилля на користувацьку історію на якомусь нижчому рівні системної структури, як, скажімо, написання процедур обробника для пошуку даних, тоді ви, швидше за все, створюєте залежності між історіями. І, напевно, ви неправильно пишете свої користувацькі історії.
Ваша найкраща ставка - розділити ваші історії незалежних користувачів на більш дрібні шматочки, які можуть стати максимально незалежними. Їм слід скористатись історіями, від яких залежать найперше (як ви сказали: ті, які потрібно закінчити першими, щоб продовжити інші). Створіть щось на кшталт індексу залежності: Якщо в історії 3 більше залежностей, ніж у історії 1, спершу слід надіслати сюжет3.
Якщо ваші залежності спричиняють занадто багато кроків, можливо, буде гарною ідеєю взагалі припинити роботу (так прямо посеред вашого поточного спринту) і переоцінити свої пріоритетні історії користувачів та вирішити їх спочатку