Данные аспекты являются интересными, но повышают сложность и увеличивают время разработки. Для MVP (minimum viable product – минимально жизнеспособный продукт) данными аспектами можно пренебречь. Но часто заказчики программного обеспечения планируют маштабируемость системы. Мультиарендная платформа используется обычно в программном обеспечении как услуге (software as a service – SaaS).
Specification
До разработки требуется определить требования и набор функциональности, которое необходимо реализовать в программном обеспечении, для этого предварительно проводится анализ бизнеса, идей и "хотелок" заказчика.
Аналитики изучают бизнес требования и формируют Техническое задание (ТЗ) или Спецификацию, с участием дизайнеров, которое включает:
• функциональные требования – описание основной и дополнительной функциональности, которое требуется реализовать в программном обеспечении;
• не функциональные требования – требования к среде исполнения, производительности, защищенности, наличия мониторинга, логирования и т.п.
• мокапы – схематическое изображение экранов или страниц с графическими элементами представления (надписи, таблицы и т.п.), ввода (поля и окна ввода, таблицы и т.п.) и управления (кнопки, радио кнопки, чек-боксы и т.п.), со схемой переходов между экранами;
• дизайн – графическое представление страниц и экранов программного обеспечения может дополнительно прилагаться к ТЗ (либо создаваться дизайнерами позже).
На базе Технического задания проводится предварительная оценка проекта: оценивается время реализации каждого требования, суммарное время, с учетом времени аналитики, дизайна, менеджмента, тестирования, поставки и рисков.
С учетом как функциональных, так и не функциональных требований формируется архитектура проекта, проводится выбор технологий, инструментов разработки, баз данных и пр., определяется требуемый состав и число ИТ специалистов.
В классическом процессе разработки ТЗ или Спецификация для программиста является исходным документом, используемым в процессе разработки.
На основе Технического задания (или Спецификации) формируется список задач программистам для реализации.
User stories
В "гибких" методологиях (позже ты изучишь их подробнее), заменой Технического задания, Спецификации (или его дополнением) являются Пользовательские истории (User stories).
User story – фиксация требования, функциональности посредством краткого описания и ряда атрибутов:
• ID – уникальный идентификатор (в системе ведения проекта ID генерируется автоматически).
• Название – краткое описание истории. Например, “Просмотр журнала своих транзакций”.
• Важность (Importance) – степень важности данной задачи, по мнению заказчика. Например,
10 или 150. Другой вариант параметра – приоритет, например, P1, P2, P3.
• Предварительная оценка (initial estimate) – начальная оценка объема работ, необходимого для реализации истории по сравнению с другими историями.
• Как продемонстрировать (how to demo) – краткое пояснение того, как завершённая задача будет продемонстрирована.
• Примечания – любая другая информация: пояснения, ссылки на дополнительные источники информации, и т.д.
Часто User story дополнительно разделяется на отдельные задачи. В таком случае реализация каждой истории требует выполнения одной или нескольких задач.
ИТ-проекты проходят через 5 основных фаз жизненного цикла:
• инициация;
• планирование;
• выполнение;
• мониторинг и контроль;
• завершение.
В начале жизненного цикла проекта проводится аналитика, формирование требований для программного обеспечения (в документах Техническое задание или Спецификация, или Пользовательские истории).
Далее следуют: планирование работ по проекту, формирование списка задач, их распределение, контроль над выполнением, тестированием задач, сборка и поставка ПО, анализ метрик по проведенной работе – все фазы, это неотъемлемая часть процесса разработки ПО.
Каким образом можно координировать, согласовывать и отслеживать проводимую работу? Для этого предназначены системы управления проектами и задачами, с разной функциональностью и возможностями.
