Переходы к бэклогам: внедрение эффективных временных рамок в разработке программного обеспечения

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

Несколько лет назад разработчики компании DST Global столкнулись с знакомой задачей: найти конкретную проблему в DST CRM. То, что мы обнаружил, было одновременно забавным и тревожным — три версии одной и той же постановки задачи, каждая с разными решениями, с интервалом от четырех до шести месяцев. Каждое решение было действительным в своем контексте, но старые из них устарели.

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

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

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

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

Проблемы в бэклоге: не более 4 месяцев

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

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

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

Филиалы: не более месяца

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

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

Лучшие практики управления филиалами

1. Частая интеграция

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

2. Небольшие, постепенные изменения

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

Эпики: не дольше четверти

На более высоких позициях в иерархии руководители инженеров во многом полагаются на эпики, чтобы понять, куда вкладываются усилия команды. Часто я замечал, что некоторые эпики, например, о техническом долге или улучшениях, в конечном итоге содержат сотни проблем. Эти всеобъемлющие эпики сильно раздуваются, потому что инженеры вынуждены связывать каждую проблему с эпопеей. В результате становится трудно отличить усилия, затраченные на элементы дорожной карты, от технического долга или задач KTLO (Keep The Light On).

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

Лучшие практики управления эпиками

1. Определите четкие границы

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

2. Регулярный обзор и обрезка

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

3. Расставьте приоритеты и классифицируйте

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

4. Ограничьте продолжительность эпической игры

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

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

Билеты: «Не больше, чем спринт»

Одной из проблем гибкой разработки как для разработчиков, так и для менеджеров является решение проблем, которые перетекают от спринта к спринту. В первом спринте выполнено 20% работы; во втором спринте выполнено 30% и так далее, но некоторые проблемы всегда переносятся. Сюжетные точки зрения на эти проблемы постоянно меняются , создавая неправильные ожидания для менеджеров по продукту и заинтересованных сторон. Это может демотивировать разработчиков, поскольку создается впечатление, что прогресс застопорился, хотя на самом деле билет слишком велик для одного спринта.

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

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