User stories
Без требований программирование – это искусство добавлять баги в пустой файл.
Описание
В "гибких" методологиях (позже ты изучишь их подробнее), заменой Технического задания, Спецификации (или его дополнением) являются Пользовательские истории (User stories).
User story – фиксация требования, функциональности посредством краткого описания и ряда атрибутов:
• ID – уникальный идентификатор (в системе ведения проекта ID генерируется автоматически).
• Название – краткое описание истории. Например, “Просмотр журнала своих транзакций”.
• Важность (Importance) – степень важности данной задачи, по мнению заказчика. Например,
10 или 150. Другой вариант параметра – приоритет, например, P1, P2, P3.
• Предварительная оценка (initial estimate) – начальная оценка объема работ, необходимого для реализации истории по сравнению с другими историями.
• Как продемонстрировать (how to demo) – краткое пояснение того, как завершённая задача будет продемонстрирована.
• Примечания – любая другая информация: пояснения, ссылки на дополнительные источники информации, и т.д.
Часто User story дополнительно разделяется на отдельные задачи. В таком случае реализация каждой истории требует выполнения одной или нескольких задач.
Чтобы руководить программистами, нужен Д. Кнут и пряник.
Описание
ИТ-проекты проходят через 5 основных фаз жизненного цикла:
• инициация;
• планирование;
• выполнение;
• мониторинг и контроль;
• завершение.
В начале жизненного цикла проекта проводится аналитика, формирование требований для программного обеспечения (в документах Техническое задание или Спецификация, или Пользовательские истории).
Далее следуют: планирование работ по проекту, формирование списка задач, их распределение, контроль над выполнением, тестированием задач, сборка и поставка ПО, анализ метрик по проведенной работе – все фазы, это неотъемлемая часть процесса разработки ПО.
Каким образом можно координировать, согласовывать и отслеживать проводимую работу? Для этого предназначены системы управления проектами и задачами, с разной функциональностью и возможностями.
Использование системы управления задачами – это не дань моде, а конкурентная необходимость, инструмент координации и эффективности работ, один из гарантов успешной реализации проекта.
Реальный отзыв команды, которая начала использовать современную систему управления проектами и задачами:
"Только при создании нового сайта мы смогли сократить срок разработки в 1,5 раза".
Для вас, как для разработчика, работа над задачей в общем случае выглядит следующим образом (реальный процесс может несколько отличаться):
Менеджером проекта вам назначается тикет (Issue), где описано, какую функциональность надо добавить или какую ошибку надо исправить.
Основные этапы выполнения задачи (тикета):
• Анализ задачи – вы знакомитесь с задачей, с документами и анализируете требования, имеющие отношение к вашей задаче. Если возникают вопросы по задаче, обсуждаете их с менеджером.
• Проектирование и оценка задачи – вы знакомитесь с кодом, который будет затронут в ходе кодирования. Обдумываете, как будете реализовывать задачу, какой паттерн программирования сможете использовать. Оцениваете задачу, а именно указываете количество времени, за которое планируете выполнить задачу, например: /estimate 1d 2h.
• Реализация задачи – рефакторинг (если требуется) текущего кода, написание нового кода, добавление юнит/интеграционных тестов. В ходе выполнения задачи или(и) после завершения задачи вы устанавливаете в задаче количество фактически затраченного времени, например: /spend 4h 30m.
• Деплоймент проекта – сборка проекта, установка в локальное рабочее окружение, ручное тестирование задачи.
• Контроль задачи – ревью кода, мерж кода в основную ветку разработки, проверка статуса сборки на сервере интеграции (проверка стилистики кода, качественных метрик кода, автоматических тестов).
В зависимости от системы управления и установленного процесса разработки задаче на каждом этапе устанавливаются различные статусы.
Следование процессу разработки значительно повышает эффективность работ, обеспечивает и поддерживает качество программного продукта, допускает взаимозаменяемость между членами команды, позволяет планировать и прогнозировать сроки выполнения итерации (этапа работ).
К процессу разработки ПО неоднократно будем возвращаться при описании последующих компетенций.
Инструменты
Десятки систем управления проектами и задачами, с разной функциональностью и разной доступностью:
Jira, Redmine, Asana, Basecamp, Trello, Wrike, GitLab и др.
Рекомендации
В случае, если вы самостоятельно разрабатываете проект, может показаться, что система управления не нужна.
Это заблуждение – в таком случае вы сами выполняете роль менеджера проекта
и принимаете решения, что делать и какую функциональность включить в разработку.
Система управления проектами позволит проводить планируемую работу:
• Записывайте задачи, которые требуется решить в ходе работ над проектом.
• Записывайте функциональность, которую планируете реализовать.
• Фиксируйте сразу обнаруженные ошибки в ПО, чтобы позже не забыть их исправить.
Навыки применения системы управления задачами пригодятся вам, когда будете участвовать в командных разработках.
Советую для изучения и практического применения Open Source системы управления проектами и задачами (с потенциальной возможностью установки на собственный сервер):
Redmine – функциональна, гибко настраивается, имеется возможность подключения плагинов с дополнительной функциональностью.
GitLab – содержит базовые функции управления проектами и задачами.
Помимо этого, в ИТ компаниях часто используют мощную (и дорогую) коммерческую систему:
Дополнительные материалы
Сравнительная статья о системах управления проектами:
43 полезных сервиса для управления проектами. Без эпитетов
Резюме
Вы должны понимать и уметь рассказать о назначении систем управления проектами и задачами.
Необходимо иметь практические навыки работы хотя бы с одной из систем.
В результате добавится новая строчка в вашем резюме, например:
Project management: GitLab