Оглавление

Постановка задач программисту (приказ)

Правила постановки задачи (пример)

При постановке и детализации задач в основе лежит принцип описания задачи "как для junior", что бы даже junior прочитал и понял что нужно. По крайней мере программисты это требуют и это справедливо с их стороны. А также принципами максимальной автономности, атомарность и компонентности (независимости) относительно других задач. Задача ставится по SMART.

Номер задачи: ____

Название задачи: добавить поле "пол" при выгрузке .csv-файла в разделе отчеты

Описание задачи

Контекст (проблема/предистория) — при выгрузке файла выгружаются 4 поля (имя, фамилия, отчество, возраст). Необходимо в выгружаемый файл добавить поле "пол" (текущее состояние выгрузки - см. скриншот). Источник данных смотреть в файле .php по адресу: \Company\Project\Controllers\Report (более детальную информацию о расположении уточнить у TM - сэкономит время). Необходимость добавления поля обоснована удобством работы с выгруженными данными для оператора - при просмотре в Excel можно выбрать кого поздравить 8 марта, кого поздравить 23 февраля.

Критерии приемки при тестировании (ограничения, описание результата, DoD):

Тестирование проводить на следующем тестовом стенде http://....ru/...
Перейти в раздел «отчеты»
Отметить галочкой 10 последних пользователей
Нажать кнопку выгрузить отчет
Просмотреть скаченный файл в Execl
Отчет содержит 5 колонок в следующей последовательности (Имя, фамилия, отчество, возраст, пол)
Для значения колонки "Мужской" выводится текстовая строка "Мужсской"
Для значения колонки "Женский" выводится текстовая строка "Женский"
При отстутствии значения полонки пол выводится "-" (дефис)

Автор задачи (ответственный): ____

Исполнитель: ____

Приоритет по срочности // сроки: //

Статус задачи: ожидает (согласно БП)

Комментарий по задаче (поле в Jira для РП): ____

Цель таски — передать знание бизнеса, ты со своей стороны добавляешь знание техчасти.
Цель таски — описать рамки задачи, цель, время, приоритет.
Знания опишутся в документации, вики.

При описании API - дать ответы на вопросы: откуда взять, как преобразовать, куда отправить. Если задача предполагает описание процесса "Как сделать" - должно быть соответствующее описание изменения "бизнес вэлью".

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

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

Здесь можно оставить комментарий!