У цьому документі описані вимоги, поставлені зацікавленою особою, до розроблюваної в рамках лабораторних робіт системи управління проєктами, а також висвітлено певні моменти з предметної області проєкту.
- СУП - Система Управління проєктами, програмне забезпечення, до базових функцій якого входить:планування завдань, складання розкладу, забезпечення спільної роботи та спілкування, а також можливості управління та адміністрування системи.[1]
- Проєкт(В управлінні проєктами) - обмежена в часі, ресурсах та вимогах якості унікальна сукупність процесів, направлена на досягнення унікальних цілей та завдань для створення нової цінності (продукту або послуги).[2]
- Життєвий цикл проєкту - проміжок часу та етапи між початком і завершенням проєкту.
- Управління проєктами - складні процеси планування, організації та управління ресурсами з метою успішного досягнення цілей та завершення завдань проєкту.[3]
- Результат проєкту - деяка продукція чи ефект, створювані під час реалізації проєкту.
- Трикутник управління проєктами - це типові обмеження згідно з якими виконується та завершується проєкт. Традиційними "сторонами" трикутника є такі обмеження: "час", "вартість" та "зміст та межі". Одна сторона трикутника не може бути змінена, щоб не вплинути на інші сторони.
Agile підхід визначають як гнучкий ітеративно-інкрементальний підхід до управління проєктами і продуктами, орієнтований на динамічне формування вимог і забезпечення їх реалізації в результаті постійної взаємодії команд, які самоорганізовуються і складаються з фахівців різного профілю.
Більшість гнучких методологій націлені на мінімізацію ризиків, шляхом зведення розробки до серії коротких циклів, що мають назву ітерацій, які зазвичай тривають один-два тижні. Кожна ітерація сама по собі виглядає як програмний проєкт в мініатюрі, і включає всі завдання, необхідні для видачі мінімального приросту за функціональністю: планування, аналіз вимог, проєктування, кодування, тестування і документування. Хоча окрема ітерація, як правило, недостатня для випуску нової версії продукту, мається на увазі те, що гнучкий програмний проєкт готовий до випуску наприкінці кожної ітерації. Після закінчення кожної ітерації, команда виконує переоцінку пріоритетів розробки.Основною метрикою agile методів є робочий продукт.
Віддаючи перевагу безпосередньому спілкуванню, Аgile-методи зменшують обсяг письмової документації в порівнянні з іншими методами. Це привело до критики цих методів як недисциплінованих. Тобто для ефективної розробки за цим підходом потрібно, щоб кожен учасник проєкту був дисциплінованим та здатним до самоорганізації.
Існує декілька методів, що базуються на ідеях Agile, найпопулярнішими серед яких є:
-
Kanban - Технологія Kanban вимагає забезпечення високої узгодженості між стадіями розробки продукту, має «плаваючу» оцінку термінів виконання та бюджету, які також постійно змінюються відповідно до вимог. Слово «Канбан» складається з двох частин: «Кан» означає «візуальний, видимий», а «бан» означає картку або дошку. Тому одним із методів в даній технології є візуалізація потоку задач та стану їх виконання в поточний момент. Постійне використання філософії «точно до терміну» спонукає відстежувати час на виконання одного завдання з метою його оптимізації, а також обмежує кількість одночасно виконуваних робіт.
-
Scrum - Основою Scrum є емпіричний процес, принципи та динаміка філософії Lean(акцентує увагу на тому, щоб позбавлятись усього, що не створює додаткової цінності;на фокусуванні на найбільш пріоритетних завданнях; постійних, але доцільних покращеннях, які дають можливість створити якісний продукт, враховуючи оптимізацію процесів та забезпечення ефективної роботи персоналу). Емпіричний процес, тобто досвід безпосередньої взаємодії в умовах динамічного середовища, змушує реагувати на такі потреби ринку, як швидкість та якість виконання замовлення в умовах обмеженого фінансування. Вирішенню цих проблем сприяють принципи Lean-філософії, яка постійно адаптується до різних сфер діяльності та розвивається.
-
Extreme Programming(XP) - На відміну від Scrum, який більше орієнтований на побудову процесів, XP визначає, як писати код, будувати архітектуру, тобто орієнтоване на інженерну частину і впливає безпосередньо на код. Agile визначає, як гнучко керувати будь-яким проєктом, а екстремальне програмування – як розробнику відповідати Agile підходам.
Варто зазначити, що дистаційна робота відрізняється від віддаленої. Ця різниця пов'язана з гострою необхідністю постійної та ефективної комунікації. Адже під час дистанційної роботи учасники проєкту працюють разом одночасно, хоч і з різних "локацій", саме тому можливість швидкого зв'язку є необхідною, для забезпечення якості цієї роботи.
Чат(Chat) та Instant messaging(IM) — це "системи" спілкування, що базуються на коротких повідомленнях, котрі можуть бути прочитані достроково(у реальному часі). Це надає більш швидкий та простий спосіб спілкування, чи обговорення певної теми. Дуже часто ці два терміни вважають взаємозамінними, хоча це не так. Чат - віртуальна кімната, до якої приєднана велика кількість людей, що можуть знати або не знати один одного, та спілкуються між собою. Зазвичай чати сфокусовані на певній тематиці, якою цікавляться різні його учасники. ІМ, на відміну від чатів, дуже комфортно використовувати для спілкування з однією людиною. ІМ, зазвичай, має список контактів, кожному з яких користувач може надіслати повідомлення, та дізнатись чи в мережі на даний момент цей контакт. Останнє також є корисною можливістю під час дистанційної роботи.
Переваги та недоліки ІМ:
- (+)Повідомлення дострокові.
- (+)Дуже корисно для швидкого спілкування в реальному часі.
- (+)Можливість використання голосових повідомлень.
- (+)Робота в якості фонового процесу.
- (-)Якщо співрозмовник не в мережі, варто шукати інший спосіб зв'язку з ним, або не слід чекати швидкої відповіді.
- (-)Незручно використовувати для обміну довгими повідомленнями.
- (-)Якщо співрозмовник пише дуже швидко чи використовує абревіатури, повідомлення можуть стати важкими для читання.
Дешборд(Dashboard) — це візуальне представлення інформації, згрупованої за змістом в одному місці(екрані) для більш комфортного та ефективного візуального сприйняття інформації користувачем. Принциповою відмінністю дєшбордів від таблиць та звітів є його форма. Дуже часто дешборди постають у вигляді "плиток", що відображають певну інформацію у реальному часі. Дешборди можна виводити на екран та надавати до них доступ іншим користувачам(членам команди), що працюють над проэктом, щоб бачити зміни в статусі його етапів та плануванні.
Планування проєкту - це процес, який передбачає визначення цілей і параметрів взаємодії між роботами та учасниками проєкту, розподіл ресурсів та вибір і прийняття організаційних, економічних, технологічних рішень для досягнення поставлених цілей проєкту. Планування забезпечує такі параметри:
- Визначення тривалості і термінів завершення проєкту.
- Структурування проетку та його декомпозиція на етапи та пакети робіт.
- Визначення необхідних ресурсів — персоналу та матеріалів.
- Забезпечення координації виконання певних робіт та їх розподіл між учасниками.
Інтеграція з GitHub'ом як системою контролю версій: Система контролю версій — це компонент управління програмним забезпеченням, що обробляє та відстежує зміни, внесені до інформації чи програмного забезпечення. Реальні проєкти потребують систему контролю версій через те, що зазвичай над ними працює не одна людина. Тож такі системи гарантують, що в коді та іншій інформації проєкту не буде співпадінь чи конфліктів.
GitHub - безкоштовний сервіс з відкритим сирцевим кодом, що базується на Git та надає віддалений доступ до його репозиторіїв, забезпечує розміщення коду та допомагає в управлінні життєвим циклом розробки програмного забезпечення. Крім того, він включає до себе такі функції, як сумісне використання коду декількома особами, відстеження помилок, та інші інструменти.
Розширення - це частинки коду, що змінюють функціонування програми. Розширення(бо розширюють можливості) можуть додавати нові функції до програми(чи сайту), чи змінювати вже наявні, а також змінювати її зовнішній вигляд чи вміст.
| boar | Github Projects | Trello | Backlog | |
|---|---|---|---|---|
| Functionality | Розширення, agile-орієнтовність, планування, дешборд, чат, інтеграція з GitHub, дистанційна робота | Інтеграція з GitHub, agile-орієнтовність. Загалом функціоналу мало, як і можливостей для його розширення | Автоматизація, синхронізація з мобільним додатком | Повідомлення, діаграми Ґанта, інтеграція з GitHub, можливість розділити задачу на підзадачі |
| Usability | Довідкова інформація в системі, документація на GitHub, простий та логічний інтерфейс | Місцями інтерфейс заплутаний, проте хороша документація | Вся інформація в наочному вигляді, user-friendly дизайн | User-friendly інтерфейс, Help Center(підтримка) |
| Reliability | Постійна доступність системи(24/7), низький рівень кількості збоїв | Майже не буває збоїв | Майже не буває збоїв | Майже не буває збоїв |
| Performance | Система зовсім не вимоглива до ресурсів, тому буде працювати досить швидко | Немає даних, але як для користувача, система працює досить швидко | Немає даних, але як для користувача, система працює досить швидко | Немає даних, але як для користувача, система працює досить швидко |
| Supportability | Локалізація: базово 3 язики; завдяки формі вебсайту доступна на будь-яких платформах із браузером | Підтримує тільки англійську мову, також працює із браузера | Є онлайн підтримка, об'ємний розділ допомоги FAQ, навчання користувача | Доступна тільки англійська мова; є підтримка користувачів(але сама система backlog платна) |
Розробка системи є доцільною як платформи для дистанційної роботи, що вкрай важливо для підходу до розробки agile. Всі конкурентні системи забеспечують лише можливість віддаленої роботи, тобто немає жодної системи саме для дистанційної роботи. Система буде поєднувати в собі систему контроля версій, чат та систему з todo-листів.