Олександр Струков: LinkedIn

Email: al.struki@gmail.com

Зміст

• Анотація
• Вступ
• Огляд літератури
• Методологія/Матеріали та методи
• Результати
• Обговорення
• Висновки
• Джерела

Анотація

Існує багато моделей розробки програмного забезпечення, таких як waterfall модель, ітеративна, Scrum, швидка розробка додатків (RAD), спіральна, Agile, Z і AZ моделі. Кожна модель розробки слідує ряду кроків для створення продукту.

У цьому дослідженні ми намагаємось відповісти на питання: “Чи забезпечує дотримання методологій точного успіху у проекті”. Для цього нам потрібно пояснити важливість ролі методологій управління проектами та як реальність часто не відповідає очікуванням. У дослідженні я детально аналізую статистичні дані, зібрані від різних QA-груп, та список літератури, зазначений нижче.

Вступ

Тема дослідження полягає в тому, що суворе дотримання методологій управління проектами відповідно до опису в ISTQB або інших джерелах не є поширеною практикою. З мого досвіду, я бачив лише невеликий відсоток проектів, які сувороо дотримувалися методології. На основі зібраної статистики я обговорюватиму теорію про те, як часто ми бачимо хороші процеси та чи є це «північною зіркою», яку слід наслідувати.

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

Ця стаття не буде глибоко розглядати кожну окрему методологію та чи був це добрий вибір для проекту та команди. Навпаки, стаття розглядатиме загальну тезу:

«Мій проект суворо дотримується методології, чи має це значний вплив?» У забезпеченні якості, як і в розробці програмного забезпечення, основна мета — забезпечити найкращу якість у межах наявних ресурсів та часу.

Огляд літератури

Для розробки програмного забезпечення розробнику потрібна певна модель, яка називається моделлю розробки програмного забезпечення. Ці моделі застосовуються відповідно до міжнародних стандартів ISO/IEC 12270 [1]. Перша модель SDLC була основною частиною інженерії програмного забезпечення, оскільки вона забезпечувала структуру для різних етапів розробки програмного забезпечення.

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

1	Al-Qutaish R. E., [1]	2008	Software Process and Product ISO Standards:	Розгорнуте дослідження процесів розробки програмного забезпечення та ISO
2	R. Kneuper [2]	2017	Sixty years of history of software development life cycles and evaluation of new software development models.	Шістдесят років досліджень моделей розробки програмного забезпечення, але не використовуючи конкретні фактори, такі як (обсяг, бюджет, ризик, ресурси, якість).
3	R. Arora et al. [3]	2016	Choose the right software development model according to user needs.	Обмеженням цього дослідження є те, що не всі моделі обговорюються, оскільки деякі моделі можуть бути змодельовані за допомогою певних інструментів.
4	M. A. Rather et al. [4]	2016	Different software process model discuss and explain that when the new model came into existence.	Обмеженням цього дослідження є те, що різні моделі вивчаються без конкретної перспективи (якості, вартості) тощо.
5	I. H. Sarker et al. [5]	2015	Survey of different development process models to choose the desired model according to requirement.	Не обговорюється гібридна техніка розробки програмного забезпечення.
6	Alshamrani et al. [20]	2015	Comparative analysis of three software development models and discuss their pros and cons.	Є велике обмеження, що лише три моделі порівнюються та аналізуються щодо їх сильних і слабких сторін.

• Найбільш широко використовувані моделі:
• Модель водоспаду 
• Ітеративна модель 
• Модель Agile
  • Модель Scrum 
  • Модель Kanban 
  • Модель Scrumban 
  • V-модель

Методологія/Матеріали та методи

Отже, для підтвердження тези та важливості методологій нам потрібно спочатку визначити, які основні загальні методології використовуються по всьому світу. Я використовуватиму статистичні матеріали зі статті Scrum statistics[7] та дані зі статті “20+ найважливіших статистик про Scrum на 2023 рік”[8]. На основі цих даних та в поєднанні зі статистикою, яку я зібрав через анкету, у якій я опитав аудиторію кількох QA-груп про їхній досвід роботи з різними методологіями.

Завдяки статистиці та даним ми дійдемо до результатів дослідження.

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

Результати

На основі дослідниз данних від “Statista”: 

Сторінка  Statista. 

Найчастіше використовується DevOps / DevSecOps. Деякі дані про цю методологію:

У 2022 році майже 47 відсотків респондентів заявили, що використовують метод DevOps або DevSecOps для розробки програмного забезпечення. DevOps — це практика, яка поєднує IT-операції з розробкою програмного забезпечення. Її мета — забезпечити безперервну доставку, скорочуючи цикл розробки систем, при цьому забезпечуючи високу якість програмного забезпечення. Причинами вибору цього методу є швидший вихід на ринок, безпека, якість коду, а також покращена комунікація та співпраця між розробниками.

“Сторінка Statista: Розподіл методологій розробки програмного забезпечення…“

За даними статті з Echometer, близько 66% респондентів використовують Scrum з agile-методологій.

Графік від статті Echometer. 

На основі дослідження “State of Scrum 2017-2018”:

“Коли справа доходить до вибору Scrum для проекту, 71 відсоток керівників погоджуються, що надання цінності клієнту є їх найвищим пріоритетом. Гнучкість і швидка реакція є значним другим пріоритетом. У той час як покращення організаційного дизайну та культури посідає останнє місце з 25 відсотками, гарне впровадження Scrum також може досягти цієї мети. За даними Scrum Alliance, середня тривалість проекту зменшилася до 11,6 тижнів. Для Agile-організацій це означає, що проекти – від запуску нового продукту до діагностики та лікування пацієнта з психічним захворюванням – встановлюються з урахуванням стандартного терміну завершення менше трьох місяців, від початку до кінця. Середній показник знижується і очікується, що ця тенденція продовжиться у 2018 році. Організації вибирають Scrum в першу чергу для надання більшої цінності клієнту. У цьогорічному опитуванні 85 відсотків респондентів заявили, що Scrum продовжує покращувати якість робочого життя.”

Нижче графік чітко окреслює відповіді респондентів щодо цінності, яку їм приносить методологія SCRUM:

Графік з статті: State of Scrum 2017-2018

Крім того, дослідження охоплює відсоток використання Scrum у чистому впровадженні та в поєднанні з іншими методологіями. . 

Графік з статті : State of Scrum 2017-2018

Отже, на основі статистичних даних, зібраних сторонніми постачальниками, можна зробити висновок, що Scrum у поєднанні з іншими методологіями використовувався в 2015 році приблизно на 56%, а тільки Scrum використовувався в тому ж році приблизно на 43%.

У наступні 3 роки популярність Scrum у поєднанні з іншими методологіями тільки зросла і досягла 78% у 2017 році, тоді як показник «тільки Scrum» зменшився до 16%. Водночас «жодного Scrum» не використовували лише 6% респондентів.

Отже, можна зробити висновок, що за статистикою Scrum як найпопулярніша методологія SDLC використовується в більшості випадків у поєднанні з іншими методологіями. Протягом років кількість команд, які використовують Scrum за книжкою, лише зменшувалася.

На основі опитування було розпочато надання іншого погляду на питання:

Більшість респондентів працювали над 3-5 проектами протягом своєї кар’єри.

Є респонденти, які працюють у цій галузі понад 10 років.

На друге питання про проекти, над якими респонденти працювали від початку до кінця, щоб ми могли визначити, скільки проектів було налагоджено належним чином, коли час, витрачений на впровадження, був би мінімальним:

Ми бачимо, що більшість респондентів працювали більш ніж на одному проєкті від початку.

Це надає чудову статистику для наступного питання: “Який відсоток цих проєктів було налаштовано відповідно до командних рамок співпраці (Agile, Waterfall…), слідуючи описаним в ISTQB рамкам, включаючи принаймні 70% необхідних артефактів та правил?”

На основі результатів відповідей можна зробити висновок, що більшість респондентів вважають проєкти, над якими вони працювали від початку, як такі, що належним чином дотримуються методології. 51% респондентів вважають, що проєкти, над якими вони працювали, суворо дотримуються рекомендацій ISTQB.

Лише 40% респондентів заявили, що проєкти, в яких вони працювали, не дотримувалися рекомендацій ISTQB або включали менше 60% необхідних артефактів, які повинні бути частиною методології.

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

Респонденти вказали, що лише 46% проєктів, в яких вони брали участь після 2 місяців від початку, мали добре налаштовану методологію відповідно до рекомендацій ISTQB і містили більше 70% необхідних артефактів.

Як підсумок статистики, зібраної з опитування, можна стверджувати наступне:

• Якщо QA був залучений з початку проєкту, 51% проєкту дотримувався більшості артефактів, визначених в ISTQB.
• Якщо QA був залучений після старту проєкту, відсоток зменшився до 46%.

Згідно з наведеними статистичними даними, Scrum як методологія приносить більше доходу і використовувався частіше протягом останніх 3 років. Тому додавання QA на початку проєкту допоможе покращити методологію та підвищити цінність для кінцевого клієнта.

Додаючи до вищезгаданих статистичних даних і статей, я хотів би взяти деякі думки з книги “Agile Testing Condensed: A Brief Introduction” авторів Джанет Грегорі та Лізи Кріспін [11]. Автори роблять висновок, що “команди не обов’язково дотримуються суворих правил agile, а радше адаптують agile-практики відповідно до своїх потреб. Важливим є дотримання цінностей agile, безперервне вдосконалення та надання цінності, а не жорстке дотримання конкретного процесу.”

У статті “Чи справді потрібно використовувати Scrum за книгою? Про ScrumBut, ScrumAnd і зрілість” [12], Крістіан Вервайс, редактор The Liberators (спільноти однодумців, які допомагають покращувати методології для команд по всьому світу), зазначає, що більшість команд використовують не лише Scrum, а й ScrumAnd і ScrumBut. Це додатково демонструє, що повна версія Scrum за книгою використовується рідко.

Ще одна стаття: “Почніть з Scrum за книгою: не зупиняйтеся на цьому” [13], написана Майком Коном, засновником Agile Alliance і Scrum Alliance, стверджує, що кожна команда повинна починати, дотримуючись Scrum за книгою, але це лише перший крок на шляху до успіху проєкту, оскільки фреймворки мають бути адаптовані до вимог проєкту та команди.

У книзі “Ідеальне програмне забезпечення: та інші ілюзії про тестування” Джеральда М. Вайнберга [14] автор зазначає:

“Жодна методологія не може бути ідеальною, оскільки ніхто не може передбачити всі можливі змінні у проєкті.”

“Тестування, як і будь-яка інша дисципліна, має адаптуватися до конкретних обставин, з якими стикається.”

“Багато команд змушені пропускати певні процеси або модифікувати інші, щоб продовжувати рухатися вперед, і це не є провалом — це адаптація.”

Це додатково підкреслює думку про те, що будь-які процеси, описані в книгах, є лише ідеалізованим уявленням про ідеальний процес, якого насправді не існує. “Ідеальне програмне забезпечення” припускає, що команди часто не дотримуються суворих agile-правил. Натомість вони адаптують і розвивають свої процеси, іноді відхиляючись від методології, щоб відповідати реальним вимогам.

Обговорення

На основі результатів наведеного дослідження можна підтвердити твердження, що в більшості випадків методології SDLC, які використовуються, базуються на Scrum. У свою чергу методології, що ґрунтуються на Scrum, довели свою ефективність у забезпеченні своєчасної доставки проєктів та наданні максимальної цінності для клієнта.

У період між 2017 і 2018 роками популярність методології Scrum зменшилася у чистому впровадженні згідно з “Agile Approaches Image from the study: State of Scrum 2017-2018”. Але водночас Scrum у поєднанні з іншими методологіями не можна вважати методологією за книжкою, оскільки вона не має чітких рекомендацій, а скоріше є ідеєю, де кожен менеджер проєкту обирає необхідні артефакти на свій розсуд.

Опитування, що зібрало відповіді від 28 респондентів, надає дані про те, що 40%-50% часу проєкти управляються за суворими рекомендаціями. Хоча 28 відповідей не можна вважати великою вибіркою для оцінки, це не спростовує результати попереднього дослідження.

Висновки 

Отже, підсумовуючи всі дослідження та висновки, можна стверджувати, що більшість методологій, описаних в рекомендаціях ISTQB або онлайн, зазвичай не дотримуються точно. Причина, чому їх не дотримуються, не лежить у часі початку проєкту (дані з опитування) чи у характеристиках клієнта, а у справжньому значенні слова Agile та меті будь-якої рамки: визначити артефакти та методологію з обґрунтуванням для кожного елемента.

Щоб відповісти на питання: “Чи забезпечує дотримання методологій за книжкою успіх у проєкті?”, нам потрібно визначити KPI успіху. Це будуть:

• Завершення проєкту у відповідності з термінами
• Показник задоволеності клієнта
• Візія продукту, яка відповідає доставленому продукту

За даними дослідження “State of Scrum 2017-2018”, чітке дотримання методології зменшується з року в рік, але гібридна методологія (використання кількох артефактів з різних методологій) тільки зростає, хоча основні напрямки, що працюють, все ще грунтуються на основі методології Scrum. Тож відповідь на питання буде “ні”.

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

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

Джерела 

Джерела літератури, що використовувалися:

[1] Al-Qutaish R. E., Al-Sarayreh K. T., and Al-Sarayreh K., “Стандарти ISO для процесів і продуктів програмного забезпечення: Всеосяжне дослідження інструментів для нефункціональних вимог з використанням міжнародних стандартів, Погляд на проект програмної інженерії: Основи,” European Journal of Scientific Research, vol. 19, no. 2, pp. 289–303, 2008. [Google Scholar]

[2] Kneuper R., “Шістдесят років моделей життєвого циклу розробки програмного забезпечення,” IEEE Ann. Hist. Comput., vol. 39, no. 3, pp. 41–54, 2017, doi: 10.1109/MAHC.2017.3481346  [CrossRef] [Google Scholar]

[3] Arora R. and Arora N., “Аналіз моделей життєвого циклу розробки програмного забезпечення (SDLC),” Int. J. Curr. Eng. Technol., vol. 6, no. 1, pp. 2277–4106, 2016, [Online]. Доступно: http://inpressco.com/category/ijcet. [Google Scholar]

[4] Rather M. A. and Bhatnagar V., “Порівняльне дослідження моделей SDLC,” no. August, 2016.[Google Scholar]

[5] Sarker I. H., Faruque F., Hossen U., and Rahman A., “Огляд моделей процесу розробки програмного забезпечення в інженерії програмного забезпечення,” Int. J. Softw. Eng. its Appl., vol. 9, no. 11, pp. 55–70, 2015, doi: 10.14257/ijseia.2015.9.11.05  [CrossRef] [Google Scholar]

[6] Alshamrani A. and Bahattab A., “Порівняння між трьома моделями SDLC: каскадною моделлю, спіральною моделлю та інкрементально/ітераційною моделлю,” IJCSI Int. J. Comput. Sci. Issues, vol. 12, no. 1, pp. 106–111, 2015. Доступно: https://www.academia.edu/10793943/A_Comparison_Between_Three_SDLC_Models_Waterfall_Model_Spiral_Model_and_Incremental_Iterative_Model. [Google Scholar]

[7] https://www.statista.com/statistics/1233917/software-development-methodologies-practiced/ – Розподіл методологій розробки програмного забезпечення у світі у 2022 році

[8] Найважливіші статистичні дані про Scrum на 2023 рік. Статистичні дані про використання Scrum, автор Ян Шафер 

[9] State of Scrum 2017-2018 – Дослідження, засноване на опитуванні, проведеному восени 2017 року в 91 країні. Проведене Scrum Alliance, висвітлює загальну статистику використання Scrum та його переваги. PDF

[10] “Як великі технологічні компанії керують технічними проектами та дивовижна відсутність Scrum” Огляд процесів великих технологічних компаній. Автор – Гергель Орос, автор чотирьох визнаних книг про керівництво розробкою програмного забезпечення, масштабування та розвиток.

[11] Agile Testing Condensed: Джанет Грегорі та Ліза Кріспін. Книга про тестування за Agile, популярна серед фахівців із забезпечення якості.

[12] “Чи потрібно використовувати Scrum за книгою” – Стаття Крістіана Вервайса, редактора “The Liberators”, організації, створеної для покращення процесів та співпраці в командах.

[13] “Почніть із Scrum за книгою: не зупиняйтеся на цьому” – Стаття автора Майка Кона, засновника Agile Alliance і Scrum Alliance

[14] “Ідеальне програмне забезпечення та інші ілюзії про тестування”: Джеральд Вайнберг. Книга про ілюзії тестування, популярна серед фахівців із забезпечення якості.