Набор инструментов, которым необходимо владеть следующий:
Jira – инструмент для декомпозиции работ проекта, постановки задач и мониторинга выполнения. Удобный инструмент особенно при работе по методологии Agile. Позволяет организовывать спринты или выводить все задачи на единую доску и отслеживать их состояние. Удобный инструмент для коммуникации с разработчиками и тестировщиками. В следующих статьях мы рассмотрим на примере как организовать проект в jira и работать в нем всей командой. Как ставить задачи, как мониторить их выполнение. Какие есть подводные камни. Как работать с jira технически вы можете найти в интернете в любом курсе, мы тоже этого коснемся, но не в общем и абстрактно, а на конкретном примере, так чтобы вы могли сделать по аналогии у себя. А главное, мы рассмотрим, как вести проект, как работать с командой, какие могут быть сложности при работе с коллективом при постановке и контроле выполнения задач в jira. Технически это сделать не сложно, но куда сложнее построить работу команды и запустить эту работу системно, так чтобы «машинка» сама работала, а вы только подруливали, задавая направление. Коснемся и такого вопроса как работать с саботажниками. Во что может превратиться jiraв руках саботажников и как с этим бороться. Какую правильную позицию занимать и как делать так чтобы ваши задачи выполнялись.
Confluence– программный продукт для размещения информации по проекту, описания архитектуры, правил работы и прочей необходимой информации для совместной работы команды, позволяет разграничивать доступ, интегрируется с продуктом jira. Confluence позволяет совместно редактировать документы, имеет свой графический редактор. Его можно установить на офисных серверах без выхода в интернет и настроить доступ по VPN, например.
MS Project – программный продукт, который позволят разрабатывать план графики работ и делать различную аналитику. В следующих статьях вы получите шаблон для построения план графика. А также мы на примере построим план график работы с оценкой трудоемкости и расчетом времени выполнения.
Порядок действий по разработке план графика проекта следующий:
- берете ТЗ, смотрите раздел «Этапность работ»;
- декомпозируете каждый этап на укрупненные блоки так чтобы на каждый блок мы могли назначить ответственного;
- совместно с ответственным или при его согласовании декомпозируете каждый блок на задачи с оценкой трудоемкости и назначаете исполнителя;
- ответственный это как правило начальник отдела или группы;
-далее определяется очередность блоков работ и очередность задач в каждом блоке;
-ранжируете блоки и задачи;
- определяете, что должно быть на входе каждой задачи и что должно быть на ее выходе, задачи называется соответственно этим данным.
- таким образом распланировали базовую техническую часть работы, теперь анализируется какая должна быть «обвязка» из работ смежных отделов, таких как дизайнерский (когда вам нужен дизайн проект), планово-экономический (когда вам нужно технико-экономической обоснование) и т.д.
- особое внимание уделяете работе отдела закупок, оцениваете, когда должно поступить железо и прочее для работы, от этой даты планируете влево, когда должна быть подана заявка и т.д. с учетом максимальных сроков поставки
- оцениваете, когда становятся нужны результаты работ соисполнителей, далее планирует влево, когда им необходимо выдать ТЗ, заключить контракт и т.д.
В следующих статьях мы на совместно составим план график проекта, по образу и подобию вы сходу сможете составлять такие же графики на своей работе.
Нужно ли это? Ну исходя из выше сказанного да. Причем составление такого графика, это достаточно напряженная аналитическая работа. Тут нужен опыт. Если у вас его еще нет, вы получите готовую методику и пример в помощь с конкретными шагами в MS Project, а освоить прочий интерфейс вы сможете и сами, так как он интуитивно понятный.
Git – система контроля версий. Завести проект в нем и сделать базовые настройки, например, для разграничения прав доступа лучше сделать самому. А организацию конвейера разработки лучше поручить devops инженеру. Git руководителю проекта нужен для того, чтобы понимать, что под капотом проекта и что делают разработчики (мы говорим о проектах в которых есть разработка ПО)
Git — это распределенная система контроля версий кода. Зачем она? Для распределенных команд нужна какая-то система управления работы. Нужна, чтобы отслеживать изменения, которые происходят со временем. То есть мы видим, какие файлы изменились и как. Особенно это важно, когда анализируешь, что было проделано в рамках одной задачи: это дает возможность возвращаться назад. Представим себе ситуацию: был работающий код, всё в нем было хорошо, но мы решили что-то улучшить. Все ничего, но такое улучшение поломало половину функционала, сделало невозможным работу. И что дальше? Без Гита нужно было бы часами сидеть и вспоминать, как же все было изначально. А так мы просто откатываемся на коммит назад — и все.
Или что делать, если есть два разработчика, которые делают одновременно свои изменения в коде? Без Гита это выглядит так: они скопировали код из оригинала, сделали что нужно. Наступает момент, и оба хотят добавить свои изменения в главную папку. Без гита это было бы слишком трудоемко, а с гитом достаточно удобно смержить все изменения. Установкой gitlab занимается точно не РП, как правило приходя в любую фирму он уже установлен. Поэтому в последующих статьях мы рассмотрим на примере как именно РП завести проект в git, настроить права доступа для участников, завести основные правила работы, поставить необходимые задачи devops инженеру по настройке pipeline в проекте, ну и вообще говорить на одном языке с разработчиками и devops. Это крайне важно если вы приходите в IT проект. И это поможет разобраться вам в уже существующем проекте если вас подключили или наняли в уже существующий.
Подписывайтесь на мой канал!