Разработка библиотечной системы, отвечающей потребностям как библиотекарей, так и посетителей библиотеки, может быть сложной задачей. Чтобы обеспечить соответствие системы требованиям всех заинтересованных сторон и своевременную её доставку, можно применить подход Agile. В этой статье мы представляем план разработки по методологии Agile для библиотечной системы, который может быть завершен за 10 спринтов в течение 100 рабочих дней.
Ситуация с проблемой — библиотечная система
Местная публичная библиотека сталкивается с проблемами в своей системе онлайн-каталога. Система в течение последней недели периодически отключалась, вызывая раздражение как у персонала библиотеки, так и у посетителей. Некоторые посетители сообщили, что не могут искать книги, в то время как другие отметили, что не могут продлить срок пользования выданными материалами онлайн.
Персонал библиотеки получает большое количество телефонных звонков и личных обращений по поводу сбоя системы, что приводит к задержкам в других библиотечных услугах. Кроме того, сотрудники заметили, что система работает медленно даже тогда, когда она работает, что вызывает дополнительное раздражение как у персонала, так и у посетителей.
IT-отдел библиотеки работает над выявлением и устранением проблемы, но пока не смог полностью восстановить функциональность системы. В это время персонал библиотеки вручную выдает и продлевает материалы для посетителей, что занимает значительное количество времени и вызывает задержки в других задачах.
Директор библиотеки запросил у IT-отдела сроки, когда система будет полностью функциональной, а также план по предотвращению подобных проблем в будущем. Директор также рассматривает возможность привлечения консультанта для оценки общей технологической инфраструктуры библиотеки и предоставления рекомендаций по улучшению.
Определение кандидатских вариантов использования на основе сценария проблемы
Чтобы определить список кандидатских вариантов использования на основе сценария проблемы, можно следовать этим шагам:
- Определите основных участников в сценарии проблемы. Участники — это люди, организации или системы, взаимодействующие с разрабатываемой системой.
- Для каждого участника определите его цели или задачи. Что участник хочет достичь, используя систему?
- Определите различные способы, с помощью которых участник взаимодействует с системой для достижения своих целей. Это может включать действия, которые он выполняет, информацию, которую он предоставляет, или информацию, которую он получает от системы.
- Для каждого взаимодействия определите конкретный вариант использования, который его описывает. Вариант использования — это описание конкретного взаимодействия между участником и системой, и он обычно включает набор шагов или действий, которые участник предпринимает для достижения своей цели.
- Проверьте и уточните список кандидатских вариантов использования, чтобы убедиться, что они полные, релевантные и не дублируются. Возможно, потребуется объединить или разделить варианты использования, либо удалить те, которые не являются необходимыми для системы.
В целом, цель определения списка кандидатских вариантов использования заключается в том, чтобы обеспечить соответствие системы потребностям и требованиям всех заинтересованных сторон, а также предоставить четкий и полный набор функций и возможностей, которые позволяют им достигать своих целей.
Вот некоторые кандидатские варианты использования для библиотечной системы:
- Поиск в каталоге: Посетители могут искать книги, DVD и другие материалы в библиотечном каталоге.
- Постановка на сохранение: Посетители могут поставить на сохранение предмет, который в настоящее время выдан или еще не доступен.
- Выдача материалов: Посетители могут брать книги, DVD и другие материалы из библиотеки.
- Продление срока пользования: Посетители могут продлить срок пользования выданными материалами онлайн или лично.
- Оплата штрафов: Посетители могут оплатить любые штрафы или сборы, которые им должны библиотеке.
- Запрос межбиблиотечного займа: Посетители могут запросить выдачу материалов из другой библиотеки, не входящей в их местную систему.
- Управление информацией о личном счете: Посетители могут управлять своей личной информацией, например, обновлять свой адрес или номер телефона.
- Управление историей чтения: Посетители могут отслеживать прочитанные книги и оставлять отзывы или оценки.
- Управление списком желаний: Посетители могут создать список книг, которые хотят прочитать, и получать уведомления, когда они станут доступны.
- Получение уведомлений: Посетители могут получать уведомления о том, когда их сохраненные материалы станут доступны или когда срок пользования выданными материалами скоро истечет.
Как определить участников
Чтобы определить участников и связать их с вариантами использования как основными и второстепенными участниками, можно следовать этим шагам:
- Определите основных заинтересованных сторон, которые будут взаимодействовать с системой. К ним могут относиться пользователи, администраторы, клиенты и другие стороны, которые будут использовать систему или на которую она повлияет.
- Для каждого заинтересованного лица определите его основные цели и задачи при использовании системы. Что они пытаются достичь, используя систему? Это поможет вам определить основные варианты использования для каждого заинтересованного лица.
- Определите любые дополнительные цели или задачи, которые может иметь заинтересованное лицо, но которые не являются центральными для их основных сценариев использования. Эти цели могут включать взаимодействие с другими заинтересованными сторонами или подсистемами в системе, или быть связанными с администрированием или обслуживанием системы. Это поможет вам определить второстепенных участников и соответствующие им сценарии использования.
- Определите любые взаимодействия между основными и второстепенными участниками, а также между участниками и системой. Эти взаимодействия могут включать обмен данными, передачу информации или запуск действий в системе. Это поможет вам определить границы и охват сценариев использования.
- Создайте список сценариев использования и участников, и свяжите каждый сценарий с его основными и второстепенными участниками. Это поможет вам убедиться, что все заинтересованные стороны учтены в модели сценариев использования, и что система разработана с учетом потребностей всех пользователей и администраторов.
Цель выявления участников и их связывания со сценариями использования — создать четкое и полное представление о функциональности системы, а также обеспечить учет всех заинтересованных сторон в процессе проектирования и разработки. Это поможет обеспечить соответствие окончательной системы потребностям и требованиям всех пользователей и администраторов.
Вот таблица, резюмирующая список кандидатских сценариев использования для библиотечной системы, а также связанных с ними участников и целей:
| Сценарий использования | Основной участник | Второстепенный(е) участник(и) | Цель сценария использования |
|---|---|---|---|
| Поиск в каталоге | Пользователь | Нет | Позволить пользователям искать книги, DVD и другие материалы в библиотечном каталоге. |
| Поставить резерв | Пользователь | Нет | Позволить пользователям бронировать предмет, который в настоящее время находится в аренде или еще не доступен. |
| Выдать материалы | Пользователь | Персонал библиотеки | Позволить пользователям брать в аренду книги, DVD и другие материалы из библиотеки. |
| Продлить срок пользования | Пользователь | Персонал библиотеки | Позволить пользователям продлить срок возврата своих выданных материалов. |
| Оплатить штрафы | Пользователь | Нет | Позволить пользователям оплатить все штрафы или сборы, которые они должны библиотеке. |
| Запрос межбиблиотечного займа | Пользователь | Персонал межбиблиотечного абонемента | Позволить пользователям запрашивать материалы для получения из другой библиотеки, не входящей в их местную систему. |
| Управление информацией о счете | Пользователь | Нет | Позволить пользователям управлять своей личной информацией, например, обновлять свой адрес или номер телефона. |
| Управление историей чтения | Пользователь | Нет | Позволить пользователям отслеживать прочитанные книги и оставлять отзывы или оценки. |
| Управление списком желаемого | Пользователь | Нет | Позволить пользователям создавать список желаемых книг, которые они хотят прочитать, и получать уведомления, когда они станут доступны. |
| Получение уведомлений | Пользователь | Нет | Позволить пользователям получать уведомления о том, когда их резервированные материалы станут доступны или когда выданные им предметы скоро должны быть возвращены. |
Приоритизация вариантов использования
Приоритизация вариантов использования — важный этап в процессе разработки программного обеспечения, поскольку он помогает обеспечить, что наиболее важные и ценные функции системы будут разработаны в первую очередь. Приоритизация помогает сосредоточить усилия и ресурсы команды разработки на тех функциях, которые принесут наибольшую пользу конечным пользователям и заинтересованным сторонам системы.
Вот приоритетный список вариантов использования от наиболее важного к наименее важному, вместе с полем приоритета:
| Вариант использования | Основной участник | Второстепенные участники | Цель варианта использования | Приоритет |
|---|---|---|---|---|
| Выдача материалов | Пользователь | Персонал библиотеки | Разрешить читателям брать книги, DVD и другие материалы из библиотеки. | 1 |
| Поиск в каталоге | Читатель | Нет | Разрешить читателям искать книги, DVD и другие материалы в библиотечном каталоге. | 2 |
| Поставить резерв | Читатель | Нет | Позволить читателям бронировать предмет, который в настоящее время находится в наличии или еще не доступен. | 3 |
| Продлить материалы | Читатель | Персонал библиотеки | Разрешить читателям продлить срок возврата своих выданных материалов. | 4 |
| Запросить межбиблиотечный заём | Читатель | Персонал межбиблиотечного заёма | Позволить читателям запрашивать материалы из другой библиотеки, не входящей в их местную систему. | 5 |
| Оплатить штрафы | Читатель | Нет | Разрешить читателям оплатить все штрафы или сборы, которые они должны библиотеке. | 6 |
| Получать уведомления | Читатель | Нет | Позволить читателям получать уведомления о том, когда их резервированные предметы станут доступными или когда их выданные предметы скоро должны быть возвращены. | 7 |
| Управление информацией о счете | Читатель | Нет | Позволить читателям управлять своей личной информацией, например, обновлять свой адрес или номер телефона. | 8 |
| Управление списком желаний | Читатель | Нет | Позволить читателям создавать список желаний книг, которые они хотят прочитать, и получать уведомления, когда они станут доступными. | 9 |
| Управление историей чтения | Читатель | Нет | Позволить читателям отслеживать книги, которые они прочитали, и оставлять отзывы или оценки. | 10 |
Обратите внимание, что порядок приоритетов может различаться в зависимости от конкретных потребностей и целей библиотечной системы, и это всего лишь один из возможных вариантов приоритизации, основанный на общих потребностях пользователей библиотек.
Сформировать команду и оценить стоимость
Например,
Чтобы оценить стоимость человеческих ресурсов на шестимесячный период в Гонконге, необходимо учитывать должности и минимальные и средние диапазоны зарплат для каждой должности.
Вот оценка стоимости для команды из 10 человек, исходя из минимального количества персонала и среднего значения диапазона средних зарплат:
- Менеджер проекта:
- Минимальная месячная зарплата: 35 000 гонконгских долларов
- Средняя месячная зарплата: 60 000 гонконгских долларов
- Ориентировочная стоимость за 6 месяцев (минимальная зарплата): 210 000 гонконгских долларов
- Ориентировочная стоимость за 6 месяцев (средняя зарплата): 360 000 гонконгских долларов
- Владелец продукта:
- Минимальная месячная зарплата: 25 000 гонконгских долларов
- Средняя месячная зарплата: 45 000 гонконгских долларов
- Ориентировочная стоимость за 6 месяцев (минимальная зарплата): 150 000 гонконгских долларов
- Ориентировочная стоимость за 6 месяцев (средняя зарплата): 270 000 гонконгских долларов
- Мастер скрама:
- Минимальная месячная зарплата: 25 000 гонконгских долларов
- Средняя месячная зарплата: 45 000 гонконгских долларов
- Ориентировочная стоимость за 6 месяцев (минимальная зарплата): 150 000 гонконгских долларов
- Ориентировочная стоимость за 6 месяцев (средняя зарплата): 270 000 гонконгских долларов
- Дизайнер пользовательского интерфейса/юзабилити:
- Минимальная месячная зарплата: 20 000 гонконгских долларов
- Средняя месячная зарплата: 35 000 гонконгских долларов
- Ориентировочная стоимость за 6 месяцев (минимальная зарплата): 120 000 гонконгских долларов
- Ориентировочная стоимость за 6 месяцев (средняя зарплата): 210 000 гонконгских долларов
- Разработчики:
- Минимальная месячная зарплата: 18 000 гонконгских долларов
- Средняя месячная зарплата: 30 000 гонконгских долларов
- Ориентировочная стоимость за 6 месяцев (минимальная зарплата): 540 000 гонконгских долларов (при условии 6 разработчиков)
- Ориентировочная стоимость за 6 месяцев (средняя зарплата): 900 000 гонконгских долларов (при условии 6 разработчиков)
- Инженер по обеспечению качества/тестированию:
- Минимальная месячная зарплата: 18 000 гонконгских долларов
- Средняя месячная зарплата: 30 000 гонконгских долларов
- Ориентировочная стоимость за 6 месяцев (минимальная зарплата): 108 000 гонконгских долларов
- Ориентировочная стоимость за 6 месяцев (средняя зарплата): 180 000 гонконгских долларов
- Инженер DevOps:
- Минимальная месячная зарплата: 20 000 гонконгских долларов
- Средняя месячная зарплата: 35 000 гонконгских долларов
- Ориентировочная стоимость за 6 месяцев (минимальная зарплата): 120 000 гонконгских долларов
- Ориентировочная стоимость за 6 месяцев (средняя зарплата): 210 000 гонконгских долларов
Предполагая минимальный диапазон зарплат, общая стоимость команды из 10 человек за 6 месяцев составит примерно 1 308 000 гонконгских долларов. Предполагая среднее значение диапазона средних зарплат, общая стоимость составит примерно 2 400 000 гонконгских долларов. Обратите внимание, что это лишь ориентировочная оценка, и фактическая стоимость может варьироваться в зависимости от конкретных деталей проекта и условий компенсации, согласованных с каждым членом команды.
Создать план разработки по методологии Agile
Вот план разработки по методологии Agile для системы библиотеки с командой, предложенной выше, при условии 10 спринтов, каждый из которых длится 10 рабочих дней:
Спринт 1 (дни 1-10):
- Провести встречу по запуску проекта
- Разработать пользовательские сценарии и приоритизировать бэклог
- Создать макеты основных экранов
- Настроить среду разработки
- Начать разработку системы аутентификации и авторизации пользователей
Спринт 2 (дни 11-20):
- Завершить разработку системы аутентификации и авторизации пользователей
- Начать разработку функциональности поиска книг
- Начать разработку функциональности выдачи книг
- Провести обзор макетов с заинтересованными сторонами и внести необходимые изменения
Спринт 3 (дни 21-30):
- Завершить разработку функциональности поиска книг
- Завершить разработку функциональности выдачи книг
- Начать разработку функциональности возврата книг
- Начать разработку функциональности бронирования книг
Спринт 4 (дни 31-40):
- Завершить разработку функциональности возврата книг
- Завершить разработку функциональности бронирования книг
- Начать разработку функциональности профиля пользователя
- Начать разработку функциональности рекомендаций книг
Спринт 5 (дни 41-50):
- Завершить разработку функциональности профиля пользователя
- Завершить разработку функциональности рекомендаций книг
- Начать разработку функциональности отзывов и оценок книг
- Начать разработку административной панели для библиотекарей
Спринт 6 (дни 51-60):
- Завершить разработку функциональности отзывов и оценок книг
- Завершить разработку административной панели для библиотекарей
- Начать разработку функциональности покупки книг и управления инвентарём
- Начать разработку функциональности управления штрафами
Спринт 7 (дни 61-70):
- Завершить разработку функциональности покупки книг и управления запасами
- Завершить разработку функциональности управления штрафами
- Начать разработку функциональности отчетности и аналитики
- Начать разработку мобильного приложения
Спринт 8 (дни 71-80):
- Завершить разработку функциональности отчетности и аналитики
- Завершить разработку мобильного приложения
- Начать разработку интеграции с внешними системами (например, платежный шлюз)
Спринт 9 (дни 81-90):
- Завершить разработку интеграции с внешними системами
- Начать тестирование и устранение ошибок
- Начать тестирование приемки пользователем
- Начать разработку документации и учебных материалов
Спринт 10 (дни 91-100):
- Завершить тестирование и устранение ошибок
- Завершить тестирование приемки пользователем
- Завершить разработку документации и учебных материалов
- Провести развертывание системы
- Провести финальный обзор и ретроспективу
Это всего лишь пример плана разработки по методологии Agile для библиотечной системы, и фактический план может отличаться в зависимости от конкретных потребностей проекта и прогресса команды в каждом спринте.
Пример проектного предложения – библиотечная система
Проектное предложение: разработка по методологии Agile для библиотечной системы
Введение: Мы рады представить проект разработки по методологии Agile для комплексной библиотечной системы, которая отвечает потребностям как библиотекарей, так и посетителей библиотеки. Предлагаемая система обеспечит плавный поиск, выдачу, возврат, бронирование, покупку, управление запасами и штрафами для посетителей, а также административную панель, отчетность и аналитические возможности для библиотекарей. Предлагаемый проект по методологии Agile гарантирует, что система будет соответствовать потребностям всех заинтересованных сторон и будет доставлена в ожидаемые сроки.
Цели проекта: цель данного проекта — разработать библиотечную систему, которая удобна в использовании, эффективна и надежна в управлении библиотечными операциями. Система предоставит следующие функции и возможности:
- Функциональность поиска книг, выдачи, возврата, бронирования, покупки, управления запасами и штрафов для посетителей.
- Административная панель, отчетность и аналитические возможности для библиотекарей.
- Безупречная интеграция с библиотечными системами и базами данных.
- Настраиваемые пользовательские интерфейсы как для посетителей, так и для библиотекарей.
Методология проекта: для достижения целей проекта мы будем использовать методологии разработки по Agile. Разработка по Agile — это итеративный и совместный подход, который акцентирует внимание на непрерывной обратной связи, гибком планировании и быстрой доставке. Он отлично подходит для сложных проектов с изменяющимися требованиями, таких как библиотечная система.
Методология разработки по Agile будет реализована через серию спринтов, каждый из которых длится 10 рабочих дней. Мы будем использовать фреймворк Scrum, который является популярной методологией Agile, акцентирующей внимание на регулярных встречах, четкой коммуникации и поэтапной разработке.
График проекта: проект будет завершен за 10 спринтов, каждый из которых длится 10 рабочих дней. График следующий:
- Спринт 1: Разработка макетов, аутентификация пользователей.
- Спринт 2: Функции поиска и просмотра книг.
- Спринт 3: Функции выдачи и возврата книг.
- Спринт 4: Функции бронирования и покупки книг.
- Спринт 5: Функции управления запасами и отчетности.
- Спринт 6: Функции управления штрафами.
- Спринт 7: Функции административной панели.
- Спринт 8: Функции отчетности и аналитики.
- Спринт 9: Тестирование, документирование и развертывание.
- Спринт 10: Финальное тестирование, документирование и развертывание.
Команда проекта: команда проекта будет состоять из следующих ролей:
- Менеджер проекта
- Scrum-мастер
- Владелец продукта
- Разработчики (2–3)
- Инженер по обеспечению качества
- Технический писатель
Команда проекта будет отвечать за разработку, тестирование, документирование и развертывание библиотечной системы. Менеджер проекта будет контролировать ход проекта, а Scrum-мастер будет обеспечивать соблюдение фреймворка Scrum. Владелец продукта будет представлять заинтересованные стороны и обеспечивать удовлетворение их потребностей, а разработчики будут создавать систему. Инженер по обеспечению качества будет контролировать соответствие системы стандартам качества, а технический писатель будет документировать систему.
Бюджет: общая стоимость проекта составит 2 000 000 гонконгских долларов. В нее входят затраты на человеческие ресурсы, аппаратное и программное обеспечение, а также любые сторонние услуги, необходимые для проекта.
Заключение: Мы считаем, что предложенный проект разработки по Agile для библиотечной системы приведет к созданию эффективной, эффективной и удобной для пользователей системы, отвечающей потребностям как читателей, так и библиотекарей. Мы с нетерпением ждем возможности обсудить этот проект с вами и рады работать с вами над созданием успешной библиотечной системы.
Пример — график оплаты
Вот график оплаты для предложенного проекта библиотечной системы:
- 20% от общей стоимости (400 000 гонконгских долларов) при начале проекта и подписании контракта.
- 30% от общей стоимости (600 000 гонконгских долларов) после завершения спринта 5 и принятия клиентом предоставленных функций.
- 30% от общей стоимости (600 000 гонконгских долларов) после завершения спринта 8 и принятия клиентом предоставленных функций.
- 20% от общей стоимости (400 000 гонконгских долларов) после успешного развертывания системы в среде клиента и принятия клиентом финального продукта.
Пожалуйста, сообщите нам, если у вас есть какие-либо вопросы или замечания по поводу этого графика оплаты.
Благодарим вас за рассмотрение нашего предложения.
С уважением, [Ваше имя]
Пример – образец сопроводительного письма для запроса одобрения проекта
Уважаемый [Клиент],
Мы рады представить наше предложение по разработке комплексной библиотечной системы. Предлагаемый нами проект по методологии Agile обеспечит удобный и эффективный поиск, выдачу, возврат, бронирование, покупку, управление инвентарем и штрафами для читателей, а также предоставит библиотекарям административную панель, отчетность и аналитические возможности.
Предлагаемая нами методология разработки по Agile обеспечит соответствие системы потребностям всех заинтересованных сторон и ее доставку в ожидаемые сроки. Мы будем использовать фреймворк Scrum для обеспечения регулярных встреч, четкой коммуникации и поэтапной разработки. Команда проекта будет состоять из менеджера проекта, Scrum-мастера, владельца продукта, разработчиков, инженера по обеспечению качества и технического писателя.
Проект будет завершен за 10 спринтов, каждый из которых длится 10 рабочих дней. Общая стоимость проекта составит 2 000 000 гонконгских долларов.
Мы уверены, что предлагаемая нами библиотечная система значительно повысит эффективность и результативность работы вашей библиотеки, и мы с нетерпением ждем возможности обсудить наше предложение с вами более подробно.
Благодарим вас за рассмотрение нашего предложения. Мы с нетерпением ждем возможности работать с вами над созданием успешной библиотечной системы.
С уважением, [Ваше имя]
Краткое содержание
Описанная в этой статье библиотечная система представляет собой комплексную платформу, которая предоставляет читателям функции поиска книг, выдачи, возврата, бронирования, покупки, управления инвентарем и штрафами, а библиотекарям — административную панель, отчетность и аналитические возможности. План разработки разделен на 10 спринтов, каждый из которых длится 10 рабочих дней, и охватывает все этапы — от разработки прототипов и аутентификации пользователей до тестирования, документирования и развертывания. Следуя этому плану разработки по Agile, библиотечная система может быть успешно и эффективно завершена с учетом удовлетворенности всех заинтересованных сторон итоговым результатом.