Agile - Что мы делаем неправильно?

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

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

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

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

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

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

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

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

22 голоса | спросил Gabriel Slomka 6 J000000Friday18 2018, 18:28:09

8 ответов


57

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

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

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

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

Чтобы очистить существующую проблему, см. превосходные ответы на Я унаследовал 200K строк кода спагетти - что теперь?

ответил Dan Pichelman 6 J000000Friday18 2018, 18:52:48
22

У вас есть то, что Мартин Фаулер называет «flacid scrum».

Если вы правильно прочитали все 12 принципов за Agile Manifesto , вы узнаете, что вы терпите неудачу из них.

  

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

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

  

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

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

  

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

Поистине главный принцип. Я считаю, что это должно быть помещено в ОГРОМНЫЕ КРАСНЫЕ ПИСЬМА на странице. Именно здесь вы терпите неудачу.

  

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

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

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

  

Как превзойти это в гибкой?

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

ответил Euphoric 6 J000000Friday18 2018, 19:09:50
9

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

два отдельных аспекта :

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

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

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

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

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

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

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

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

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

Мой совет:

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

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

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

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

Резюме

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

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

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

ответил AlexK 7 J000000Saturday18 2018, 11:19:03
7

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

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

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

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

ответил Bryan Oakley 6 J000000Friday18 2018, 19:33:14
5

Эван прав. Причина, по которой менеджменту нравится scrum, заключается в том, что они могут потребовать функции в стиле staccato и быстро получать результаты. До тех пор, пока не возникнет проблема с проблемой elses.

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

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

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

ответил Martin Maat 7 J000000Saturday18 2018, 17:10:49
3

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

  

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

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

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

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

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

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

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

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

ответил Vogel612 8 J000000Sunday18 2018, 12:24:54
2

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

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

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

Причины, по которым это может отсутствовать, следующие:

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

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

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

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

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

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

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

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

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

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

ответил AndyHasIt 8 J000000Sunday18 2018, 14:37:34
-1

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

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

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

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

и

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

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

ответил Ewan 6 J000000Friday18 2018, 18:53:55

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132