Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Вопросы Проекты Вакансии
Разработка бизнес решений
Рекомендуем
Продвинуть свой проект
Лучшие проекты за неделю
30
Битрикс24

Битрикс24

www.bitrix24.ru

22
Отследить-посылку

Отследить-посылку

B2B-сервис трекинга посылок

13
WebResidentTeam

WebResidentTeam

webresident.agency

12
Devicerra

Devicerra

devicerra.com

12
Perezvoni.com

Perezvoni.com

perezvoni.com

11
Expresso

Expresso

www.expresso.today

11
myPreza

myPreza

mypreza.ru

9
Reader

Reader

Интернет-журнал о современных технологиях.

9
ADN Digital Studio

ADN Digital Studio

adn.agency

Показать следующие
Рейтинг проектов
Подписывайтесь на Спарк во ВКонтакте

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

66 3 В избранное Сохранено
Авторизуйтесь
Вход с паролем
Оценка работы. Работа со спринтами. Подготовительный процесс перед стартом.

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

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

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

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

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

Выбор технологий и первоначальная оценка

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

Требования

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

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

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

Файловая структура

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

Деплой приложения

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

Взаимодействие с пользователями

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

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

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

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

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

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

Вывод

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

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

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

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