# Аналіз предметної області
# Вступ
В аналізі предметної області представлені:
- Основні визначення, де користувач зможе детальніше ознайомитися зі структурою систем управління проєктами
- Підходи та способи вирішення завдання в області систем управління проєктами
- Порівняльна характеристика наявних засобів вирішення завдання, де користувач ознайомиться з усіма перевагами та недоліками систем, у порівнянні з Duallo
- Висновки
- Посилання на вищевказану інформацію
# Основні визначення
Система управління проєктами (opens new window) - сукупність процесів, інструментів, методів, методологій, ресурсів і процедур з управління проєктом. Система документується в плані управління проєктами, і її зміст може відрізнятися в залежності від галузі застосування, організаційного впливу, складності проєкту і доступності наявних систем. Система управління проєктами, може бути як формальною, так і неформальною, допомагає менеджеру проєкту ефективно доводити проєкт до завершення.
Проєкт (opens new window) - сукупність моделей, проєктна конструкторська документація, яка містить проєктні рішення і дає повне уявлення про будову розроблюваного виробу, процесу або організації.
Елементи проєкту (opens new window) - проєкт повинен містити ряд елементів, що складають хороший проєкт. Для цього Інститут управління проєктами (PMI) визначає, які елементи життєво необхідні для правильної презентації нашого проєкту.
- Погода: Період, протягом якого триватиме проєкт.
- Сфера дії: Загальний вплив проєкту на суспільство.
- Вартість: Вартість ресурсів, необхідних для виходу проєкту.
- Організація та планування: Діяльність, яку слід розробити, а також терміни запуску проєкту.
- Управління зацікавленими сторонами: Управління інтересами зацікавлених сторін як акціонерів або учасників.
- Спілкування: Як розвиватиметься спілкування, а також інформаційні потоки.
- Завдання: Розподіл завдань та функцій.
- Результати: Вимірювання цілей, які ми сподіваємось отримати від проєкту.
Життєвий цикл програмного забезпечення (opens new window) – період часу, що починається з моменту узгодження рішення про необхідність створення програмного продукту і закінчується в момент його повного вилучення з експлуатації.
Мінімально життєздатний продукт (MVP) (opens new window) - така версія продукту, що виконує свою головну функцію і при цьому її не відхиляють клієнти та визнають її корисність.
Інститут Управління Проєктами (PMI) (opens new window) створює стандарти та проводить наукову та освітню діяльність у сфері управління проєктами та менеджменту. Також PMI проводить акредитацію в галузі управління проєктами, яка є однією з найпоширеніших та визнаних сертифікацій для керівників проєктів.
Методологія розробки програмного забезпечення (opens new window) - методи, застосовані на різних стадіях життєвого циклу розробки ПЗ, які мають спільний підхід та, згідно із цим підходом, дозволяють забезпечити найкращу ефективність процесів розробки.
Agile (opens new window) - це філософія та підхід до розробки програмного забезпечення, що спрямована на спрощення та прискорення процесу розробки. Він базується на ітераціях, співпраці між командами та постійному вдосконаленні.
Scrum (opens new window) - одна з Agile-методологій, яка використовується для управління проєктами. Вона покладається на ітерації, під назвою "спринти", і визначені ролі в команді, такі як Scrum Master і Product Owner.
Kanban (opens new window) - метод управління проєктами, що базується на візуальному представленні завдань та їхньому потоку. Він дозволяє бачити, наскільки навантажена команда і визначити пріоритети.
Kanban-дошка (opens new window) — один з інструментів, що може використовуватися при впровадженні методу управління розробкою «Kanban». Такі дошки можна як варіацію на тему традиційних kanban-карток. Замість сигнальних карток, які, зазвичай, позначають потребу або пропускну здатність, разом із дошкою використовуються магніти, пластикові фішки, кольорові шайби або наліпки для представлення робочих елементів та процесів. Кожен з цих об'єктів є етапом виробничого процесу і рухається по дошці, в міру прогресу. Такий рух відповідає руху процесу виробництва. Дошка, як правило, поділена на три логічні секції: «очікування», «робота в процесі» та «завершена робота». Співробітники переміщують нотатки до тієї секції дошки, яка відповідає статусу завдання.
Артефакт (opens new window) — це конкретний об'єкт або документ, що відображає або представляє результат робочого процесу розробки. Це може бути файл коду, технічна документація, діаграма, тестовий сценарій або будь-який інший матеріал, що з'являється в процесі планування, розробки, тестування та реалізації програмного продукту. Артефакти служать для документації, комунікації та відслідковування різних етапів життєвого циклу програмного проекту.
Класифікація за ядрами (opens new window) - при зверненні до методології, яка має ядро, відповідне способу опису алгоритму, та додаткові особливості, можна виділити такі п'ять основних ядер методологій:
- Методологія імперативного програмування
- Методологія ООП
- Методологія функціонального програмування
- Методологія логічного програмування
- Методологія програмування в обмеженнях
# Підходи та способи вирішення завдання
У програмного забезпечення, як у живої істоти є свій життєвий цикл. Зазвичай до етапів життєвого циклу відносять:
- Аналіз вимог
- Проектування
- Програмування
- Тестування і налагодження
- Експлуатацію, супровід і підтримку
За великим рахунком всі моделі можна розділити на дві великі групи: послідовні та ітераційні моделі. Давайте розглянемо основні моделі життєвого циклу.
# Waterfall (каскадна модель)
Основна суть моделі Waterfall у тому, що етапи залежать один від одного і наступний починається, коли завершений попередній, утворюючи таким чином поступальний (каскадний) рух уперед.
Плюси:
- Простота викладу в документацію
- Просте відслідковування прогресу
- Зрозумілість процесу розробки
Мінуси:
- Отримання результату лише по проходженню всіх етапів
- Складність виявлення помилок
- Повертатися назад важко
- Якщо стався збій на якомусь етапі, його наслідки видно тільки в кінці
- Негнучка
Схема каскадної моделі [1] (opens new window)
# Ітераційна модель
Передбачає розбиття проекту на частини (етапи, ітерації) і проходження етапів життєвого циклу на кожному з них. Кожен етап є закінченим сам по собі, сукупність етапів формує кінцевий результат. На кожній ітерації ми працюємо з одним і тим же продуктом і в кінці кожної ітерації отримуємо результат, яким можна користуватися (звісно з певними обмеженнями).
Плюси:
- Висока адаптивність
- Зменшення ризику завдяки можливості виправлення помилок на різних етапах розробки
- Можливість завершення розробки в кінці будь-якої ітерації
Мінуси:
- Можлива збільшена складність управління ітераціями.
- Збільшення витрат на тестування та забезпечення якості.
Схема ітераційної моделі [2] (opens new window)
Розглянемо підвиди ітераційної моделі (спіральну та інкрементну):
# Спіральна модель
Спіральна модель розглядає розробку програмного забезпечення як процес, що просувається в спіралеподібному циклі через чотири основні фази: ідентифікація цілей, аналіз та інженерія вимог, розробка та тестування, впровадження та оцінка.
Плюси:
- Ризиковий аналіз: Спіральна модель надає підхід до оцінки та управління ризиками на різних етапах розробки, що допомагає попереджати можливі проблеми.
- Змінність вимог: Цей підхід дозволяє легко внести зміни в вимоги на будь-якому етапі проекту.
- Поступовий розвиток: Проект розвивається поступово, кожен цикл додає новий функціонал до продукту.
Мінуси:
- Складність управління: Спіральна модель може бути складною для управління через велику кількість фаз та ітерацій.
- Витрати на аналіз та планування: Проведення детальних аналітичних робіт на кожному етапі може вимагати значних зусиль та витрат.
- Затримки через ризики: Якщо ідентифіковані ризики не управляються ефективно, це може призвести до затримок у проекті.
Схема спіральної моделі [3] (opens new window)
# Інкрементна модель
Принцип, що лежить в основі інкрементної моделі, має на увазі розширення можливостей, добудовування модулів і функцій програми. Буквальний переклад слова інкремент: «збільшення на один». Це «збільшення на один» застосовується в тому числі для позначення версій продукту. Продукт розбивається на версії за ітераціями.
Плюси:
- Швидка доставка: Інкрементна модель дозволяє швидко доставляти робочий функціонал клієнту, що сприяє більш швидкому отриманню поверхневих результатів.
- Змінність вимог: Зміни в вимогах можуть бути легко впроваджені в окремих інкрементах, не впливаючи на інші частини системи.
- Зниження ризиків: Ризики розподіляються на окремі інкременти, що дозволяє ефективніше управляти ними.
Мінуси:
- Складність інтеграції: Інкременти повинні бути ефективно інтегровані між собою, що може вимагати додаткових зусиль.
- Збільшена складність управління: Управління багатьма інкрементами може бути складнішим у порівнянні з іншими моделями розробки.
- Потреба у постійному оновленні: Кожен інкремент потребує постійного оновлення та підтримки.
Схема інкрементної моделі [4] (opens new window)
Загалом, вибір між спіральною моделлю і інкрементною моделлю залежить від конкретних вимог проекту, бюджету, строків і рівня ризику. Обидва підходи можуть бути ефективними, якщо вони правильно відповідають контексту проекту.
# Agile
Agile - це методологія управління проєктами, яка покладає акцент на співпрацю, гнучкість та ітеративний розвиток.
Основні принципи:
- Важливіша роль відводиться співпраці людей, ніж дотриманню процесів та використанню інструментів.
- Акцент ставиться на наявності робочого продукту, а не обсяжної документації.
- Підкреслюється важливість активної співпраці із замовником, на відміну від строгих умов контракту.
- Висувається пріоритет гнучкості та адаптивності до змін над ретельним виконанням попереднього плану.
Плюси:
- Клієнтська спрямованість: Agile дозволяє обмінюватися досвідом між учасниками команди і клієнтом і кожному з них впливати на прийняття рішень. Завдяки такому підходу знижуються ризики втрати часу і грошей і підвищується здатність команди вирішувати складні нестандартні завдання з високим ступенем невизначеності.
- Гнучкість: Здатність адаптуватися до змін у вимогах та середовищі.
- Ефективність: Швидке виправлення помилок та швидший виход на ринок.
- Заохочення творчості: Сприяє ідеям та інноваціям у команді.
- Покращена комунікація: Збільшена внутрішня комунікація та зрозумілість завдань.
Мінуси:
- Додаткові вимоги до команди: Щоб запобігти виникненню хаосу, команди повинні бути невеликі, учасники повинні бути компетентні та мотивовані, ітерації короткі з максимально зрозумілими цілями, встановлені чіткі обмеження за часом і кінцевий результат повинен бути очевидним.
- Нестійкість до змін: Не підходить для проєктів із сталими вимогами.
- Складність управління: Може бути важко управляти більшими та складними проєктами.
- Вимоги до часу: Зазвичай вимагає більше часу на виправлення ітерацій і спроб.
Схема Agile [5] (opens new window)
# Lean
Ідея підходу Lean полягає в тому, що ми ощадливо ставимося до ресурсів (у тому числі часу) і вирішуємо завдання найпростішим способом. Наприклад: ми не робимо весь продукт, щоб зрозуміти, що він нікому не потрібен - ми робимо лендінг і форму підписки і даємо на нього рекламу, щоб перевірити, що цей продукт викликає інтерес клієнтів і прийняти усвідомлене рішення про необхідність розробки.
Плюси:
- Мінімізація втрат: Основна ідея - зменшити витрати, запаси та зайву працю, що призводить до економії ресурсів.
- Покращення якості: Lean спрямований на вдосконалення процесів, що сприяє покращенню якості продукту або послуги.
- Задоволення клієнтів: Спрощені процеси і зниження вартості можуть призвести до покращення задоволення клієнтів.
Мінуси:
- Загроза погіршення якості: В окремих випадках прагнення до економії може призвести до зниження якості продукту або послуги.
- Загроза втрати користувача: Прагнення все спростити іноді призводить до ситуацій, в яких продукт спрощують настільки, що губляться дійсно важливі функції і продукт по суті виявляється непотрібним, оскільки не несе цінності користувачеві.
- Не підходить до складних інноваційних проєктів: Lean зазвичай краще підходить для оптимізації існуючих процесів, а не для революційних змін.
Схема Lean [6] (opens new window)
# Гнучкі методології
Нижче наведено короткий опис основних гнучких методологій розробки ПЗ.
- Scrum: Ґрунтується на понятті спринту (sprint), протягом якого виконується робота над продуктом. Перед початком кожного спринту проводиться планування (Sprint Planning), на якому проводиться оцінка вмісту списку завдань із розвитку продукту (Product Backlog) і формування беклога на спринт (Sprint Backlog), у рамках яких і діє команда. Для спринту завжди існують обмеження по часу, зазвичай від тижня до місяця. Життя продукту таким чином розбита на рівні по тривалості спринти.
- Kanban: Проект ділиться на етапи, що візуалізуються у вигляді канбан-дошки. Етапи, це наприклад: планування, розробка, тестування, реліз і т.п. Завдання у вигляді "карток" переміщуються з етапу на етап. Нові завдання можна додавати у будь-який час. Завдання закривається не по закінченню конкретного часу, а по зміні статусу на "завершено".
- RUP (Rational Unified Process): Розробка продукту за даним методом складається з чотирьох фаз (початкова стадія, уточнення, побудова, впровадження), кожна з яких включає в себе одну або декілька ітерацій. Методи, рекомендовані RUP, засновані на статистиці комерційно успішних проектів.
- RAD (Rapid Application Development): Передбачає застосування інструментальних засобів візуального моделювання (прототипування) і розробки. RAD передбачає невеликі команди розробки, терміни до 4 місяців й активне залучення замовника з ранніх етапів. Дана методологія спирається на вимоги, але також існує можливість їхніх змін під час розробки системи. Такий підхід дозволяє скоротити витрати і звести час розробки до мінімуму.
- DSDM (Dynamic Systems Development Model): Принципи спрямовані на головну мету - здати готовий проект вчасно і вкластися у бюджет, з можливістю регулювати вимоги під час розробки. DSDM належить до гнучких методологій розробки програмного забезпечення, а також розробок, що не входять у сферу інформаційних технологій.
- XP (Extreme Programming): Методологія, орієнтована на постійну зміну вимог до продукт, пропонує 12 підходів для досягнення ефективних результатів у подібних умовах. Серед них: швидкий план і його постійна зміна, проста архітектура, часте тестування, участь одночасно двох розробників в одному завданні або навіть за одним робочим місцем, постійна інтеграція і часті невеликі релізи.
Незважаючи на обширний обсяг досліджень, оцінка ефективності різних методик, принципів і методологій часто базується на особистому досвіді, емоційних реакціях та професійних навичках менеджера, що використовував їх. Безперечно, не завжди одна певна методологія, описана вище, є найкращим вибором для успішної реалізації вашого проекту. Тому чим більше ви ознайомлені з різними методологіями і підходами, тим більше ви зможете здійснювати керівництво проектами, комбінуючи найкращі практики залежно від конкретних вимог та умов вашого проекту.
# Порівняльна характеристика наявних засобів вирішення завдання
Github Projects (opens new window) — це інструмент для управління проектами в середовищі GitHub, який являє собою адаптивну електронну таблицю. Він є гнучким і інтегрованим рішенням, що взаємодіє безпосередньо з issues та pull-реквестами користувача на GitHub. Головна мета — оптимізувати процес планування та моніторингу роботи. Користувачі мають можливість створювати, налаштовувати та візуалізувати свої завдання та робочі процеси, використовуючи різноманітні фільтри, сортування, групування та додавання специфічних полів метаданих. Завдяки цьому інструменту команди можуть ефективно адаптувати свої робочі процеси, незалежно від вибраної методології.
Trello (opens new window) — це хмарний інструмент для управління проектами, який базується на методології Kanban. Він дозволяє командам візуально планувати, координувати та моніторити робочі процеси за допомогою дошок, списків та карток. Кожна картка символізує окреме завдання чи ідею, яка може пересуватися між колонками відповідно до її статусу в проекті. З можливістю додавання файлів, контрольних списків, автоматизації та призначення відповідальних осіб, Trello робить співпрацю команд ефективною та організованою.
Basecamp (opens new window) — це онлайн-платформа для керування проектами та командної співпраці, яка надає інтуїтивний інтерфейс для оптимізації робочих процесів. Цей сервіс комбінує можливості комунікації, планування, обміну файлами та відстеження завдань в єдиному цифровому просторі, що забезпечує централізований доступ до інформації для всієї компанії. Basecamp пропонує інструменти для створення проектних дошок, автоматичних чек-інів, організації робочих завдань та запуску приватних чатів. Він також дозволяє користувачам легко орієнтуватися у поточних завданнях, забезпечуючи прозорість робочих процесів і допомагає командам ефективно планувати свою діяльність.
Nifty (opens new window) — це універсальний інструмент для керування проектами та спільної роботи, який включає в себе широкий спектр функцій, спроектованих для команд будь-якого розміру, що працюють над складними завданнями. Він об'єднує можливості для реального часу співпраці над документами, обміну файлами, відстеження завдань та проектів, а також автоматизації робочих процесів. Використовуючи інтуїтивні інтерфейси, такі як канбан-дошки, списки завдань і вбудований календар, користувачі можуть адаптувати своє робоче середовище для максимальної продуктивності. Також із мобільними додатками для Android та iOS, Nifty забезпечує гнучкість для роботи в русі.
Backlog (opens new window) — це ефективний веб-інструмент для керування проектами та кодом, спеціально розроблений для технічних команд. Він надає користувачам можливість відстежувати проекти кодування, зокрема розробку веб-сайтів, із візуально зручними схемами та функцією відстеження завдань. Особливістю Backlog є його модуль для виявлення та відстеження помилок, дозволяючи командам співпрацювати для їх вирішення, незалежно від того, чи були помилки позначені внутрішньо чи повідомлені ззовні. Інструмент також включає гнучкі дошки у стилі канбан та можливість управління підзавданнями.
Asana (opens new window) — це веб-заснований та мобільний інструмент для керування проектами та завданнями, призначений для оптимізації співпраці в командах. Asana дозволяє розбивати комплексні проєкти на конкретні завдання, Також забезпечує зручний обмін файлами, коментарями та відстеженням термінів виконання. Ця платформа забезпечує візуалізацію завдань через різноманітні інструменти, такі як календарі та портфоліо, й інтегрується з численними зовнішніми додатками. Завдяки своєму багатофункціональному набору інструментів, Asana стає хорошим рішенням для команд будь-якого розміру, спрямоване на зменшення потреби в зустрічах та електронній кореспонденції, допомагаючи організувати та контролювати робочий процес ефективно.
Miro (opens new window) — це інтерактивний онлайн-інструмент для створення, співпраці та обміну візуальним контентом. Він надає користувачам можливість реалізовувати проекти в реальному часі на великій віртуальній дошці. До можливостей Miro входить створення діаграм, мап думок, сценаріїв користувачів та інших візуальних елементів, які полегшують спільне обговорення та планування. Інтеграція з іншими популярними інструментами та платформами робить Miro ефективним рішенням для команд, що працюють дистанційно або в гібридному форматі.
Порівняльна таблиця
| Вимоги | Критерії | Duallo (Наш проєкт) | github projects | trello | base camp | nifty | backlog | asana | miro |
|---|---|---|---|---|---|---|---|---|---|
| Functionality (Функціональні) | |||||||||
| Кросплатформеність | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | |
| Мобільна версія | 🟡 | 🟡 | 🟡 | 🟢 | 🟢 | 🟢 | 🟡 | 🟢 | |
| Наявність API | 🟡 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | |
| Підтримка артекфактів | 🟢 | 🟢 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🟡 | |
| Офлайн доступ | 🟢 | 🟢 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | |
| Система сповіщень | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | |
| Instant chat | 🟢 | 🟢 | 🟡 | 🟡 | 🟢 | 🟢 | 🟡 | 🟡 | |
| Пошуковий фільтр | 🟢 | 🟢 | 🟢 | 🟡 | 🟢 | 🟢 | 🟢 | 🟢 | |
| Задання дедлайнів | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | |
| Призначення завдання учаснику | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟡 | |
| Usability (до зручності) | |||||||||
| User-friendly interface | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | |
| Багатомовність | 🟡 | 🔴 | 🟢 | 🔴 | 🔴 | 🔴 | 🟡 | 🟢 | |
| Інтеграція з Github | 🟢 | 🟢 | 🟢 | 🔴 | 🟢 | 🟢 | 🟢 | 🟡 | |
| Ведення паралельно кількох проєктів | 🟢 | 🟢 | 🟡 | 🟡 | 🟡 | 🟡 | 🟢 | 🟢 | |
| Доступ до дошки без реєстрації | 🔴 | 🟢 | 🟢 | 🔴 | 🔴 | 🔴 | 🔴 | 🟢 | |
| Reliability (до надійності) | |||||||||
| Резервне копіювання | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | |
| Швидкість виправлення багів | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | |
| Приватні проєкти | 🟢 | 🟢 | 🟢 | 🟡 | 🟢 | 🟢 | 🟡 | 🟢 | |
| Історія зміни проєктів | 🟢 | 🟢 | 🟢 | 🟡 | 🟢 | 🟢 | 🟢 | 🟢 | |
| Протокол шифрування | TLS | TLS | TLS | TLS | TLS | TLS | TLS | TLS | |
| Багаторівнева автенфікація | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | |
| Performance (до продуктивності) | |||||||||
| Швидкість інтерфейсу | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | |
| Швидкість виконання запитів | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | |
| Синхронізація в реальному часі | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟡 | |
| Стійкість до збоїв | 🟢 | 🟢 | 🟢 | 🟡 | 🟡 | 🟢 | 🟡 | 🟢 | |
| Supportability (до підтримки) | |||||||||
| онлайн підтримка | 🟢 | 🟢 | 🟢 | 🟡 | 🟢 | 🟢 | 🟢 | 🟢 | |
| FAQ | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 |
# Висновки
В існуючому ринку інструментів управління проєктами справді існують недоліки та прогалини. Згідно таблиці більшість сервісів не забезпечують деяких критичних функцій, таких як підтримка артефактів. Ця функція можуть виявитися вирішальною для конкретних груп користувачів або в конкретних ситуаціях використання.
Додатково, наявність важливих функцій лише в платних версіях деяких платформ може обмежувати доступність та привабливість цих інструментів для широкого спектра користувачів, особливо для малих компаній або індивідуальних розробників.
З урахуванням цього, ідея розробки нової платформи управління проєктами, яка буде враховувати вказані недоліки та надавати унікальні можливості, виглядає обґрунтованою. Такий інструмент, розроблений з урахуванням потреб спільноти та відсутності ключових функцій в інших платформах, може зайняти свою нішу на ринку та стати популярним серед користувачів.
# Посилання
- Система управління проєктами (opens new window)
- Проєкт (opens new window)
- Елементи проєкту (opens new window)
- Інститут Управління Проєктами (PMI) (opens new window)
- Методологія розробки програмного забезпечення (opens new window)
- Класифікація за ядрами (opens new window)
- Життєвий цикл пз [1] (opens new window) [2] (opens new window)
- Схеми та малюнки [1] (opens new window) [2] (opens new window) [3] (opens new window) [4] (opens new window) [5] (opens new window) [6] (opens new window)
- About Github Projects [1] (opens new window) [2] (opens new window)
- About Trello [1] (opens new window) [2] (opens new window)
- About Basecamp [1] (opens new window) [2] (opens new window)
- About Nifty [1] (opens new window) [2] (opens new window)
- About Backlog (opens new window)
- About Asana (opens new window)
- About comparison table [1] (opens new window) [2] (opens new window)