Команда постійно не справляється зі спринтними цілями

Ми невелика програмна компанія з одним продуктом.

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

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

В основному моє запитання:

Коли справедливо шукати проблему в якості розробників?

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

Я щось пропускаю?

Спершу слід запитати: "кого турбує"?

Виконання спринтів відчуває себе добре, а в деяких компаніях призводить до отримання файлів cookie від батьків-scrum. Але кінцевим тестом є те, чи відповідає компанія своїм цілям.

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

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

Я щось пропускаю?

ТАК!

Ви їхали 18 місяців - чи десь у районі 36 спринтів із ретроспективою, але якимось чином не змогли це виправити? Керівництво не притягувало до відповідальності команду, а потім їх керівництво не притягувало їх до відповідальності за те, що команда не несе відповідальності?

Вам не вистачає, щоб ваша компанія була некомпетентною .

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

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

Я хотів би запропонувати вам зробити невелику зміну і спробувати Kanban на пару тижнів замість Scrum . Це може працювати краще для вашої команди.

У той час як Scrum керує продуктивністю, обмежуючи час роботи, доступний у спринті, Kanban керує продуктивністю та швидкістю, обмежуючи кількість активних, одночасних проблем. Оцінка часу вже не є частиною процесу. ( джерело )

Якщо коротко, що таке Канбан?

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

Як SCRUM і Kanban однакові?

І Scrum, і Kanban дозволяють розбити та виконати великі та складні завдання. Обидва надають високу цінність постійному вдосконаленню, оптимізації роботи та процесу. І обидва поділяють дуже схожий акцент на добре помітному робочому потоці, який тримає всіх членів команди в циклі на WIP і на майбутнє.

Дивіться решту деталей за цим посиланням

Моє запитання в основному: коли справедливо шукати проблему в якості розробників

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

Якщо я неймовірно обдарований розробник, в команді неймовірно обдарованих розробників, і нам не вдалося закінчити історії X у двох спринтах (або 36!), Чи некомпетентні ми? Або ми просто смокчемо оцінку? Це залежить від того, чи розповіді були "створити екран для входу" або "безпечно відправити людину в марс".

Проблема починається з поганих історій та / або поганих оцінок

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

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

Проблема ускладнюється поганими ретроспективами

Здається, що ви робите неправильно, це те, що ви не користуєтесь ретроспективами. Ви минули 18 місяців, не вирішуючи цю проблему, тому або команда не помічає проблеми, або не вдається вирішити її у своїх ретроспективах.

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

Рішення не в тому, щоб покласти вину, це навчитися

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

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

Постійне вдосконалення - це рішення

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

У будь-який час сприймайте ретроспективи всерйоз. Якщо вони не закінчили спринт, з’ясуйте, чому і діяти. Чи було в них занадто багато невідомих? Чи мають вони неправильну суміш навичок? Наскільки хорошими були їхні оцінки? Якщо вони оцінили історію як X балів, чи вимагала вона відносно рівного обсягу роботи, як апріорні історії, вартістю X балів? Якщо ні, використовуйте це для коригування точок історії, яка рухається вперед.

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

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

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

• Чи недооцінили складність роботи?
• Чи тиснуло керівництво на них, щоб взяти на себе більше роботи, ніж команда вважала, що може впоратися?
• Чи було у них занадто багато перебоїв / надзвичайних ситуацій, які забирали ресурси для завершення запланованих робіт?
• Чи відчували вони вузькі місця, які затягували завершення робіт (скажімо, чекали активів від зовнішньої команди проектування)?
• І навіть: чи один чи кілька членів команди взагалі не здатні виконати роботу?

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

• Беріть менше роботи в наступному спринті (так!)
• Будьте більш консервативними в оцінках
• Скажіть, хто тисне на нас, щоб ми зробили більше роботи, щоб затамувати, оскільки ми вже беремо на себе більше, ніж можемо виконати зараз
• Краще керуйте перебоями та регулюйте обсяг роботи в наступному спринті для розміщення неминучих надзвичайних ситуацій
• Виправте вузькі місця або намічайте навколо тих, яких не уникнути
• Не привласнюйте розповіді членам команди, які не можуть їх виконати (і окремо, з’ясуйте реакцію керівництва для вирішення ситуації з неякісним членом команди, від навчання та наставництва до звільнення)

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

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

Зрозуміло, як уже тут уже зазначалося декілька, цілі спринту - це прогнози, а не залізні зобов'язання, а відсутні цілі самі по собі не є свідченням нічого іншого, окрім як робити неточні прогнози. Чудова команда може пропустити багато голів, тому що вони погані синоптики, в той час як жахлива команда може зустріти кожного і не принести жодної фактичної цінності. Але якщо ваші прогнози помиляються в одному напрямку протягом 18 місяців поспіль, ця частина вашого процесу не працює. Використовуйте свої ретроспективи, щоб виправити процес, щоб ваші прогнози були досить близькими до реальної реальності того, що команда може винести кожен спринт.

"програмне забезпечення робиться тоді, коли його буде зроблено, не раніше, ні пізніше."

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

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

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

Однак більшість розробників, як правило, мають розумну (хоч і оптимістичну ) боротьбу з витратою зусиль, які вони в змозі докласти, за певний проміжок часу.

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

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

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

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

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

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

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

Тож якщо розробники беруть участь у захопі вимог:

• Чи є в команди можливість сісти з менеджером продукту, щоб уточнити вимоги / визначення зробленого?
• Чи задає команда достатньо запитань, щоб уточнити загальноприйняті / прийняті вимоги? Як часто на ці запитання відповідають задовільно?
• Чи вимагає команда критерії прийняття (визначення зробленого) перед тим, як дати оцінку?
• Наскільки добре зазвичай приймаються критерії прийняття для кожного завдання? Це розпливчастий документ із обмеженими деталями чи він описує відчутну функціональність та формулювання, яке розробник міг однозначно перекласти у тест?

Шанси полягають у тому, що продуктивність вашої команди не є проблемою; Ваша команда, мабуть, докладає всіх зусиль, які вони можуть докласти для розвитку. Вашими реальними проблемами може бути одне або більше з наступного:

• Неповні та розпливчасті вимоги.
• Вимоги / завдання, які в першу чергу занадто великі.
• Погана комунікація між командою розвитку та вищим керівництвом.
• Відсутність чітко визначених критеріїв прийняття до передачі завдань команді.
• Неповна або неоднозначна / неоднозначна специфікація приймальних тестів. (тобто визначення завершеного)
• Недостатній час, відведений на визначення / узгодження критеріїв прийняття.
• Розробники не розглядали час перевірити існуючий базовий код або виправити наявні помилки
• Розробники протестували наявний базовий код, але не підвищували помилок як блокування проблем, перш ніж надавати оцінки щодо вимог
• Керівництво побачило проблеми / помилки і вирішило, що помилки не потрібно виправляти перед написанням нового коду.
• На розробників тиснуть 100% свого часу, хоча, можливо, 20% (або якесь подібне число) свого часу, ймовірно, займають зустрічі, відволікання, повідомлення електронної пошти тощо.
• Оцінки узгоджуються за номіналом, і ніхто не коригує місце для помилок чи надзвичайних ситуацій (наприклад, "Ми вирішили, що це потребує 5 днів, тому ми очікуємо, що це буде зроблено через 8").
• Оцінки трактуються всіма (розробниками та керівництвом) як одиничні числа замість реалістичного числа «діапазону» - тобто
  • Найкраща оцінка випадку
  • Реалістична оцінка
  • Найгірша оцінка

... цей список може тривати набагато довше.

Вам потрібно зробити деякий «пошук фактів» і точно з’ясувати, чому оцінки послідовно відключаються від реальності. Чи є існуюче базове програмне забезпечення поганим? Чи не вистачає покриття тестовим блоком? Чи уникають ваші розробники спілкування з керівництвом? Чи уникає менеджмент спілкування з розробниками? Чи існує розрив між очікуванням керівництва та очікуванням розробників, коли мова йде про "Визначення завершеного" ?

Моя порада перезавантажувати команду - вибрати найменшу можливу історію для команди, за спринт, і завершити цю одну історію та лише одну історію!

Я погоджуюся з іншими афішами: або команда некомпетентна, або вони намагаються робити надто багато чого.

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

Вам слід збирати дані та будувати рівень довіри на основі минулої ефективності.

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

Найпростіший приклад - це постійні спринти часу, такі як кожні два тижні. Підрахуйте, скільки сюжетних очок закінчить команда протягом двох тижнів. Потім, після закінчення двотижневого спринту, подивіться, скільки дійсних очок закінчилося. З часом ви можете побачити, що ви оцінили 15 балів, але лише закінчите 10. У цьому простому випадку ви можете почати рухатися вперед з регулюванням швидкості, тому плануєте лише 10 балів за спринт. Або що ви плануєте закінчити 66% передбачуваних робіт.

Побудувавши рівні довіри зі стандартними відхиленнями, ви можете сказати керівництву: згідно з поточними цілями проекту ми очікуємо лише 50% впевненості, яку ми зможемо закінчити за 3 тижні, але 95% впевненості ми можемо закінчити за 5 тижнів.

Ідея Agile and Scrum полягає в тому, щоб створити щільний цикл зворотного зв'язку, щоб ви могли оцінити свій процес. Ви повинні запитати "Де це зламалося?", Оскільки, здається, воно повністю вийшло з ладу.

1. Сплануйте, що ви збираєтеся робити, і складіть його список
   • Це повинно складатися з вибору предметів із відставання предметів, які необхідно виконати. Перш ніж що-небудь витягнути до списку справ для спринту, команді потрібно погодитись, що вони його повністю розуміють, і що вони приблизно оцінюють, що для завершення потрібно буде менше, ніж спринт.
   • В ідеалі відставання впорядковується за пріоритетом (для бізнесу), і ви можете користуватися пріоритетним замовленням.
   • Якщо предмети із відставання занадто великі, розбийте їх на менші шматки. Потім розбийте шматки на окремі завдання, які можна виконати за день або менше.
   • Не очікуйте, що таке планування буде легким чи швидким.
2. Виконувати на елементах зі списку за певний проміжок часу (спринт)
3. Перегляньте, що ви зробили
   • Які історії закінчили?
   • Якщо жодної історії не було закінчено, то які завдання з складання розповідей були закінчені?
   • Якщо жодних завдань не було закінчено, то що саме всі робили минулого понеділка? Минулого вівторка ?, і т. Д. - на даний момент настав час суворої самоаналізу ...

4. Вирішення проблем (аналіз зворотного зв'язку та адаптація)

   • Скільки часу займали закінчені речі?
   • Що заважало виконувати завдання?
   • Чи розбивають учасники команди розповіді (функції) на завдання, які можна виконати за 1 день чи менше? Якщо ні, зробіть це та внесіть його до списку справ.
   • Які зміни у списку завдань чи елементів у списку завдань були внесені під час спринту? Чи це було причиною не закінчення? Якщо це так, не змінюйте список чи функції. Киньте змінену функцію на відставання, поки вона не стане стабільною.
   • Як можна зменшити розмір та обсяг кількох предметів до чогось, що можна закінчити у спринті? Виберіть щось крихітне, як поліпшення журналу, просте виправлення помилок, помилка друку, лише щоб закінчити деякі речі, щоб команда змогла оцінити, що вони можуть зробити. Якщо ви не можете цього зробити, то припиніть спринт і переплануйте .

5. Поверніться до першого кроку і повторіть до виходу ...

Чи існують перешкоди для документації, проблеми зв’язку, що створюють залежності, проблеми зв'язку, недостатня інформація у вимогах? ... Що? Чи витрачали розробники свій час на вивчення нових технологій? Вони витрачали величезну кількість часу на дизайн? Чи були такі речі, як навчання, зараховані до списку завдань спринту?

Ви думали, що ваша команда думала, що вони виділяли свої проблеми кожну ретроспективу? Чи діяла команда, щоб виправити проблеми. Чи не реагувала команда, і керівництво просто продиктувало рішення та хід дій?

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

У вашій ситуації ретроспективи занадто пізно.
Чи проводите ви щоденні зустрічі з stand-up і справді отримуєте статус від людей щодо того, що вони робили за попередні 24 години?
Чи використовує майстер scrum ці зустрічі для вимірювання прогресу кожного розробника щодо їх цілей?
Вам потрібно використовувати цю частину методології Scrum, щоб стежити за ходом роботи. Це повинно дати вам добре уявити, що люди роблять.
Вони відволікаються? Ви витрачаєте занадто багато часу на каву, або допомагаєте іншим людям в SE / SO, чи читаєте новини, чи робите перевірки, які не враховуються? Або вони справді головою вниз, на повну пару вперед і ретельно переконані? Щоденний огляд повинен дати тобі гарне уявлення. Це також допоможе тримати розробників зосередженими на виконанні завдання, тому їм не потрібно визнавати, що вони нічого не зробили вчора.
І звичайно, якщо вони повідомлять про стабільний прогрес через спринт і все ще не здають в кінці, тоді вони брешели, і, можливо, настав час нового розробника.

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

Розробники програмного забезпечення не дуже люблять складати графіки. Зазвичай вони намагаються піти без одного. "Це буде зроблено, коли це буде зроблено!", - кажуть вони, очікуючи, що такий сміливий, веселий джинджер зведе їхнього начальника до прихильності, і внаслідок цього веселості графік буде забутий.

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

Scrum робить кілька речей.

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

По-друге, він генерує дещо корисний продукт, навіть якщо все не закінчено. Це сенс мати "потенційно зміщуваний продукт" в кінці кожної ітерації.

По-третє, це дає жорсткішу петлю зворотного зв'язку. Наполягаючи, що "робити" справи в кінці спринту, ви уникаєте проблеми "90% повною, але лише наполовину виконаною" проблемою; при натисканні на терміни, ви можете відсунути речі, які потрібно зробити вбік, щоб це виглядало так, що ви майже досягли терміну, або можете підробити це. Маючи визначення зробленого та наполягаючи на тому, що робиться, ви знаєте, чи щось складніше, ніж виглядає раніше, ніж пізніше.

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

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

Це корисний спосіб використання scrum-esque візерунків. Він продовжує працювати, він планує наближатися до виробництва, надає певні петлі зворотного зв’язку тощо. Він навіть має переваги в тому, що він не викривляє розробку та тестування, щоб відповідати системі (якщо тестування найкраще виконати з роботою, в основному закінчено , намагаючись закінчити і перевірити речі в рамках одного спринту, змушує задній край спринту не залучати нових розробок!)

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

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

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

З іншого боку, тому що вони не дотримуються правил SCRUM, ви не отримуєте той же вид зворотного зв'язку. Ви повинні вивчити отриманий матеріал, щоб побачити, чи є тими недоліками недоліки, з якими SCRUM був розроблений; Чи є історії, які живуть так, як зомбі назавжди, і лише вбиваються пізно? Чи є історії, які здаються легкими, вони вибухають, і в ретроспективі, де не варто загальної роботи? Чи справді продукт мінливий у той момент, коли вам потрібно / хочете його поставити?

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

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

Сенс спритного розвитку полягає в тому, що кожен новий твір повинен бути настільки ж хорошим, наскільки потрібно, щоб відповідати цьому спринту, І НЕ БУДЕ ЛІШЕ !!!!!! Так, це найбільше наголос, який я можу додати в StackOverflow - і це все ще недостатньо. Якщо ви виявите, що люди додають речі, які не потрібні вже в цю секунду, то їм потрібна підготовка до того, як правильно робити розробки.

О, і так, ми використовуємо ретроспективи.

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

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

Що майстер scrum визначив як потенційні проблеми з командою? Чи постійно їм призначають удвічі більше роботи, ніж вони впораються? Якщо так, майстер scrum повинен обережно запропонувати їм взяти на себе менше роботи, тому що майстер scrum може дивитися на швидкість команди.

Коли справедливо шукати проблему в якості розробників?

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

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

Це покладає на себе керівництво, особливо майстра SCRUM. Хитрість полягає в тому, щоб написати завдання, які, якщо їх виконати, дуже цінні, але якщо їх не виконати, вони все ще забезпечують достатню кількість доданої вартості для компанії, яка б вартувала їх зарплати. Через 18 місяців я б очікував, що ваші ретроспективи чогось навчили вас. Якщо їх немає, можливо, ви повинні писати розповіді з явним наміром невдалих історій, щоб виявити щось, що не так у вашій компанії, і вияснити його. Це дозволило б забезпечити компанію величезними цінними даними, враховуючи, скільки розчарувань у компанії є команда розробників. Проблема може бути, зокрема, розробниками. Або проблема може бути патологією в менталітеті компанії, про яку ви досі не мали уявлення!

Якщо справді проблема полягає в компанії, а не розробниках, інформація, яку ви отримуєте з цих неповних історій, дійсно може коштувати більше, ніж продукт, який ви збираєте з успішних! Це може бути інформація, яка рятує всю вашу компанію! Мені це здається дійсно цінною інформацією, і ви можете використовувати SCRUM як інструмент, який допоможе вам зібрати її.

"Коли справедливо дивитися на якість розробників?"

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

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

Це дасть вам хороше порівняння з поточним ринком, не замикаючи вас на довгостроковому наймі.

Це також може дати хлопцям-пермцям трохи поштовх попкою.

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

Якщо це довгостроковий матеріал, то він змусить вас його кількісно оцінити і занести в спринт як вимоги!

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

Але мені цікаво, чому "[ваші] розробники вибирають функції, які вони хочуть включити у кожен спринт". Зазвичай розробники повинні працювати над функціями, які мають найвищий пріоритет, і пріоритет - це бізнес-рішення, тобто воно повинно надходити від власника продукту, який виступає як проксі для бізнес-зацікавлених сторін.
(Існують винятки з цього. Зокрема, функції підвищеного ризику, як правило, працювали раніше. І в деяких випадках функція, орієнтована на користувачів, може залежати від інших функціональних можливостей, наприклад, "нам дійсно потрібно додати базу даних, перш ніж ми зможемо реалізувати X". )

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

Здається, у вас досить дисфункціональний процес. Я б рекомендував не привертати консультантів для розробників, принаймні поки що, тому що це, мабуть, негативно вплине на мораль. Але здається, що ваша організація може скористатись деякою допомогою на стороні управління проектами. Ось з чого я би почав, залучивши досвідченого спритного тренера - якщо не для середньо- та довгострокової участі, то принаймні для оцінки чи «перевірки здоров’я». Хороший тренер скаже вам, якщо у вас є недорозвинені розробники, але, принаймні, таким чином, вся команда (а не лише чорти) перебуває під пильним наглядом.

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