Що означає бути спритним?

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

У попередніх проектах ми проводили зустрічі з плануванням, потім визначали журнал зворотного продукту та розподіляли роботу розробникам у 2–3 тижневих спринтах. Кожного ранку у нас відбувалися зустрічі зі скаргами (які, здавалося, тривали по 1/2 години щоразу), і кожен розробник після цього продовжував. Навряд чи хтось написав тести, поки в кінці спринту і робота, яка не була завершена, не була додана до наступного спринту.

Розробники навряд чи розмовляли між собою, і в розробці не було залучено TDD. Насправді більшість розробників мали специфікацію на старті і просто зайнялися цим протягом 2 або 3 тижнів спринту. З клієнтом / власником акцій майже не було спілкування.

QA залучався зазвичай через кілька місяців, і тоді ми виявили відсутні вимоги, що ще більше збільшило обсяг роботи, яку нам довелося виконати. Очевидно, що циклу зворотного зв'язку не було.

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

Те, що ви описуєте, не є Agile за визначенням (Agile Manifesto) - це Водоспад із щоденними зустрічами зі статусом. Agile означає легко адаптуватися до змін, якщо немає інтерактивної петлі зворотного зв’язку з власником продукту і, таким чином, з покупцями, то які зміни відбуваються?

Agile - це швидкі збої, завдяки постійному спілкуванню з власником продукту / покупцями. Краще відмовитися раніше, ніж пізніше, робиться менше роботи, і менше «втрачається». І ви не зациклюєтесь на аргументі, що "ми не маємо часу зробити це правильно, оскільки ми витратили стільки часу, роблячи це неправильно, нам просто потрібно продовжувати цей самий шлях, навіть якщо це призводить до невдачі ".

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

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

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

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

Джаррод дав хорошу відповідь (+1 до цього), і я хотів би трохи продовжити це.

Agile - це не лише швидкі збої та відгуки між власником продукту (замовником) та командою; йдеться про швидкий зворотний зв'язок між усіма зацікавленими сторонами. Бути по-справжньому спритним (а це прямо з маніфесту ) - це визнати, що процес існує лише для того, щоб допомогти розробникам у наданні кращого продукту. Люди вище процесу означають, що як тільки команда визнає, що ваш існуючий процес не працює, ви змінюєте його і змушуєте його працювати.

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

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

Це може зайняти трохи часу, але ...

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

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

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

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

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