Как вы структурируете спринт разработки?[закрыто]

Question

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

Я думаю:

• Планирование спринта на один день
  • Заполните бэклог и выясните, чем будет заниматься каждый разработчик после этого спринта.
• Три недели разработки
  • ИДТИ!ИДТИ!ИДТИ!
• Ежедневное стендап-митинг
  • Проверьте, не нуждается ли кто-нибудь в помощи или не чувствует себя не в своей тарелке.
• Два дня обзора спринта
  • здесь проводятся проверки кода, презентации заинтересованных сторон
• Ретроспектива однодневного спринта
  • что мы сделали в последнем спринте?как мы можем добиться большего в следующий раз?

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

Что-нибудь еще?Очевидно, что agile — это нечто большее.Я хочу предоставить команде простой план того, как мы будем действовать, когда начнем этот проект.

Answer 1

Я бы поэкспериментировал со спринтами продолжительностью менее одного месяца.

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

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

Конечно, это только мой опыт — в основном разработка веб-приложений небольшими (4–12) командами.Ваш опыт может отличаться.

Тем не менее, я бы определенно попробовал более короткие спринты.Как и в случае с интеграционными сборками — многие вещи становятся проще, если вы делаете их чаще.

Answer 2

Отключите электронную почту, мобильный телефон и приложения для обмена мгновенными сообщениями на время основного кода.Для этого подойдут периоды с 10:00 до 13:00 и с 14:00 до 17:00.

Заказывайте еду, напитки для команды, когда они находятся в «зоне».

Отмените все остальные встречи до и после сессии планирования и дней обзора.

Answer 3

• Убедитесь, что «стендап» остается стендапом.Очень легко перейти к более длительным встречам.
• Один день планирования спринта и три дня в конце могут оказаться слишком большими.Планируйте столько времени, сколько вам нужно.
• +1 к идее более коротких итераций.Лично четыре недельные итерации в рамках спринта сработали хорошо.Люди отлично умеют оценивать краткосрочные задачи;после этого это становится все более и более догадками.

Answer 4

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

Несколько вопросов:

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

Означают ли 3 недели разработки «разработка, тестирование, документация, установщики и т. д.»?Т.е.все, что вам нужно, должно быть действительно сделано?

Answer 5

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

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

Answer 6

Я не рекомендую откладывать проверки кода до окончания спринта, они должны быть неотъемлемой частью процесса разработки.Другими словами, задача не будет выполнена, пока код не будет проверен (и протестирован, и не задокументирован, и...).

Answer 7

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

Такие идеи, как «выключить мобильные телефоны, отключить приложения для обмена мгновенными сообщениями и т. д. во время кодирования» — все это плохие идеи.Когда вы нанимаете свою команду, вы нанимаете их с уверенностью в том, что они знают, как правильно выполнять свою работу.Если вы наняли их с таким пониманием, почему вы хотите ограничить их способность выполнять свою работу наилучшим образом, который они знают?Если вы используете SCRUM, то каждый разработчик выберет ту работу, которую, по его мнению, он способен выполнить, а ваша работа как Scrum-мастера — устранять препятствия, а не создавать их.

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

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