스크럼에서 디자인을 어떻게 다루나요?

26

스크럼에서 디자인을 어떻게 다루나요? 각 스크럼 반복에 대해 잘 작성된 디자인 문서가 있습니까? UML 다이어그램을 특징으로하는 디자인 노트 만합니까? 아니면 주석이 달린 코드가 있습니까?

각 반복마다 디자인 변경이 필요할 수 있으므로 사람들이 이것을 어떻게 캡처하는지 알고 싶기 때문에 새로운 개발자가 도메인을 이해하고 가능한 한 빨리 보드에 오르는 작업을 쉽게 수행 할 수 있습니다.

design scrum

— 세스
소스

스프린트 이전과 도중에 팀이 디자인을 점진적으로 처리해야합니다. 대부분의 팀은 백 로그 개선을 진행중인 활동으로 통합하여 향후 백 로그 항목을 검토합니다. 팀이 노력을 추정하기에 충분한 솔루션을 설계하고 설계하기에 완벽한시기입니다. 생성 된 모든 유물은 스토리에 첨부되어야합니다. 스프린트 중에는보다 세분화 된 아키텍처 및 디자인 활동이 발생해야합니다. 이 유물도 첨부하십시오. 스토리가 완료되면 제공된 솔루션에 대한 풍부한 정보가 있어야합니다.

— treefiddy

11

스크럼이기 때문에 모든 스프린트가 변경되는 것은 아닙니다!

스크럼은 필요한 일을하는 것입니다 . 여전히 디자인을해야하고 문서화해야합니다. 그 금액은 고정되어 있지 않으며 어떻게해야합니까?

각 스프린트 계획 중 일부는 수행해야 할 작업을 결정합니다. 백 로그의 무언가가 다른 것들에 영향을 미치기 때문에 설계해야하는 경우, 설계 프로세스에 특정 태스크를 추가하고 구현 태스크 전에이를 수행해야합니다.

— 마틴 요크
소스

9

이 주제에 대해 할 말이 많습니다. 회사 / 팀 / 사람들이 소프트웨어에 대한 애자일 접근 방식을 사용하고 있다고 말하는 많은 사례를 보았지만 실제로는 애자일 방식이 원칙을 지키지 않고 약속 한 보상을 얻고 자합니다.

빠른 반복 작업을 위해서는 테스트 중심 개발을 수행해야합니다 (TDD를 마지 못해해야한다는 말을 멈췄습니다). TDD에서 테스트는 코드의 디자인과 의도를 표현합니다 ( "코드는 문서입니다"라고 말할 때 "테스트는 문서입니다"). 현재 기능에 대한 이해를 나타내는 단위 테스트를 작성하면 코드가 필요하다고 생각하는 것을 명시 적으로 나타냅니다. 그런 다음 코드를 작성하십시오. 그런 다음이 코드를 리팩터링하여 훌륭한 아키텍처 주체 인 "Red-Green-Refactor"를 준수하십시오.

체크인 할 때마다 (또는 체크인 할 때마다) 단위 테스트를 실행하면 작성한 새 코드가 응용 프로그램의 다른 영역에서 예상되는 기능을 중단하지 않는지 확인합니다. 이것은 무모한 포기로 코드를 변경할 수있는 안전망을 제공합니다. 현재 요구 사항에 대한 이해가 높아짐에 따라 새로운 지식을 반영하도록 테스트를 수정할 수 있습니다. 실제 디자인은 단위 테스트에 있습니다. 다루지 않은 코드를 포함한 다른 모든 것은 거짓말입니다.

다음은 몇 가지 권장 사항입니다

애자일 개발에 진정으로 접근하는 방법을 배우기 시작하기에 좋은 곳입니다.

— 마이클 브라운
소스

4

@ 머프 : 아이디어는 아키텍처가 등장한다는 것입니다. 아키텍처를 미리 정의하는 대신 테스트를 통해 찾아야합니다.

— Martin Wickman

5

@Martin 나는 일종의 볼 수 있지만 여전히 규모의 끔찍한 문제가 있습니다. 나는 그것을 특정 수준까지 편안하게 생각하지만 그 이상으로 ... 음 나는 당신이 아마도 스크럼 수준의 개발에 도달하기 전에 (또는 적어도 초기 구조를 가지고) 아마도 높은 수준의 아키텍처와 낮은 수준을 개선하고 발전시키는 팀).

— Murph

2

@ 머프 : 예 부트 스트랩은 문제입니다. 최소한 프로그래밍 언어를 선택해야합니다. 확장 성 및 성능과 같은 비 기능적 요구 사항은 아키텍처에 많은 영향을 미치며 최대한 빨리 고려해야합니다. 그러나 그 외에도 필자는 절대적으로 가능한 한 간단하게 시작한 다음 점진적으로 반복적으로 작업 기능 (yagni)을 조각별로 추가합니다. 리팩토링에 중점을 두어 코드베이스를 깨끗하게 유지하고 디자인이 나타날 때까지 추출하십시오.

— Martin Wickman

1

스크럼이 반복적 인 이유는 소프트웨어의 본질이 처음에는 제대로되지 않는다는 것을 의미하기 때문입니다. 많은 경우 이해 당사자들은 무언가 앞에 뭔가가 생길 때까지 그들이 정말로 원하는 것을 알지 못합니다. 더 좋은 점 : 기능에 대한 디자인을 작성하는 데 몇 시간을 소비하고 (고무가 포장 도로에 닿으면 다듬어야 할 가능성이 가장 높음) 해당 디자인을 구현 자에게 전달합니다. 또는 기능에서 첫 번째 패스를 구현하고 테스트 및 리팩토링을 통해이를 개선하는 데 시간을 소비합니다.

— Michael Brown

3

그건 그렇고, 테스트가 예기치 않게 빨간색으로 변할 때까지 TDD의 진정한 가치를 깨닫지 못할 것입니다. 그것은 TDD와의 나의 큰 "aha"순간이었다. 방금 빨갛게 변한 테스트를 살펴보면 테스트 없이는 코드가 테스터가 손에 든 후에 버그를 추적하기가 매우 어려울 것임을 깨달았습니다. 높은 수준의 하향식 아키텍처가 필요한 경우 코드에서 시퀀스 및 클래스 다이어그램을 생성 할 수있는 많은 도구가 있습니다. 그것들을 사용하여 스냅 샷 보고서를 받고 법이 아니기 때문에 폐기하십시오.

— Michael Brown

2

스크럼 은 소프트웨어 개발 방법론이 아니라 프로젝트 관리 방법론입니다. 스크럼은 일반적으로 애자일 방법론과 함께 사용됩니다. 거기에 당신의 대답이 있습니다.

— 스티븐 에이 로우
소스

4

스크럼은 민첩한 방법론이며 개발 팀과 스테이크 보유자에게 중점을두고 작업 코드를 반복적으로 제공합니다. 하향식 프로젝트 관리 및 스크럼은 석유 및 물과 같습니다.

— Michael Brown

1

@Mike는 동의했지만 Scrum은 프로젝트 관리자의 민첩한 방법론이며 Extreme Programming은 개발자의 민첩한 방법론이라고 항상 느꼈습니다. 즉, 스크럼이 소프트웨어 이외의 많은 프로젝트에 적용되는 것을 보았습니다. 흥미롭게도 Wikipedia는 이러한 Scrum 정의를 제공합니다. Scrum은 소프트웨어 엔지니어링 유형 인 애자일 소프트웨어 개발에서 자주 볼 수있는 프로젝트 관리를위한 반복적이고 점진적인 방법론입니다. en.wikipedia.org/wiki/Scrum_(development) .

— ahsteele

2

내가 실수로 귀하의 의견을 내리는 것을 깨달았습니다 ... 의미하지 않았습니다. 사소한 수정을하지 않으면 투표를 취소 할 수 없습니다. Scrum이 이전에 프로젝트 관리 방법으로 묘사 된 것을 본 적이 없습니다. 흥미 롭군 그러나 TDD를 적용하지 않고 소프트웨어에서 스크럼이 작동 할 것으로 기대하는 것이 "민첩한 행동"에 대한 많은 시도가 실패하는 이유라고 생각합니다.

— Michael Brown

1

요구 사항이 자주 변경되는만큼 선행 설계가 많지 않습니다. 따라서 클래스 수준으로 설계하는 것은 일반적으로 시간 낭비입니다. 그러나 더 높은 수준의 아키텍처 결정을 스케치하는 것이 좋습니다.

헤비 듀티 디자인 문서를 만들 때의 문제점은 문서를 만들 자마자 거의 쓸모가 없다는 것입니다. 따라서 가장 효과적인 방법은 일반적으로 짧은 시간 안에 완전히 변경되지 않는 고급 문서입니다.

— 바딤
소스

1

요구 사항이 지속적으로 변하고 있다고 말하고 싶지 않습니다. 실제로 스프린트 동안 요구 사항은 정적이고 변경되지 않습니다. 각 스프린트 후 요구 사항의 우선 순위를 다시 평가할 수 있습니다. 전체 목표를 구매해도 변경되지 않습니다.

— Martin York

@ 마틴 좋은 지적. 나는 그들이 스크럼에서 스크럼으로 바뀌고 있다고 말해야한다고 생각합니다.

— Vadim

1

스크럼은 민첩한 가치에 기반한 반복적이고 점증적인 모델입니다 . 즉, 별도의 디자인 단계가 없습니다. 아이디어는 프로젝트 전체에서 분석, 구현, 테스트 및 통합을 지속적으로 다루 듯이 디자인을 지속적 으로 다루어야 한다는 것 입니다.

이 작업을 수행하려면 약간의 계획이 필요합니다. 입력 스프린트 계획 회의 팀이 스프린트 앞서 대한 작업을 추정. 대부분의 사람들은 이것이 추정 회의 일뿐 아니라 설계 노력이라는 것을 인식하지 못합니다. 예를 들어 작업은 "새 자동차 모델의 코드 추가"일 수 있습니다. 아직 이것을 추정 할 수 없으므로 조금 더 알아야합니다. 따라서 팀은 디자인에 대해 논의하고 광범위한 솔루션 ( "하위 클래스 자동차")을 제시하고이를 작업에 대한 알림으로 추가합니다. 그보다 더 많은 형식이 거의 필요하지 않습니다. 이제 문제점을 해결하는 방법에 대한 아이디어가 있습니다. 아직 모든 세부 사항이 없으며 괜찮습니다 . 편안한 추정을 할 수 있도록 충분한 디자인을 알고 있습니다. 다이어그램을 전혀 만들지 않아도됩니다 (현재).

내용은 실제 물리적 문서 , 내가 추천 볼 수있는 모두를위한 벽면에 다이어그램 개관 시스템을 만들. 개요에는 가장 중요한 클래스와 모듈 만 포함하면되며 업데이트가 거의 필요하지 않습니다. 또한 시스템에서 가장 중요한 클래스에 대한 몇 가지 상태 다이어그램을 만드는 것이 매우 유용합니다. 사람들이 사물이 어떻게 연결되어 있는지 쉽게 알 수 있도록 전형적인 사용 사례의 몇 가지 선택 시퀀스 다이어그램을 뿌립니다. 코드에서 클래스 계층 다이어그램을 생성하여 문제를 쉽게 해결할 수 있다고 가정합니다.

모든 다이어그램은 실제 구현 후에 생성됩니다. 이것은 "포괄적 인 문서보다 소프트웨어 작동"과 적시 디자인을 유지하는 것입니다.

그리고 네, 읽을 수있는 코드는 확실히 문서입니다.

— 마틴 위크 먼
소스

1

프로젝트 소유자가 스토리를 만들 때 프로젝트의 전체 아키텍처와 높은 수준의 디자인은 스크럼 팀 외부에서 수행됩니다.

스토리와 고객의 기대 사이의 관계를 확인하는 데 도움이되도록 어떤 형태로도 작성된 전체 디자인이 충분해야합니다.

각 스토리에 필요한 일부 디자인은 계획 중에 제품 소유자와의 계획 및 협상에서 수행됩니다.

스토리의 디자인 노력은 대부분 스프린트에서 수행됩니다.

스토리가 추정하기에 충분히 정의되지 않은 경우, 현재 스프린트에 시간 상자를 설정하여 나중에 스프린트에 적합한 스토리를 작성할 수있는 충분한 디자인 작업을 수행 할 수 있습니다.

— 블레이크
소스

0

본인은 프로젝트 시작시 수집해야하는 선행 요구 사항으로 더 높은 수준의 디자인을 수행한다는 것을 이해하고 있습니다. 이 디자인을 잘 문서화했습니다.

그런 다음 실제로 요구 사항을 구현할 때는 필요에 따라 하위 수준 디자인을 변경하지만 상위 수준 디자인을 변경하지 마십시오.

어쨌든 그것은 5 분 전에 나에게 설명 된 방법입니다 ...

— 인디
소스

0

오늘날 Eclipse 커뮤니티에는 모델이 코드 / 개발을 주도하는 MDD에 초점을 둔 전통적인 UML 도구와 반복이 모델뿐만 아니라 개발 프로세스를 주도해야한다고 생각하는 Omondo가 분리되어 있습니다.

MDD는 쓰레기이기 때문에 UML은 다른 팀원들과 의사 소통하기 위해 표준화하기 때문에 정말 훌륭한 방법입니다. 대체 텍스트

— UML_GURU
소스