Беклоги проекта или где что хранить

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

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

Беклог продукта

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

Группировка

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

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

  1. Юзабилити. Иногда имеет смысл не делать каждый отдельный запрос по улучшению юзабилити продукта, а накопить некоторое количество и заняться всеми сразу. Более того, большое количество улучшений по юзабилити в соответствующей категории вашего беклога говорит о том, что, скорее всего, вашему проекту требуется некоторая переработка в плане удобства использования.
  2. Новые блоки функциональности. Если у вас в беклоге имеется несколько новых глобальных фич (например, социализация всего сервиса), есть смысл выделить их всех в отдельную категорию. Такие крупные фичи отличаются от более конкретных мелких заданий. С увеличением размера фичи растет время на ее реализацию, возникает необходимость глубокого анализа, обширных исследований и более-менее скрупулезного планирования. Хранение подобных новых фич в одном месте позволяет легче расставлять приоритеты при планировании новой фазы проекта, заранее организовывать создание набросков дизайна, технические и бизнес исследования.
  3. Маркетинг. В этой категории стоит хранить те задания и новые фичи, которые так или иначе связаны с маркетингом. В частности, сюда можно отнести поддержку распродаж или специальных предложений, создание тематического блога в рамках проекта, внедрение поддержки партнерских программ.

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

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

Эстимирование

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

Теги

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

  1. Needs analysis - заданию требуется отдельное исследование на бизнес- или маркетинг- тематику
  2. Needs technical research - заданию требуется исследование технической стороны реализации задания
  3. Needs specification - заданию требуется проработка деталей, которые должны быть собраны в функциональной спецификации
  4. Needs prototype - заданию необходим прототип для UX тестирования или просто - посмотреть.
  5. Needs design - задание жаждет внимания дизайнера и очень хочет из простых скетчей стать чем-то красивым и стильным

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

Приоритеты

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

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

  1. High (лучше всего сделать)
  2. Medium (было бы хорошо сделать)
  3. Low (подумайте, стоит ли это делать)

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

Технический беклог

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

Назначение

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

Наполнение технического беклога

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

  1. Четко определите проблему
  2. Определите плюсы и минусы от решения данной проблемы
  3. При необходимости определите некие гайдлайны, которых следует придерживаться всей команде для устранения проблемы в будущем
  4. Определите необходимость проведения дополнительных технических исследований
  5. Определите модули проекта, которые будут затронуты при решении проблемы - по сути, шпаргалка для QA отдела

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

Отложенные проблемы и баги

Часто отведенного на фазу времени не хватает для решения всех существующих проблем и поэтому клиенту приходится поставлять продукт с некоторым количеством известных проблем (known issues). Большинство известных проблем обычно не очень серьезны, некоторые очень сложно воспроизвести, но их объединяет одно: закрыть и забыть их вам не позволит профессиональная совесть :).

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

Исследования и анализ

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

Итого

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

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

Нашли в тексте ошибку — выделите её и нажмите Ctrl+Enter.
Новые комментарии

Обсуждение

Missing-male
-2

"Эстимирование" - нет такого слова. Есть слово "оценка".

C379be0fabb8e7e43522ec663293cd1d?1529713206
Иван Сухинин
– Sr. Director, POC and Innovation в Kibo

-2

Много каких слов нет в русском языке :). Лично для меня слово "оценка" больше связано с материальной ценностью, а "эстимирование" - именно с оценкой времени.

А если по теме - какой трекинговой системой вы пользуетесь в Skype?

Picture_5070?1356409952
+2

И всё-таки вопрос терминологии, на мой взгляд, достаточно важен. Вспоминаю выступление одного разработчика (или, более близким Вам термином, "девелопера") перед пользователями (теми, которые "юзеры"). С моей точки зрения, называть таблицы "гридами", а элементы управления "контролами" не так уж и круто... Тем более, когда слушатели этого не понимают.

C379be0fabb8e7e43522ec663293cd1d?1529713206
Иван Сухинин
– Sr. Director, POC and Innovation в Kibo

+1

Найдите в моем тексте хотя бы одно слово "девелопер" или "юзер" :) "Элементы управления" же как-то длинно, контролы звучит куда лучше. "Гриды" - в первый раз слышу.

Picture?type=square

Поддержваю.

Терминология должна быть понятная. Простое копирование иностранных слов - признак плохого вкуса.

Picture_5070?1356409952

Кстати, "беклоги" -- это устоявшийся термин? Анализ строения этого слова наводит на мысль о некоторой ретроспективе, и это не вяжется с Вашим "списки запланированных и пока еще не завершенных заданий". AFAIK, то, о чём Вы рассказываете, обычно называют "списками ToDo".

C379be0fabb8e7e43522ec663293cd1d?1529713206
Иван Сухинин
– Sr. Director, POC and Innovation в Kibo

-1

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

Picture_5070?1356409952

Ок с ней, с терминологией, пытаюсь вникнуть в тему ;-)

C379be0fabb8e7e43522ec663293cd1d?1529713206
Иван Сухинин
– Sr. Director, POC and Innovation в Kibo

=)

Picture?type=square

Следите за чистотой вашего письменного языка. Читать очень сложно.

Для термина backlog я у нас предложил использовать "список требований". Хотя в устной речи использую термин "стакан".

Missing-male
Mutare
– работаю в Digiteum

Так это же не список требований. В backlog хранятся не только требования, но и баги (а это вы как предлагаете называть?) и улучшения (CRs). И собственно в чем смысл пытаться ко всем терминам найти аналог на русском языке? А Scrum как назвать?

Picture?type=square

Для Заказчика - это больше список требований (CR - новое требование, баг - требование исправить ошибку).

C379be0fabb8e7e43522ec663293cd1d?1529713206
Иван Сухинин
– Sr. Director, POC and Innovation в Kibo

По такой логике все подряд можно называть требованиями и суть термина "требование" уже теряется. Баги это НЕ требования.

Missing-male
Mutare
– работаю в Digiteum

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

425430dd6319f7df5899a4626125ae5c?1427577634
+1

У нас называется Лукап Воркайтемов (уж точно не лучше, чем Беклог :).

Иногда Список СиАров (тут немного не то, потому что в Беклогах все в куче: и дефекты, и сиары, и фичи новые).

C379be0fabb8e7e43522ec663293cd1d?1529713206
Иван Сухинин
– Sr. Director, POC and Innovation в Kibo

Лукап Воркайтемов это даааа :D

Missing-male

Оценка рисков, оценка трудозатрат, оценка качества... Нормальное универсальное слово. Всяко лучше эстимирования ;)

Мы пытаемся практиковать scrum.

425430dd6319f7df5899a4626125ae5c?1427577634

Я бы еще добавил, что вместо поля приоритет по-хорошему нужно два поля: Эффект и Стоимость.

Тогда приоритет High = Эффект High с Low Стоимостью.

Ну и так далее... получается Приоритет = Эффект * Стоимость.

Зачем разбивать? Иногда достаточно сложно определить приоритет, поскольку этот составной параметр могут оценивать разные стороны: Эффект может оценивать бизнес-заказчик, а Стоимость — разработчик, архитектор, ПМ.

Missing-male

Product owner определяет product backlog items (т.е. что нужно сделать). Разработчики дают оценку каждому айтему. Product owner определяет приоритет на основе бизнес требований и предварительных оценок. В оценке по идее заложена сложность исполнения / стоимость / риск и т.п. Так это и работает.

Picture_432?1356409809
+2

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

1. По собственному опыту, если в бЭклоге больше 50 айтемов, но это не очень хороший бэклог. А почему, собственно? На то есть несколько причин

- его надо время от времени просматривать, приоритеты расставлять, и выбрасывать что не надо -> waste

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

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

2. Вообще общее правило - в бэклоге должны хранится истории, с минимальным описанием. Это маркеры дискуссии, которая велась с заказчиком (ну или product owner'ом). Описывать истории детально надо только тогда, когда она приближается к разработке. Например, мы знаем, что скоро начнем делать ленту комментариев. Когда решение принято, вот тогда и надо заниматься придумыванием решений, прототипами, UX тестированием и в конце спецификацией истории. А до тех пор история "лента комментариев" может содержать пару предложений.

3. Мне лично не нравится отдельный технический бэкглог. Приоритеты должны расставляться продукт оунером. А как их можно расставить, когда бэклога 2? Никак невозможно без переноса в какой-то другой обший бэклог. Так что по типу историй или проблем бэклоги разделять нельзя. Но зато бэклоги можно разделять по горизонту событий. Например, может быть "долгий ящик" - это такая свалка, куда кладут все, что в ближайшее время делать не собираются. И реальный бэклог, в который складывают то, что скоро собираются делать. И этот актуальный бэклог должен быть маленьким.

C379be0fabb8e7e43522ec663293cd1d?1529713206
Иван Сухинин
– Sr. Director, POC and Innovation в Kibo

>> если каждую стори описывать так детально, как описано в разделе "наполнение тех. бэклога"

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

>> Вообще общее правило - в бэклоге должны хранится истории, с минимальным описанием.

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

>> А как их можно расставить, когда бэклога 2?

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

Повторюсь, в случае не собственного продукта, а аутсорсинга (который в наших краях встречается намного чаще), разделение беклогов на приносящий business value и на не приносящий bv имеет смысл: со вторым надо обращаться совсем по-другому и по-другому его продвигать заказчику.

Missing-male
Mutare
– работаю в Digiteum

+3

Да, Миша, с большего я с тобой согласна. С тех пор, как я придумала систему ведение беклогов, описанную в статье, много воды утекло.

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

>> По собственному опыту, если в бЭклоге больше 50 айтемов, но это не очень хороший бэклог

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

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

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

На прошлой неделе я так 27 стори прибила из беклога, и думаю, что нужно сделать еще один подход. :)

>> Вообще общее правило - в бэклоге должны хранится истории, с минимальным описанием.

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

>>Мне лично не нравится отдельный технический бэкглог

Я раньше подходила к беклогам скорее с точки зрения категоризации, теперь с точки зрения тегирования. :) Технические вещи есть смысл тегировать, как технические. Почему? Потому что подход к ним другой. Ну, например, есть у меня item "clean up css". Value для проекта однозначная, чистка направленая на улучшения перформанса. Но писать это, как улучшение перформанса смысла нет, потому что css, это всего лишь одна из мер, направленная на его улучшение, которая все время откладывается из-за отсуствия человека, который этим займется. А теги они удобны, можно выбрать и посмотреть, что по каким направлениям есть. И действительно можно взять что-то из технического направления. Технические задачи приятнее брать вместе с функциональными, тогда конечным пользователям больше радости. Кто-то css почистил, а кто-то новую плюшку прикрутил. А если все занимались только техническими вещами, то есть ощущение, что проект временно застывает в разивтии.

Picture_432?1356409809
+1

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

Никогда. Никогда. Никогда не надо делать вещей, которые не несут прямой выгоды заказчику. Любой нормальный рефакторинг, любое изменения архитектуры должно быть оправдано. Заказчику ВСЕГДА надо доносить, какие есть риски и тп, если мы оставим вот этот кривой код, но это исключительно его право принимать решения, что будет делаться в следующем релизе. В связи с этим, копить технический бэкглог с подробными описаниями точно так же не имеет большого смысла, как и описывать подробно истории. Придет время, тогда и достанем оттуда что нибудь техническое.

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

C379be0fabb8e7e43522ec663293cd1d?1529713206
Иван Сухинин
– Sr. Director, POC and Innovation в Kibo

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

Никогда. Никогда. Никогда не надо говорить "никогда", особенно так категорично :) Понятно, что делать что-то бесполезное никто не станет. Проблема в том, что не все заказчики понимают в технических деталях и объяснять приходится буквально на пальцах. Более того, я не говорил о "бесполезности", я говорил об "отсутствии прямой бизнес-выгоды", которая совсем не "бесполезность". Простой пример - перевод веб-сайта с группы серверов с IIS6 на группу серверов с новой операционкой и IIS7. Есть ли прямая выгода? Нет. Есть ли *косвенная*? Да куча просто: ускорение разработки из-за отсутствия костылей для ASP.NET MVC, включения автоматического динамического gzip сжатия и ускорения отдачи страницы пользователю, поддержка более легкого управления серверами через PowerShell. И как переезд с IIS6 на IIS7 в продукт беклог всунуть? Да никак, если только заказчик не разбирается в тонкостях. А вот если закинуть это в технический беклог, расписать подробно все затраты и косвенные выгоды, красиво расписать это все в письме заказчику и уговорить его сделать это через одну итерацию - вот и счастье привалило.

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

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

Picture_432?1356409809

> Никогда. Никогда. Никогда не надо говорить "никогда", особенно так категорично :)

Никогда не стреляй себе в башку из оружия. Это тоже звучит категорично?

>Понятно, что делать что-то бесполезное никто не станет.

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

> И как переезд с IIS6 на IIS7 в продукт беклог всунуть?

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

C379be0fabb8e7e43522ec663293cd1d?1529713206
Иван Сухинин
– Sr. Director, POC and Innovation в Kibo

>> Никогда не стреляй себе в башку из оружия. Это тоже звучит категорично?

Да, если целью является собственно самоубийство. Нет - для большинства случаев.

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

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

>> Ускорение разработки - вот это и надо продать заказчику.

Ну так это и продается :) Результат пребывания таска в техническом беклоге - набор бонусов, которыми можно уговорить заказчика принять это задание. Собственно, всем вышеперечисленным и уговорили.

>> А если его текущая скорость устраивает, значит юзер стори не надо делать.

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

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

Missing-male
Mutare
– работаю в Digiteum

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

А так и там, и там улучшение, предложенное командой или конечными пользователями проходит через чьи-то руки

C379be0fabb8e7e43522ec663293cd1d?1529713206
Иван Сухинин
– Sr. Director, POC and Innovation в Kibo

Смена характера принятия решений продукт оунера - это не "нет разницы между аутсорсингом и продуктовым бизнесом", это капитальная разница в общем случае. Это, как ты сама говоришь, дополнительная прослойка и дополнительные усилия на объяснение заказчику чего и как. Если бы тогда это был собственный продукт - мы бы технический беклог вряд ли бы завели, просто в общий кинули и не парились.

C379be0fabb8e7e43522ec663293cd1d?1529713206
Иван Сухинин
– Sr. Director, POC and Innovation в Kibo

См. выше.

Picture_130?1356409798

Технический бэклог? Это что такое?

У нас есть два основных бэклога -- Master Product Backlog и Sprint Backlog. MBP может содержать сколько угодно пунктов. Мне как скрам мастеру всё равно, я не смотрю дальше первых 10-15. Остальное -- головная боль продакт оунера.

SB мы с продакт оунером обсуждаем перед каждым спринтом. Я обычно принимаю не больше 7 пунктов, чаще всего штук 5. При обсуждении SB отсеиваются:

1) Недостаточно сформулированные пункты

Если они плохо сформулированы, то, как правило, они не до конца продуманы. Мы не делаем то, что не понимаем ни мы, ни сам заказчик.

2) Чересчур большие задачи.

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

3) Неважные задачи.

Если я сомневаюсь в целесообразности задачи, которая не делается за час с учётом кофе и сортира, я прошу объяснить, почему это важно. Если выполнение задачи облегчит работу десятку человек, то, скорее всего, эта задача не сильно важна. Таким задачам мы понижаем приоритет и, как правило, они никогда не делаются. :)

Мы ещё иногда делаем что-то небольшое, но полезное, чего в бэклогах нет и вряд ли будет. Ну, там кнопочку, которая экономит несколько кликов, или там отступ где-нить, чтобы читалось легче, и т.п. Мы называем это candies.

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

Технический бэклог не нужен.

>>> Такие решения могут приводить к плохой архитектуре,

Если делать небольшие изменения, то и архитектура не испортится.

>>> ухудшению качества кода

Как вы меряете "качество кода"? Для меня всегда это было загадкой. Как по мне, так работающий код -- хороший код, а не работающий -- плохой.

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

Ну, лучше поздно, чем очень поздно. Это, вообще-то, внутреннее дело команды, нет?

C379be0fabb8e7e43522ec663293cd1d?1529713206
Иван Сухинин
– Sr. Director, POC and Innovation в Kibo

>> У нас есть два основных бэклога...

На здоровье :) Хорошая у вас система, по книжке и работает.

>> Технический бэклог не нужен.

Не судите по себе.

>> Если делать небольшие изменения, то и архитектура не испортится.

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

Во-вторых, даже маленькими изменениями можно легко изгадить архитектуру. ЛЕГКО.

>> Как по мне, так работающий код -- хороший код, а не работающий -- плохой.

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

>> Ну, лучше поздно, чем очень поздно. Это, вообще-то, внутреннее дело команды, нет?

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

Picture_968?1356409826
Dreamer
– Software Engineering Team Leader в EPAM

Нет такого даже русскоязычного термина - "бЕклог"... Есть "бЭклог".

Смотрим Гугл:

"бэклог": 2,220 results

"беклог": 641 results

Автор подправьте пж-та, а то глаз режет.

Picture?type=square

Простите, а русскоязычный термин "бэклог" вы в словаре Ожегова нашли?

Picture_968?1356409826
Dreamer
– Software Engineering Team Leader в EPAM

+1

Разумеется, нет. Я кстати выступаю за чистоту языка. Но если уж автор считает, что без заимствования никак не обойтись, то пусть это будет бэклог. Русскоязычный звук "е" намного мягче, чем англоязычный "a". Сравните слова APPLE и ЕЛЬ.


Авторизуйтесь, чтобы оставлять комментарии

Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси