Файл: Сравнительная характеристика трех-пяти программных продуктов.pdf

Введение

В качестве систем управления проектами для сравнения я выбрал следующие программные продукты:

1. GitHub.
2. Trello.
3. Jira.

Коротко о каждом продукте:

1. GitHub[2] – это интернет портал, который является web – хостингом многих проектов, обычно его используют для open source разработки, то есть это значит что любой желающий может скачать исходный код проекта и бесплатно использовать приложение (услугу), а так же дополнять и предлагать свои идеи, их одобрят (конечно если они хорошие!!). Чуть позже я расскажу про систему контроля версий и зачем её используют
2. Trello[1] - сервис для управления проектами и персональными задачами. Простой, бесплатный и гибкий визуальный онлайн-инструмент для организации работы команды или отдела по методологии “канбан” (это целая тема для реферата!).
3. Jira[3] коммерческая система отслеживания ошибок, предназначена для организации взаимодействия с пользователями и для управления проектами. Разработана компанией Atlassian, является одним из двух её основных продуктов (наряду с вики-системой Confluence). Имеет веб-интерфейс.

Именно эти 3 продукта мы начнём сравнивать между собой по некоторым критериям, а именно:

1. Порог вхождения и освоения.
2. Поддержка git (чуть позже разберём что это такое).
3. Удобство отслеживания заданий и ошибок.
4. Цена.
5. Дополнительно.

И так, прежде чем сравнивать по критериям стоит понимать что эти критерии значат на практике.

Порог вхождения и освоения – этот критерий будет говорит о том на сколько будет сложно освоить этот инструмент для комфортного использования, причем стоит отметить что для каждой должности будет свой уровень, потому что project-manegry придётся более глубже освоить инструмент, потому что ему придётся банально больше задач делать в этой программе.

Git[5] – это система контроля версий нашего проекта. Работает она по принципу ветвления корней дерева или его ветвей.

Сейчас объясню на примере. У нас есть первоначальное состояние проекта, давайте назовём это состояние буквой A. Потом мы сделали пару изменений добавили допустим авторизацию в нашем проекте и теперь мы сохраняем 2 уже состояние нашего проекта.

На рисунке 1 представлена примерная схема в gite.

Рисунок 1. Добавление авторизации в gite

Теперь мы подумали и поняли, что было бы не плохо протестировать это и решаем создать ветку для тестирования этого нового функционала, но мы продолжили делать новые изменения в проекте и добавлять новый функционал. На рисунке 2 представлен процесс создания новой ветке в gite.

---

Рисунок 2. Создание новой ветке в gite

То есть, мы сделали разделение (ветвление проекта), что бы можно было не волноваться, что тестирование помешает нам делать новый функционал, что очень удобно.

После того как мы убедились, что авторизация работает корректно мы можем сделать слияние, допустим что к этому моменту мы уже сохранили 3 версию нашего приложения. Теперь нам потребуется слить 2 ветки в 1 (см. рис. 3).

Рисунок 3. Слияние двух веток в gite

И мы можем повторять это сколько угодно раз, создавая ветки для разных задач к примеру: тестирование, добавления экспериментальной функции и т. д.

Теперь поговорим немного о рейтинге или же доминировании веток.

При первом сохранении состояния проекта, git самостоятельно создаст первую и самую главную ветку (master), если перевести с английского то это означает “хозяин”. Что же это значит на практике ?

Ветка master предназначена для “релиза” новой версии приложения, там хранится самый стабильный и “чистый” код. Что за такое “релиз”?

Релиз – это новая версия приложения, отличить одну версию от другой можно не только сменой дизайна. Есть специально разработанная система ведения версий приложения. Ведутся версию при помощи специального номерования.

Вот пример первой версии какого-нибудь приложения “version 1.0.0”

Давайте разберём что эти цифры значат

Первая цифра обозначает изменения в проекте, которые будут не совместимы с предыдущими, т.е. версия 2.0.0 не будет поддерживать версию 1.0.0, название таких изменений принято называть старшими (major), вторая цифра обозначает изменения, которые совместимы с предыдущей версией

к примеру 2.3.0 будет поддерживать 2.0.0, это ещё называют младшими изменениями (minor), последняя цифра обозначает исправление ошибок и мелкие изменения (maintenance, micro)

Вот ещё пример в качестве картинки

Рисунок 4. Пример нумерации версий приложения

Удобство отслеживания заданий и ошибок –думаю, не секрет, что когда ты видишь тоску с важными задачами и последовательность их выполнения, то разрабатывать и управлять становится проще, здесь мы сравним какие инструменты для ранжирования нам дают эти программы.

Цена –думаю, и так всё понятно.

Основная часть

Теперь переходим к самому сравнению по критерию.

---

Порог вхождения и освоения.

И тут без условно есть фаворит, Trello, в нём достаточно простая концепция для понимания человека, все задания разбиты на плашки с семантическим называнием (смысловым), то есть если у нас задача по добавлению авторизации, то скорее всего плашка в Trello будет называться “авторизация”. В этих плашках можно писать подзадачи и назначать ответсвенного за выполнение, так же под плашками будет написано процент выполнения задач.

GitHub – к сожалению github не может похвастаться такой простотой как у Trello, в нём придётся создавать текстовые файлы для описания задачи и вручную отслеживать её выполнение, здесь github проигрывает.

Jira – пожалуй это самый сложные программный продукт в нашей 3, потому что в нём очень много возможностей покрытия задач по управлению проекта, у заданий есть свои коды, которые говорят о важности, по мимо этого есть возможность расписывать и указывать каким образом решена эта задача, к примеру для отчётности.

Поддержка git.

Trello – есть конечно возможность сделать поддержку gita, но это займёт довольно приличный промежуток времени и будет это не особо с точки зрения самих программистов, поэтому здесь Trello к сожалению проигрывает GitHub и Jira.

GitHub – этот программный продукт был сделан с идей того что все проекты должны быть сделаны с использованием git, всё проекты по умолчанию используют эту систему контроля версий, что облегчает работу для программистов.

Jira – она не особо далеко ушла от GitHuba, в принце больше нечего добавить про неё в этом пункте.

Удобство отслеживания заданий и ошибок

Trello – нет особо ранжирования, есть 3 состояния задания:

• Нужно сделать.
• В работе.
• Готово.

А так же разбития задач на плашки и всё

GitHub – тут всё печальнее, придётся вручную вести фалы с рейтингом задач и обновлять их после каждого сохранения состояния

Jira – а это наш победитель, в ней достаточно удобно сделано ранжирование в виде досок с сематическим названием в которых по приоритету расставлены задания

---