Я только начал работу со Scrum, и, кажется, чего-то не хватает. Я новичок в Scrum

Код представляет собой полный беспорядок комбинации классического ASP / ASP.NET. Схватка состоит в том, что мы исправляем большой беспорядок или вносим в него дополнения. Мы все слишком заняты этим, чтобы начать переписывать, поэтому мне интересно ...

Где та часть в Scrum, где разработчики могут сказать, что этого достаточно, и потребовать, чтобы им было дано время начать большую переписку? Мы находимся в бесконечном цикле просто исправления старого кода с помощью «Stories».

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

Так кто же отвечает за то, чтобы это большое изменение в переписывании произошло? Разработчики? Скрам Мастер?

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

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

We seem in an endless loop of just patching old code with 'Stories'.

Время разработчика - это деньги. Много денег. Я ушел из компании, которая планировала обновить их пользовательский интерфейс более года назад, и надеялась, что принятие схватки поможет им перестать крутить колеса. Что произошло? Тот же самый "тот же самый". Они продолжали прибегать к новым функциям, и у «технического долга» не было бизнес-кейса, хотя половина написанного нами кода теряла смысл с каждой итерацией, поскольку базовая кодовая база представляла собой полностью устаревший беспорядок. С тех пор, как я ушел, ничего не изменилось в их интерфейсе, и меня привлекли с целью полной реконструкции. За те два месяца, что я там провел, я не особо коснулся CSS или JavaScript. Я просто возился с HTML и какой-то древней системой шаблонов Java с конца 1990-х годов.

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

Игнорирование этих проблем ВСЕГДА стоит дороже в долгосрочной перспективе. И не немного больше, но много больше. Это не только сосание грудной клетки, когда дело касается времени разработки, но также неизбежно приведет к снижению уровня ваших талантов, так как разработчики, которые знают лучше и имеют другие варианты, будут избегать вашей компании, как чумы. Мой нынешний начальник - разработчик И владелец компании. Есть вещи, которые мы не будем переписывать, чтобы сосредоточиться на других приоритетах, но когда что-то действительно нуждается в рефакторинге из-за постоянной согласованности времени, оно получает правильный рефакторинг. И результаты очевидны. Модификация и добавление нового материала становится проще и быстрее благодаря нескольким факторам. То, что когда-то могло занять часы, может занять минуты при правильной архитектуре. Бизнесу не нравится это слышать, но для этого стоит приостановить ситуацию.

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

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

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

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

http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky
http://www.joelonsoftware.com/articles/fog0000000069.html

Чтобы расширить на "переписать не хорошая идея":

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

Я буду очень тупым ...

• Вы отвечаете за разработчиков в этой работе?
• Вы руководитель проекта?
• Какую «долю» держат разработчики в проекте?
• Каково ваше деловое оправдание для переписывания?
• Что такого в кодовой базе, которая делает его совершенно бесполезным и невосстанавливаемым?

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

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

Возьмите операционную систему Windows в качестве примера. С каждой новой созданной версией был большой кусок кода, перенесенный с предыдущей версии. Иногда целые библиотеки и API переносятся через несколько поколений ОС. Зачем? Поскольку разработчики знают, что эти элементы работают, были протестированы, исправлены и исправлены, чтобы предотвратить проблемы безопасности и памяти, а также потому, что они попали в это состояние очень дорого. Никто не хочет выбрасывать рабочий код, когда он зарабатывает деньги, даже если затраты на обслуживание относительно высоки, затраты на запуск с нуля всегда будут еще выше, а в такой компании, как Microsoft, в банке есть миллиарды, которые позволяют им начать с самого начала, если они хотят, но они не т, потому что они хотят максимизировать свою отдачу от своих инвестиций. Ваш работодатель ничем не отличается от Microsoft, за исключением небольшого количества наличных денег на проект.

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

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

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

Еще лучший вариант - организовать команду как единое целое, чтобы вы могли привлечь кого-то к себе со стажем, достаточным для того, чтобы он мог подготовить хороший пример, чтобы позволить группе более гибко планировать время для улучшения базы кода. Мне все равно, насколько занята компания или насколько жестким является график, всегда есть случайные «затишья» в деятельности, которые можно использовать, чтобы втиснуть улучшение или два. Однако еще лучше, если улучшения могут быть сделаны при выполнении других задач. Если бы это был я, я бы побеседовал с менеджером и познакомил бы их с концепциями в некоторых канонических книгах, которые читают разработчики программного обеспечения. Чистый кодВероятно, это то, что вашей команде нужно больше всего. Расскажите о том, как улучшить код, и приведите несколько примеров того, что вы имеете в виду. Хороший менеджер увидит ценность добавления дополнительных улучшений в код, особенно если вы в состоянии описать концепцию технического долга . Помогите руководителю вашей команды или менеджеру составить хорошее экономическое обоснование для улучшения кода, и у них будет лучшая мотивация для его решения.

Также недостаточно сказать «код неопрятен». Вы должны поощрять своих коллег постоянно практиковаться в кодировании и использовать чистую технику кодирования, чтобы поощрять небольшую уборку в процессе работы. У меня есть небольшой плакат, который я распечатываю и вешаю на стену своего офиса каждый раз, когда беру на себя новую работу. Он говорит: «Всегда старайся сделать код немного красивее, чем ты его нашел». Прямо рядом с ним я добавляю еще один, который гласит: «Лилии не нужно золочить». Они оба напоминают мне, что я всегда должен пытаться улучшить то, что нахожу, но избегать просто позолоты одной проблемы с другой. Массовые переписывания часто являются наихудшим видом «позолоты», потому что они часто делаются по неправильным причинам. Конечно, в какой-то момент совершенно новая версия продукта может быть оправдана,

Вот официальное определение команды разработчиков Scrum из официального руководства Scrum . Я подчеркиваю те части, которые касаются вас напрямую:

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

• Они самоорганизуются. Никто (даже Scrum Master) не говорит команде разработчиков, как превратить бэклог продукта в приращения потенциально высвобождаемой функциональности;

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

• Scrum не признает никаких названий для членов команды разработчиков, кроме разработчика, независимо от того, какую работу выполняет человек; нет никаких исключений из этого правила;

• Отдельные члены команды разработчиков могут обладать специализированными навыками и сферами деятельности, но подотчетность принадлежит команде разработчиков в целом; а также,

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

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

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

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

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

Это нормально

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

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

Я согласен с другими, беспорядок в коде из-за разработчиков. Я уверен, что это предшествовало принятию SCRUM на многие годы.

Это не техническое решение или решение разработчика переписать, это бизнес-решение.

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

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

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

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

Если вы действительно можете показать доказательство , а не только теории , но трудно доказательство , что расходы Xдолларов на новые проекты повторной записи будет гарантированно сделать X * N долларов для бизнеса в Yпериод времени (где Nвысока и Yкороток), вы можете получить некоторую тягу от управления , Это очень маловероятный случай, который вы можете представить и доказать.

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

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

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

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

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

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

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

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

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

Кстати, это не совсем проблема Scrum, и я не предлагаю решение, специфичное для Scrum. Это касается разработчиков, берущих на себя ответственность за код.

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

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

Ты спросил:

Где та часть в Scrum, где разработчики могут сказать, что этого достаточно, и потребовать, чтобы им было дано время начать большую переписку? Мы находимся в бесконечном цикле просто исправления старого кода с помощью «Stories». Таким образом, вещи управляются нетехническими людьми, которые, кажется, не хотят настаивать на переписывании, потому что они не понимают, насколько плохой стал кодовый базис ..

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

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

Я чувствую твою боль, но не уверен, что это имеет отношение к Scrum. Решение о том, следует ли переписывать код, не зависит от процесса разработки.

Чего ждать?

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