Як ми можемо скоротити час простою в кінці ітерації?

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

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

Які методи ми можемо використовувати як команда для підтримки імпульсу протягом останнього дня? Чи слід вирішувати дефекти? Все-таки розпочати роботу над наступною ітерацією? Щось ще?

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

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

Приклади:

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

Що б не мотивувало програміста, даючи їм стимул вчасно випустити реліз.

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

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

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

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

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

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

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

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

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

Кен Швабер заявляє у своєму блозі http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/

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

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

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

Усі розробники в моїй команді використовують вільний час до кінця спринту (за умови завершення всіх завдань щодо спринту) як "час Google".

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

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

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

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

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

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

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

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

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

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

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

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