• Лекція 10
• Гнучкі методології Extreme Programming та Agile
  • 10.1 Управління проектами і розробка ПЗ
    • 10.1.1 Проектний трикутник/трикутник компромісів
  • 10.2 Управління проектами
  • 10.3 Розвиток методологій та методів
  • 10.4 Гнучка розробка (Agile software development)
    • 10.4.1 Методи та фреймворки
    • 10.4.2 Методологія гнучкої розробки (Agile software development)
  • 10.5 Організаційна структура компанії-розробника
    • 10.5.1 Функціональна структура
  • 10.6 Матрична структура
    • 10.6.1 Слабка матриця
    • 10.6.2 Збалансована матриця
    • 10.6.3 Сильна матриця
  • 10.7 Метод Extreme Programming
    • 10.7.1 Цінності у Extreme Programming
    • 10.7.2 Практики у Extreme Programming
  • 10.8 Метод Scrum
    • 10.8.1 Ролі учасників проекту
    • 10.8.2 Артефакти Scrum
    • 10.8.3 Зустрічі Scrum
    • 10.8.4 Від гнучкої розробки до DevOps
    • 10.8.5 Безперервна доставка (Continuous delivery)
    • 10.8.6 Основні процеси DevOps
    • 10.8.7 Continuous delivery та DevOps
    • 10.8.8 DevOps та MSF
    • 10.8.9 Azure DevOps. Керування проектом

Лекція 10

Гнучкі методології Extreme Programming та Agile

Створення програм є проектною діяльністю. Ця діяльність має бути ефективною.

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

10.1        Управління проектами і розробка ПЗ

10.1.1        Проектний трикутник/трикутник компромісів

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

Для планування і контролю цих показників застосовуються різні підходи, перелічені нижче:

Scope - WBS, CCB (change control board), Backlogs, Tickets

Schedule - CPM, PERT, Timeboxes, Severity Levels

Budget – EVM (earned value management), ROI, Burndowns, and KPIs

Статут проекту (Project charter)

Статут (концепція) проекту (Project charter) – документ, випущений спонсором проекту, який формально визначає правомочність проекту та дозволяє менеджеру проекту використовувати організаційні ресурси [PMBOK® Guide].

Успішно виконана специфікація проекту істотно зменшує ризики в ході його реалізації.

Статут – ключовий документ для прийняття рішень та підтвердження результатів проекту. Визначає менеджера (керівника) проекту, допущення та обмеження.

Структура Статуту:

Мета

опис бізнес-потреб та завдань.

значима, конкретна, вимірювана, реальна

Результати

користь для клієнта, який продукт/ послуга будуть отримані, високорівневі вимоги

вимірювані

Припущення та обмеження

Припущення пов’язані із ризиками

Обмеження – нормативні, технічні, захист інформації, можуть включатись вимоги за замовчуванням

Ключові учасники та stakeholders

Спонсор проекту

Замовник

Користувачі

Куратор проекту

Менеджер (керівник) проекту

Субпідрядники, постачальники

Ресурси

Персонал - ресурс проектів із розроблення ПЗ, який визначає вартість

Матеріальні ресурси, послуги

Бюджет

Строки

Контрольні точки -досягнення важливого результату. Часто закінчення певної ітерації має дати працюючий прототип

Ризики (Ризик – невизначена подія (умова), настання якої негативно/позитивно впливає на мету проекту [PMBOK® Guide].)

Якісна оцінка (низький, середній, високий)

Критерії приймання

Чисельні значення характеристик системи.

Заміряються у ході ПСІ або дослідної експлуатації

Обґрунтування корисності

Для кого результати

Опис поточних проблем (As Is)

Як результати усувають проблеми (To Be)

Оцінка економічного ефекту

Переваги, які отримає розробник

10.2        Управління проектами

Традиційні методи розробки були орієнтовані на запезпечення передбачуваності проекту (Traditional aims for Predictability).

У 50-ті рр ХХст. у промисловому виробництві (зокрема автомобільній галузі) почався пошук підходів, які б забезпечили розвиток та удосконалення продукту – з’явилось поняття ощадливої розробки (Lean aims for Innovation). Цей підхід був орієнтований на роз’вязок виявлених проблем (наприклад, потрібно створити авто, яке буде найшвидшим у своєму класі) и потребував наявності експертів (кваліфікованих розробників) для якомога швидшого пошуку рішення.

У 90-ті рр ХХст. з’явилась ідея гнучкої розробки, яка була орієнтована на швидку видачу продукту проекту (Agile aims for Speed).

Традиційні методи – ефективність завдяки найкращій ціні

Ощадлива розробка – поставка інновацій у мінімальні терміни

Гнучка розробка – швидка передача користувачеві перших працюючих прототитів

Cтатистичні дані, зібрані у звіті Standish Group, виданому 2015 р., свідчать, що не залежно від розміру проекту гнучкі підходи (agile approaches) дають більш успішні результати.

10.3        Розвиток методологій та методів

Як видно, масове виробництво спочатку використовувало традиційні підходи, у 50-ті рр ХХст. з’явилось ощадливе виробництво, використовувались формалізовані підходи.

У 90-ті рр. ХХ ст. пошук більш ефективних методів призвів до появи терміну Скрам, методу XP, що вилилось у 2001р у маніфест гнучкої розробки.

10.4        Гнучка розробка (Agile software development)

10.4.1        Методи та фреймворки

10.4.2        Методологія гнучкої розробки (Agile software development)

Agile (гнучка методологія розробки) – концептуальний каркас, на основі якого виконується розробка ПЗ. Акцент на мінімізації ризиків, постійній взаємодії розробників та замовників.

Agile-команда сама організує роботу.

Як видно, гнучка розробка орієнтує команду виконавців на швидку передачу клієнту працюючого продукту (спочатку із мінімальною функціональністю - мінімально життєздатного продукту (minimum viable product, MVP)) та самоорганізацію своєї роботи

Agile Manifesto

• задоволення клієнта за рахунок ранньої та безперебійної поставки ПЗ, яке має цінність

• вітання змін вимог навіть наприкінці розробки

• часта поставка робочого ПЗ

• щоденне спілкування замовника з розробниками

• проект виконують мотивовані особистості у зручному середовищі, які мають підтримку і довіру

• найбільш ефективний метод передачі інформації - розмова віч-на-віч

• робоче ПЗ - найкращий вимірювач прогресу

• Agile-процеси сприяють сталому розвитку.

• постійна увага поліпшенню технічної майстерності та зручному дизайну

• простота - мистецтво не робити зайвої роботи - дуже важливо

• найкращі технічні вимоги, дизайн та архітектура виходять у самоорганізованої команди

• команда регулярно роздумує про те, як стати більш ефективною і відповідно налаштовує та корегує свою поведінку

Мета гнучкої розробки

Основна мета - поставка мінімально життєздатного продукту (minimum viable product, MVP), який відповідає цілям проекту.

Цілі проекту фіксуються у його статуті (Project Charter) у розділі мета.

Для забезпечення мети гнучкої розробки потрібно:

• Спільне бачення проету (може змінюватись)

• Повні команди (команда клієнта + міжфункціональна команда)

• Інкрементна поставка (використання невеликих "спринтів")

• Безперервна інтеграція та тестування

Стадії управління гнучкою розробкою

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

Бізнес-кейси (як при використання традиційних методів) визначаються для усіх цілей проекту, часто містять очікувані якісні та кількісні показники.

Команди виконавців конкурують в процесі передачі робіт на виконання:

• Зовнішні постачальники подають пропозиції відповідно до Request for Proposals.

• Внутрішні команди подають бюджети та пропозиції, щоб виграти виділене фінансування від PMO (офіс менеджера проекту).

Рання розробка часто організується методом Scrum: процес ділиться на спринти, щоб ітеративно давати приріст працюючого продукту до релізу.

Кожного спринту виконується:

• Sprint Planning - Власник продукту (Product Owner) та Команда (Team) планують спринт

• Sprint Development - Команда розробляє, будує та випробовує приріст роботи за фіксований період часу

• Sprint Retro & Review - Клієнт оглядає роботу, і команда переглядає спринт для удосконалення

Постійна поставка – DevOps:

• Розвиток (Development).

• Create - створення нового або виправлення складання (build).

• Verify - переконання, що продукт працює.

• Package - передача до випуску.

• Операції (Operations)

• Release - розгортання нових можливостей / покращення / виправлення помилок.

• Configure - увімкнення / вимкнення операцій та функцій тестування.

• Monitor - моніторинг продуктивності функціональності.

• Plan - визначення пріоритетів наступного удосконалення.

10.5        Організаційна структура компанії-розробника

Функціональна і проектна організаційні структури – протилежіні полюси, а матрична – проміжний стан (частково усуває проблеми функціональної та проектної структур, часто використовується розробниками ПЗ).

Не можна визначити одну кращу організаційну структуру.

10.5.1        Функціональна структура

Переваги:

• Зрозумілі та стабільні умови роботи.

• Спеціалізація забезпечує експертизу.

• Один керівник.

Недоліки:

• Важко приймати рішення та взаємодіяти.

• Неефективний контроль виконання.

Проектна структура

Переваги:

• Команда збирається для проекту.

• Зручно в віддалених проектах.

Недоліки:

• Повільний старт.

• Досвід не накопичується.

10.6        Матрична структура

У розробці ПЗ найбільш поширена матрична організація.

У компаніях, які займаються продуктової розробкою ПЗ, функціональні підрозділи визначаються у відповідність з лінійкою продуктів. Наприклад, відділ розробки CRM-систем, відділ розробки фінансових систем, відділ розробки додаткових продуктів.

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

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

10.6.1        Слабка матриця

У слабкій матриці роль і повноваження співробітника, який координує проект, сильно обмежені.

Реальне керівництво проектом здійснює один з функціональних керівників. Координатор проекту. Він допомагає цьому керівнику збирати інформацію про статус виконуваних проектних робіт, враховує витрати, складає звіти.

10.6.2        Збалансована матриця

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

10.6.3        Сильна матриця

У сильної матриці визнається, що проектне управління є самостійною областю компетенції, в якій необхідно накопичувати експертизу і використовувати загальні ресурси. Тому в сильній матриці менеджери проектів об'єднуються в самостійне функціональне підрозділ - офіс управління проектами (Project Managment Office). PMO розробляє корпоративні політики та стандарти в області проектного управління, планує і здійснює професійний розвиток менеджерів.

10.7        Метод Extreme Programming

Extreme Programming (XP) - метод гнучкої розробки ПЗ, орієнтований на проекти із короткими циклами і частими випусками продукту, підвищення продуктивності команди, удосконалення якості ПЗ та забезпечення виконання вимог замовника.

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

Застосовується там, де:

• динамічно змінюються вимоги;

• ризики створюються фіксацією часу та використанням нової технології;

• є невелика об’єднана команда;

• використовується технологія, яка дозволяє проводити автоматичне тестування.

10.7.1        Цінності у Extreme Programming

Цінності:

• Комунікація

• Простота

• Зворотній зв'язок

• Сміливість

• Повага

10.7.2        Практики у Extreme Programming

Практики:

• Гра в планування (planning game).

• Невеликі версії (small releases).

• Визначення метафори (metaphor).

• Простий дизайн (simple design).

• Тестування (testing).

• Переробка (refactoring).

• Програмування парами (pair programming).

• Колективна власність (collective ownership).

• Безперервна інтеграція (continuous integration).

• 40-годинний тиждень (40-hour week).

• Замовник на місці розробки (on-site customer).

• Стандарти кодування (coding standards).

Ролі учасників проекту у Extreme Programming

• Клієнт (Customer) – особа, яка буде користуватись продуктом

• Розробник (Developer)

• Трекер (Tracker) - координатор проекту, збирає інформацію про статус виконуваних робіт, враховує витрати, складає звіти.

• Тренер (Coach) – забезпечення цлісного уявлення про проект, визначення методології проекту. Його часто вважають "головним архітектором" проекту.

10.8        Метод Scrum

Спринт – є ітерацією проекту, яка обов’язково має надати приріст продукту (інкремент).

Функціонал ПЗ, який буде реалізуватись в спринті (Sprint Backlog), визначається на його початку в ході планування і не можє змінюватися на всій його довжині

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

Спринт (Sprint) – основна одиниця виміру часу (від 1 до 4 тижнів). Результатом є працююча версія ПЗ.

10.8.1        Ролі учасників проекту

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

Основні обов'язки Скрам Майстра такі:

• Створює атмосферу довіри.

• Бере участь в мітингах в якості фасилітатора.

• Усуває перешкоди.

• Робить проблеми і відкриті питання видимими.

• Відповідає за дотримання практик і процесу в команді.

Скрам Майстер веде Daily Scrum Meeting і відстежує прогрес команди за допомогою Sprint Backlog, відзначаючи статус всіх завдань в спринті.

ScrumMaster може також допомагати Product Owner створювати Backlog для команди.

Product Owner

Product Owner - людина, яка відповідає за розробку продукту. Як правило, це product manager для продуктової розробки, менеджер проекту для внутрішньої розробки і представник замовника для розробки на замовлення.

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

Обов'язки Product Owner такі:

• Відповідає за формування product vision.

• Управляє ROI.

• Управляє очікуваннями замовників і всіх зацікавлених осіб.

• Координує і пріорітізірует Product backlog.

• Надає зрозумілі і тестовані вимоги команді.

• Взаємодіє з командою і замовником.

• Відповідає за приймання коду в кінці кожної ітерації.

Product Owner ставить завдання команді, але не має права ставити завдання конкретному члену проектної команди.

Команда (Team)

У Scrum команда самоорганізується та є самокерованою. Команда бере на себе зобов'язання щодо виконання обсягу робіт на спринт перед Product Owner. Робота команди оцінюється як робота єдиної одиниці.

Обов'язки команди такі:

• Відповідає за оцінку елементів баклога

• Приймає рішення по дизайну та імплементації

• Розробляє софт і надає його замовнику

• Відстежує власний прогрес (разом зі Скрам Майстром).

• Відповідає за результат перед Product Owner

Ідеальний розмір команди 7 ± 2 особи:

• крос-функціональна;

• складається із розробників, тестувальників, архітекторів, аналітиків і т. д.;

• знаходиться в одній кімнаті (colocated).

Ролі, які не приймають безпосередню участь у проекті

• • Замовники, продавці (Customers, Vendors) - ті, хто ініціює проект і з ким узгоджується виконання, підключаються для перегляду спринту;

  • Керівник (Manager) – людина, яка контролює інфраструктуру проекту.

10.8.2        Артефакти Scrum

Product backlog – документ із списком вимог до функціональності, впорядкований за ступенем важливості.

Елементи:

• • «історії» (user story)

  • елементи backlog'a (backlog items)

Product backlog відкритий для редагування для всіх учасників Scrum-процесу

Sprint Backlog - містить функціональність, обрану Product Owner з Product Backlog. Функції розбиті за завданнями, кожна з яких оцінюється командою.

Кожен день команда оцінює обсяг роботи, який потрібно виконати для завершення завдань

Timebox - встановлений період часу, в якому виконується найважливіша робота

• тривалість спринту фіксується

• робота, не виконана у таймбоксі, повертається до беклогу

Release та Roadmap (дорожня карта) - встановлює цілі для основних функцій, які будуть випускатися разом

• встановлюють об'єкти для кількох спринтів, які можуть бути виконані на різних рівнях якості

Burndown chart - показує, скільки вже виконано і скільки ще залишається зробити

10.8.3        Зустрічі Scrum

• • Планування спринту (Planning Meeting)

Відбувається на початку ітерації. 4-8 год.

• • Мітинг (Daily Scrum Meeting)

Відбувається кожен день протягом спринту. 15 хв

• • Демонстрація (Demo Meeting)

Відбувається в кінці спринту. 4 год.

• • Ретроспектива (Retro & Review Meeting)

Всі члени команди розповідають своє ставлення до ходу минулого спринту. Обмежено 1-3 год.

10.8.4        Від гнучкої розробки до DevOps

10.8.5        Безперервна доставка (Continuous delivery)

Continuous delivery (CD) – підхід розробки ПЗ, який забезпечує швидкий та надійний випуск версії у будь-який час.

Мета CD - створення, тестування та випуск ПЗ швидше та частіше..

CD фокусується на:

• Об'єднанні різних процесів;

• Виконанні їх швидше та частіше.

10.8.6        Основні процеси DevOps

DevOps (Development & Operations) – методологія розробки та супроводу ІС, спрямована на активну взаємодію та інтеграцію спеціалістів з розробки та ІТ-сервісів

10.8.7        Continuous delivery та DevOps

• Continuous delivery (CD) і DevOps схожі за своїм значенням, але являють собою дві різні концепції: DevOps застосовується в більш широких аспектах.

• DevOps і CD використовують гнучкі методи: невеликі і швидкі зміни з цілеспрямованим результатом для кінцевого клієнта.

• Т.ч. DevOps та CD мають загальні кінцеві цілі і часто використовуються разом для їх досягнення.

10.8.8        DevOps та MSF

Порівняння узагальнених фаз життєвого циклу DevOps та фаз MSF.

10.8.9        Azure DevOps. Керування проектом

1. Визначення типу проекту:

• • • Базовий (Basic)

    • Гнучкий (Agile)

    • Scrum

    • Зрілий (CMMI - Capability Maturity Model Integration)

2. Виділення типів робочих елементів (work item types, WIT), визначення історій користувачів (user stories) для планування проекту

3. Відстеження прогресу проекту на основі статусів цих історій