Статьи

Карпаччо из слона (по рассказам пользователей)

Июнь 22, 2018

В нашем еженедельном книжном клубе мы выполнили упражнение Алистера Кокберна под названием « Слон карпаччо» . Цель состояла в том, чтобы улучшить нашу способность разбивать истории по более мелким границам, а не более примитивными способами, и научиться развиваться чрезвычайно итеративным способом — итерациями по 10 минут.

Теория

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

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

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

  • Независимо друг от друга, так что они могут быть легко расставлены по приоритетам.
  • По договоренности, так что объем может быть определен вместе с клиентом.
  • Ценен так, что каждый из них считается полезным для клиента.
  • Оценивается так, чтобы приоритизация могла учитывать затраты и время цикла.
  • Маленькие, чтобы они не оставались в разработке вечно, влияя на итеративность.
  • Тестируемый, чтобы мы знали, когда мы закончили.

практика

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

1-й рассказ

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

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

for (i = 1; i <= 10; i++) {
  if (i % 2) {
  // 000
  // XXX
  // 000
  } else {
  // 0X0
  // 0X0
  // 0X0
  }
}

Пока все хорошо: каждая пара может сделать демо в конце этой первой итерации.

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

2-я итерация

Вот вторая история: предоставить NxN вид на неподвижную планку, вращающуюся вместо поля 3×3.

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

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

3-я итерация и последующие

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

Другие начальные точки сократили количество итераций (всего 1 вместо 10), чтобы показать только пользовательский интерфейс или начальную конфигурацию игры (одну живую ячейку вместо стабильной мутирующей конфигурации, такой как планка из 3 ячеек. Промежуточное звено выбор может быть, чтобы выбрать стабильную, но не мутирующую конфигурацию как блок:

0000
0XX0
0XX0
0000

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

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

Выводы

Мы провели очень быструю ретроспективу упражнения в конце 4 Pomodoros, обнаружив, что:

  • Игра Жизни считалась хорошей проблемой для кого-то, а не хорошей. Есть много других проблем (даже более простых, таких как FizzBuzz), доступных вам на выбор, но мне обычно нравится Игра Жизни в качестве системы отсчета.
  • Я думал о привлечении нетехнического коллеги в качестве клиента, но это может сделать упражнение более длительным и трудным для понимания тех аспектов, которые мы считаем важными. Может быть, разговор с Владельцами продукта — это отдельное упражнение от этого.
  • Отзывы о коде бесценны, так как то, что казалось простым для реализации, взорвалось через 10 минут из-за технической задолженности или даже за одну итерацию из-за ее неосуществимости. Оптимизм не всегда оправдан, поскольку реальность наступает …

81
Share: