Skip to content

Home

Jump to bottom
Artsiom Platkouski edited this page Feb 12, 2021 · 3 revisions

RSClone

Обязательно к прочтению

Пререквезит

  • Создать приватный репозиторий
    • Repository name rsclone
    • пригласить остальных участников команды
    • название ветки, в которой ведётся разработка - develop
    • ветка master пустая, содержит только README.md
  • Выбрать тему проекта: https://pro.trackingtime.co/#/tasks/date
  • Кол-во участников: от 2 до 4;
  • Заполнить таблицу
  • Разбить работу на спринты
  • Каждая команда ведет Trello board - Github Project
  • README.md:
    • содержит список фич, которые были реализованы (source)
    • нужно добавить инструкцию по запуску приложения
    • описание библиотек, фреймворков, технологий, которые были задействованы в процессе разработки приложения, их преимущества и недостатки

Общие требования

Группа Баллы Наименование фичи
UI 20 hot keys
UI 10-20 интерфейс на нескольких языках
UI 10 модальный диалог
UI 20 Routing (source)
UI 20 Пользовательские настройки
UI 20 3+ анимации
UI 20 Bootstrap
UI 10-20-30 работает на телефоне/планшете/PC
Приложение 30 работать на нескольких вкладках
Приложение 20 Возможность добавлять либо настраивать дополнительные окна
Приложение 20 статистика
Приложение 40 Контекстное меню или выделение элементов
Тех.стек 20 Canvas/WebGL/etc
Тех.стек 10 Работа с Audio API
Тех.стек 20 Unit test (source): Jest (describe, it)
Тех.стек 10 webpack
Тех.стек 10 использование Local storage
Тех.стек 40 TypeScript (source)
Код 20 Flow-patterns: Redux (source)
Код 10 eslint, eslint-config-airbnb-base
Код 20 Понятный чистый код (source)
Back-end 30 RESTful API
Back-end 30 работа с БД
Back-end 20 Аутентификация
Back-end 20 статистику/графики/таблицы, данные для которых получает от бекенда
Back-end 40 Реализован nodejs и express
Доп. 40 Сетевой режим

Back-end

  • Запрос должен возвращать корректный ответ в том числе на ошибку (source)

Первый спринт

  • Выбрать стек технологий
    • Angular / React / Vue
    • Bootstrap/Material UI/Ant design/etc
    • css фреймворки, html и css препроцессоры (SCSS)
    • встроенные API браузера: Canvas (?), WebGL, SoundAPI и другие
    • графические движки: Threejs, Phaser, Pixi, Babylon
    • рекомендуется использовать TypeScript
    • рекомендуется создать и использовать бекенд: nodejs vs express (source)
  • получить MVP

Второй спринт

Третий спринт

  • подготовить README.md

Четвёртый спринт

  • демо-версия приложения размещается на gh-pages
  • создать и выложить на youtube видео с обзором приложения
  • написать и выложить на medium статью о разработке приложения
    • прикрепить к статье ссылку на видео на youtube
    • добавить changelog: , кто какие тикеты заимплементил (source, source)
  • создать pull request из ветки develop в ветку master (см. требования к pull request)
    • добавить ссылку на статью на medium
    • ссылку на видео
    • описание фич
    • ссылку на видео, в котором демонстрируются все реализованные фичи
    • ссылку на репозиторий с back-end’ом
  • сделать репозиторий публичным

Deadline

  • провести презентацию своего проекта

Анализ требований

Терминология

Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет

Спринт ~ sprint — итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени Пользователь ~ user - клиент, который взаимодействует с системой непосредственно или косвенно (например, пользуется результатами работы системы. хотя не генерирует эти результаты). Также называется конечным пользователем

Пользовательская история ~ user story - способ выражения пользовательских требований в проектах гибкой разработки в форме одного или двух предложений, формирующих потребность пользователя или описывающих единицу необходимой функциональности, а также говорящих о пользе, какую эта функциональность приносит пользователю

Активности бизнес-аналитика (см. BABOK)

  • Планирование: План работе по бизнес-анализу на Проекте N
    • +изучения доменной области
    • +выявления заинтересованных лиц: список заинтересованных лиц включающих контакты, удобное время для контакта, а также зону ответственности
    • +коммуникации. Организация:
      • место встречи
      • формат мероприятия
      • предварительная подготовка к коммуникация
    • +выявлений требований. Задание вопросов с предложением вариантов: матрица требований, нумерованный список и т.п.
    • +анализа
    • +документирования. Запись требования для разработчика:
      • формат “Вариант использования” (use case) - хорошо подходит для описания процессов
      • “Пользовательская история” (user story): критерии приёмки (Acceptance Criteria) - легко читается, легко изменяется при необходимости, но не показывает общую картину (на одну User Stroy 4-5 AC, max 10 AC)
      • Вопрос-варианты ответов
      • Схемы, графики, таблицы
      • интеграционная спецификация (блок-схема, макет) - при интеграции (см. на GDrive)

Пользовательская история (user story)

Набор пользовательских историй (Feature) (10-12 US, max 20 US) - содержит описание общего функционала, который используется для входящих в набор пользовательских историй. И описание места каждой “user story” в наборе

https://advancedanalyst.com/2017/04/14/business-analysis-role/#more-847

Пользовательские истории — это не требования

Несмотря на то, что стори играют в огромной степени роль, ранее принадлежавшую спецификациям требований (SRS), сценариям использования и т. п., они все же ощутимо отличаются рядом тонких, но критических нюансов:

  • Они не являются детальным описанием требований (то-есть того, что система должна бы делать), а представляют собой скорее обсуждаемое представление намерения (нужно сделать что-то вроде этого)
  • Они являются короткими и легко читаемыми, понятными разработчикам, стейкхолдерам и пользователям
  • Они представляют собой небольшие инкременты ценной функциональности, которая может быть реализована в рамках нескольких дней или недель
  • Они относительно легко поддаются эстимированию, таким образом, усилия, необходимые для реализации, могут быть быстро определены
  • Они не занимают огромных, громоздких документов, а скорее организованы в списки, которые легче упорядочить и переупорядочить по ходу поступления новой информации
  • Они не детализированы в самом начале проекта, а уже более детально разрабатываются «точно в срок», избегая таким образом слишком ранней определенности, задержек в разработке, нагромождения требований и чрезмерно ограниченной формулировки решения
  • Они требуют минимум или вовсе не требуют сопровождения и могут быть безопасно отменены после имплементации(3)

User story вкратце описывает:

  • человека, использующего систему (заказчик);
  • то, что должно содержаться в данной системе (примечание);
  • то, для чего она нужна пользователю (цель).

Пример user story

  1. Как посетитель сайта я хочу видеть изображение просматриваемого товара чтобы иметь визуальное представление о товаре

  2. Как посетитель сайта я хочу иметь возможность приблизить любую область на изображении товара чтобы детально изучить внешний вид товара

Кто? "Как ..." Что нужно? Я хочу ... Зачем? Чтобы ...

Clone this wiki locally