Как вы справляетесь с дизайном в Scrum?

26

Как вы справляетесь с дизайном в Scrum? У вас все еще есть хорошо написанные проектные документы для каждой итерации? Вы просто делаете заметки о дизайне с использованием диаграмм UML? Или у вас просто хорошо прокомментированный код?

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

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

Ответы:

11

только то, что это схватка, не означает, что каждый спринт меняет все!

Scrum - это делать то, что необходимо (но не более) . Вам все еще нужно сделать дизайн, и вам все равно нужно документировать. Его просто сумма не установлена, ни как это сделать.

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

Мартин Йорк
источник
9

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

Чтобы быстрая итерация работала, вы должны выполнить тестовую разработку (я не сказал, что вам нужно неохотно делать TDD). В TDD ваши тесты выражают дизайн и предназначение кода (когда они говорят, что «код - это документация», то, что они должны говорить, это «тесты - это документация»). При написании модульных тестов, которые выражают ваше понимание имеющейся функции, вы явно указываете, что, по вашему мнению, должен делать код. Затем вы пишете код, который делает это. Затем вы реорганизуете этот код так, чтобы он придерживался хороших архитектурных принципов "Red-Green-Refactor".

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

Вот некоторые рекомендуемые чтения

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

Майкл Браун
источник
4
@Murph: Идея состоит в том, что архитектура является новой, что вы должны найти ее с помощью тестирования, а не определять ее заранее.
Мартин Уикман,
5
@ Мартин, я вижу, но там все еще есть ужасные проблемы масштаба. Я доволен этим до определенного уровня, но за пределами этого ... ну, я полагаю, вам, вероятно, следовало сделать это (или, по крайней мере, получить первоначальную структуру), прежде чем вы достигнете уровня развития схватки (где можно ожидать команда, чтобы усовершенствовать и развить архитектуру высокого уровня так же как низкого уровня).
Murph
2
@ Murph: Да, загрузка - это проблема. Вам нужно как минимум выбрать язык программирования. Нефункциональные требования, такие как масштабируемость и производительность, сильно влияют на архитектуру и должны быть приняты во внимание как можно скорее. Но помимо этого мне нравится начинать с как можно более простого, а затем постепенно и последовательно добавлять рабочие элементы (ягни) по частям. Сосредоточьтесь на рефакторинге, чтобы сохранить базу кода чистой и извлекать вещи, пока не появится дизайн
Мартин Уикман,
1
Причина, по которой Scrum итеративен, заключается в том, что сама природа программного обеспечения означает, что мы никогда не понимаем его с первого раза. Во многих случаях заинтересованные стороны не знают, чего они на самом деле хотят, пока у них не будет чего-то перед ними. Что лучше: тратить часы на создание дизайна для функции (которую нужно будет доработать или, скорее всего, выбросить, когда резина попадет на тротуар), и донести эту конструкцию до исполнителя; или потратить эти часы, выполняя первый проход к функции и уточняя ее с помощью тестов и рефакторинга.
Майкл Браун
3
Между прочим, вы никогда не поймете истинное значение TDD, пока у вас нет теста, НЕОБХОДИМЫМ ставшего красным. Это был мой большой "ага" момент с TDD. Глядя на тест, который только что стал красным, я понял, что без теста было бы очень трудно отследить ошибку после того, как код оказался в руках тестировщиков. Если вам нужна высокоуровневая нисходящая архитектура, есть много инструментов, которые могут генерировать диаграммы последовательности и классов из вашего кода. Используйте их, чтобы получить отчет о снимке и избавиться от них, потому что это не закон.
Майкл Браун
2

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

Стивен А. Лоу
источник
4
Scrum - это гибкая методология, ориентированная на команду разработчиков и заинтересованных лиц, а также на получение итеративных поставок рабочего кода. Сверху вниз управление проектом и Scrum - это как нефть и вода.
Майкл Браун
1
@ Майк согласился, но я всегда чувствовал, что Scrum - это гибкая методология руководителя проекта, а Extreme Programming - гибкая методология разработчика. Тем не менее, я видел, что Scrum применяется ко многим проектам, кроме программного обеспечения. Интересно, что Википедия предоставляет такое определение Scrum: Scrum - это итеративная, инкрементная методология управления проектами, часто встречающаяся в гибкой разработке программного обеспечения, тип разработки программного обеспечения: en.wikipedia.org/wiki/Scrum_(development) .
4
2
Просто понял, что я случайно отклонил ваш комментарий ... не хотел. Они не позволят мне удалить этот голос, если вы не внесете незначительные изменения. Я никогда не видел, чтобы Scrum описывали как метод управления проектом. Интересный. При этом, я думаю, ожидание, что Scrum будет работать для программного обеспечения без применения TDD, является причиной того, что многие попытки «сделать agile» терпят неудачу.
Майкл Браун
1

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

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

Вадим
источник
1
Я бы не сказал, что требования постоянно меняются. Infact во время спринта требования являются статическими и неизменными. После каждого спринта приоритет требований может быть переоценен. Купите вашу общую цель не изменится.
Мартин Йорк,
@ Мартин, хорошая мысль. Думаю, мне стоит перефразировать, что они меняются от схватки к схватке.
Вадим
1

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

Вам нужно немного планирования, чтобы это работало. Введите совещание по планированию спринта , где команда оценивает задачи для спринта впереди. Большинство людей не понимают, что это не только оценочная встреча, но и проектная работа. Например, задачей может быть «Добавить код для новой модели автомобиля». Вы еще не можете оценить это, вам нужно знать немного больше. Таким образом, команда обсуждает дизайн и предлагает широкое решение («Автомобиль подкласса?») И добавляет это как напоминание к задаче. Вам редко нужно больше формальностей, чем это. Теперь у вас есть идея, как решить проблему. У вас еще нет всех деталей, и это хорошо, вы достаточно знаете дизайн, чтобы иметь возможность сделать комфортную оценку. Без необходимости создавать какие-либо диаграммы вообще (на данный момент).

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

Обратите внимание, что все диаграммы создаются после фактической реализации. Это согласуется с «рабочим программным обеспечением над всеобъемлющей документацией» и своевременным проектированием.

И да, читаемый код - это определенно документация.

Мартин Викман
источник
1

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

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

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

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

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

Блейк
источник
0

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

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

Ну, так мне все объяснили пять минут назад ...

indyK1ng
источник
0

Сегодня в сообществе Eclipse существует раскол между традиционными инструментами UML, ориентированными на MDD, в котором модель управляет кодом / разработкой, и Omondo, который считает, что итерации должны управлять процессом разработки, а не только моделью.

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

UML_GURU
источник