"Shape Up: How to Develop Quickly and Avoid Burnout", Dmytro Popov
•Download as PPTX, PDF•
0 likes•199 views
I'll share my experience of successfully implementing the Shape Up project development methodology at Work.ua. It's about how we started creating more successful projects, doing it quickly, with high quality, and enjoying our work without burnout.
Report
Share
More Related Content
Similar to "Shape Up: How to Develop Quickly and Avoid Burnout", Dmytro Popov
Similar to "Shape Up: How to Develop Quickly and Avoid Burnout", Dmytro Popov (20)
More from Fwdays
More from Fwdays (20)
"Shape Up: How to Develop Quickly and Avoid Burnout", Dmytro Popov
- 2. ● Понад 10 років у веброзробці ● 6 років у Work.ua ● Software Engineer Team Lead Про мене
- 3. ● Сайт пошуку роботи №1 в Україні ● 17 років на ринку ● Успішно використовуємо Shape Up понад 3 роки Про компанію
- 4. Що таке Shape Up Методологія розробки проєктів, яка була сформована у компанії Basecamp під час роботи над їхнім однойменним продуктом Basecamp.
- 5. Про що доповідь ● Чому ми вирішили перейти на Shape Up. ● Як ми здійснили цей перехід. ● Як ми це успішно використовуємо.
- 6. Проблеми, які у нас були (трішки історії) ● Довге написання ТЗ (багато деталей прописуються заздалегідь).
- 7. Проблеми, які у нас були (трішки історії) ● Довге написання ТЗ (багато деталей прописуються заздалегідь). ● Потім ТЗ бере дизайнер, дивиться і щось йому не подобається. ТЗ коригується.
- 8. Проблеми, які у нас були (трішки історії) ● Довге написання ТЗ (багато деталей прописуються заздалегідь). ● Потім ТЗ бере дизайнер, дивиться і щось йому не подобається. ТЗ коригується. ● Потім ТЗ і дизайн отримує розробник і в нього теж доволі багато запитань. ТЗ знову коригується.
- 9. Проблеми, які у нас були (трішки історії) ● Довге написання ТЗ (багато деталей прописуються заздалегідь). ● Потім ТЗ бере дизайнер, дивиться і щось йому не подобається. ТЗ коригується. ● Потім ТЗ і дизайн отримує розробник і в нього теж доволі багато запитань. ТЗ знову коригується. ● ТЗ повертається туди-сюди й дописується прямо під час роботи над проєктом. Дедлайн теж зміщується.
- 10. Проблеми, які у нас були (трішки історії) ● Довге написання ТЗ (багато деталей прописуються заздалегідь). ● Потім ТЗ бере дизайнер, дивиться і щось йому не подобається. ТЗ коригується. ● Потім ТЗ і дизайн отримує розробник і в нього теж доволі багато запитань. ТЗ знову коригується. ● ТЗ повертається туди-сюди й дописується прямо під час роботи над проєктом. Терміни виконання проєкту зміщуються. ● В результаті маємо такий собі затягнутий Waterfall.
- 11. Проблеми, які у нас були (трішки історії) І ще нюанси… ● Майже завжди задачу робив один розробник + він був у курсі всього – наприклад, захворів, і дедлайн накрився ● Code Review робив розробник, який не був глибоко залучений у проєкт.
- 12. Проблеми, які у нас були (трішки історії) Бували відчуття, що… Проєкт і дороблювати не хочеться, і кинути шкода 🫠
- 13. Проблеми, які у нас були (трішки історії) Все ж таки проєкти дороблювалися якісно, але із запізненням. Це виглядало якось так →
- 14. Але одного дня з нами стався Shape Up…
- 15. Shape Up Як бачимо, прямо у назві написано рішення нашої проблеми, яка була на малюнку на слайді з проблемами :) “Перестаньте ходити по колу і робіть тільки те, що потрібно”
- 16. Як ми переходили на Shape Up ● Провели експеримент: 1 проєкт для 1 команди ○ Вийшло швидко. Нам сподобалось. ● Поговорили з усіма. ● Перенесли проєкти з Jira та Google Docs у Basecamp 3. ● Всі почали працювати за методологією. ● За 2 місяці зрозуміли, що це у нас працює, і працює круто.
- 18. Термінологія Shape Up ● Shape (Формувати проєкт) — вважайте створити ТЗ ● Fat marker (Товстий маркер) ● Appetite (Апетит) ● Scopes (Шматки) ● Scope hammering (Збивання шматків) ● 6-weeks cycle (6-тижневий цикл) — схоже на Спринт ● Cooldown (Кулдаун), або Перерва між проєктами
- 19. Shape Up flow
- 20. Shape Up flow В оригіналі У нас
- 22. Shape (формування проєкту) ● Збираються керівники відділів, топменеджери, стейкхолдери.
- 23. Shape (формування проєкту) ● Збираються керівники відділів, топменеджери, стейкхолдери. ● Придумують ідеї та обговорюють ТЗ на високому рівні абстракції.
- 24. Shape (формування проєкту) ● Збираються керівники відділів, топменеджери, стейкхолдери. ● Придумують ідеї та обговорюють ТЗ на високому рівні абстракції. ● Вибирають Апетит (Appetite), який дозволено витратити на проєкт (ціна фічі)
- 25. Shape (формування проєкту) ● Збираються керівники відділів, топменеджери, стейкхолдери. ● Придумують ідеї та обговорюють ТЗ на високому рівні абстракції. ● Вибирають Апетит (Appetite), який дозволено витратити на проєкт (ціна фічі) ● Формують Товстий маркер (Fat marker) — загальний нарис, кордони проєкту: «що точно робимо і що точно не робимо».
- 26. Shape (формування проєкту) ● Збираються керівники відділів, топменеджери, стейкхолдери. ● Придумують ідеї та обговорюють ТЗ на високому рівні абстракції. ● Вибирають Апетит (Appetite), який дозволено витратити на проєкт (ціна фічі) ● Формують Товстий маркер (Fat marker) — загальний нарис, кордони проєкту: «що точно робимо і що точно не робимо». ● Обовʼязково позбавляються «пасток» (Rabbit Holes), через які можна вийти за рамки Апетиту.
- 27. Shape (формування проєкту) ● Збираються керівники відділів, топменеджери, стейкхолдери. ● Придумують ідеї та обговорюють ТЗ на високому рівні абстракції. ● Вибирають Апетит (Appetite), який дозволено витратити на проєкт (ціна фічі) ● Формують Товстий маркер (Fat marker) — загальний нарис, кордони проєкту: «що точно робимо і що точно не робимо». ● Обовʼязково позбавляються «пасток» (Rabbit Holes), через які можна вийти за рамки Апетиту. ● Створюється формувальний документ (ТЗ)
- 28. Shape (формування проєкту) ● Збираються керівники відділів, топменеджери, стейкхолдери. ● Придумують ідеї та обговорюють ТЗ на високому рівні абстракції. ● Вибирають Апетит (Appetite), який дозволено витратити на проєкт (ціна фічі) ● Формують Товстий маркер (Fat marker) — загальний нарис, кордони проєкту: «що точно робимо і що точно не робимо». ● Обовʼязково позбавляються «пасток» (Rabbit Holes), через які можна вийти за рамки Апетиту. ● Створюється формувальний документ (ТЗ) ● Збирають команду виконавців проєкту.
- 29. Shape (формування проєкту) Детальніше про наші Апетити (Appetite) ● L (4 тижні build + 2 тижні кулдаун) ● M (2 тижні build + 1 тиждень кулдаун) ● S (1 тиждень build + 2-3 дні кулдаун) ● Цикл зажди 6 тижнів (тобто можна зробити 1L або 2M або 4S) ● На практиці у нас кулдаун враховується в Апетиті.
- 31. Build (Розробка проєкту) — Початок розробки ● Презентація Формувального документа команді, яка зібрана під проєкт.
- 32. Build (Розробка проєкту) — Початок розробки ● Презентація Формувального документа команді, яка зібрана під проєкт. ● Команда може скорегувати Апетит (але дуже часто буває, що на етапі формування апетит обрано правильно)
- 33. Build (Розробка проєкту) — Початок розробки ● Презентація Формувального документа команді, яка зібрана під проєкт. ● Команда може скорегувати Апетит (але дуже часто буває, що на етапі формування апетит обрано правильно) ● Команда не відволікається на інші проєкти (навіть на попередні, які були зроблені в минулих циклах)
- 34. Build (Розробка проєкту) — 6-weeks cycle За 6-тижневий цикл розробки можна зробити, наприклад, 1 проєкт з апетитом L, або декілька проєктів з апетитом M.
- 35. Build (Розробка проєкту) — 6-weeks cycle З цікавого: ● Цикл проходить із вівторка по вівторок (не включно) 6 тижнів. ● Саме вівторок, щоб завершити всі справи не у пʼятницю, а зробити це в понеділок.
- 36. Build (Розробка проєкту) — В процесі робіт ● Проєкт бʼється на Scopes (Шматки)
- 37. Build (Розробка проєкту) — В процесі робіт ● Проєкт бʼється на Scopes (Шматки) ● Кожен Scope — це незалежна частина робіт, яку можна тестувати, показувати замовнику і в ідеалі навіть релізити.
- 38. Build (Розробка проєкту) — В процесі робіт ● Проєкт бʼється на Scopes (Шматки) ● Кожен Scope — це незалежна частина робіт, яку можна тестувати, показувати замовнику і в ідеалі навіть релізити. ● Всі члени команди намагаються працювати над шматками одночасно, а не послідовно.
- 39. Build (Розробка проєкту) — В процесі робіт ● Проєкт бʼється на Scopes (Шматки) ● Кожен Scope — це незалежна частина робіт, яку можна тестувати, показувати замовнику і в ідеалі навіть релізити. ● Всі члени команди намагаються працювати над шматками одночасно, а не послідовно. ● Можна відсікти (scope hammering) якийсь шматок, без чого буде теж повноцінний реліз.
- 40. Build (Розробка проєкту) — В процесі робіт ● Проєкт бʼється на Scopes (Шматки) ● Кожен Scope — це незалежна частина робіт, яку можна тестувати, показувати замовнику і в ідеалі навіть релізити. ● Всі члени команди намагаються працювати над шматками одночасно, а не послідовно. ● Можна відсікти (scope hammering) якийсь шматок, без чого буде теж повноцінний реліз. ● Головне — це не випасти з Апетиту (Appetite) !!!
- 41. Build (Розробка проєкту) — Cool Down 😎 Після успішного релізу проєкту починається Кулдаун.
- 42. Build (Розробка проєкту) — Cool Down 😎 ● Cool Down — це можливість «відпочити» перед початком наступного проєкту.
- 43. Build (Розробка проєкту) — Cool Down 😎 ● Cool Down — це можливість «відпочити» перед початком наступного проєкту. ● Команда повинна зарелізити проєкт до Cool Down.
- 44. Build (Розробка проєкту) — Cool Down 😎 ● Cool Down — це можливість «відпочити» перед початком наступного проєкту. ● Команда повинна зарелізити проєкт до Cool Down. ● Вся команда зацікавлена в тому щоб Кулдаун був.
- 45. Build (Розробка проєкту) — Cool Down 😎 ● Cool Down — це можливість «відпочити» перед початком наступного проєкту. ● Команда повинна зарелізити проєкт до Cool Down. ● Вся команда зацікавлена в тому щоб Кулдаун був. ● Що наші команди роблять у цей час: ○ фікс багів зарелізеного проєкту ○ NTH задачі (Nice-to-have) ○ ретроспективи ○ написання технічної документації ○ різні цікаві і корисні дослідження, для яких інколи немає часу ○ технічний борг
- 46. Що ми не використовуємо з Shape Up ● Bet — необхідність проголосувати за проєкти, які сформовано під час усіх попередніх циклів і після голосування передати в Розробку. ● Голосують формувальники. ● Якщо проєктів сформовано багато, а в роботу треба менше, то проєкт відкладається на обговорення і голосування на наступний Shape.
- 47. Що ми не використовуємо з Shape Up У нас: ● Відразу формуються проєкти, які треба робити в наступний Build. ● Термінові або трендові проєкти, які треба брати й робити. ● Проєкти погоджуються без формальних голосувань.
- 48. Це все щодо нашого Shape Up flow.
- 49. На початку були деякі складності… ● Формувальникам було важко домовитись. Рішення: навчились домовлятись.
- 50. На початку були деякі складності… ● Формувальникам було важко домовитись. Рішення: навчились домовлятись. ● Формувальники не встигали сформувати достатньо проєктів для всіх команд. Рішення: почали формувати заздалегідь.
- 51. На початку були деякі складності… ● Формувальникам було важко домовитись. Рішення: навчились домовлятись. ● Формувальники не встигали сформувати достатньо проєктів для всіх команд. Рішення: почали формувати заздалегідь. ● Розробка виходила за рамки 6-тижневого циклу. З досвідом це зникло.
- 52. На початку були деякі складності… ● Формувальникам було важко домовитись. Рішення: навчились домовлятись. ● Формувальники не встигали сформувати достатньо проєктів для всіх команд. Рішення: почали формувати заздалегідь. ● Розробка виходила за рамки 6-тижневого циклу. З досвідом це зникло. ● Деяким членам команди (дизайнер / верстальник) під кінець циклу було нічого робити. Рішення: вони робили інші корисні задачі.
- 53. На початку були деякі складності… ● Формувальникам було важко домовитись. Рішення: навчились домовлятись. ● Формувальники не встигали сформувати достатньо проєктів для всіх команд. Рішення: почали формувати заздалегідь. ● Розробка виходила за рамки 6-тижневого циклу. З досвідом це зникло. ● Деяким членам команди (дизайнер / верстальник) під кінець циклу було нічого робити. Рішення: вони робили інші корисні задачі. ● Розробка “зʼїдала” повноцінні кулдауни. З досвідом це зникло.
- 54. Але в результаті стало краще! ● Прогнозованість. Проєкти виконуються вчасно. ● Сфокусованість. Немає перемикання між різними проєктами / контекстами. ● Автономність команд. В процесі розробки багато рішень команда приймає самостійно. ● Час щоб нормально закінчити проєкт. Завдяки кулдауну завершуємо проєкт без “хвостів”. ● Командний дух. Люди в команді багато спілкуються і взаємодіють між собою вирішуючи спільну проблему.
- 55. Підсумок ● Все, що я розказав, є головною концепцією Shape Up. ● Ми можемо впевнено сказати що у нас Shape Up, але трішки зі своїм фльором 🙂 ● Стало набагато краще: більше виконаних проєктів, і немає постійної втоми від гонитви задач.
- 56. Корисні посилання ● https://basecamp.com (Система управління проєктами Basecamp) ● https://basecamp.com/shapeup/shape-up.pdf (Книга Shape Up) ● Посилання на мій LinkedIn для зворотного звʼязку:
- 57. 🧐 Запитання?