Методології розробки ПЗ

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

Waterfal

Waterfall (каскадна, водоспадна) – одна з найстаріших методологій і має на увазі суворе послідовне виконання всіх етапів, кожен із яких має завершитися перед початком наступного. Тобто, перехід на наступний етап означає повне завершення робіт на попередньому. На зображенні показано, що спочатку ми аналізуємо завдання (документуємо завдання, обговорюємо складності), потім відбувається дизайн (на цьому етапі формується структура проекту), далі кодинг та тестування. Повернення на наступні етапи не передбачено. Використовувати таку систему рекомендується в невеликих проектах, де заздалегідь відомі вимоги і мала ймовірність, що вони змінюватимуться. Переваги:

• Повна та узгоджена документація на кожному етапі;
• Простота використання;
• Стабільні вимоги.
• Бюджет та дедлайни заздалегідь визначені

Недоліки:

• Велика кількість документації;
• Не дуже гнучка система;
• Немає можливості повернутися на крок назад.

Scrum

Scrum – система розробки ПЗ, заснована на розподілі всього процесу на ітерації, де наприкінці кожної їх команда готова надати демо-версію продукту. На картинці видно, що команда проходить усі етапи розробки паралельно, що дозволяє наприкінці кожної ітерації мати готову частину проекту. Постараюся коротко пояснити простими словами суть методології, але дуже багато термінів. Думаю, найважливіше зрозуміти суть, а терміни вже запам'ятаються з досвідом. Вся технологія ділиться на спринти (часто 2-3 тижні). Є backlog (список завдань) для всього періоду розробки та кожного спринту окремо. Кожне завдання має власний story point (оцінку складності). Кожен учасник процесу має свою роль:

• Scrum-команда – це команда, що працює над проектом (розробники, тестери, дизайнери).
• Scrum-майстер – людина, яка стежить, щоб дотримувалися принципів скраму.
• Product owner – замовник.

Оскільки в цій системі ставку зроблено на спілкування, то присутня велика кількість мітингів:

• Stand-up – короткий мітинг, проводиться щодня, беруть участь усі члени команди та кожен учасник відповідає на 3 запитання: що робив? Що робитиме? І які блокери?
• Пленінг – проводиться на початку спринту і на цих зборах визначають які завдання мають бути виконані за наступний спринт.
• Ретроспектива – проводиться наприкінці спринту та її суть – з'ясувати, що було зроблено добре та що можна було покращити.

Переваги:

• Замовник може спостерігати результат у процесі розробки.
• Щоденний контроль за процесом розробки.
• Можливість вносити корективи під час опрацювання.
• Налагоджені комунікації з усіма членами команди.
• Невелика кількість документації.

Недоліки:

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

Kanban

Канбан – система, побудована візуалізації процесу виконання завдань команди. Основна ідея в цій системі зменшувати кількість завдань, що виконуються в даний момент (у колонці «in progress»). У скрамі орієнтація команди на успішне виконання спринтів, у Канбані на першому місці завдання. Хороший для проектів які на стадії підтримки де основний функціонал вже розроблений і залишабося мінімальні доробки та багофіксінг. У канбані завдання здаються індивідуально. Завдання незалежно від інших завдань проходить по всіх етапах на дошці і як тільки вона виконана, її можна показати замовнику. Канбан дошка складається з стовпчиків, кожна з яких це окремий процес розробки. На деякі стовпці (наприклад, in progress) вводять обмеження кількості тасок, які там можуть знаходитися. Це допомагає легко та швидко знаходити проблемні місця у розподілі завдань. На картинці приклад просто такої дошки. Кількість колонок та назви можуть змінюватися, назву найпоширеніші:

• To do – список завдань, які треба зробити
• In progress – завдання над якими ведеться робота на даний момент
• Code review – завдання, зроблені та відправлені на рев'ю
• In testing – завдання, які готові до тестування
• Done – зроблені завдання.

Переваги:

• Простота використання.
• Наочність. (допомагає у знаходженні вузьких місць, спрощує розуміння)
• Висока залученість команди до самого процесу.
• Висока гнучкість у розробці.

Недоліки:

• Нестабільний перелік завдань.
• Важко застосовувати на довгострокових проектах.
• Відсутність твердих дедлайнів.

На закінчення методології розробки ПЗ

На мою думку, ґрунтовно розумітися на методологіях розробки ПЗ потрібно людям, які займають управлінські посади або прагнуть до них, але розуміти хоча б основи бажано всім. Це невід'ємна частина процесу розробки та використовується не лише у IT-сфері. Дякую, що приділабо час читання моєї статті, сподіваюся, вона була вам корисною. Я намагався описати тільки ключові моменти максимально доступно і коротко, тому стаття не є вичерпною. Радий почути вашу думку про неї і відповісти на ваші запитання. Всім добра!