저는 약 3 년 동안 민첩한 방법론 (SCRUM)을 사용해 왔으며 특히 여러 수준의 단기 피드백에서 (초기 액세스 권한이있는 고객부터 구현 된 기능에 이르기까지 기능을 테스트 할 수있는 테스터) 새로운 코드에 대한 매우 빠른 피드백을 검토 등을 통해 제공 할 수있는 다른 개발자로부터 구현되는 즉시)

반면에, 나는 두 가지 열린 문제가 있는데, 그 중 첫 번째는이 질문에서 설명하려고합니다.

문제점 : 좋은 디자인을 얻는 데 어려움

코드가 지저분 해지면 리팩토링을 시도하고 가능한 한 단위 테스트를 작성합니다 ( 일반적으로 버그를 방지하고 특히 리팩토링 할 때 도움 이 됨). 다른 한편으로, 일일 커밋과 함께 약간의 복잡한 기능을 조금씩 개발하고 코드가 구조화되지 않을 때 코드를 계속 다시 생각하면 실제로 좋은 디자인을 만들 수 없습니다.

내가 최근에 생산할 수있는 유일하게 잘 디자인 된 모듈은 다른 접근법을 취함으로써 얻은 것입니다. 나는 며칠 동안 문제를 분석했습니다. ), 며칠 동안 모든 관련 클래스 및 관계의 다소 세부적인 디자인을 스케치 한 다음 내 사무실에 갇히고 약 3 주 동안 중단없이 작업하여 전체 코드를 작성했습니다. 결과는 찾기 쉽고 수정하기 쉬운 버그가 거의 없었으며 매우 명확한 디자인으로 인해 그 이후로 관련 변경이 필요하지 않은 최고의 결과였습니다.

그래서 지금까지 큰 그림이 마술처럼 프로세스에 등장하기를 희망하면서 코드를 작은 단위로 작성하기 전에 미리하고 싶은 것에 대한 전반적인 그림을 얻는 것이 훨씬 효과적이라는 것을 알았습니다. 최선의 노력으로 소규모 증분 개발 방식으로 인해 항상 디자인이 나빠졌습니다.

질문 : 비슷한 경험을 한 사람이 있습니까? SCRUM을 잘못된 방식으로 적용하고 있습니까? 또는 조금씩 개발하고 제대로 디자인 된 소프트웨어를 사용하려면 어떻게해야합니까? 아니면 실제 코딩을 시작하기 전에 디자인 사용자 스토리를 예약해야 합니까? 최소한 평균보다 복잡한 기능에 대해서는 이것이 모범 사례로 간주됩니까?

편집-참고

나는 좋은 디자인 이 절대적인 것이 아니며 그 자체로 가치가 없지만 상황에 달려 있다는 사실을 알고 있으며, 당면한 문제에 충분히 적합한 디자인을 목표로 삼아야합니다 .

예를 들어, 간단한 구성 요소를 구현해야하는 경우 (1) 가능한 한 빨리 준비해야하고, (2) 한 번만 사용하고, (3) 시스템의 다른 부분 (YAGNI)에서 사용합니다.

구성 요소 (1)을 여러 번 사용하고 제품의 여러 가지 다른 릴리스에서 (2) 시간이 지남에 따라 유지 관리 및 확장해야 할 때 (3) 구성 요소에 따라 다른 많은 구성 요소가있을 때 우수한 설계 .

답변