Agile - Что мы делаем не так?

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

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

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

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

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

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

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

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

Это не имеет ничего общего с Agile или Scrum.

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

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

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

Чтобы избавиться от существующей проблемы, посмотрите отличные ответы: я унаследовал 200 000 строк кода для спагетти - что теперь?

То, что у вас есть, это то, что Мартин Фаулер называет «вялой схваткой».

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

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

Можете ли вы сказать, что вы поставляете действительно работающее программное обеспечение? Или просто программное обеспечение, которое едва работает?

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

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

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

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

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

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

Из вашего комментария

Как предотвратить это в agile?

Во-первых, узнав, что такое Agile на самом деле. Скрам не проворный. Кто-то скажет, что Scrum - худший из гибких фреймворков, так как слишком легко достичь вашей конкретной ситуации. Вы должны узнать о других гибких рамках. Я бы порекомендовал это экстремальное программирование. Который явно решает ваши проблемы. Решения не просты (сфокусированы на техническом совершенстве благодаря надежному автоматизированному тестированию, парному программированию и непрерывной доставке), но очень эффективны. Как сообщается в отчете State of DevOps .

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

Есть два отдельных аспекта того, что вы описываете:

• Отсутствует общее понимание / видение и, следовательно, не быть эффективным
• Как измерить успех / прогресс и общую стоимость

Идти по неверному пути или бегать кругами

По моему опыту, главная причина этого состоит в том, что, пытаясь быстро создать код, команды активно откладывают случаи использования или требования, которые они уже знают или о которых легко могут узнать. Думайте об этом так: 10-20 лет назад люди пытались написать гигантские спецификации и думать обо всем заранее и часто терпели неудачу. Они либо заняли слишком много времени, либо что-то упустили. Одним из уроков прошлого было то, что в разработке программного обеспечения есть вещи, которые вы не можете знать, и вещи сильно меняются, отсюда и идея быстрой итерации и быстрого получения некоторого осмысленного результата. Это очень хороший принцип. Но сегодня мы находимся в другой крайности: «Меня это не волнует, потому что это часть следующего спринта» или «Я не регистрирую эту ошибку, я имею дело с ней, когда она появляется снова».

1. Соберите все высокоуровневые сценарии использования , требования, зависимости и ограничения, которые вы можете найти. Поместите это в некоторые вики, чтобы все заинтересованные лица и разработчики могли их видеть. Добавьте к ним, когда появится что-то новое. Поговорите с вашими акционерами и пользователями. Используйте это как контрольный список при разработке, чтобы предотвратить реализацию вещей, которые не вносят вклад в конечный продукт или являются обходными путями / взломами, которые решают одну проблему, но вызывают три новых.
2. Сформулируйте концепцию высокого уровня . Я не говорю о разработке интерфейсов или классов, но вместо этого в общих чертах очерчиваю проблемную область. Каковы основные элементы, механизм и взаимодействия в конечном решении? В вашем случае это должно быть очевидно при использовании jquery-обходного решения в качестве промежуточного шага и когда это только вызывает дополнительную работу.
3. Подтвердите свою концепцию, используя список, который вы собрали. Есть ли в этом явные проблемы? Имеет ли это смысл? Существуют ли более эффективные способы достижения той же ценности для пользователя, не вызывая долгосрочную техническую задолженность?

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

Имейте в виду ошибочную стоимость : если вы начинаете с одной архитектуры или типа базы данных, большинство людей не решаются изменить ее в середине проекта. Так что это хорошая идея - потратить некоторое время на то, чтобы получить «обоснованное лучшее предположение», прежде чем приступить к реализации. У разработчиков есть тенденция быстро писать код. Но часто наличие пары макетов, живых прототипов, скриншотов, каркасов и т. Д. Позволяет выполнять итерацию еще быстрее, чем написание кода. Просто помните, что каждая написанная строка кода или даже модульные тесты затрудняют повторное изменение вашей общей концепции.

Измерение успеха

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

Ваш пример «загрузки» довольно хорош. У меня были такие вещи в прошлом, когда все (включая продажи, ПО, пользователей) соглашались, что это раздражает. Но это никак не повлияло на успех продукта и не вызвало долгосрочных долгов. Таким образом, мы отбросили его, потому что были более ценные вещи, связанные с dev-ресурсами.

Мой совет здесь:

1. Сохраняйте все, даже небольшие ошибки, как билеты в вашей системе тикетов . Примите активное решение, что находится в рамках проекта, а что нет. Создайте вехи или иным образом отфильтруйте ваш журнал, чтобы у вас всегда был «полный» список всего, что еще нужно сделать.
2. Имейте строгий порядок важности и четко обозначенную точку, в которой проект можно считать успешным. Какой уровень стабильности / качества кода / документации на самом деле нужен конечному продукту? Старайтесь проводить каждый день работы как можно лучше, выбирая сверху. При работе с одним тикетом, попытайтесь решить его полностью, не вводя новые тикеты (если нет смысла откладывать вещи из-за более низкого приоритета). Каждый коммит должен вести вас вперед к конечной цели, а не в сторону или назад. Но еще раз подчеркну: иногда взлом, который впоследствии производит дополнительную работу, все же может быть чистым позитивом для проекта!
3. Используйте ваше ПО / пользователей, чтобы выяснить пользовательскую ценность, но также попросите ваших разработчиков определить стоимость технологий . Не разработчики, как правило, не могут судить, какова истинная долгосрочная стоимость (а не только стоимость внедрения!), Поэтому помогите им. Помните о проблеме с кипящей лягушкой: множество мелких, не относящихся к делу проблем со временем может привести команду в замешательство. Попробуйте определить, насколько эффективна ваша команда.
4. Следите за общей целью / расходами. Вместо того, чтобы думать от спринта к спринту, лучше подумайте: «Можем ли мы как команда сделать все необходимое до конца проекта» . Спринты - просто способ сломать вещи и иметь контрольные точки.
5. Вместо того, чтобы показывать что-то раньше, проложите свой курс по самому быстрому пути к минимально жизнеспособному продукту, который можно дать пользователю. Тем не менее, ваша общая стратегия должна предусматривать поддающиеся проверке результаты между ними.

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

Хитрость заключается в том, чтобы спорить с общей стоимостью проекта: если, например, ПО настаивает на принятии ярлыков, чтобы сделать крайний срок, количественно определить объем работы, которая должна быть выполнена впоследствии, чтобы считать проект выполненным!

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

Резюме

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

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

Надеюсь, это поможет!

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

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

Если они говорят, что это последнее, то, что вы делаете неправильно, вы не даете им то, что они хотят.

Одним из краеугольных камней Scrum является прозрачность. Если вы делаете разборки, вы должны делать спринт-обзоры с клиентом. В этих обзорах вы говорите клиенту, что сокращаете углы, чтобы быстрее доставлять программное обеспечение? Если нет, вы должны быть. Вы должны быть на 100% ясны с вашим клиентом о последствиях вашего выбора дизайна, чтобы дать им возможность принять обоснованное решение о том, поставляете ли вы свое программное обеспечение с соответствующим уровнем качества.

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

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

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

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

Давайте рассмотрим, что вы делаете, отложив Agile на мгновение.

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

Это называется «Взятие технического долга». Мартин Фаулер описал «Квадрант технического долга» в своем блоге по двум осям: «Безрассудный против разумного» и «Умышленный против случайного».

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

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

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

То, что вы делаете, неправильно на самом базовом уровне. Это плохая инженерия !

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

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

Просто прекратите использовать Agile ...

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

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

Причины этого могут отсутствовать:

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

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

1. Состояние кода препятствует способности команды выполнять работу вовремя и без ошибок.
2. Чем больше функций мы добавим, тем хуже будет.
3. Поэтому действительно имеет смысл приостановить, переоценить и (возможно, радикально) перепроектировать детали.

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

Сказав это, есть много вещей, которые менеджеры могут сделать, чтобы усугубить вещи:

1. Deathmarching ваших разработчиков к срокам.
2. Заявление о том, что разработчики могут регистрировать время только по тикетам, не имея при этом билетов на «обдумывание, консолидацию и качественный рефакторинг» и щедрых временных надбавок на них.
3. Не предоставляя права собственности на архитектуру одному человеку достаточно долго, чтобы справиться с ней
4. Не позволяя этому человеку вносить необходимые изменения

Глядя на это таким образом, легко увидеть, как некоторые интерпретации agile & scrum на самом деле продвигают вас по этому пути еще быстрее!

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

Другой подход заключается в планировании спринтов, чтобы использовать только 25-50% возможностей вашей команды. Затем разработчики записывают свое время на реальные тикеты (запишите время, которое это должно было занять без рефакторинга) и время рефакторинга (один большой тикет на неделю, без циклов утверждения, только обсуждение между разработчиками). Если рефакторинга нет, вы можете получить билеты из спринта на следующей неделе. Вы корректируете процентный ползунок на ближайшие недели, когда улучшается основной код проекта.

Поэтому, чтобы ответить «что мы делаем неправильно», я бы сказал, что вы доверяете методологии, а не здравому смыслу. Вы даже просите «гибкого подхода к этой проблеме» . Я бы сказал, отказаться от слов и подумать о реальной проблеме. Если вы действительно хотите отделить различные манифесты, пытаясь понять, действительно ли ваш последний подход на основе здравого смысла подпадает под маску «гибкой» или «разборки», обязательно сделайте это :-)

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

Если у вас есть второстепенные цели, над которыми вы работаете, то лучше всего выразить их как «нефункциональные требования» или «определение выполненного».

например, у вас может быть нефункциональное требование:

«Все новые функции должны быть написаны в React»

а также

«Все асинхронные вызовы должны реализовывать загрузочный счетчик и обработку ошибок»

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