Dmytro Yarmak: Product Development Flow або як пришвидшити розробку вашого продукту
•
0 likes•93 views
Dmytro Yarmak: Product Development Flow або як пришвидшити розробку вашого продукту UA Online PMDay 2022 Website - https://pmday.org/online Youtube - https://www.youtube.com/startuplviv FB - https://www.facebook.com/pmdayconference
Recommended
Recommended
More Related Content
Similar to Dmytro Yarmak: Product Development Flow або як пришвидшити розробку вашого продукту
Similar to Dmytro Yarmak: Product Development Flow або як пришвидшити розробку вашого продукту (20)
More from Lviv Startup Club
More from Lviv Startup Club (20)
Dmytro Yarmak: Product Development Flow або як пришвидшити розробку вашого продукту
- 1. Product Development Flow або як пришвидшити розробку вашого продукту
- 2. Enterprise Agile Coach, Partner 13 років в IT Ключові клієнти:
- 3. 100 % зайнятість в команді Очікує велика черга завдань 50 % зайнятості в команді Очікує маленька черга завдань Команда “Стахановці” Команда “Лодарі”
- 5. А як щодо IT команд?
- 8. Resource utilization trap Agner Krarup Erlang Працює для систем з: - Непередбачуваним часом появи завдання - Непередбачуваною тривалістю завдання
- 11. 1. Візуалізувати свою роботу
- 12. 2. “Дивіться за естафетною паличкою” What is a better process? Process A with Flow efficiency = 14% OR Process B with Flow efficiency = 9%
- 13. Реальний приклад розрахунку ефективності потоку
- 15. 3. Перше правило роботи з чергами: намагайтеся видалити їх Lead time зменшився з 14 днів to 11 днів (20% покращення) Ефективність потоку впала з 14 % до 9 %.
- 16. 4. Lead time головна метрика оптимізації потоку Lead time - головна метрика ефективності потоку. Flow efficiency - допоміжна метрика для покращення lead time. Lead time залишився таким же. Flow efficiency покращився у два рази.
- 17. 5. Друге правило роботи з чергами: фокусуйтеся на неактивностях Подвійне покращення усіх Value added кроків зменшить lead time тільки на 7%. А Flow efficiency буде навіть гіршою.
- 18. Зміна старої машини на Lamborghini на заблокованій дорозі не покращить ваш потік роботи.
- 20. Друге правило роботи з чергами: фокусуйтеся на неактивностях Подвійне покращення усіх кроків неактивностей зменшить lead time на 50%. А Flow efficiency збільшиться до 30 %.
- 21. 6. Зменшуйте розмір задач
- 22. Transaction and holding costs
- 23. Як знайти оптимальний розмір задач?
- 24. LinkedIn.com/in/LarryMaccherone credit: Larry while at Rally Software and Carnegie Mellon Larry Maccherone Larry_Maccherone@Comcast.com Larry Maccherone LinkedIn.com/in/LarryMaccherone
- 25. 90000 команд Длина ітерації Розмір команди Процес оцінки Співвідношення тестерів до розробників Work in progress … Work in progress
- 28. Як пришвидшити розробку вашого продукту? 1. Уникайте Resource Utilization Trap 2. Візуалізуйте роботу команди 3. Дивіться за “естафетною палочкою” 4. Lead time є головною метрикою ефективності потоку 5. Перше правило роботи з чергами: намагайтеся видалити їх 6. Друге правило роботи з чергами: фокусуйтеся на неактивностях 7. Зменшуйте розмір задач 8. Зменшуйте WIP (паралельну роботу) 9. Працюйте над крос-функціональністю в команді, фокус на вивчення нових навиків.
- 29. “The reality is that the idea to adopt virtual kanban systems from manufacturing to software engineering came from Don Reinertsen. Dragos Dumitriu and I implemented it.” David J Anderson
Editor's Notes
- Поговоримо про важливі аспекти Product Development Flow: Як метафора з Ламборджіні, яка може дуже швидко їхати, але швидкість її потоку дорівнює нулю. Або як команда, у якій наче усі працюють, але результату немає, або дуже повільно їдемо, або їдемо, але всі вигорають по дорозі? Про тісний зв'язок між Теорією Черг, яку почали описувати більше ніж 100 років тому, та сучасною розробкою програмного забезпечення. Як знайти оптимальний розмір задач. Чому фокус на ефективність може мати катастрофічні наслідки для швидкості роботи.
- Трішки про себе і про agiledrive. Компанія agiledrive допомагає з впровадженням змін, аджайл та айті трансформаціями, навчанням, проведенням стратегічних сесій, та коучингом власників та топ керівників компаній. Основна експертиза у впровадженні аджайлу в організаціях, фасилітація, лідерство та коучинг.
- https://www.menti.com/kgznwgfv2a Ок, а яка команда краще працює? Як люблять відповідати коучі - it depends
- Ключовим тут є наскільки важоивою є черга завдань. І як ми з вами далі подивимось існує залежність між зайнятістю команди і чергою задач.
- Хочемо ми їх як стахановців чи лодарів?
- Насправді це дилема між оптимізацією ресурсів та оптимізацією потоку. Давайте подивимось, що таке оптимізація ресурсів.
- Щоб краще відчути різницю між оптимізацією ресурсів та оптимізацією потоку, давайте подивимось на метафору естафети. Оці хлопці пашуть, а оці стоять нічого не роблять. У них ефективність ресурсів 50%. Упс, там ще дві групи стоять і нічого не роблять, у них ефективність 25%. Під час оптимізації ресурсів ми дивимось на те, щоб усі були зайняті. Не слідкуйте за бігунами, слідкуйте за естафетною паличкою. А що є естафетною паличкою в командах розробки?
- На цьому фото зображено данський математик, який започаткував наукові напрямки по вивченню трафіку в телекомунікаційних мережах, а також започаткував теорію черг. На початку ХХ століття дуже стрімко розвивалася телефонія. І постало питання, скільки необхідно комутаторів для того, щоб обслуговувати користувачів з прийнятним часом очікування. І він вивів формулу, яка описує наступну залежність між часом очікування та зайнятістю ресурсів. Ви можете спитати, що спільного між залежністю для телефонних ліній і тим, як працюють команди? А спільне те, що ця залежність працює для любої системи, у якої є непередбачуваний час появи завдання, а також непередбачена тривалість завдання. Звонки - рандомно заходять. Дзвинки можуть бути рандомнлї тривалості. Зразу давайте вирівняємось, що у процесі з рандомним заходом задач, з рандомною тривалістю задач, залежність черги від ресурс ефективності виглядає таким чином.
- Чому на приладах зону приблизно після 80% малюють червоною, машина може працювати і розрахована на 100%, але вже після 80% - кажуть про небезпеку. Тахометр на машині. Так само і з нашим навантаженням.
- Але на практиці питання зводиться до знаходження балансу між оптимізацію потоку та оптимізацією ресурсів. Давайте тоді подивимось, як же нам знайти цей баланс.
- По перше з чого треба почати, це візуалізувати роботу команди. Це перше правило Канбан підходу. Без візуалізації просто неможливо зрозуміти який у команди cycle time чи наскільки вони завантажені, чи хто над чим працює, яка черга задач. Також допоможе команді вирівнятися, чим ж вони займаються і мати спільне розуміння. І важливо, що не керівник візуалізує роботу команди, а команда це робить і несе відповідальність за апдейти цієї дошки задач.
- Якщо ми хочемо оптимізувати потік, то необхідно вимірювати наскільки цей потік оптимальний? Правильно? Згадаємо формулу. Приклад розрахунку. Питання, який процес виглядає кращим, з flow efficiency 15% чи flow efficiency 10%?
- Давайте подивимось на реальний приклад однієї з команд, які ми запускали по продуктовому підході. Як ви думаєте, що є причиною, що реальна робота займає, наприклад, 2 години, а чекаємо ми на результати 2 дні?
- Чому черги такі погані? Так, причина - це черги, які породжують необхідність у мультитаскінгу, переключенню контексту та у втраті Як багато з нас говорили: “Воно вже в роботі”, коли по факту робота почата, але у даний час ви над цим не працюєте, бо у вас є інші завдання або ви чекаєте на когось. Ок, що ж робити з чергами?
- Перше правило - намагатися забрати ці черги! А як же бути з тим, що наша ефективність потоку стала гірша ніж була? Все вірно, треба дивитися в комбінації з lead time. У більшості випадків для того, щоб повністю видалити чергу, необхідні будуть системні зміни в організації, в структурі, процесах, підходах, інструментах і т.д.
- Давайте подивимось на приклад, коли ми увесь час працюємо над візитом фермера. Наша ефективність потоку покращилася у два рази. На цьому прикладі ми можемо побачити, що коли ми оптимізуємо потік, то не достатньо дивитися тільки на flow efficiency, це повинно бути у комбінації з lead time, як швидко ми поставляємо цінність. Що у кінці кінці важливіше клієнту? Що його обслуговувати будуть 11 днів, замість 14 днів? Чи що ефективнсіть потоку компнанії класна?
- Ок, що ще ми можемо зробити з чергами. Друге правило роботи з чергами, це фокусуватися на неактивності у першу чергу, а потім вже на активності. Making activities more efficient is much less important than eliminating inactivity. Our real problem is periods of inactivity, not slow activities. One of the questions that working professionals get asked the most is “When will my request be completed?” In order to answer, we often look at lead time metrics to give a predictable answer. Looking at lead times over a period of time can give us a pretty high confidence level in setting delivery expectations. It is a strategy for predictability. When we look at improving those lead times, we often focus on how to improve the active work we do for the requests we receive. We might improve test automation, implement code review process and/or continuous delivery pipelines. Those are all great endeavors. However, too many teams are not aware that the biggest way to improve the lead times for our work may actually be focusing on reducing the time we spend NOT working on our requests.
- Натомість якщо ми покращемо неактивності на 50%, то наш лід тайм зменшиться до 7 днів.
- Зменшення розміру задач є одним з найбільш дешевих, простих та потужних шляхів зменшити черги і lead time. Питання як знайти оптимальний розмір?
- How to find optimal batch size? Empirical. Якийсь приклад зрозумілий. Про код. U-curve optimization problem
- Ще один з потужних шляхів керування чергами є обмеження паралельної роботи, або WIP. Це є в системі канбан. WIP constraints are came to us from TPS in manufacturing, but they are even more important in product development as we have higher variability. Ларі був директором Аналітики та Дослідження в Rally Software. Один з продуктів компанії Rally Software - це дуже популярна у Північній Америці, так звана task-tracking system. Аналог Jira.
- Що зробив Ларі, він взяв дані 90 тисяч команд, які працювали в цій системі, і витягнув їх. На основі цих даних він зробив дуже класне дослідження і захистив докторську дисертацію. І Ларі хотів допомогти показати імперичні дані (інакше кажучи факти) на основі великої кількості команд, і маючи їх як докази, допомогти людям повірити у зміни.