Що було єдиним пунктом провалу, коли ваша компанія вирішила замінити поточні процеси на SCRUM?
Чи можете ви навести кілька прикладів того, що помилилися, коли компанія намагалася представити SCRUM? Я хотів би почути ваші анекдоти, щось, що ви пережили самі, великий провал, який ви побачили, що ви приїхали, але не змогли запобігти.
Я чую багато занепокоєння з приводу відсутньої документації щодо рішень про деталі реалізації, а також щодо розмірів та рівня деталізації розповідей.
Відповіді:
Найбільша проблема - нерозуміння. Поширені збої:
Тільки команда займається Scrum, але решта компанії (включаючи продаж, управління, HR) все ще думають по-старому. Приклади:
Постійна взаємодія із залученням клієнта та замовника дуже важлива.
HR повинен розуміти, що ефективність команди важливіша, ніж продуктивність окремих людей. KPI має змінитись на це.
Визначення функції - це безперервний процес. Визначення проекту буде змінюватися під час розробки за відгуками клієнтів. Через зазначений термін проекту необхідний бюджет чи набір результатів можуть змінюватися (після затвердження зацікавленою стороною).
Зміна є частиною процесу.
Оцінка - це безперервний процес, який ви не можете сказати на початку проекту, що ви будете виконати всі функції (багато з них на початку невідомі) протягом 5 місяців.
Команда уповноважена приймати рішення. Команда бере на себе зобов’язання щодо кількості функцій, наданих під час наступного спринту. Цього не можна вимагати чи командувати.
Спринт - безпечна зона для команди. Після того, як команда здійснює деякі визначені історії користувачів, зобов'язання не можуть бути змінені поза командою.
Частина старої структури організації не має сенсу при переході до Scrum. Scrum визначає три ролі: Scrum master, власник продукту, команда. Є й інші ролі, але цих трьох зазвичай достатньо для доставки програми. Звичайний глузд - мати майстра Scrum, керівника команди, власника продукту та одного або декількох керівників проектів. Керівник проекту та керівник команди - зайві ролі в Scrum.
Хлопець, призначений роль Scrum master, не виконує Scrum master. Scrum master вирішує перешкоди. Все, що заважає команді, є перешкодою, яку необхідно вирішити якнайшвидше. Найпоширеніший збій - це призначення цієї ролі розробнику без попереднього досвіду роботи з Scrum. Ця роль частково замінює звичайного менеджера проектів, але майстер Scrum не має сили над командою, і Scrum master не вимагає впровадження будь-яких функцій. Scrum master захищає команду навіть проти власника продукту з нездійсненними вимогами.
Редагувати:
Я додаю важливу примітку. При застосуванні спритного підходу головний момент полягає в тому, щоб якомога швидше доставити клієнту найвищу вартість бізнесу. Але замовник (представлений власником продукту) описує, у чому полягає цінність бізнесу. Тож, як правило, неправда, що у вас немає аналізу чи документації під час використання Scrum. Якщо замовник вимагає аналізу чи документації та відмічає його як ділову цінність (наприклад, через масштабний або довгостроковий проект, який слід вдосконалити протягом наступних кількох років), ви також створите його. Найбільш базовий підхід - це включення аналізу та документації в критерії прийняття історій користувачів. Аналіз у такому випадку - це документоване спілкування з власником товару деяким стандартизованим способом.
The most basic approach is including analysis and documentation in acceptance criteria for user stories.Це теж моя початкова реакція. Якщо історія має критерії прийняття, це найкраща документація, яку ви можете мати. Але якщо команда вирішить створити якісь додаткові документації (подумайте про README в багажнику або вікі з корисною інформацією), то я не бачу проблеми. Я думаю, що люди побоюються, що SCRUM = нічого не записується.
Найбільшою проблемою, яку я помітив за 10 років xp та scrum, є те, коли команди, які ще не дуже "спритні", вирішують "бути гнучкими у спритності" і починають налаштовувати її, скидаючи певні частини тощо, без того чітке розуміння того, що робить кожна частина, і чому вона існує.
Я бачив, як команди спонукають успішніше, коли вони спочатку займаються книжкою, ніж команди, які змінюють те, чого ще не "отримують".
Ось тоді ви отримаєте такі речі, як "перший спринт, ми виконаємо всі вимоги. Другий спринт весь дизайн, тощо, тощо. Останній спринт - все тестування". Також відомий як водоспад. Або навіть прості речі на кшталт "давайте сидімо все одно, що з цим автономним бізнесом?".
Щось із Сухарі ( http://c2.com/cgi/wiki?ShuHaRi ).
Найбільша проблема - це завжди покупка. Якщо будь-яка команда чи ключові особи ще не купували (управління проектами, контроль якості, розробка тощо), то відмова майже гарантована.
Інша пов’язана проблема - це фактично зробити так, щоб усі учасники усвідомлювали, що насправді відбувається, а що ні.
Я бачив середовища, де керівництво проектами насправді сприймало це як квиток, щоб безпосередньо прийти до розробників із змінами, і очікую, що це станеться завтра, оскільки ми використовуємо чудовий новий процес. Кожен, хто опинився в цій ситуації або в інших невдалих спробах впровадження Scrum і має гіркий смак у роті. Ці люди іноді намагатимуться також скасувати проект.
Ще одна проблема, яку я бачив, - це зустрічі протистояння. Ви завжди знайдете хлопця, який хоче сісти під час засідання на стендах .... "У мене погана спина" чи що завгодно. Завжди здається, той самий хлопець, який не має уявлення про те, яка мета стоїть за стандапом, і не буде замовчувати ні про політику, ні про те, що він робив у ці вихідні. Я знайшов, що зустрічі протистояння - запорука ефективної комунікації. Важливо не дозволяти нікому отруювати ці зустрічі.
management has actually taken this as a ticket to come directly to developersЦе хороший приклад ситуації, коли процес SCRUM не зрозумілий, правда? Що команда не може прийняти нові історії в середині спринту.
Намагаючись зробити весь аналіз коду, який ми розробляли в тому ж спринті, який ми фактично його кодували.
Ми переїхали до scrum трохи раніше тому, і відверто кажучи, керівництво, яке керувало ним, ставилося до кожного scrum як до 2-тижневого процесу водоспаду. Було таке дотримання правил scrum, що стало самим собою процесом!
Це ця проблема, яку я знаходжу, всі спритні методики повинні стосуватися гнучкості, щоб ефективно працювати так, як працює для вас. Не той спосіб, який передбачено процесами. Наприклад, у нас було 2 тижні скандалів, і команда сказала, що їм здається, що 2 тижні недостатньо для того, щоб зробити хорошу роботу (не з простоєм, спричиненим кінцем демонстрації scrum та початковим переглядом вимог), тому вони хотіли перейти до 3 тиждень. Шоковий жах! Керівництво відмовилося, оскільки вони вирішили, що 2 тижні за кожну скрутку було ідеальним, і це тепер було зафіксовано в процедурах якості.
Scrum - найменш спритний з спритних методів, і тому, мабуть, він був настільки популярний - його легше продати старому гвардію. ви повинні видалити речі, які вам не подобаються, але я не думаю, що це станеться. Моя рада - розробитись з більш гнучким, меншим на основі правил, і замість цього додати потрібні правила. Я вважаю за краще Кристал через це.
Зрештою, просто запам’ятайте маніфест напівскладного спритності .
Найбільша проблема полягає в тому, що також ваш клієнт повинен прийняти процес SCRUM і також стати спритним. Більшість клієнтів хочуть почути це на початку проекту:
Це звучить розумно, але абсолютно не сумісний із спритним. Вам потрібно пояснити своєму клієнтові, чому спритний користь для нього замість водоспаду.
how much will it cost?і вони очікують детальної відповіді саме тоді. Моя відповідь на цю проблему завжди "якщо ви точно знаєте, чого хочете, врешті-решт, вам не потрібно проворного. Просто кодуйте це". Але ми всі знаємо, що цього не станеться. ;-)
На моєму першому переході до SCRUM у нас було два великих питання:
1) Ми насправді не мали власника продукту. Нашому начальнику довелося грати цю роль, тому що ніхто, хто мав би бути власником продукції, не погодився б це зробити. Цей вид викликає обтяження у речах, оскільки він не завжди знав відповіді.
2) Ми погано враховували зовнішні компоненти. Наші перші кілька спринтів включали в себе повне автоматизоване тестування та запуск, і ми неодноразово стикалися з проблемою автоматизації тренажерів, які ми використовували. Якось нам ніколи не стало краще розуміти, що це відбудеться.
Основна проблема, з якою я стикаюся в своєму проекті, полягає в тому, що збір вимог відбувається після того, як ми оцінили наступний спринт. Ми оцінюємо на основі критеріїв прийняття. Під час збору вимог ми бачимо, що тонко налагоджений змінного струму набагато більше, тому завдання, яке оцінюється на 8 годин, тепер дійсно 24 години! Тож чи можу я змінити відставання спринту та переглянути оцінки та зменшити свої історії? Ні, сер! Agile запити про те, що ви не можете змінити відставання спринту! Ось що говорить мій TL. Тому я не повинен кодувати згідно з оригінальними критеріями прийняття, для яких я оцінив час як 8 годин! Боже! Ні! Ви не можете це зробити! Це не було б спритним, чи не так!