Ілона Кулинич “Маленький Скрам проти Великого Вотерфолу: історія одного ПМа”
•
4 gefällt mir•1,590 views
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Ілона Кулинич “Маленький Скрам проти Великого Вотерфолу: історія одного ПМа”
Ähnlich wie Ілона Кулинич “Маленький Скрам проти Великого Вотерфолу: історія одного ПМа” (20)
Mehr von Lviv Startup Club
Mehr von Lviv Startup Club (20)
Ілона Кулинич “Маленький Скрам проти Великого Вотерфолу: історія одного ПМа”
- 1. CIKLUM CONSULTING 1 Львів квітень, 2014 Маленький Скрам проти Великого Вотерфолу: історія одного ПМа
- 3. Сіклум Консалтінг 3 1. Agile трансформація бізнесу 2. Сертифікації, тренінги та публічні класи 3. Робота з командами Сіклума
- 4. 4 Агенда 1. Проект Х: особлива звичайність 2. Виклики для ПМа 3. Рішення 4. Досвід
- 5. 5 Проект X
- 6. З мене досить! 6 • поганий код • немає контролю • постійні запізнення З мене досить!
- 7. Ліричний відступ №1: що аналізувати? 7 engagement quality productivity time to market
- 8. Погляд на команду 8 engagement quality productivity time to market Погляд на команду
- 9. 9 1. 500 осіб = 100 компаній 2. Класичний вотерфол 3. Відсутність єдиної культури 4. 90% ситуацій вирішується усним спілкуванням Погляд на клієнта
- 10. Проект очима ПМа 10 1. Команді потрібно виробляти продукт, а не код 2. Створити середовище, де можлива нормальна розробка. Навчити клієнта підтримувати це середовище 3. Клієнт завжди правий. Майже завжди
- 11. 11
- 12. 12 Чому аджайл? http://stateofagile.versionone.com/ • Продуктивність • Якість • Прозорість • Зниження ризиків • Спрощення процесу • Зменшення коштів • Покращення командного духу • Сильні інженерні практики • Можливість перенести процес на розподілену команду
- 13. 13 Аджайл у реаліях проекта X Engagement Quality Productivity Time to Market 1. Командна робота з фічею 1. Фокус час – 6 годин 2. Сінхронізація команди 3. Два стендапи: вранці, ввечері 2. Командні естімейти 3. Командне планування 1. Написання командою юзер сторі, аксептанс критерієв 2. Перевірка коду найбільш довсідченим програмістом 1. Визначення, що таке «готово» 2. Демо клієнту та Продакт Менджеру. 3. Календарне планування фронт енду
- 14. 14 Ризики Engagement Quality Productivity Time to Market 1. Командна робота з фічею 1. Фокус час – 6 годин 2. Сінхронізація команди 3. Два стендапи: вранці, ввечері 2. Командні естімейти 3. Командне планування 1. Написання командою юзер сторі, аксептанс критерієв 2. Перевірка коду найбильш довсідченим програмістом 1. Визначення, що таке «готово» 2. Демо клієнту та Продакт Менджеру. 3. Календарне планування фронт енду Команда не крос-функціональна Відсутність Продакт Менеджера у нашому процесі Перша спроба працювати як команда Вотерфол на стороні клієнта
- 15. Людські фактори 15 • Хвороба на 2 тижні • Хочу в тім-ліди! • Відпустка «з понеділка» • Звільнення • Декрет продакт менеджера • Ігнор бек-енда • Новий Рік
- 16. 16
- 17. Делівері. Людські фактори. Знову. 17 • Черга змін дизайну • Бек-енд команда не встигла підготувати API
- 18. 18 Ліричний відступ №2: тестування при вотерфолі
- 19. 19 Баги? спокій, тільки спокій 120+ багів Не все баги – «наші» Свої баги – 32 години на фікс
- 20. 20 Ефект «цапа»
- 22. 22 Все що не робиться...
- 23. 23 В чому сила ПМа?
- 24. 24 Велика компанія – не завжди історія успіху
Hinweis der Redaktion
- Доброго дня,Мене звати Ілона. Мій творчий шлях в айті – 10 років, вже майже 5 років я працюю проджект менеджером на просторах українского айті світу. Мій менеджер-шлях розпочався з роботи продакт менеджера і поступово таск за таском я перетворилася на ПМ. У жовтні минулого року я приєдналася до Консалтінг Офісу Сіклума і вже 6 місяців працюю з командами клієнтів Сіклума. 23 – це кількість годин у поїзді Донецьк-Львів.
- Про Сіклум – модель, коли команда, що розташована в Україні стає командою клієнта. Клієнт сам керує командою. Про Сіклум КонсалтінгAgile business transformationR&D departments 50-450 peopleSolving issues, efficient teams and toolsEducation, public classes – большой опыт позволяетPractical experience+ ground theoretical frameworksICAgile, SAFe- Managed Services – Ciklum clients
- Підписаний НДА не дозволяє розкрити назву компанії, або навіть натякнути на індустрію. Відчуваю себе як шпигунка, але якщо після моєї доповіді ніхто не може назвати мого клієнта – це означає, що я впоралася із задачею: розвопісти бізнес кейс і не порушити НДА.Отже – мой клієнт це 500 осіб, де 250 – програмісти. 1 мільярд на біржі, великі плани на майбутнє, в тому числі й для аутсорсу. До речі, клієнт абсолютно новенький в аутсорсі і Сіклум для нього – перша спроба. Розпочалося співробітництво з команди в 4 особи на теренах України. Я почала свою роботу над проектом через 3 місяці після старта. І як ви могли здогадатися покликами консультанта не просто так.
- Моя робота на проекті почалася з того, що клієнт висловив намір закрити команду. Такий гарний початок, що не обіцяв нічого. Під час розмови з клієнтом я слухала про те, що хлопці працюють погано (код пишуть недбало), велика кількість багів, багато часу на розмови. Клієнт не має уявлення, що вони роблять прогятом дня і часто не може знайти людей біля компьютеру. Терміни постійно порушуються, особливо на маленьких завданнях у 2-3 години. Якщо узагальнити, то «все погано». Ось такий початок.Мені треба було зрозуміти, що насправді турбує клієнта, бо «все погано» - це як все болить. Отже, що ми робимо в таких випадках? Ми виключаємо емоції та включаємо аналітику.
- Ліричний відступ №1. Сьогодні у нас буде два ліричних відступи про те як ми працюємо у Консалтінг офісі. Перший про те, як ми вимірюємо успішність проекту, будь-якого.Отже, коли нам потрідно зрозуміти, які проблеми, або як себе почуває проект то ми вимірюємо такі речі як: -people engagement into the project;-product quality;-people productivity;-time to market;
- З проектом Х було зроблено аналіз за критеріями і було виявлено, що проект є провальним за всіма критерями. Люди не зацікавлені в роботі, навіть з великими грошима. Якість коду низька, робота з багами займала 75% часу. Порівняно з он-шор командою українська команда показувала низький рівень коду, витрачала на це більше часу. Естімейти ніколи не були правдою.
- Коли намагаєшся знайти причину проблеми, то варто дивитися не тільки на команду, але і на клієнта. Компанія не давала можливості зазирнути у свою структуру, процес розробки, який вони мають. Отже, залишалося піти до людей та запитати. Я звязалася з людьми, які безпосередньо працюють з командою та запитала про їх бачення ситуації – чому ніа-шор команда працює не так, як очікувалося. Окрім думок, що інколи біли влучними, інколи дивували, зїясувалося, що компанія клієнта, де працюють 500 осіб – це 100 маленьких команд, кожна з яких працює за своєю власною культурою. Здавалося б нічого особливого. Але для розподіленої команди це означало, що клієнт будує співробітництво на усному спілкуванні між членами невеличких команд. Виявилося, що всередині компанії клієнта люди також мають звичку звинувачувати іншу команду, не мають уявлення, що робить інша комада, як і взагалі навіщо інші 499 осіб існують.
- Це виглядає як звичайний проект, який ніхто не хоче: клієнт, програмісти – всі були вже роздратовані. Гарний початок? Але виклик прийнято адже ми ПМи, хто, як не ми? Отже, для ПМа проект виглядає як звичайний:-на проекті не просто все погано, а погано все-все (ми це перевірили раніше)-клієнт – співучасник злочину, бо створив все, що було потрібно для провалу-клієнт не хоче визнавати, що він робив щось неправильно, а це означає, що і далі він будет робити так саме-проект має проблеми, які неможливо вирішити роботою лише на цій стороніЯкі шанси, що клієнт послухає ПМа, якого бачить третій раз в житті і змінить свою практики, свій світогляд?
- Як всім зрозуміло, клієнт залишився. Погодився дати ще один шанс команді, Сіклуму і мені. Не можна не зрадіти, але ризики нікуди не зникли. З всього, що біло раніше єдиною зміною був настрій мого дорогого клієнта. Одже, задача була такою: швидко зробити команду робочою, довести клієнту, що він може працювати з розподіленою командою. Звичайно, в голові була ідея, що «скрам їм би допоміг»Отчет о ежегодном опросе «State of Agile Development» уже несколько лет удивляет интересными наблюдениям. В рамках этого исследования раз в год публикуются результаты, которые так или иначе позволяют увидеть, куда движется индустрия разработки программного обеспечения.
- Я вирішила, що візьму найбільш популярні практики зі скрама і наступну фічу будемо розробляти за ціма практиками:1. Грумінг задачі, розділ спеки на юзер сторі, а сторі на таски. Ми робили самі, бо продакт менеджер не мала часу на цю маячню.2. Планування, на якому команда сама визначає, скільки часу потрібно на розробку функціоналу, робить естімейти, пояснює їх.3. Перевірка прогресу кожного дня, а ми додали навіть два рази на день: вранці та ввечері4. Демо готових сторі5. Тестування за аксептанс критеріями, які ми написали самі.6. Відокремлення часу тестування від часу розробки7. Ревью кода своїх колег8. Календарне планування фронт енду, щоб привязатися до бекенду вчасно.9. Клієнт отримував статуси про прогрес кожного дня.
- Я вирішила, що візьму найбільш популярні практики зі скрама і наступну фічу будемо розробляти за ціма практиками:1. Грумінг задачі, розділ спеки на юзер сторі, а сторі на таски. Ми робили самі, бо продакт менеджер не мала часу на цю маячню.2. Планування, на якому команда сама визначає, скільки часу потрібно на розробку функціоналу, робить естімейти, пояснює їх.3. Перевірка прогресу кожного дня, а ми додали навіть два рази на день: вранці та ввечері4. Демо готових сторі5. Тестування за аксептанс критеріями, які ми написали самі.6. Відокремлення часу тестування від часу розробки7. Ревью кода своїх колег8. Календарне планування фронт енду, щоб привязатися до бекенду вчасно.9. Клієнт отримував статуси про прогрес кожного дня.
- Все неможливо передбачити. Після роботи над цією фічею з цією командою я вірю, що є нещасливі команди. За історію спрінта трапилися всі людські фактори, які я взагалі можу згадати як можливі. Маю зізнатися, що я була готова до 1-2, може 3, але...1 програміст захворів на два тижні2 захотів стати тім лідом та показував мені як він ображається на моє НІ3 пішов у відпустку «з понеділка»4 звільнивсяПродакт менеджер народила дитинуБек-енд команда пішла в ігнорНаступив Новий Рік
- * Лирическое отступление №2 (тестирование в разработке через Ватерфольный опыт) - 4я редакция спеки вместо той, над которой работали тестировщики
- 120+ багів Не всі баги наші32 години на власні баги
- На цьому етапі ми зустріли багато «цапів», але через деякий час зрозуміли, що ці цапи це є ми в очах он-шорної команди. На нас звалили провину за всі баги, за всі затримки. Коли я звернула увагу на кількість нашіх багів, що ми зробили своїми руками, то .... Нас звинуватили в тому, що ми «не команда». Баги розподілили навпіл ... Ми отримали баги до фіч, які ніколи не бачили. Як вам таке рішення? Оптимальне? Все це тільки додало стресу до того, що все був. удаленные команды стали себя защищать и “вспомнили о командности” ** баги не наши, но фиксить все равно нужно ** эффект “козлов”
- * Кризис не все пережили ** один ушел, второй собрался ** однако, выяснилось, что это именно те люди, которые допускали ошибки и их уход повысил качество разработки :-)
- ** однако, выяснилось, что это именно те люди, которые допускали ошибки и их уход повысил качество разработки :-)
- Заключение (1-2-3 слайда)* маленький ПМ все равно может донести сообщение, если вооружится фактами и проявит настойчивость ** работа ПМ - это лидерство и рассчет, а не “руко водительство” и пустые лозунги
- - Большая компания - не означает, что там знают, что и как делать ** не всегда размер - это история успеха компании.