Описывает то что должна сделать программа для решения поставленной задачи но не как она это

Итак для начала — что такое постановка задач по SMART, лучше всего ответит Википедия . Если вкратце — это такая схема постановки задач при которой задачи должны получаться:

1. конкретными — в задаче описана конкретная область для улучшения
2. измеримыми — количественная оценка или что-то, что покажет прогресс по задаче
3. назначаемыми (достижимыми) — у них должен быть один конкретный исполнитель)
4. реалистичными — с описанными конкретными результатами, но чтоб это не было Нью-Васюками
5. осязаемыми (связанными со временем) — т.е. с понятными реальными сроками выполнения

Много букв, согласен. Раньше у меня в голове почему-то это все никак не могло уложиться в голове и стать привычкой при постановке задач, но потом я посмотрел выступление Александра Афенова Трудно быть Колей: теория и практика knowledge sharing в Lamoda и все встало на свои места.

В тексте должна быть картинка 😉 https://www.proofhub.com/wp-content/uploads/2019/11/The-16-Best-Kanban-Apps-for-Increased-Productivity-in-2020.jpg

Особенности организации независимого тестового контроля для студентов технических специальностей

Короче, есть вариант попроще SMART, с которым вполне можно успешно и не затратно по времени работать. Его как по мне проще запомнить и он понятнее, хотя суть вообще не меняется. У нас в команде мы уже взяли его на вооружение и я вижу отличные результаты — задачи стали сильно понятнее. Даже когда к задаче возвращаешься через время она не вызывает дискомфорт в плане того, что ты вне контекста и забыл что-то, что надо бы помнить для этой задачи.

Why, What, DOD

В любой задаче в описании должны быть заполнены следующие блоки:

Why (почему мы хотим сделать задачу)
What (что именно хотим сделать)
DOD (definition of done) список критериев успешности выполнения. Именно список, а не «проза» в виде простыни связанных предложений.

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

Пример будет состоять из Epic (длинная задача не на один спринт, по сути подпроект) и одной задачи в нем.

Epic: Перевод UI на ReactJS

Why : Поддержка LTS версии AngularJS кончается 21 декабря 2021 года, у нас весь проект написан на нем и проект имеет большую кодовую базу. Если мы не перейдем на другой фреймворк, то рискуем полной или частичной неработоспособностью нашего сервиса из-за обновлений браузеров, которые могут что-то непоправимо сломать. Нужно уже сейчас переходить на новый UI фреймворк, так как это очень трудоемкий процесс и нам нужен запас по времени. https://docs.angularjs.org/misc/version-support-status

What : Сейчас самым разумным видится перевод на React ввиду его гибкости, удобству и популярности у разработчиков, что поможет проще искать людей, а так же наличию гораздо большего количества готовых компонентов, по сравнению с Angular (2+).

Блок-схемы для начинающих (Блок схемы алгоритмов)

• Работы нужно выполнить так, чтобы расширять компоненты меты можно было без перекомпиляции и сборки ядра. Видится это как подключение через конфигурацию js и css заранее скомпилированных в отдельном репозитории файлов UI компонент.
• В процессе выполнения задач находить решения, которые не будут останавливать разработку UI из-за «переписывания всего» или сразу крупных частей на reactjs

Задача: Сделать прототип кода, который позволит подключать react компоненты в ui для постепенного переписывания на ui react

Why : У нас много кода для ui, мы не можем остановиться и разрабатывать его «с нуля» на react

What : Надо найти рабочее простое решение для того, чтобы уже сейчас можно было подключать простые компоненты интерфейса на reactjs

• Решение может не включать поддержку рендеринга angularjs компонентов в новых реакт компонентах (React -> AngularJs -> React).
• на react должен быть переведен компонент me-input text и там должна работать валидация и отключение валидации при рендере опционального lego
• компонент проверен рендерингом в me-lego-list
• вывод информации о пользователе в верхнем меню переведен на react
• angular 2 bootstrap отключен (так как если это не сделать, то мы очень сильно добавим времени на старт приложения и объем загружаемого кода)

Очень надеюсь, что вы уловите суть — вся техническая требуха в DOD по пунктам, а не сплошным монолитным текстом. Why, What жестко разделены и отвечает каждый за свое. Прям принцип единой ответственности в деле 😉

Пример

Далее я приведу пример того, как часто ставятся задачи в проектах, почему это плохо и как предлагается их менять.

Текст задачи: «Вывести красную кнопку Купить справа от названия товара.»

И . часто это в принципе вся задача, ну может еще скриншоты со стрелкой, указывающей куда надо поместить кнопку.

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

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

А вот как следовало бы поставить такую задачу, чтобы всем все было понятно и программист бы чувствовал важность задачи наравне с менеджером, а не относился к этому как с самодурству или типа того.

Название задачи : Вывести дополнительную кнопку Купить на странице товара справа от названия товара

Why : Исследования вебвизора показали, что пользователи, с не высоким экраном не всегда скролят вниз до деталей товара и не видят кнопку Купить. Поэтому решено провести тестирование с выводом дополнительной кнопки.

What : Справа от названия товара вывести стандартную красную кнопку «Купить», которая бы открывала стандартное модальное окно начала покупки.

• Обязательно проверить адаптивность верстки на мобильных телефонах, так, чтобы кнопка тоже была видна
• Кнопка не должна перекрывать название товара
• Кнопку реализовать малыми силами, так как возможно, ее нужно будет убирать, если тест будет неудачный

+ Приложить к задаче ссылки и скриншоты с вебвизора на отчет по проблеме

При такой постановке задачи она будет понятна даже junior разработчику, особенно, если тимлид приложит в тело задачи, а не в комменты ( в jira это есть) ссылки на storybook (пример использования) с красной кнопкой.

Если вам понравилась эта статья, то возможно вам будет интересна и моя статья про принципы принятия решений в команде .

А на этом всё, спасибо за внимание!

Подписывайтесь на канал , ставьте лайки, оставляйте комментарии — это помогает продвижению в Дзене.

#тимлид #teamlead #разработка #management #jira #постановка целей #постановка задач

Источник: dzen.ru

Программирование в динамическом мире

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

22.01.2013 Сергей Архипенков

• Ключевые слова / keywords:
• Мнение
• Opinion
• Программная инженерия

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

«Серебряной пули нет, — сказал в прошлом веке Фредерик Брукс, надолго остудив пыл благородных рыцарей от программирования в борьбе с Драконом сложности. — Я не очень верю в драконов, зато верю в то, что сложность — понятие субъективное. Одно из определений слова «сложный» — трудный, запутанный. То, что для одного человека является трудным и запутанным, для другого может быть легким и ясным». В природе нет ничего трудного и запутанного. Может быть, программные системы, которые мы разрабатываем, мы сами делаем сложными и запутанными?

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

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

Созданные в мышлении человека модели предметной области могут относиться как к явлениям реального мира (например, движение космического объекта в гравитационном поле и атмосфере Земли), так и к таким понятиям, как интернет-магазин. Модель — это ментальный образ будущего инструмента, который позволит нам решить поставленную задачу. Для расчета траекторий межпланетных перелетов достаточно моделировать гравитационное поле как суперпозицию точечных масс Солнца и планет. А решение отдельных задач глобальной спутниковой навигационной системы (ГЛОНАСС/GPS) невозможно без привлечения моделей времени и пространства из общей теории относительности. Итак, программа — это записанное на понятном некоторому вычислителю языке решение стоящей перед нами задачи.

Об объектно-ориентированном подходе

История развития языков программирования схожа с историей развития человеческой речи. Существует мнение, что первые высказывания человека состояли исключительно из требований помощи и обязательно содержали глаголы в повелительном наклонении («дай!», «неси!», «ломай!», «режь!», «тяни!» и т. п.). Причем эти команды сопровождались жестами, которые точно указывали, к чему конкретно это действие должно быть применено, что очень похоже на команды языков программирования — например, ассемблеров с точным указанием адресов памяти или регистров.

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

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

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

Объектно-ориентированный подход к построению ментальных моделей физического мира имеет более чем двухтысячелетнюю историю успешного применения и берет начало еще в трудах Аристотеля. В мире Аристотеля существуют только единичные и конкретно определенные вещи с заданным набором свойств и отнесенные к одной и только одной категории.

Да, теперь мы уже научились говорить не просто «неси», а «неси дрова» или «неси камень». В своем развитии языки программирования остановились на том, что научились различать объекты (дрова и камень), но не научились выделять действия над ними. И с точки зрения языка программирования men.carry (firewood) и men.carry (stone) будут разными языковыми единицами, если только объекты firewood и stone не имеют общего предка. Просто реализация этими объектами интерфейса «то, что может носить человек» нас не выручит, поскольку это будут две реализации, а следовательно, и единиц исходного кода тоже будет две.

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

Мы должны рассматривать его с точки зрения разумных предположений о том, как будет использоваться данный дизайн впоследствии. Если перевести этот тезис на язык «дров» и «камней», то это будет звучать примерно так. Проектируя программные объекты «дрова» и «камень», мы должны быть в курсе планов Господа по совершенствованию программной системы. А именно — мы должны предполагать, что Он не ограничится созданием дров и камней, а на шестой день сотворения мира создаст человека, который их будет перетаскивать.

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

Это противоречит реальности, в которой объекты могут эволюционировать, приобретать новые свойства и утрачивать ранее существовавшие. Например, роза может стать товаром, а потом подарком. Наследником какого класса должна быть роза-подарок? Роза-товар или роза-цветок? Другой пример.

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

Следовательно, один и тот же объект должен иметь возможность принадлежать разным классам, и этот набор классов должен быть динамическим, изменяясь в ходе эволюции объекта и самой программной системы. На набор классов, к которым относится объект, как правило, накладываются ограничивающие взаимосвязи. Например, чтобы стать солдатом, человек должен достичь 18 лет.

Еще одна странность ООП. «Поведение — это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений» [1]. Но если я моделирую столкновение двух автомобилей, то какой из них и какие получает и передает сообщения?

«Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств» [1]. Но принадлежит ли свойство объекта самому объекту? Нет. Например, мы говорим: данное яблоко — зеленое. Но что это означает на самом деле?

Это значит, что если мы направим источник света, близкого по спектру к солнечному свету, то данное яблоко поглотит все длины волн, кроме тех, которые соответствуют диапазону зеленого цвета, и наблюдатель, который способен воспринимать весь спектр солнечного света, увидит только отраженный зеленый свет. Если источник или наблюдатель имеет другой диапазон, например, инфракрасный, то цвет яблока будет черным. Таким образом, свойство не есть неотъемлемая характеристика объекта, свойство — это возможное проявление объекта при его взаимодействии с другими объектами. Например, свойство предмета «плавать по поверхности» может проявляться во взаимодействии с водой и не проявляться во взаимодействии со спиртом.

Постановка задачи в ИТ-проектах

Техническое задание — это не то же самое, что и постановка на реализацию. Техническое задание — это результат обработки исходных (организационных, бизнес-) требований, их уточнения и перевода на системный/технический уровень.

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

Место постановки на реализацию
 в процессе создания IT-продукта

Постановка на реализацию (розовый блок на рисунке) выполняется в рамках проектирования (светло-зеленый) перед реализацией.

Процесс реализации ИТ-проекта от инициации идеи до внедрения и эксплуатации готового ИТ-решения

Техническое задание разрабатывается на этапах Инициации и Определения метода решения бизнес-задачи. Здесь мы говорим про выявление проблемы, сбор исходных требований, формирование какого-то запроса на решение этой проблемы.

Далее на этапе Определения метода решения мы занимаемся Уточнением требований. Здесь уже появляется структура функций, ИТ-продуктов будущего проекта. А постановка на реализацию описывает, как мы эти функции и продукты будем реализовывать.

Постановка описывает конкретную функцию, модуль, что-то максимально локализованное. Объектами постановки могут быть отдельные компоненты, модули или функции – в зависимости от того, как мы декомпозировали функциональную структуру системы/решения в техническом задании.

Зачем нужна постановка на реализацию?

1. Определить границы, защититься от их изменений
2. Зафиксировать критерии успешного результата

Подписаться на рассылку
Подпишитесь на рассылку, чтобы получать от нас полезные материалы и оставаться на связи

«Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности»

Кто пишет постановку на реализацию?

1. Менеджер проекта / менеджер продукта
2. Аналитик
3. Тимлид разработки, например, когда аналитика на проекте нет. Тогда менеджер верхнеуровнево описывает необходимые функции, а команда разработки сама пишет для себя постановки и задачи.

Кому нужна постановка на реализацию?

1. Менеджеру проекта (или продукта) . Для менеджера постановка на реализацию выполняет защитную функцию: он понимает, что часть функциональности описана, все понимают что делать, границы реализации защищены.
2. Аналитику. Сама по себе постановка – это способ документирования, к ней всегда можно вернуться, чтобы посмотреть как функция была реализована. Постановка – это хороший способ отслеживать свой результат.
3. Команде. Именно в постановке есть описание того, что нужно делать. В постановке описывается некий облик решения, который позволяет команде разработать продукт не только в соответствии с требованиями, но и в соответствии с теми решениям, которые были приняты на верхнем уровне.
4. Заказчику. Так, например, технический заказчик может активно участвовать в технических решениях. Бизнес-заказчик может согласовывать отдельные разделы постановки – ниже мы поговорим о том, что может быть ему интересно. Участие заказчика позволяет определить перечень требований, которые нужно реализовать в рамках этой постановки. Оно необходимо, чтобы понимать, что будет на выходе после реализации.

Основные разделы постановки на реализацию

1. Контекст задачи
2. Ключевые источники информации
3. Заинтересованные стороны
4. Критерии приемки результата
5. Нефункциональные требования и ограничения
6. Описание решения

Разделы постановки на реализацию

Рассмотрим эти разделы на примере:

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

Необходимо разработать сервис по расчету и предоставлению клиенту плановых сроков доставки заказа. Считаем, что до этого мы никаких сроков потенциальному клиенту не озвучивали.

Давайте пройдемся по разделам постановки и попробуем понять, какую информацию стоит в них отражать.
Раздел 1. Контекст задачи

Контекст задачи – это краткая информация о ситуации и проблемах, из-за которых возникла стоящая перед вами задача по автоматизации. Данная часть постановки – это, по сути, срез бизнес-требований, которые были собраны бизнес-аналитиком на предыдущем этапе.

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

1. Описание функций бизнес-языком
2. Описание бизнес-процесса
3. Бизнес-требования
4. Перечень проблем бизнеса

Кейс: возможность предоставления клиенту плановых сроков доставки заказа

Компания не имеет собственных средств доставки грузов.

Базовые сроки доставки предоставляются сервисами компаний-перевозчиков, далее в них учитываются сроки подготовки заказа и риски, которые может учесть компания.

Дорабатываем систему Self Care в части отображения клиенту сроков доставки товара при оформлении заказа. Необходимо разработать АРМ для оператора call-центра, которому звонят с запросом сроков доставки.

Для чего этот бизнес-контекст разработчикам?

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

Пример из практики:

Делали систему для компании, где работали операторы 24 часа в сутки. Специфика работы компании заключалась в том, что ночью было принято работать без света. Если не знать этой специфики, можно было бы сделать какой-то вырвиглазный интерфейс, в котором ночью работать было бы невозможно. А зная и понимая это, проектировщик интерфейсов разработал такие интерфейсы, которые позволяют работать одинаково удобно и днём, и ночью.

1. Мы можем делать постановку на разном уровне детализации.
2. Чем выше уровень детализации постановки, тем больше места для маневра команды разработки. Это позволяет выбрать лучший вариант для решения поставленной бизнесом задачи.

Раздел 2. Ключевые источники информации

В этом разделе постановки речь идёт о едином перечне источников информации, описание которых снижает риск использования недостоверной информации.

Во-первых, это, конечно, глоссарий. Он необходим, чтобы заказчик, бизнес и команда оперировали одними и теми же согласованными терминами. Глоссарий должен быть приложен как один из источников информации.

• Описание внешнего или ранее реализованного API (например, API компании-перевозчика). Разработчик не должен сам искать в интернете какую-то версию, т.к. она может оказаться не последней и не согласована с архитектором.
• HLD (high-level design, описание архитектуры)
• Стандарты заказчика, если речь идет про передачу листинг кода, а также когда есть свои определенные стандарты его оформления
• Ссылка на памятку по чтению постановки. В некоторых случаях формат постановки может быть достаточно объемным и в нем могут использоваться артефакты, которые не всегда будут понятны человеку со стороны (или даже разработчику команды, который может воспринять постановку неправильно). Поэтому ссылка, например, на соглашение о моделировании вполне может быть источником информации.

Раздел 3. Заинтересованные стороны

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

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

Роли заинтересованных сторон

Разница между проектными ролями и бизнес-ролями ЗС

Существуют разные роли, в которых выступают заинтересованные стороны по отношению к постановке. Например, бизнес-роли и проектные роли.