You have to know this: моделі життєвого циклу проєкту!

06.10.20.⏰Час прочитання - 16 хв

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

Історія розвитку проєктного менеджменту

До появи офіційно прийнятого визначення «управління проєктами», люди примудрялися керувати компаніями, будувати заводи, будинки, пароплави і в цілому цивілізація успішно та стрімко розвивалася. Результати одних проєктів ми з Вами бачимо досі (єгипетські піраміди, іригаційні канали, Велика китайська стіна та ін.).

Іригаційні канали

У це важко повірити, але історія методик управління проєктами вже має п'ять тисяч років, хоча офіційно це поняття з'явилося на світ на початку 20 століття.

«Батьками» проєктного менеджмену можна назвати трьох вчених:

Генрі Гант (Henry Gantt, 1861–1919) — американський інженер, який запропонував в 1910 році нову техніку календарного планування з використанням горизонтальних діаграм.
Анрі Файоль (Henri Fayol, 1841–1925) — французький гірський інженер, творець класичної теорії управління. Відомий тим, що визначив п'ять основних функцій менеджменту, які стали основою управління проєктами.
Фредерік Уінслоу Тейлор (Frederick Winslow Taylor, 1856–1915) — американський інженер, роботи якого стали прототипами багатьох сучасних інструментів, включаючи ієрархічну структуру робіт.

Вже в 70-х роках сформувався своєрідний "світ управління проєктами", який об'єднав фахівців різних континентів і країн, напрямків і сфер діяльності, національностей, культур. А все тому що були створені професійні організації управління проєктами: в Австралії — Австралійський інститут управління проєктами (AIPM); в Азії — Японська асоціація розвитку інжинірингу (ENAA).

Водоспадна (Каскадна) модель (Waterfall Model)

Основна суть моделі Waterfall у тому, що етапи залежать один від одного і наступний починається, коли попередній завершений. Таким чином утворюється постовий (каскадний) рух уперед.

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

Команди різних етапів між собою не комунікують, кожна команда відповідає чітко за свою роботу.

Недоліками цієї моделі є отримання результату по проходженню всіх етапів і складність виявлення помилок. Повертатися назад важко. Незрозуміло що повертати: якщо стався збій на якомусь етапі — його наслідки видно тільки в кінці.

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

Колись такою моделлю керувалась на початку автомобільна компанія Toyota. Вони виготовляли величезну кількість деталей для автомобілів на різних цехах, які не були між собою зв’язані. Відповідно між виготовленням партії та моментом збору автомобілів була велика часова яма, яка могла тривати тижнями. І якщо якийсь з відділів допускав помилку, то і дізнавалися про неї аж під час збору. Можете собі уявити, якими жахливими були збитки: оплата роботи, зіпсовані матеріали, транспорт, час!

Згодом, щоб уникнути таких збитків, проєктні менеджери заводів вигадали Канбан (про нього поговоримо згодом).

Ітераційна, спіральна й інкрементна моделі

Ітераційна модель

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

Пояснимо розбиття на етапи на побутовому прикладі. Припустимо, нам потрібен стіл у вітальню.

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

На кожній ітерації ми працювали з одним і тим же продуктом, тож в кінці кожної ітерації отримували результат, яким можна користуватися (звісно з певними обмеженнями).

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

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

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

Спіральна й інкрементна моделі є видами ітераційної моделі життєвого циклу.

Спіральна модель

Усі етапи життєвого циклу проєкту в спіральній моделі йдуть витками, на кожному з яких відбуваються проєктування, розробка, дизайн, тестування і т.д. Такий процес відображає суть назви: піднімаючись, проходиться один виток (цикл) спіралі для досягнення кінцевого результату. Причому не обов'язково один і той же набір процесів має повторюватись від витка до витка. Але результати кожного з витків ведуть до головної мети.

Інкрементна модель

Принцип, що лежить в основі інкрементної моделі, полягає у розширенні можливостей, добудовуванні модулів і функцій програми. Буквальний переклад слова інкремент — «збільшення на один». Саме це «збільшення на один» застосовується для позначення версій продукту.

Якщо в каскадній моделі по суті є лише два стани продукту: «нічого» і «готовий продукт», то з появою ітераційних моделей появилось таке поняття як версіонування продукту. Кожна ітерація позначається цифрою: 1,2,3 і відповідно продукт після кожної ітерації має версію з відповідним номером: v.1, v.2, v.3. Числами після слова версія позначають масштабні зміни в ядро продукту.

У випадку, коли одна з версій в експлуатації, а наступна, з огляду на недоліки попередньої, тільки планується або знаходиться в розробці, а покращення хочеться втілити прямо зараз, тоді з'являються мінорні версії. Туди потрапляють зміни, що не впливають на ядро розробки і представлені як під-версії 1.1, 1.2, 1.3 або релізи 1.1.1, 1.1.2 і т.д.

У сукупності такі поетапні релізи призводять до повноцінної версії 2.0.

Agile і Lean

Agile

Це набір принципів та ідей гнучкої розробки.

Основні ідеї Agile:

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

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

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

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

Agile чудово справляється з невизначеністю. Правило таке: чим вища невизначеність — тим коротша ітерація, причому її тривалість може бути навіть у рамках 24 годин, як і відбувається на хакатоні. На початку кожної ітерації неминуче виконується контроль, ретроспектива, оцінка та аналіз результатів, планування наступної ітерації.

У внутрішньому плануванні та у продуктовій розробці без цього принципу й елементів Agile не обійтися.

Lean

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

Коли доходить до розробки продукту або робиться якесь покращення — виробниче або інженерне, ми спочатку створюємо його MVP (minimum viable product).

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

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

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

Гнучкі методології

Scrum методологія ґрунтується на спринтах (sprint), протягом яких виконується робота над продуктом. Перед початком кожного спринту проводиться планування (Sprint Planning), на якому відбувається оцінка вмісту завдань (Product Backlog) і формування беклога на спринт (Sprint Backlog), у рамках якого і працює команда. Для спринту завжди існують обмеження в часі, зазвичай від тижня до місяця. Життя продукту таким чином розбите на рівні відносно тривалості спринтів.

За Kanban методологією проєкт ділиться на етапи, що візуалізуються у вигляді канбан-дошки. Етапи — це, наприклад: планування, розробка, тестування, реліз і т.д. Завдання у вигляді "карток" переміщуються з етапу на етап. Нові завдання можна додавати у будь-який час. Завдання закривається не по закінченню конкретного часу, а по зміні статусу на "завершено".

Детальніше про Kanban, який ми також застосовуємо у навчальних процесах, можна почитати тут.

Ролі в ІТ командах

Ролі в процесі розробки ПЗ:

Замовник (Customer) — особа (фізична або юридична), яка зацікавлена у виконанні робіт, наданні йому послуг або купівлі будь-якого продукту (в широкому сенсі).
Менеджер Проєкту (Project Manager) — фахівець, чиїм головним завданням є управління проєктом в цілому: розстановка пріоритетів, планування виконання завдань, контроль, комунікація, а також оперативне вирішення проблем.
Керівник команди (Team Lead) — це IT-фахівець, який керує своєю командою розробників, володіє технічною стороною, бере участь у роботі над архітектурою проєкту, займається рев'ю коду, перевіркою або складанням планів тестування, а також розробкою деяких особливо складних завдань на проєкті.

Розробники

Архітектор (Architect) — IT-фахівець, який приймає рішення щодо внутрішнього устрою і зовнішніх інтерфейсів програмного комплексу з урахуванням проєктних вимог та наявних ресурсів.
Розробник (Developer) — фахівець, який займається написанням і коригуванням програм.
Технічний керівник (Technical Leader) — це фахівець, чиї обов'язки схожі на обов'язки менеджера проєкту або архітектора. Обидва виконують і менеджерську, і технічну ролі, однак техлід більш поглиблено займається технічною частиною проєкту.

Фахівці з тестування

Керівник команди тестування (QA Lead) — керує групою QA-інженерів і відповідає безпосередньо за тестування і забезпечення якості.
QA Автоматор (QA Automation engineer) — це фахівець із забезпечення якості продукту, який використовує програмні засоби для створення тестів і перевірки результатів виконання.
QA інженер (QA Engineer) — це фахівець із забезпечення якості, діяльність якого спрямована на поліпшення процесу розробки ПО, запобігання дефектів і виявлення помилок в роботі продукту.

Аналітики та інші

Бізнес-аналітик (Business Analyst) — це фахівець, який досліджує проблему замовника, шукає рішення і оформлює його концепцію в формі вимог, на які в подальшому будуть орієнтуватися розробники при створенні продукту.
QA аналітик (QA Analyst) — це фахівець, який відповідає за створення і виконання плану тестування від початку і до кінця; відповідає за управління всією діяльністю в плані забезпечення того, щоб всі цілі були виконані.
Технічний письменник (Technical Writer) — спеціаліст, який займається написанням різної документації як внутрішнього призначення, так і призначеної для кінцевих користувачів ПЗ (керівництва користувача, довідкові системи і т.д.).

Основні ролі в методології Scrum

Беклог продукту (Резерв продукту, Product backlog) — розподілений по пріоритетах список запланованих завдань проєкту. Резерв може містити призначені для користувача історії, бізнес-процеси, запити на зміну і розробку інфраструктури. Робочі елементи з резерву призначаються на майбутні ітерації на основі їх пріоритетів.
Власник продукту (Product Owner) — представляє інтереси кінцевих користувачів та інших зацікавлених в продукті сторін.
Покер планування (Planning Poker, Scrum poker) — інструмент планування в гнучкій розробці. Техніка оцінки, яка використовується для оцінки складності майбутньої роботи або відносного обсягу вирішуваних завдань при розробці програмного забезпечення.
Скрам-команда (Scrum Team) — крос-функціональна команда розробників проєкту, що складається з фахівців різних профілів: тестувальників, архітекторів, аналітиків, програмістів і т. Д. Розмір команди в ідеалі становить 7 ± 2 людини.
Скрам-майстер (Scrum Master) — проводить наради (Scrum meetings), стежить за дотриманням всіх принципів скрам, дозволяє суперечності і захищає команду від відволікаючих чинників.