Главное Свежее Вакансии Образование
118 3 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Проект, который построил Джек

Оценка работы. Работа со спринтами. Подготовительный процесс перед стартом.

Зачем и почему

Работа над проектом идёт от спринта к спринту. В конце каждого спринта нужно представить продукт с определённым функционалом. Для этого разработчики перед началом спринта формируют список задач, которые должны включать в себя всю работу по реализации ожидаемого функционала. Чтобы правильно составить этот список, у команды должно быть понимание того, какую работу предстоит сделать вообще и что нужно сделать в первую очередь, чтобы не метаться от задачи к задаче, а делать их одну за другой.

Лестница к светлому будущему

Получение представления о конечном продукте

На первом этапе надо узнать о заказчика как можно больше о том, что он хочет иметь в результате. Поскольку он может и не знать этого, или иметь туманные представления, то вопросы нужно задавать в форме утверждений. Неправильно: какие роли будут у пользователей? Правильно: предложить к рассмотрению список ролей и охарактеризовать каждую. Выбор технологий и первоначальная оценка

На данный момент у команды есть список общих утверждений о системе. Этот список используется как исходная информация для выбора технологий реализации. Выбрав технологии, команда может назвать первичную оценку проекта с учётом времени на освоение технологий, если это потребуется. После того, как заказчик согласится с общей первичной оценкой, можно переходить к составлению требований.Требования

Требование должно давать ясное представление о тех возможностях, которые имеет пользователь программной системы, и включать инструкции по их использованию. Инструкция должна состоять из последовательности простых шагов. Рекомендуется такая структура:

  1. Исходное состояние: первый пункт состоит из описания начального состояния системы. Указывается пользователь, его роль, другие данные, которые можно задать в рамках программной системы.
  2. Описание действий строится так: Глагол действия + объект воздействия = результат. Пример: Наводит курсор мыши на поле — появляется подсказка.
  3. Конечное состояние: описываются данные, которые должны были измениться в результате проведённых действий.

После того, как требований было написано достаточно много для реализации хотя бы части функционала, можно приступать к подготовке платформы.Файловая структура

Большинство решаемых веб-программистами задач укладываются в рамки старых проверенных абстракций. Данные хранятся в моделях, раздаются через контроллеры, отрисовываются через шаблоны. Чтобы не заниматься постоянным рефакторингом вместо реализации бизнес-логики, команде лучше заранее договориться о файловой структуре проекта. Разработчик не должен выбирать место, в котором его код будет смотреться лучше всего — он должен знать это наверняка, исходя из принятой конвенции. Спорные случаи можно обсудить на код ревью.Деплой приложения

После того, как команда примет решение о структуре проекта, необходимо перейти к выбору стратегии размещения приложения и работы с ним в режиме разработки и в продакшн режиме. Такие фреймворки как Meteor, Loopback имеют встроенные системы деплоя и мониторинга приложений. Однако, деплой на продакшне всегда отличается от запуска на локальной машине — приложение на продакшн почти всегда работает со сторонними сервисами и его доступность не должна зависеть от них. Веб-приложение не должно падать при возникновении программной ошибки — оно должно отдавать ошибку клиенту, записывать в логи подробности, откатывать транзакцию в БД при необходимости и продолжать работать дальше. Однако, приложения падают, и поднимать их помогают такие утилиты, как, например, forever.Взаимодействие с пользователями

Разработчик должен знать, как и кем будет использоваться конечный продукт, для того, чтобы реализовать подходящие под задачу интерфейсы связи с приложением. В случае реализации публичного HTTP API большое внимание нужно уделять вопросам безопасности и проводить нагрузочные тестирования для выявления подводных камней в архитектуре или просто банальных ошибок.

Приложение всегда имеет пользователей. Схема авторизации должна быть изучена перед началом работы и быть прозрачной для разработчиков. Систему прав желательно делать максимально гибкой и расширяемой, отдавая предпочтение проверенным решениям.

Система прав заслуживает отдельный абзац. Обычно, приложение делится на две части — одни методы доступны публично, другие — только после авторизации. Делать специальные «админские» методы неправильно — у команды всегда есть доступ к серверу для запуска нужных скриптов напрямую. Надо учитывать возможность появляения дополнительных «уровней» авторизации и представлять себе как это может быть реализовано. С другой стороны, надо помнить о том, что разграничение по правам может потребоваться во время отдачи/получения данных. Это означает, что автоматические отдача или сохранение всех полученных от клиента полей зачастую нежелательны. Если есть возможность где-то прописать доступ к полям модели в зависимости от действия (добавление, изменение, получение) и роли пользователя — лучше делать это сразу. Это позволит избежать непонимания и путаницы, сделает правила доступа прозрачнее.

Тесты и тестовые данные

Тестовые данные должны создаваться по мере реализации функционала, использующего их. При ручном составлении данные придётся обновлять после каждой миграции. Поэтому предлагается к изучению подход к генерации данных фабриками.

В том случае, когда разработчику доступна роскошь писать тесты, нужно ей пользоваться на максимум. Нет ничего сложного в том, чтобы настроить сервер для Continous Integration и запускать тесты после каждого коммита.

Вывод

Итак, чтобы начать оценивать спринты и работать по ним, нужно убедиться, что все предварительные шаги были сделаны:

  • Была выбрана платформа (фреймворк, библиотеки)
  • Решены вопросы деплоя приложения (как, куда, чем отличается продакшн от дев деплоя)
  • Определились с методологией тестирования (не писать тесты — тоже методология, просто она самая плохая)
  • Поняли каким образом добавлять тестовые данные и в какой момента запуска приложения это нужно делать (после инициации фреймворка и до старта веб-сервера например)
  • Определили использумые приложением сторонние сервисы и выбрали способы взаимодействия (прочитали доки к сторонним API, потыкали их простейшими HTTP-клиентами)
  • Поняли, какой будет API (защищённый, с возможностью авторизации, открытый)
  • Выбрали систему авторизации и проверки прав пользователей

Если по каждому из этих пунктов разработчики могут дать внятный аргументируемый ответ — можно приступать к работе спринтами. Если нет — то высока вероятность того, что разработчики будут заниматься именно этими пунктами вместо того, что прописано в тикете. Потому что они такие

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Автоматизация бизнеса.
Разработка ПО на платформе 1С:Предприятие
Нагибович Константин
Не понятно о чем эта статья.
Ответить
Грищёв Сергей
В каком тикете? Какие разработчики? Что такое спринты? Что мы разрабатываем? Зачем?
Ни черта не понял.
Ответить
Daria 29276
Это больше техническая статья, мы поняли, что нужно поменять стиль написания. В следующий раз улучшим)
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.