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

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

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

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

Как справиться с неурегулированными чувствами?

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

Один из способов улучшить работу большинства команд — помочь им писать лучшие тикеты. И да, вы правильно прочитали. Отсюда я почти слышу объединённые стоны программистов по всему миру. Ничто так часто не отравляет наше существование, как то, что мешает программированию, я знаю.

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

Приступим к делу.

Опасность заключается в нашей бессознательной некомпетентности

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

История показала мне, работая со многими различными предприятиями — большими, малыми, начинающими или государственными — фундаментальную истину:

Большинство компаний прискорбно не оснащены для того, чтобы писать хорошие билеты.

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

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

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

Проблема с нашими билетами

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

1) Они написаны для одной аудитории, а не для всей команды. Тикеты — это уникальный зверь, поскольку они являются документом для бизнеса, а также инструментом для развития. Исторически сложилось так, что эти две партии говорят на двух разных языках. Я имею в виду — буквально два разных языка. Что неизбежно приводит к сбоям в общении. Часто тикеты пишутся либо для команды разработчиков, либо для бизнеса. Не оба — как они должны быть.

2) Отсутствие согласованности — согласованные шаблоны помогают в поиске информации. Подумайте о том, как трудно найти ваши любимые продукты, когда супермаркет решает реорганизовать план этажа. Внезапно вы обнаруживаете, что делаете круги по проходам в поисках коробки с Cap’n Crunch. В конце концов, однако, вы входите в ритм, и поиск вещей постепенно становится легче. У нас та же проблема с программными билетами; они должны быть последовательными, чтобы мы могли быстрее найти то, что нам нужно.

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

Как видите, все вышеперечисленные проблемы можно решить, если использовать последовательный подход: Шаблон.

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

Часть 1: История пользователя

КАК пользователь с правами администратора Я ХОЧУ сделать что-нибудь ТАК ЧТО что-нибудь.

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

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

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

Нюанс 1 – возвращение пользователя в пользовательские истории.

Одним из нюансов хорошей пользовательской истории является (что неудивительно) пользовательская часть. Это первый раздел, где вы пишете «КАК [пользователь] Я ХОЧУ»… В спешке этот шаг легко пропустить и буквально написать «КАК пользователь». Я имею в виду, они все-таки пользователи, верно?

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

В этот момент вы можете подумать: «Во-о-о! Подождите минутку — что такое персона, мы не говорили об этом? Вы правы - у нас нет. Итак, давайте сделаем это быстро сейчас.

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

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

Нюанс 2 – достаточно маленькие истории

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

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

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

Нюанс 3 — истории, которые не представляют реальной ценности

Если наши истории слишком велики, легко начать думать о том, как представить истории в так называемом горизонтальном срезе.

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

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

Проблема здесь в том, что история приносит пользу только в последнем спринте. Что же тогда является решением? Нарезать по вертикали.

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

Часть 2: Бизнес-контекст

Пользовательские истории не появляются из воздуха; у них есть контекст, происхождение и намерение.

Рассмотрим этот пример:

Добавление раздела истории в профиль кандидата позволит человеку увидеть, какие действия были предприняты с его учетной записью.

Эта функция разработана на основе отзывов пользователей, проведенных Дженни, результаты которых можно найти в документации [здесь] и [здесь].

Предоставление этой функции соответствует нашей квартальной бизнес-цели KPI, а именно: увеличить количество регистраций кандидатов.

Хорошие лидеры способны четко сформулировать видение, чтобы их последователи могли работать с ними над его достижением.

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

Предоставление бизнес-контекста похоже на расстановку знаков препинания в предложении. Без него наше общение может быть неясным и неправильно понятым. Это разница между давай поедим бабушку! И поедим, бабушка!

Нюанс 1 – начните с вопроса "Почему".

Люди покупают не то, что вы делаете, они покупают то, почему вы это делаете, — эту фразу снова и снова повторяет Саймон Синек в своем чрезвычайно популярном выступлении на TED Как великие лидеры вдохновляют на действия.

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

Нюанс 2 – связать функцию с ее источником

Каждая предоставленная функция должна отражать изменение в поведении пользователя.

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

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

Нюанс 3 – опирайтесь на данные

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

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

Часть 3: Критерии приемлемости

Я часто слышу: Каковы критерии приемлемости? Но идея критериев приемлемости означает и выглядит для каждого человека по-своему. Однако это может выглядеть как…

ДАННО Я не являюсь администратором.

КОГДА Перейдите на страницу /admin.

ТО Я вижу окно с предупреждением: "У вас нет доступа к этой странице".

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

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

Критерии приемлемости могут быть записаны в таком формате: ДАННО, КОГДА, ТОГДА.

Нюанс 1 – недостаточно исходных данных для определения критериев приемки

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

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

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

Нюанс 2 – привязка критериев приемки к вашему выходу

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

Часть 4: Каркасы

И последнее, но не менее важное: наиболее распространенной областью билетов являются каркасы или макеты.

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

Собираем все вместе

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

Как теперь выглядит билет целиком? Что-то типа…

История пользователя

КАК пользователь с правами администратора Я ХОЧУ просматривать историю, ЧТОБЫ я мог видеть, какие действия были предприняты с моей учетной записью.

Бизнес-контекст

Добавление раздела истории в профиль кандидата позволит человеку увидеть, какие действия были предприняты с его учетной записью.

Эта функция возникла на основе отзывов пользователей, предпринятых Дженни, результаты которых можно найти в документации [здесь] и [здесь].

Внедрение этой функции соответствует нашей квартальной бизнес-цели KPI, которая заключается в увеличении числа регистраций кандидатов.

Критерии приемлемости

ДАННО Я не являюсь администратором.

КОГДА Перейдите на страницу /admin.

ТО Я вижу окно с предупреждением: "У вас нет доступа к этой странице".

Вот и все.

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

Чтобы узнать больше об этой статье, посетите мой веб-сайт: www.thedevcoach.co.uk.

А чтобы получать еженедельные статьи в свой почтовый ящик, подпишитесь здесь.

Первоначально опубликовано на simpleprogrammer.com 12 марта 2018 г.