Все, що потрібно знати про методології розробки ПЗ: тренди, принципи та пастки для новачків

Розробка ПЗ – це складний бізнес-процес. Отже, ІТ потрібно розмовляти мовою оптимізації, планування та розрахунку. Розуміння концепцій управління дає велику перевагу і роботодавцям і розробникам і допомагає вивести співпрацю на новий рівень.

Початківцям на замітку: моделі, методології та загальна плутанина

Важливе уточнення для початку: є окремо моделі розробки програмного забезпечення та окремо – методології цієї самої розробки. Моделі пророкують майбутню поведінку системи. Методології потрібні щоб система працювала, причому так, як потрібно. Плутати моделі та методології розробки ПЗ – свята справа кожного ІТ-новачка, тому грубою помилкою це не вважається. І все ж моделі - це класична каскадна Waterfall , з її лінійністю, чіткою постановкою цілей для кожного етапу і строгим контролем за термінами. Моделі - це Spiral , з її фокусуванням на ранньому виявленні та зменшенні проектних ризиків. Розробка Spiral починається в невеликому масштабі, спочатку вирішуються локальні завдання, а потім - комплексніші. І нарешті, моделі – це IID, В якій життєвий цикл проекту розбивається на послідовність ітерацій, кожна з яких нагадує «міні-проект». Загалом, модель це те, що описує процес розробки ПЗ . А ось методології — це системи контролю, оцінки та моніторингу роботи над поставленими завданнями. Методології - це батіг і пряник сучасного розливу, які потрібні для контролю кожної ланки процесу розробки. Їх обирають, виходячи з напряму проекту, його бюджету та термінів реалізації кінцевого продукту. Більше того, методології можуть вибирати виходячи з темпераменту керівника проекту та його команди. Навіть виходячи з філософії компанії чи замовника. Давайте розглянемо найпопулярніші методології.

1. Методологія "Scrum"

Scrum - гнучкий метод управління проектами . У його основі лежать «спринти» — короткі ітерації, суворо обмежені в часі (зазвичай, 2-4 тижня). Тривалість нарад у своїй зводиться до мінімуму, але збільшується їх частота. Кожен спринт складається зі списку завдань до кінця ітерації, і кожна з них має свою “вагу”. Під час нарад команда обговорює, хто що зробив, що збирається зробити та які є проблеми. Для планування у Scrum використовують журнал спринтів. У такому підході у команді часто з'являється Scrum-майстер, який налагоджує безперервну роботу всієї команди, створюючи для неї комфортні умови. Також на проекті з'являється роль Product Owner – керівника розробки, людини, яка стежить за продуктом та виступає головною ланкою між запитом клієнта та результатом команди.

Плюси:

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

Мінуси:

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

Кому це підійде:

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

2. Методологія "Kanban"

Найважливіша особливість Kanban – візуалізація життєвого циклу проекту . Створюються стовпчики виконання завдань, які здаються індивідуально. Колонки позначені маркерами типу: To do, In progress, Code review, In testing, Done (назва колонок, звичайно, може змінюватися). Мета кожного учасника команди – зменшувати кількість завдань у першій колонці. Підхід Kanban наочний і допомагає зрозуміти де виникла проблема. Структуру Kanban не визначають остаточно і безповоротно: залежно від специфіки проекту можна додати імпровізовані колонки. Наприклад, деякі команди використовують систему, у якій потрібно визначити критерії готовності завдання перед виконанням. Тоді додають дві колонки – specify (уточнити параметри) та execute (взятися за роботу).

Плюси:

• гнучкість планування. Команда концентрується лише з поточної роботі, пріоритет завдання також визначено;
• наочність. Коли всі виконавці мають доступом до даних, глобальну проблематику легше помітити;
• висока залученість до процесу розробки. Візуалізація процесів підвищує самоорганізацію та самоконтроль.

Мінуси:

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

Кому це підійде:

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

3. Методологія "RUP"

Методологія RUP використовує ітеративну модель розробки. Наприкінці кожної ітерації (яка займає від 2 до 6 тижнів) команда повинна досягти запланованих цілей та отримати тимчасову, але працюючу версію проекту. RUP передбачає поділ проекту на чотири фази , у кожній з яких ведеться робота над новим поколінням продукту: фазу початку проекту, уточнення, побудова та впровадження. Після закінчення фази вводиться маркер завершення етапу (Project Milestone). Project Milestone можна вважати моментом, коли команда дає оцінку досягнутим результатам. У результаті методологія передбачає, що у першому етапі випускаються основні функції, але в наступних фазах додаються доповнення.

Плюси:

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

Мінуси:

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

Кому це підійде:

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

Методологій багато, тренд один

Окрім безперечно популярних Scrum та Kanban, які ґрунтуються на принципах гнучкості під загальною назвою «Agile» , як і окрім живучої ітераційної RUP, компанії працюють з безліччю варіаціями методологій. Комусь ближче екстремальне програмування та прийняття найшвидших і найпростіших рішень, комусь — розробка через тестування, а хтось віддає перевагу швидкій розробці додатків (RAD). При цьому головний та безумовний тренд — використання кількох методологій одночасно . Або навіть об'єднання моделей та методологій в унікальну систему контролю. Сучасні компанії прагнуть усунути бюрократичні перепони, створити атмосферу спільної командної роботи всередині організації, не перекладаючи відповідальність між підрозділами та блоками. За данимизвіту Scrumalliance , від 70% ІТ-компаній використовують Scrum. Серед них такі гіганти, як Google, Amazon, Salesforce, Microsoft, Adobe. Стартапи та молоді проекти більш схильні до Kanban, але її також використовує Toyota та, наприклад, ігровики з Wargaming. Більш скромні СНД-ні Prom.ua, Bigl.ua, Kabanchik.ua використовують методології Scrum і Kanban одночасно, але для різних завдань. Scrum – як інструмент планування, Kanban – для моніторингу ходу робіт. Що стосується RUP, її найчастіше практикують західні компанії з 50-200 співробітниками та доходом 1-10 мільйонів доларів. Але при цьому IBM змінила RUP, щоб наблизитися до принципів гнучкості Agile, випустивши методологію OpenUP - "RUP, тільки гнучкий". Та сама хвалена гнучкість Agile зараз управляє ІТ-сферою. Це не просто мода наших днів — це інноваційно, і це реально працює в багатьох великих компаніях. За Agile працюють у Кремнієвій долині, її використовує Facebook та Uber.

У сухому залишку

Кожному проекту – своя методологія розробки програмного забезпечення, залежно від команди, фінансування, термінів та вимог замовника. Універсальної управлінської технології немає: навіть шалено популярний Agile не може забезпечити найкращий підхід до процесу розробки. Тому методологію обирають ретельно, інколи ж навіть принципово. Настільки, що по ній можна робити висновки про саму компанію чи замовників. Методології міксують, доповнюють моделями та адаптують під себе. Настільки, що породжують нові підходи. Хоча в результаті управлінське царство залишається в руках Scrum та Kanban, з несподіваними вкрапленнями моделі Waterfall чи ітераційною RUP.