Спритні помилки втрачають спринт - блог Мейфлауер
Все було повністю розроблено, і, виконавши невелику вечірню роботу та кілька компромісів щодо якості, ви могли насправді доставити все, що було в спринті. У огляді ви представляєте розроблені функції, розробники показують історії, над якими працювали. Критерії прийнятності перевіряються, і в кінці кожного матеріалу вас запитають, чи це нормально. Потім власник продукту приймає історію, підтверджуючи, що вона впроваджена. Все це офіційно задокументовано - у квитках або у вікі - і в кінці є протокол події.
Це корисно для команди: ці історії закінчено, крім виправлень помилок та нових функцій, ви не почуєте багато від них. Нарешті чогось досяг.
Втратити спринт?
Але керівництво Scrum не бачить цього по-іншому з поважної причини. Огляд там явно описується як „неформальна” зустріч; власник товару не приймає. Навіть через зацікавлені сторони.
Обговорюється виконана робота - але там власник товару звітує про себе і не слухає команду, як замовника під час презентації товару. Він представлений, але мова йде не про прийняття, а про загальну картину того, якими будуть наступні кроки. Чи достатньо цієї функції для нас? Ми вже маємо початкові відгуки про те, що нам слід щось додати? Було показано, що інший варіант може насправді генерувати більше значення, ніж обраний?
Погляд у майбутнє
Йдеться не про оцінку минулої роботи; це було б марною тратою часу, оскільки в минулому нічого не можна змінити. Йдеться про з’ясування того, чи спринт спричинив щось для роботи, яку потрібно зробити зараз.
Завдання команди не полягає в тому, щоб «доставити» функції і тим самим передати відповідальність за них. Завдання команди полягає в тому, щоб у будь-який час робити те, що є найбільш корисним та важливим для користувачів та продуктів. Тому питання про прийняття функцій не виникає, лише питання "Чи існують інші найбільш корисні та важливі речі, які слід робити зараз?"
У своїй статті 4 поради щодо кращого зворотного зв’язку в оглядах спринту Мартін показує, які варіанти можна дізнатись через відповідні відгуки та які помилки ви можете зробити.
... до речі
Вас цікавлять спритні непорозуміння і
інший анти-шаблон? Ви можете знайти відповідний додаток у
Apple App Store.
Наша серія Agile Непорозуміння
Спритні непорозуміння
Швидкі методи мають чіткий намір: вони хочуть збільшити додану вартість у розробці програмного забезпечення. Для цього вони пропонують цілу низку цінностей, принципів та методів, які підтримують це.
На практиці наміри, що стоять за цими інструментами, часто вже не є настільки ясними, а іноді вони взагалі втрачаються; метод з його ускладненнями та гачками залишається лише без бажаного ефекту. Я хочу повідомити про цей тип спритного непорозуміння тут - і про те, як з ними боротися.
Про Йоганна-Пітера Гартмана
3 думки на тему "спритні непорозуміння: схуднення на спринті"
Порада для читання: Швидкі непорозуміння: програйте спринт https://t.co/STO9pae82O https://t.co/2xs8qS1Sjq
"Втрата ваги" спринту - чи можливо це взагалі? https://t.co/Hsoi0cj4aD через @mayflowergmbh #agile
Казка про затверджений спринт: https://t.co/LlRWUfP0PO
Залиште коментар скасувати відповідь
про нас
Mayflower супроводжує своїх клієнтів у цифровому переході та забезпечує злагоджені команди для швидкої реалізації окремих ІТ-проектів. Ми підтримуємо вас збалансованим поєднанням стратегії, знань, талантів, впровадження та методичних навичок.
Крім того, ми пропонуємо консультації та тренінги, за допомогою яких ми або спочатку застосовуємо знання з практики, або цілеспрямовано розширюємо наявні навички.
Місцезнаходження
Берлін
Liegnitzer Strasse 15
10999 Берлін
Вюрцбург
Ландштейнерштрассе 4
97074 Вюрцбург
телефон (0931) 466216 - 11 77
факс (0931) 466216 - 28
Мюнхен
Ландсбергерштрассе 314
80687 Мюнхен
телефон (089) 242054 - 11 77
факс (089) 242054 - 29