Я разработчик в гибкой команде, и мы пытаемся использовать Scrum.
Поэтому я поставлю здесь гипотетическую проблему, чтобы проиллюстрировать ситуацию.
У нас очень старое приложение, использующее какой-то грязный и плохо обслуживаемый код JQuery. У нас также есть части приложения, использующие React, и эти части проще обновлять / поддерживать. Кроме того, целью компании является создание клиентского одностраничного приложения для React, поэтому использование JQuery поможет вам еще дальше от этого отказаться.
Когда мы занимаемся планированием, мы всегда идем к простому решению с точки зрения времени разработки, поэтому, например, если мы создаем новый диалог или что-то еще, мы используем старый JQuery, потому что он быстрее, и мы говорим, что мы возвращаемся позже привести в порядок и превратить в React, но это случается редко.
Требования к тому, что мы должны делать, мы получаем из пользовательских историй (которые хорошо сделаны IMO, они тонкие, но объясняют, что мы делаем и почему мы это делаем).
Иногда требования к новым функциям очень узки, поэтому, например, если требование говорит «создать диалог, который загружает тонны содержимого», но не говорит о реализации функции загрузки, мы, в большинстве случаев, не реализуем ее хотя мы все знаем, что это будет лучше для клиентов, потому что это может поставить под угрозу нашу цель в спринте (хотя я лично считаю, что это не так).
В результате наша кодовая база представляет собой большой беспорядок с очень плохой ремонтопригодностью, а новые функции иногда очень малы и требуют полного спринта (что может быть достигнуто за один день в хорошей кодовой базе) в основном из-за этой разработки стратегия, просто иди быстро, сделай минимальное.
В этом случае, что мы делаем не так? Должны ли мы заняться решениями более полно, чтобы не писать плохой код и переписывать код, который мы только что написали на прошлой неделе? Или мы должны продолжать делать это, просто следя за тем, чтобы весь этот код был переписан? Каков был бы хороший проворный подход к этой проблеме?
Ответы:
Это не имеет ничего общего с Agile или Scrum.
Проблема с «клейкой лентой сейчас, а мы исправим позже» заключается в том, что позже никогда не наступит, и в то же время вы накапливаете много технического долга .
Первый шаг к восстановлению - это распознать проблему и перестать ее усугублять.
Для каждой новой пользовательской истории команда должна подумать «как правильно написать код?», А не «как быстрее всего это взломать?» и планируйте спринты соответственно.
Чтобы избавиться от существующей проблемы, посмотрите отличные ответы: я унаследовал 200 000 строк кода для спагетти - что теперь?
источник
То, что у вас есть, это то, что Мартин Фаулер называет «вялой схваткой».
Если вы правильно прочитаете все 12 принципов гибкого манифеста , вы обнаружите, что не справились с большинством из них.
Можете ли вы сказать, что вы поставляете действительно работающее программное обеспечение? Или просто программное обеспечение, которое едва работает?
Можете ли вы сказать, что ваш процесс является устойчивым? Принимаете ли вы решения с точки зрения устойчивости? Или вы выбираете решения, которые решают текущую проблему без учета долгосрочных последствий?
Действительно главный принцип. Я считаю, что это должно быть написано в огромных красных буквах на странице. Это где вы терпите неудачу больше всего.
И наиболее очевидно. Если вы обнаружите, что ваше поведение не приводит к желаемым результатам, вы должны изменить его. Если ваша команда не видит, что у нее есть проблемы, она не может начать их исправлять.
Из вашего комментария
Во-первых, узнав, что такое Agile на самом деле. Скрам не проворный. Кто-то скажет, что Scrum - худший из гибких фреймворков, так как слишком легко достичь вашей конкретной ситуации. Вы должны узнать о других гибких рамках. Я бы порекомендовал это экстремальное программирование. Который явно решает ваши проблемы. Решения не просты (сфокусированы на техническом совершенстве благодаря надежному автоматизированному тестированию, парному программированию и непрерывной доставке), но очень эффективны. Как сообщается в отчете State of DevOps .
источник
То, что вы описываете, - по крайней мере, по моему опыту, - довольно распространенный шаблон команд, пытающихся «быть проворными». Открыто для обсуждения, если это на самом деле является частью самого Agile или является его неправильной реализацией, противоречит проворному манифесту / принципам или его неотъемлемым следствиям и так далее. Просто с эмпирической точки зрения и только на основании моего собственного небольшого выборочного опыта (и людей, с которыми я общаюсь), если команда гибкая, у нее больше шансов столкнуться с этой моделью. Давайте просто оставим это и сосредоточимся на вашем конкретном примере.
Есть два отдельных аспекта того, что вы описываете:
Идти по неверному пути или бегать кругами
По моему опыту, главная причина этого состоит в том, что, пытаясь быстро создать код, команды активно откладывают случаи использования или требования, которые они уже знают или о которых легко могут узнать. Думайте об этом так: 10-20 лет назад люди пытались написать гигантские спецификации и думать обо всем заранее и часто терпели неудачу. Они либо заняли слишком много времени, либо что-то упустили. Одним из уроков прошлого было то, что в разработке программного обеспечения есть вещи, которые вы не можете знать, и вещи сильно меняются, отсюда и идея быстрой итерации и быстрого получения некоторого осмысленного результата. Это очень хороший принцип. Но сегодня мы находимся в другой крайности: «Меня это не волнует, потому что это часть следующего спринта» или «Я не регистрирую эту ошибку, я имею дело с ней, когда она появляется снова».
Не переусердствуйте. Вам просто нужно что-то, чтобы у всех в команде (включая не разработчиков) было общее понимание того, каков наилучший путь к вашему MVP. Все должны согласиться с тем, что нет очевидных упущений, и это может сработать. В целом это помогает предотвратить тупик или необходимость повторять одно и то же несколько раз. Agile может помочь вам лучше справляться с неожиданностями, это не аргумент игнорировать то, что известно.
Имейте в виду ошибочную стоимость : если вы начинаете с одной архитектуры или типа базы данных, большинство людей не решаются изменить ее в середине проекта. Так что это хорошая идея - потратить некоторое время на то, чтобы получить «обоснованное лучшее предположение», прежде чем приступить к реализации. У разработчиков есть тенденция быстро писать код. Но часто наличие пары макетов, живых прототипов, скриншотов, каркасов и т. Д. Позволяет выполнять итерацию еще быстрее, чем написание кода. Просто помните, что каждая написанная строка кода или даже модульные тесты затрудняют повторное изменение вашей общей концепции.
Измерение успеха
Совершенно отдельный аспект - как вы измеряете прогресс. Допустим, цель вашего проекта - построить башню высотой 1 м из лежащих вокруг вещей. Построение карточного домика может быть вполне приемлемым решением, если, например, время выхода на рынок более важно, чем стабильность. Если ваша цель состоит в том, чтобы создать что-то, что длится долго, использование Lego было бы лучше. Суть в том, что считать хаком и какое элегантное решение целиком зависит от того, как измеряется успех проекта .
Ваш пример «загрузки» довольно хорош. У меня были такие вещи в прошлом, когда все (включая продажи, ПО, пользователей) соглашались, что это раздражает. Но это никак не повлияло на успех продукта и не вызвало долгосрочных долгов. Таким образом, мы отбросили его, потому что были более ценные вещи, связанные с dev-ресурсами.
Мой совет здесь:
Поэтому, когда кто-то делает что-то, что не вписывается в вашу конечную цель реализации, в идеале не считайте историю законченной. Если полезно закрыть историю (например, чтобы получить обратную связь от клиентов), немедленно откройте новую историю / ошибку, чтобы устранить недостатки. Сделайте прозрачным, чтобы использование ярлыков не уменьшало затраты, а просто скрывало или задерживало их!
Хитрость заключается в том, чтобы спорить с общей стоимостью проекта: если, например, ПО настаивает на принятии ярлыков, чтобы сделать крайний срок, количественно определить объем работы, которая должна быть выполнена впоследствии, чтобы считать проект выполненным!
Также остерегайтесь оптимизации на основе критериев : если ваша команда измеряется количеством историй, которые они могут показать в обзоре спринта, лучший способ получить хороший «балл» - это разрезать каждую историю на десять крошечных. Если он измеряется количеством написанных модульных тестов, он будет иметь тенденцию писать множество ненужных. Не считайте истории, скорее измерьте, сколько работает необходимого пользовательского функционала, насколько велика стоимость за счет технического долга, который необходимо решить в рамках проекта, и т. Д.
Резюме
Чтобы свести это к минимуму: быстрый и минимальный подход - это хороший подход. T он проблема заключается в интерпретации «быстрой» и «минимальный». Всегда следует учитывать долгосрочную стоимость (если у вас нет проекта, где это не имеет значения). Использование ярлыка, который занимает всего 1 день, но приводит к техническому долгу в 1 месяц после даты доставки, обходится вашей компании дороже, чем решение, которое заняло 1 неделю. Немедленно начать писать тесты, кажется, быстро, но не в том случае, если ваша концепция ошибочна, и они цементируют неправильный подход.
И помните, что означает «долгосрочный» в вашем случае: я знаю более одной компании, которая обанкротилась, пытаясь написать отличный код и, следовательно, отправила ее слишком поздно. Хорошая архитектура или чистый код - с точки зрения компании - ценна только в том случае, если затраты на ее достижение меньше, чем затраты на ее отсутствие.
Надеюсь, это поможет!
источник
Строго говоря, с точки зрения разборки кажется, что вы делаете неправильно, что вы не работаете с клиентом. Вы должны работать вместе с клиентом, чтобы прийти к пониманию того, что им нужно, а не только то, что они хотят . Нужна ли им серия быстрых исправлений или им нужна стабильная, обслуживаемая система, которая будет обслуживать их в долгосрочной перспективе? Это может быть трудно определить, но качество является таким же требованием, как цвет фона или тест производительности. Заказчик должен знать, что стабильность и ремонтопригодность не являются бесплатными, и его необходимо интегрировать в продукт.
Если они говорят, что это первое, вы не делаете ничего плохого - предполагая, что вы объясняете им в обзорах спринтов, что вы сокращаете инженерные углы для достижения их целей.
Если они говорят, что это последнее, то, что вы делаете неправильно, вы не даете им то, что они хотят.
Одним из краеугольных камней Scrum является прозрачность. Если вы делаете разборки, вы должны делать спринт-обзоры с клиентом. В этих обзорах вы говорите клиенту, что сокращаете углы, чтобы быстрее доставлять программное обеспечение? Если нет, вы должны быть. Вы должны быть на 100% ясны с вашим клиентом о последствиях вашего выбора дизайна, чтобы дать им возможность принять обоснованное решение о том, поставляете ли вы свое программное обеспечение с соответствующим уровнем качества.
источник
Юан прав. Причиной, по которой руководству нравятся схватки, является то, что они пользуются функциями стаккато и быстро получают результаты. Пока получающийся беспорядок не является проблемой кого-то другого.
Теперь, когда у меня есть ваше внимание, пожалуйста, позвольте мне объяснить. Это не Scrum как таковой. Это типичная обстановка сильного менеджера по продукту и слабой команды разработчиков, которая не может дать разумные и реалистичные оценки, потому что они чувствуют давление. Таким образом, они приходят к далеко не оптимистичным оценкам и все глубже попадают в неприятности, сокращая углы, чтобы успеть вовремя.
В Scrum вы (как разработчик) можете заниматься своим собственным планированием. Никто не говорит вам, чтобы доставить какую-то функцию в х дней. Если кто-то говорит вам, чтобы доставить в х дней, вы не делаете Scrum.
Какова бы ни была проблема, которую нужно решить, отнимите свое время. Как вы думаете, вам нужно время, чтобы сначала что-то переделать? Включите это в свою оценку. Можете ли вы позволить себе это сделать?
источник
Давайте рассмотрим, что вы делаете, отложив Agile на мгновение.
Это называется «Взятие технического долга». Мартин Фаулер описал «Квадрант технического долга» в своем блоге по двум осям: «Безрассудный против разумного» и «Умышленный против случайного».
Вы явно решаете использовать известную старую технологию jquery, которая отдаляет вас от одной из ваших экспресс-целей (а именно, одностраничного приложения). Вы делаете это, чтобы доставить «быстро». Это умышленное.
В это вычисление «быстро» не входит время, необходимое для реализации функциональности для последующей реакции. Вы выбираете альтернативу, у которой есть только недостатки по сравнению с альтернативой, которая, как вы знаете, является правильной (а именно, занимает время для реализации функции в реакции), основываясь на оценке того, что скорость имеет существенное значение. Это безрассудно.
Мартин Фаулер суммирует этот вид долга в разделе «У нас нет времени на дизайн». Это подходящий выбор в среде, где вы не ожидаете сохранения кода или даже не планируете писать код более нескольких дней. Но ваш проект - это длительный проект, который явно включает обслуживание ваших клиентов.
То, что вы делаете, неправильно на самом базовом уровне. Это плохая инженерия !
Вы взяли на себя технический долг, игнорируя необходимость погашения этого долга и начисления процентов. И вы продолжали делать это до тех пор, пока процентная ставка по вашему долгу не начала приближаться к имеющейся у вас работе во время спринта.
То, что вы должны делать, это снижение уровня задолженности . Поговори со своим боссом, поговори со своим клиентом. Вы должны работать над ремонтопригодностью вчера.
источник
Просто прекратите использовать Agile ...
Или, скорее, прекратите пытаться сделать что-то определенным образом просто потому, что это (ваше понимание) проворный (или разборки и т.д.) диктует. Попытка применить одну (неправильную) интерпретацию одного из этих терминов к проекту на неправильной стадии может быстро стать наихудшим вариантом действий. Вместо этого используйте вашу причину.
Причина, по которой ваш проект, как и почти все другие проекты в мире, - это путаница кода и расходящиеся подходы, связана с отсутствием централизованного, всеведущего архитектурного проекта (там я это сказал).
Причины этого могут отсутствовать:
Простое решение состоит в том, чтобы отбросить все эти волшебные слова и взглянуть на реальность ситуации, которую можно суммировать следующим образом:
Вы, естественно, придете спросить, почему он вообще дошел до этого состояния, когда палец вины вертелся по кругу. Ответ в том, что это неизбежно: по мере того, как ваш дизайн созревает, вы понимаете, что должны были сделать это по-другому, но вы не могли этого предвидеть. Кроме того, это не реализация каждого проекта, это будет происходить несколько раз, и вам нужно планировать это.
Сказав это, есть много вещей, которые менеджеры могут сделать, чтобы усугубить вещи:
Глядя на это таким образом, легко увидеть, как некоторые интерпретации agile & scrum на самом деле продвигают вас по этому пути еще быстрее!
Один из подходов заключается в создании билетов для каждого бита рефакторинга. Проблема в том, что вы часто не понимаете, что вам нужен большой рефакторинг, пока вы не начнете работать с меньшим билетом, который отодвигает крайние сроки, и если билет проходит через петли одобрения, он просто все замедляет.
Другой подход заключается в планировании спринтов, чтобы использовать только 25-50% возможностей вашей команды. Затем разработчики записывают свое время на реальные тикеты (запишите время, которое это должно было занять без рефакторинга) и время рефакторинга (один большой тикет на неделю, без циклов утверждения, только обсуждение между разработчиками). Если рефакторинга нет, вы можете получить билеты из спринта на следующей неделе. Вы корректируете процентный ползунок на ближайшие недели, когда улучшается основной код проекта.
Поэтому, чтобы ответить «что мы делаем неправильно», я бы сказал, что вы доверяете методологии, а не здравому смыслу. Вы даже просите «гибкого подхода к этой проблеме» . Я бы сказал, отказаться от слов и подумать о реальной проблеме. Если вы действительно хотите отделить различные манифесты, пытаясь понять, действительно ли ваш последний подход на основе здравого смысла подпадает под маску «гибкой» или «разборки», обязательно сделайте это :-)
источник
Вы не делаете ничего плохого. Такая методология предназначена для предоставления функций по спецификации и максимально быстро.
Если у вас есть второстепенные цели, над которыми вы работаете, то лучше всего выразить их как «нефункциональные требования» или «определение выполненного».
например, у вас может быть нефункциональное требование:
«Все новые функции должны быть написаны в React»
а также
«Все асинхронные вызовы должны реализовывать загрузочный счетчик и обработку ошибок»
Вам просто нужно, чтобы ваш владелец продукта (или его эквивалент) согласился с тем, что это то, что стоит делать, а не вкрадывать их, потому что разработчики любят их.
источник