Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Методологія розробки ІТ проектів Scrum

1.063 visualizaciones

Publicado el

Методологія розробки ІТ проектів Scrum проведена у Вільному кафе STANTSIYA у Івано-Франківську. 3.02.2015

Publicado en: Empresariales
  • Sé el primero en comentar

Методологія розробки ІТ проектів Scrum

  1. 1. Методологія розробки ІТ проектів SCRUM Євген Вершинін 3.02.2015 Вільне кафе STANTSIYA
  2. 2. Чому Scrum?  Scrum – це один з Agile процесів, який дозволяє сфокусуватись на постановці найважливіших, з точки зору бізнесу, ціностях в найкоротші строки.  Бізнес розставляє пріоритети. Команди самоогранізуються і визначають найкращий шлях випуску функцій з високим пріоритетом.  З регулярністю від двох тижнів до місяця всі можуть бачити реально працюючий програмний продукт, і вирішити випускати його, як він є або продовжити поліпшення в наступному спринті.
  3. 3. Основні характеристики  Самоорганізуючі команди  Продукт розробляється послідовністю ітерацій («спринтів»), кожний з них не більше місяця  Усі вимоги записуються у вигляді єдиного списку, «беклог продукту»  Інженерні практики не є частиною Scrum  Використовуються прості правила для створення гнучкого середовища розробки проектів  Один з Agile процесів
  4. 4. Agile Manifesto – декларація цінностей процесів і інструментів Люди і взаємодія важливіші слідування попереднім планом Готовність до змін важливіша вичерпної документації Працюючий продукт важливіший узгодження умов контракту Співпраця з замовником важливіша
  5. 5. Scrum Відміна Повернення Спринт 2-4 тижні Повернення Ціль спринта Беклог спринта Потенційно готовий до випуску продукт Беклог продукту Купони Подарочна упаковка Купони Відміна 24 години
  6. 6. Scrum в одній картинці
  7. 7. Спринт - ітерація  Scrum проекти розробляються послідовністю «спринтів»  Типова тривалість - від 2-х тижнів до місяця з жорстким обмеженням за часом  Постійна тривалість спринту привносить ритм в розробку  Продукт проектується, розробляється і тестується протягом одного спринту
  8. 8. Замість того, щоб виконувати ці активності по черзі ... ... Scrum команди роблять потрошки від кожної весь час Вимоги Дизайн Розробка Тестування Источник: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. Розробка: Послідовна проти паралельної
  9. 9. Ніяких змін під час розробки спринту  Плануйте тривалість спринту виходячи з міркування про те, як довго ви можете працювати, не вносячи зміни до плану робіт  Зміни все ж таки можливі, але треба розуміти втрати і попередні заплановані задачі. Зміни
  10. 10. Структура Scrum  Ролі в команді (Roles)  Власник продукту (Product Owner)  Scrum мастер (Scrum Master)  Команда  Зустрічі (Ceremonies)  Планування спринту  Огляд спринту (Demo)  Ретроспектива сринту  Щоденний Scrum (Stand-up meeting)  Документи (Artifacts)  Беклог продукту (Product Backlog)  Спринт беклог  Burndown графіки
  11. 11. Ролі в команді (Roles)  Власник продукту  Одна людина, яка визначає вимоги до продукту  Визначає дату релізу і функціонал  Відповідальний за продукт та його дохідність  Пріоритизує вимоги, виходячи з їх ринкової цінності  Коригує пріоритети на кожній ітерації, якщо необхідно  Приймає виконану роботу  Scrum мастер  Відповідальний за впровадження цінностей і практик Scrum  Не роздає завдання  Усуває перешкоди і захищає команду від зовнішніх впливів  Відповідальний за ефективність роботи команди
  12. 12. Команда  Зазвичай 5-9 осіб  Крос функціональна  Програмісти, тестувальники, дизайнери  Зайняті на повний робочий день  Можливі вийняти (наприклад, адміністратор баз даних)  Команди самоорганізовуються  Склад команди може змінюватись тільки між сринтами
  13. 13. Зустрічі  Зустрічі (Ceremonies)  Планування спринту  Огляд спринту (Demo)  Ретроспектива спринту  Щоденний Scrum (Stand-up meeting)
  14. 14. Планування спринту Планування Що робимо • Аналізуємо беклог • Вибираємо Ціль спринту Як робимо • Вирішуємо як досягти Цілі спринту (дизайн) • Створюємо Беклога спринт (Завдання) з елементів Беклога Продукту (історій користувача / функцій) • Оцінюємо Беклог Спринту в годинах / попугаях / інше Ціль спринту Спринт беклог Бізнес середовище Команда Беклог продукту Технологія Продукт
  15. 15. Процес планування  Команда вибирає з Беклога Продукту вимоги, які вони можуть реалізувати за спринт  Створюється Беклог спринту  Створюються конкретні задачі та оцінюються командою (1-16 годин)  Все виконується командою, а не Scrum мастером  Враховується архітектура проекту і інші обставини Як відпочиваючий, я хочу переглянути фото готелів Запрограмувати серверну частину (8) Створити GUI (4) Створити тести (4) Оновити документацію (4)
  16. 16. Щоденний Scrum Daily Stand-up meeting  Характеристики  Щоденно у визначений час  15 хвилин  Стоячи  Не для вирішення проблем  Всі ролі мають бути присутні на зустрічі  Scrum мастер тільки веде зустріч
  17. 17. Кожний відповідає на 3 питання  Що ти зробив учора?  Що будеш робити сьогодні?  Які проблеми заважають? • Це не статус для Scrum мастер • Це зобов'язання перед колегами
  18. 18. Огляд спринту (Demo)  Команда презентує, що було зроблено за спринт  Фокус на результат, а не процес  Зазвичай приймає форму демонстрації  Неформально  Максимум 2 години на підготовку  Без слайдів  Вся команда приймає участь  Запрошуються всі, кому може бути цікаво
  19. 19. Ретроспектива  Періодичний перегляд процесу проекту  Зазвичай 15-30 хвилин  Проводиться після кожного спринту  Приймає участь вся команда  Можуть бути запрошені клієнт, власник продукту, керівництво компанії  Один з варіантів проведення зустрічі:  Що нового потрібно започаткувати у процесі розробки?  Що потрібно зупинити і відмовитись?  Що потрібно продовжувати робити?
  20. 20. Документи (Artifacts)  Беклог продукту (Product Backlog)  Спринт беклог  Burndown графіки
  21. 21. Беклог продукту  Вимоги  Список бажаної функціональності  В ідеалі написаний так, що кожен елемент має значення для кінцевого користувача  Сортований по пріоритету  Пріоритети виставляє Власник продукту  Пріоритети оновлюються на початку спринту Беклог продукту  Новий функціонал  Помилки  Технічні задачі  Дослідження
  22. 22. Приклад беклогу продукту News • As a site visitor, I can read current news on the home page. • As a site visitor, I can access old news that is no longer on the home page. • As a site visitor, I can email news items to the editor. (Note: this could just be an email link to the editor.) • As a site a site editor, I can set the following dates on a news item: Start Publishing Date, Old • News Date, Stop Publishing Date. These dates refer to the date an item becomes visible on the site (perhaps next Monday), • the date it stops appearing on the home page, and the date it is removed from the site (which may be never). • As a site member, I can subscribe to an RSS feed of news (and events? Or are they separate?). • As a site editor, I can assign priority numbers to news items. Items are displayed on the front page based on priority.
  23. 23. User Story  Короткий і простий запис вимоги записаний від імені користувача.  As a <type of user>, I want <some goal> so that <some reason>.  Як модератор форуму, я хочу блокувати користувачів на 2, 5, 10 днів, таким чином я зможу запобігти частим порушенням правил форуму.
  24. 24. Проект описаний User Story (story mapping)
  25. 25. Ціль спринту  Коротке речення, яке описує, на чому буде сфокусована робота під час спринту БД Фінанси Наука Підтримка функціональності необхідної для вивчення генетики Додати підтримку котирувань в реальному часі Зробити в додатку підтримку MSSQL на додаток до Oracle
  26. 26. Беклог спринту  Члени команди вибирають роботу на свій вибір з найважливіших елементів беклогу продукту  Оцінка роботи, що залишилася, щодня оновлюється  Будь-який член команди може додати, видалити або змінити елементи Беклога Спринту  Якщо завдання не зрозуміле, то цьому елементу беклога резервується більше часу і він розбивається на складові частини пізніше  Формується на зустрічі Планування спринту
  27. 27. Приклад беклогу спринту
  28. 28. Burndown графік  Оновлюється кожний день  Показує реальний стан виконання задач  Візуалізує процес та кінцеву мету
  29. 29. Scrum дошка
  30. 30. Scrum дошка
  31. 31. Все і одразу!
  32. 32. Все і одразу
  33. 33. Посилання та література  www.mountaingoatsoftware.com/scrum  www.scrumalliance.org  www.controlchaos.com  Scrum and The Enterprise by Ken Schwaber  Succeeding with Agile by Mike Cohn  User Stories Applied for Agile Software Development by Mike Cohn  www.scrumalliance.org/why-scrum  Scrum и XP: заметки с передовой  www.agilemanifesto.org  blog.bbv.ch/2011/02/02/presentation-scrum-at-bbv- software-services-ag/  goagile.co.uk  www.agilebuddha.com/agile/story-mapping-andvs-process- maps/
  34. 34. Дякую за увагу!  jen.versh@gmail.com  www.twitter.com/jen777  www.facebook.com/yvershynin

×