sem
Егор Ширялин
0 ответов 206 12.09.2018

Постановка задачи через пользовательские истории по Agile



В своей заметке о том, как поставить задачу разработчикам программы 1С я обратил ваше внимание, что время больших ТЗ истекло. Сейчас – это анахронизм, который используется тогда, когда надо попилить выделенные бюджеты и обосновать фин. директору, главбуху и, возможно, CEO на что пойдут еще не выделенные миллионы и почему их нужно выделить. Тряся кипой бумаг, которые в скором времени отправятся в помойку, ваш ИТ-директор будет надуваться от значимости и доказывать вам экономическую эффективность проекта, если, конечно, авторы ТЗ не забыли про этот важный раздел.

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

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

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

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

Эта модель подходит, когда:

Вы хотите начать использовать новые возможности «уже завтра».

Вы хотите корректировать направление разработки, т.к. не вполне уверены в целесообразности нововведений или тестируете процессы на ходу.

Вы хотите применить новые технологии, возможно опережающие рынок в целом, но не вполне изученные бизнесом.

Есть некоторые особенности и цели с высоким риском, которые могут измениться в будущем.

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

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

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

Как запустить работу по модели Agile совместно с вашим подрядчиком?

Конечно, я не буду описывать все тонкости работы в данной методологии, тем более, что она должна быть принята самим подрядчиком на уровне компании (ну ладно, он хотя бы должен что-то слышать о ней). Но я с удовольствием подскажу вам, как заказчику, как строить взаимоотношения с вашими разработчиками, используя техники Agile на своей стороне.

Что интересно эти техники подойдут вам, даже если ваш подрядчик исповедует классические методологии управления проектами, такие как ITIL или водопад или даже если он работает вообще без какой-либо методологии:)

Итак, начнем.

Первое, что вам нужно научиться делать, это формировать пользовательские истории, так называемые User-Story.

Затем нужно собрать пользовательские истории в «Backlog».

Задать им приоритеты.

Отправить готовый бэклог разработчикам.

Страшно? – Ничуть. Давайте разбираться по шагам.

User Story

Когда вы формулируете задачу в принципах пользовательских историй она становится очевидной на 87%. Остальные 13% не смогут испортить ваш проект так же сильно как непонятное ТЗ.

В чем состоит секрет User Story?

В формулировке задачи через ответы на 3 ключевых вопроса:

  • Кто?
  • Что?
  • Зачем?

При ответе на вопрос «Кто?» мы должны выявить заказчика потребности – то лицо, которое будет пользоваться результатом работ. Кому нужен разрабатываемый функционал. Это может быть не только конкретный человек, но и роль, отдел или система. Василий Михайлович из бухгалтерии, оператор холодного цеха или менеджер по продажам – все они могут быть полноценными заказчиками потребности.

Ответив на вопрос «Кто?», мы должны подумать над вопросом «Что?». Что необходимо сделать? Какова потребность конкретного Василия Михайловича из бухгалтерии или безымянного менеджера по продажам? Какую задачу нужно решить? Какой функционал реализовать?

Генеральный директор может ответить на этот вопрос, например, так: «Сделать, чтобы мне на почту, каждый вечер, приходил отчет об остатках денежных средств в кассе предприятия». А Вася из снабжения может захотеть «Добавить кнопку печати накладной за поставщика».

Далее в пользовательской истории необходимо закрыть вопрос «Зачем?». Сделать это должен и Вася и генеральный директор. У ген. директора может получиться примерно следующее: «Хочу контролировать ситуацию, чтобы не иметь штрафов за превышение допустимого остатка д/с в кассе. Также хочу избежать подтасовки данных бухгалтером».

При этом Вася может написать нечто вроде: «Не хочу ждать оригиналы накладных. Буду печатать за клиентов и расписываться за них сам».

Альтернативой формулировке «Зачем?» будет являться формулировка «Для чего это нужно?» или «Почему это важно для вас?». Таким образом, нам следует выявить бизнес-ценность. То самое, почему мы не можем отказаться от данной задачи, чем именно она важна для нас.

Основной параметр пользовательской истории и, одновременно, ее ценность – краткость. Считается, что чем короче пользовательская история, тем она эффективнее. Сухим формальным языком ТЗ это называется атомарность.

Вам нужно понимать следующее – если ваша пользовательская история получилась какой-то длинной – значит, скорее всего, ее надо попробовать разбить на две.

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

Вот на такой:

Кстати, первично я рекомендую записывать ваши пользовательские истории именно так – на стиккерах в формате, который обозначен выше: «Кто – Что - Зачем». Когда у вас наберется некоторый объем таких историй, соберите их вместе и читайте дальше.

Собираем Backlog

Сделали User-Story? - Отлично! Теперь пройдите по отделам своей организации и соберите их у всех сотрудников. Проверьте чтобы формат «Кто – Что - Зачем» неукоснительно соблюдался. Научите этому формату того, кто не справился.

Теперь приступайте к главному. Вам понадобится секретарша Мариночка, чтобы все пользовательские истории собрать в один файл, который называется бэклог. Бэклог – живой. В него регулярно пишутся новые пользовательские истории.

Выглядит он, примерно так:

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

В общем случае автором стиккера может быть не только владелец потребности, но и какое-то другое лицо, которое «знает лучше» или «чуть больше» о том, что нужно самому владельцу.

Я все же рекомендую не придумывать потребности третьим лицам, а выбрать группу инициативных лиц из каждого отдела организации, которые сами такие потребности декларируют и даже могут, при необходимости, их защитить.

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

Ну что, заполнили бэклог? Поехали дальше!

Задаем приоритеты

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

В буржуйской интерпретации приоритеты определяются словом «MOSCOW», которая, в данном случае, является аббревиатурой следующих выражений.

M (Must Have) – это функция, которая должна быть в конечном продукте, и продукт без неё будет бесполезен. Пример: тормозная система автомобиля.

S (Should Have) – это важная характеристика конечного продукта, и мы будем сталкиваться с трудностями без неё. Но можно найти альтернативный вариант или получить то же самое, «подручными» средствами. Пример: кондиционер в автомобиле.

C (Could Have) – это действительно важная функция, и хочется её видеть в данном решении, но если этой функции в продукте нет, то это не станет большой проблемой. Пример: камера для парковки авто.

W (Will not Have This Time) – это удобная функция, но на данный момент времени мы не готовы в неё вкладывать деньги. Пример: онлайн мониторинг состояния автомобиля.

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

Важно!

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

Теперь у вас появился полноценный файл – бэклог, который вы можете смело отправлять вашим разработчикам на оценку. Разобраться в нем не составит большого труда, а сэкономленное на разработку бесполезного ТЗ время, вы сможете потратить более эффективно. Уверен, вы найдете куда!

Ловите фишку (точнее файл).

b254534816-backlog-proekta-v-03.xlsx

Вы можете использовать этот файл как шаблон для постановки задач вашим подрядчикам. Скачайте его прямо сейчас и отдайте Мариночке на заполнение. Затем повесьте в гугл-докс и оправляйте ссылку на него вашим разработчикам.


Вуа-ля! Задача поставлена!

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

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

Комментарии (0)

Для добавление комментария необходимо авторизоваться.

Вход | Регистрация

Блог руководителя 1СStyle
СМС через 1С
0 133 05.11.2018
Егор Ширялин [sem]
Обработка загрузки 1С
0 74 31.10.2018
Егор Ширялин [sem]