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

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

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

Отмените все другие собрания в дни, до и после сессии планирования и в дни обзора.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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