Здравствуйте, у нас достаточно большой поток разнообразных проектов.
В какой-то момент нам пришла в голову блестящая идея создать внутренний устав управления проектами, с которым согласен каждый член команды.
Есть надежда, что это снизит затраты, повысит качество и уменьшит количество путаницы, облегчит введение новых «игроков» и вообще в качестве системы управления проектами был выбран Redmine, и надо сказать даже в стандартной установке эта штука корректно решает за вас многие вопросы: разделение на Ошибки\Улучшения, интеграция с Git, журнал действий, подпроекты, удобная Wiki и т.д. Каждое приложение — это один проект в формате Redmine. Например, мобильное приложение «Поиск свежего хлеба».
Скорее всего, приложение будет иметь три стороны: веб, Android и iOs, тогда структура проекта будет выглядеть так:
Основное - веб (все организационные вопросы есть) Подпроект 1 – iOS Подпроект 2 – Android Задачи внутри проекта Стандартный процесс статусов задач (М.- менеджер, П.
- программист): М.
Создано → Ф.
В работе → П.
Решено → М.
Закрыто.
( М.
при необходимости изменить на К – клиент ) Уточнение параметров задачи: М.
Создано → П.
Обратная связь → М.
Обратная связь → П.
В работе.
Тип задач: Ошибка — исправление ошибок, Поддержка — плановые работы, Улучшение — работы, не включенные в первоначальный план.
Маленькая, но емкая в Вики.
Например: FTP-доступ, контакты участников команды и т. д. Другими словами, информация административного характера.
Redmine — это стремление построить единое информационное пространство, в котором вся необходимая информация доступна каждому члену команды.
Гит Обязательная ссылка на фиксацию задачи.
Если есть возможность, следуйте правилу одной выполненной задачи — привязанного коммита.
И соответственно, наоборот, к каждому коммиту прикрепляется задача.
При описании коммита (commit -m) указывайте идентификатор задачи — «refs #Issue ID».
Миграция базы данных Программист создает в корне проекта файлmigration.sql, содержащий инструкции по созданию базы данных.
Файловое хранилище Файлы — хранение файлов внутри каталога проекта.
PSD и PDF в соответствующих папках основного проекта (дизайн и пользовательский интерфейс).
Таким образом сохраняется история рисования; на жестком диске нет пустой траты места).
Описание тест-кейсов.
По ходу проекта менеджер и программист описывают сценарии тестирования приложения.
В конце каждого микро-релиза проводится регрессионное тестирование проекта в конце спринта.
На основании выполненных в релизе задач документ дополняется.
Вехи Мы поддерживаем идеологию непрерывной интеграции; В начале проекта руководитель проекта оценивает ключевые этапы разработки проекта.
И отмечает их на оперативном плане.
Например, «Возможна регистрация пользователя» 15 мая.
Таким образом, вы сможете примерно оценить длительность проекта, стоимость и загруженность специалистов.
Не проверено на практике Спринт Продолжительность спринта для каждого проекта варьируется от 3 до 5 рабочих дней и устанавливается индивидуально для каждой команды.
В начале спринта команда совместно выбирает задачи для следующей итерации (с учетом назначенного приоритета и личной заинтересованности в задаче).
В конце спринта команда встречается для «ретроспективы», обсуждая прогресс предыдущего спринта; как правило, это занимает не более 20 минут. Итак, на входе есть задачи, они решаются в процессе спринта, и в результате мы получаем рабочие интерфейсы.
Если в ходе спринта задача не решена, программист описывает причину в комментариях.
В конце каждого спринта команда проводит регрессионное тестирование.
Алгоритм реализации проекта Инициализация проекта в Redmine. Разработка пользовательского интерфейса.
На форуме проекта откроется тема пользовательского интерфейса.
PDF-файл прикрепляется непосредственно к сообщению на форуме; Обратите внимание, что обсуждения UI на форуме не отменяют встречи в офисе.
После завершения и согласования пользовательского интерфейса в разделе «Файлы» появится файл «Final UI.pdf».
Менеджер проекта начинает первый спринт, используя параллельные процессы проектирования и программирования.
В оперативный план входит: дата завершения спринта, версия 0.1. Для обсуждения дизайна на форуме создается ветка; В обсуждении участвуют следующие участники: менеджер, дизайнер, ui-специалист. Как и в случае с пользовательским интерфейсом, форум не отменяет живые встречи.
Результат согласовывается, и в разделе «Файлы» появляется файл «Окончательный ПРОЕКТ».
Вид верстки и программирования заслуживают отдельной статьи.
P.S. Итак, %username%, я обращаюсь к вам.
Все пункты проверены на практике и написаны кровью.
Но если бы вы могли поделиться немного мудростью, я был бы очень благодарен.
Особенно интересует, как вы используете Redmine, есть ли в вашей команде стандарты кодирования? Теги: #менеджмент качества #веб-студия #работа в команде #статья без картинок и девушек #разработка сайтов #php
-
Другой Тип Компьютерщика
19 Oct, 24 -
Обзор Тенденций На Рынке Видеорегистраторов
19 Oct, 24
