64
В команде Scrum приняты 3 роли:
Владелец продукта (Product owner) – участник, сфокусированный на
требованиях бизнеса и рынка, занимается отбором задач и их приоритезацией.
Скрам-мастер (Scrum-master) – участник, сфокусированный на
обучении и контролировании следования методологии всех участников команды, в
том числе владельца продукта.
Скрам-команда (Scrum team) – автономная и многофункциональная
команда.
Вся деятельность в Scrum поделена на короткие, повторяющиеся итерации –
спринты. Как правило спринт длится от 1 до 4 недель и состоит из следующих
этапов:
Планирование – начало спринта, команда выбирает из списка
невыполненных задач продукта (Product backlog) те, которые собирается
выполнить в этом спринте, оценивает их, записывает на стикеры и переносит на
скрам-доску (Sprint backlog), которая разделена на несколько колонок: Новая, В
работе, Тестируется, Сделано.
Ежедневные собрания – каждый участник команды за 3-5 минут
рассказывает что было сделано вчера, что нужно сделать сегодня, какие есть
проблемы. Таким образом, собрание проходит в среднем 20-30 минут.
Обзор спринта (Sprint review) – встреча с участием заказчика и руководства,
на которой команда рассказывает, что было выполнено за спринт и демонстрирует
готовые части продукта.
Ретроспективное собрание (Sprint retrospective) – заключительный этап
спринта, на котором команда подводит итоги и выдвигает предложения по
усовершенствованию работы.
Существует несколько методик, которые позволяют наиболее точно
спланировать задачи в следующем спринте. Наиболее распространенные из них –
это использование последовательности Фибоначчи и покера планирования. Данные
методики позволяют оценить ресурсоемкость задач не в часах, а в числах
Фибоначчи и комбинациях карт, что как показывает практика получается точнее,
чем при оценке в часах.
65
2.2.2 Формирование команды проекта автоматизации
Среди общераспространенных проблем процесса разработки программного
обеспечения встречаются следующие:
изменение требований непосредственно в процессе разработки;
нечеткое распределение ответственности за выполняемую работу и ее
результат;
наличие непрерывного потока мелких, «быстрых», наваливающихся
требований, отвлекающих разработчиков и менеджеров от основного направления
работ;
как следствие, срыв сроков, раздувание бюджетов, потеря качества;
Для решения задачи успешной организации процесса разработки ПО была
выбрана гибкая методология разработки проектов, так как она позволяет избежать
указанных проблем.
Участниками проекта, традиционно для Scrum методологии, являются
владелец продукта, скрам-мастер и команда. Команда включает в себя
специалистов всех необходимых направлений и выполняет работу на всех стадиях
проекта.
Владелец продукта является связующим звеном между командой разработки
и заказчиком, он понимает, как работает бизнес, умеет воодушевить людей, не
боится ошибаться и получать обратную связь от команды и заказчика. В его задачи
входит:
решает, каким должен быть продукт;
создает и изменяет бэклог продукта на весь период и совместно с
командой определяет приоритет задач, а так же бэклог спринта;
набирает команду продукта;
распоряжается бюджетом;
отвечает за бизнес показатели.
Скрам-мастер – тренер и помощник команды продукта. Он следит, чтобы все
участники разделяли ценности Скрама, соблюдали правила фреймворка и были
крепкой командой. Именно он строит правильный Скрам и помогает компании
стать гибкой. В его задачи входит:
обучает ценностям методологии команду и владельца продукта;
66
помогает команде стать самоорганизованной и кросс-
функциональной;
решает конфликты в команде;
помогает упорядочить бэклог;
создает условия в которых все участники понимают и уважают друг
друга.
Команда продукта – команда разработки, которая состоит из специалистов,
производящих непосредственную работу над производимым продуктом. Команда
выполняет следующие задачи:
разрабатывает продукт;
распределяет совместно с владельцем продукта задачи на бэклог
спринта;
определяет приоритет задач;
определяет ресурсоемкость задачи;
в команде все помогают друг другу и вместе отвечают за результат.
В команде участвует 5 человек, 3 из них – скрам-команда, владельцем
продукта является руководитель отдела, а скрам-мастером – соответствующий
специалист. В команде принято решение ведение недельных спринтов, в конце
каждого производится обновление продукта для быстрой обратной связи от
пользователей.
2.2.3 Средства коллективной работы над проектом автоматизации
В рамках анализа существующих систем для координации работы над
проектом было принято решение использовать систему «Первая форма», на базе
которой разрабатывается описываемая ИС, так как она включает в себя весь
необходимый функционал, в том числе возможность ведения спринтов. Интерфейс
главного экрана системы приведен на рисунке 13.
67
Рисунок 13. Интерфейс системы «Первая форма»
Система позволяет создавать и вести задачи по их жизненному циклу,
создавать категории задач с формированием жизненного цикла задач, вести
справочники и отчетность, а также трудозатраты пользователей, интегрировать
другие ИС, такие как 1С, Active Directory, CRM системы и так далее. Важной
особенностью системы является то, что при разработке сделан акцент на
безопасность и конфиденциальность данных, что является одним из важнейших
критериев при выборе средства автоматизации разработки ИС.
В системе возможно настроить среду для ведения спринта. Для разработки
ИС в рамках данной работы была настроена категория «Бэклог», в которой
собраны все задачи для реализации проекта. Еженедельно командой определяется
бэклог спринта, каждой задаче выставляется исполнитель и номер спринта, таким
образом формируется область видимости, для каждого участника команды.
Поскольку спринт также является задачей, то в нем так же можно вести
обсуждения в виде групповой переписки. Каждой задаче в системе выставляется
срок, как правило это 15:00 в пятницу, и статус, тем самым можно управлять
жизненным циклом каждой отдельной задачи. Система «Первая форма» позволяет
вести переписку в каждой задаче и в чате, таким образом можно легко
взаимодействовать как с командой, так и с любым сотрудником компании, получая
68
от них обратную связь. Кроме того, в системе предусмотрены VoIP звонки, так что
если участники спринта работают удаленно, то ежедневные встречи, планирование
и ревью можно проводить с помощью встроенной телефонии.
2.3 Информационное обеспечение задачи
2.3.1 Информационная модель и её описание
Инфологическая модель используется после словесного описания
предметной области.
Между сущностями могут быть связи – бинарные ассоциации, указывающие,
как сущности взаимодействуют или сравниваются между собой. Связь может быть
между двумя разными сущностями или между одной и той же сущностью
(рекурсия). Она отражает, как связаны экземпляры сущностей друг с другом. При
этом если есть связь между двумя сущностями, то она отражает взаимосвязь между
экземплярами той и другой сущности.
Связи можно разделить на три типа по множественности:
связь один-ко-одному (1:1) показывает, что экземпляр первой
сущности связан с одним экземпляром второй сущности;
связь один-ко-многим (1:М) показывает, что один экземпляр первой
сущности связывается с несколькими экземплярами второй сущности;
связь «многие-ко-многим» (М:М) показывает, что несколько
экземпляров первой сущности связываются с несколькими экземплярами второй
сущности. Между двумя сущностями можно задать множество связей с разными
смысловыми нагрузками.
Связь любого из этих типов будет обязательной, если в данной связи
участвует каждый экземпляр сущности, и вовсе не обязательной – если не каждый
экземпляр сущности участвует в данной связи. При этом связь будет обязательной
с одной стороны и необязательной, с другой стороны.
Информационная модель разрабатываемой системы представлена на рисунке 14.
69
Рисунок 14. Информационная модель системы
70
2.3.2 Характеристика нормативно-справочной, входной и
оперативной информации
Входной информацией для проектируемой системы являются задачи,
сведения о сотрудниках компании, содержащиеся в штатном расписании, сведения
о клиентах, а также сведения о категориях задач, формируемые на основании
деятельности компании.
Данные из входных документов вносятся в систему путём ручного ввода
данных через интерфейс приложения.
Сведения о категориях задач содержат только наименования данных
реквизитов. Основным документом, вносимым в систему, является заявка на
выполнение задачи. Для обеспечения работы системы предусмотрены
справочники, приведенные в таблице 9.
Таблица 9
Перечень используемых справочников
Название
справочника
Ответственный
Средний
объём
справочник
а в записях
Средняя
частота
актуализации
Средний
объем
актуализа
ции, %
Специализации
Администратор
45
1 раз в месяц
10
Клиенты
Администратор
150
1 раз в год
10
Категории
Администратор
10
1 раз в месяц
10
Пользователи
Администратор
250
1 раз в год
10
Статусы
пользователей
Администратор
5
1 раз в год
10
Справочник Специализации формируется на основании штатного
расписания и содержит только наименование отдела. На основании этого же
документа формируется и справочник Пользователи. Справочник Категории – на
основании результатов анализа работы отдела. Справочник Пользователи
формируется на основании штатного расписания предприятия, а также
справочника Статусы пользователей в системе.
2.3.3 Характеристика результатной информации
Основным результатным документом для разработанной системы является
список задач, распределенный по следующим статусам: новые, в процессе, на
проверке, закрытые, удаленные.
Реквизиты данного документа следующие:
71
номер задачи;
статус;
приоритет;
вложенные файлы;
дата последнего изменения статуса задачи;
ФИО пользователя, открывшего задачу;
наименование задачи;
описание;
категория;
компания;
комментарии.
Данные реквизиты являются общими для всех задач. Для проектов,
перешедших в статус «В процессе» и дальше предусмотрены также следующие
реквизиты:
сведения об исполнителе, в том числе:
ФИО исполнителя;
должность исполнителя;
сведения о жизненном цикле проекта, в том числе дата и время
изменения каждого статуса.
Кроме того, для удобства работы администратора формируются следующие
выходные документы:
список пользователей с возможностью редактирования;
список клиентов;
список категорий задач.
Документ «Список пользователей» содержит следующие реквизиты:
номер пользователя в системе;
ФИО пользователя;
статус пользователя;
отдел пользователя;
логин;
хэш пароля;
72
соль шифрования пароля.
Данный документ формируется на основе таблиц Пользователи, Отделы, а
также справочника Статусы пользователей.
Выходной документ Список клиентов содержит только номера и
наименования клиентов и формируется на основании соответствующего
справочника.
Выходной документ Список категорий содержит только номер и
наименование категории и формируется на основании соответствующего
справочника.
Также в системе формируются следующие отчеты:
отчет по поступившим, обработанным и закрытым задачам за
произвольный период;
отчет по задачам, выполненным определенным сотрудником за
произвольный период;
отчет с табелем трудозатрат каждого пользователя за определенный
период.
Кроме перечисленных отчетов система позволяет гибко настраивать любой
отчет, включая в него необходимые категории данных.
2.4 Программное обеспечение задачи
2.4.1 Общие положения (дерево функций и сценарий диалога)
Разрабатываемая информационная система призвана автоматизировать
деятельность компании по многим направлениям. На основании деятельности
компании построено дерево функций системы, которое представляет
декомпозицию функций системы и формируется с целью детального исследования
функциональных возможностей системы и анализа совокупности функций,
реализуемых на различных уровнях иерархии системы.
Дерево функций системы указывает декомпозицию функций системы и
создается для предметного исследования всех возможностей системы и изучения
совокупности функций, используемых на различных уровнях иерархии системы.
Подготовка дерева функций является процессом декомпозиции целевой функции и
множества основных и переменных функций на более элементарные функции,
которые применяются на других уровнях декомпозиции. Все реализуемые сложной
73
системой функции разделяют на две группы: основные и служебные.
Основные функции указывают на ориентацию системы и являются
совокупностью макрофункций, реализуемых системой. Эти функции определяют
существование системы некоторого класса. Базовые функции поддерживают
условия реализации целевой функции (получение, отправка, покупка, хранение,
выдача).
Служебные функции увеличивают функциональные возможности системы,
сферу ее работы и улучшают показатели качества системы, а также поддерживают
условия реализации основных функций (разведение, направление, гарантирование).
Дерево функций системы (рисунок 15) – это декомпозиция функций
системы, и создаётся оно для подробного изучения функциональных возможностей
системы и анализа взаимосвязанных функций, принятых на разных уровнях
иерархии системы. Сценарии диалога, формирующийся на основе дерева функций,
приведен на рисунке 16.