Наскільки розслабленим (чи ні) повинен бути спринт?

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

Чи прийнятний негативний / страшний досвід для пропущених спринтерських зобов'язань? Чи повинні відповідальні розробники нести відповідальність за пропущені спринтерські зобов’язання, коли виникають несподівані завдання, з якими потрібно вирішувати (наприклад, виробнича підтримка)?

Ви повинні абсолютно прагнути домогтися предметів у спринті.

Однією з головних переваг SCRUM є те, що він надає проекту «серцебиття».

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

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

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

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

Ключовим є те, що потрібно нести відповідальність за те, щоб не завершити розповіді.

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

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

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

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

Це не повинно бути страшним чи негативним досвідом, чи не так?

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

Розслаблені спринти означають, що у вас була недомовленість.

Нерекламовані спринти означають, що у вас виникло перевиконання.

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

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

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

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

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

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

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

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

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

В ідеалі, яка б проблема не була, вона піднімається під час ретроспективи та фіксується.

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

Це дійсно залежить від вашої часової шкали.

Іноді вам ПОТРІБНО буде все, щоб розповісти, або більшість із них все одно. Хоча Agile надає певну гнучкість, вам також потрібно буде виконати проект, можливо, на чіткій часовій шкалі. Отже, маючи більшість зроблених історій, ви зможете вчасно виконати проект.

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

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

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

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

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

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

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