민첩한 방법론 : 빠르고 더럽거나 계획을 먼저 세우십니까?

민첩한 질문 : 애자일은 일을 시작하고 "빠르고 더러운 길"을 운영한다고 믿습니까? 아니면 방법론 질문이 아니며 사례별로 평가하는 질문입니까?

나는 이미 많은 구조 자체를 구축 한 후에 기술적으로 시스템의 기초를 "재창조"하고 있습니다. 그것은 엄청난 양의 작업이 아닙니다. 그것을 조정하고 빌드? 나는 이런 식으로 더 나은 방법으로 생각합니다 ... 지저분한 시스템을 세우면 어떻게 해야하는지 더 잘 볼 수 있습니다 ... 반면에 조직적이지 않습니다 ... 최고의 개발이 궁금합니다. 연습은이 점에 있습니다.

프로토 타입 작성 및 폐기 코드에 대해 묻지 않기 때문에이 질문은 애자일 및 프로토 타이핑과 다소 다르다고 생각 합니다. 프로덕션 등급 코드의 민첩성에 관심이 있습니다.

민첩한 방법론이 먼저 계획됩니다. 모든 것을 먼저 계획하지는 않습니다. 실제로 요구 사항, 디자인, 코드, 테스트, 배포 및 제시를 수집합니다. 배포하고 피드백을 얻을 수있는 가장 작은 기능에 대해 2 주도 안되는 시간 (주거나 가져 가기)으로 모든 작업을 수행하면됩니다. 그런 다음 다른 기능을 다시 추가하거나 이전 기능을 조정하십시오.

핵심은 변경을 허용하는 코드를 작성하여 "전체 흐름이 어떻게 진행되는지"를 볼 때 코드를 변경하여 변경할 수 있도록하는 것입니다. 이런 식으로 "흐름이 진행되는 방식"(또는 무엇이든)이 또 다시 바뀌면 외상이 아닙니다.

더럽고 더러운 글을 쓸 수 없습니다. 빠르고 더러운 것은 리지드 코드를 제공합니다. 작은 일을함으로써 금식하십시오. 지식을 전파하지 않음 으로써 유연성을 유지하십시오 . 이상적으로 단일 기능 변경은 코드의 한 위치에만 영향을 미칩니다.

계획을 세우는 것 외에는 아무 것도 할 수 없습니다. 계획을 세울 수는 있지만 계획을 변경할 수 있어야합니다. 계획을 변경해야하는 이유를 신속하게 찾아야합니다. 계획이 순조롭게 진행될 때, 배울 점이없이, 계획이 너무 오랫동안 진행된 시점입니다. 계획과 코딩은 서로 밀접하게 이루어져야합니다. 당신이 배우고 있다면 계획이 더 나이가 들수록 어둡습니다.

장기적으로 더 똑똑해질 계획입니다. 유연한 코드를 작성하십시오. 그러면 더 똑똑해 진다고해서 후회하지는 않습니다.

나는 대부분의 사람들에게 그것이 "빠르고 더러워 지거나" "큰 디자인의 선구자"라는 것을 싫어한다. 그들은 다른 옵션도 고려하지 않습니다.

애자일은 개발이 늦어도 변화가 사소한 시스템 구축에 관한 것입니다. 작은 증분 청크로 소프트웨어를 구축하고 강력한 자동 테스트로 해당 청크의 동작을 잠그면됩니다. 그리고 빈번하고 자동화 된 프로덕션 배치를 사용하여 이러한 변경의 가치를 검증합니다.

강력한 자동 테스트를 통해 장기간에 걸쳐 증분 리팩토링을 통해 아키텍처의 가장 어려운 부분이라도 변경하는 것이 쉽지 않습니다. 따라서 프로젝트 중간에 아키텍처를 더 잘 수행 할 수 있다는 사실을 알고 있어도 비교적 빠르게 변경하는 것이 현실적으로 가능합니다.

어떤 사람들은 "일부 디자인은 앞서 가기"가 민첩하다고 말합니다. 그러나 나중에이 디자인을 반복하려는 경우 개발 문화가 변경하기 쉬운 시스템을 생성하도록해야합니다. 따라서 "SDUF"는 강력한 테스트, 강력한 리팩토링 및 지속적인 배포의 필요성을 무효화하지 않습니다.

시스템에 "변경 용이성"을 구축하면 나중에 변경 될 수 있으므로 프로젝트의 초기 설계에 대해 열심히 생각할 필요가 없습니다. 대부분의 사람들은이를 "스파이크"라고 부르는 "빠르고 더러운"접근 방식은 가치있는 기능을 안정화 한 경우에만 사용할 수 있습니다. 그러나 코드베이스에 해킹 된 코드 조각을 너무 오래 남겨두면 변경 속도가 느려질 수 있습니다.

둘 다.

"간단히 시작하고 향상시키면서 개선"입니다.

빠르고 더러운 것은 부서지기 쉽지만 빠릅니다 (프로젝트가 충분히 작고 수명이 짧은 경우).

먼저 계획 은 단단하지만 안정적입니다 (프로젝트가 재정적 또는 시간적 제약을 받기 전에 완료된 경우).

애자일은 위의 2에 대한 대안입니다. 이 기능은 기능을 한 번에 하나씩, 기능별로 완성하는 반복적 인 접근 방식에 의존하며, 이러한 모든 기능을 갖춘 프로그램을 완성하면서 얻은 지식은 개발이 진행됨에 따라 계획을 구체화하고 조정하는 데 사용됩니다. 그러기 위해서는 미리 계획을 세워야합니다. 개별 기능에 필요한 작업량을 추정 할 수있는 계획이 충분해야합니다. 그러나 민첩한 변화를 기대하기 때문에 과도한 계획은 낭비로 이어집니다.

애자일의 주요 특징 중 하나는 짧은 반복을 수행 한 다음 재평가하는 것입니다. 새로운 지역을 탐험하고 배우고 계획을 세우기 위해 앞서 나갑니다. 그렇게하면 계획이 더 좋아질 것입니다. 그리고 만약 당신이 실패한다면 (과정 아이디어가 효과가없는 것을 찾으십시오), 당신은 "빠른 실패"를 할 것입니다.

그래서 당신의 접근 방식은 괜찮습니다. 그러나 위험은 "좋아요, 다 됐습니다. 다음은 무엇입니까?"라고 말하는 것입니다. 완료되지 않았으며 똑바로 깎을 코너가 많으며 접근 방식이 작동하고 작동 가능한 시스템을 제공하는 것이 확실 해지면 올바르게 처리 할 시간을 가져야합니다. 테스트 작성, 문서 작성, StyleCop, 최적화, 동료에게 수행 한 작업 및 수행 방식, 검토 방법 등에 대해 교육 할 수 있습니다.

위의 답변에 추가하기 위해 핵심 원칙은 YAGNI 입니다. 선행 디자인 및 계획을 통해 다음 단계를 수행 할 수 있다면 좋습니다. 그러나 증명할 수없는 가상의 미래 단계 가 필요하다면 YAGNI를 가정하십시오.

하향식과 상향식 모두의 많은 디자인은 코드 재사용이 상당하다고 가정합니다. 경험에 따르면 코드 재사용은 그리 일반적이지 않습니다. 왜냐하면 동일한 문제를 거의 해결하지 못하기 때문입니다. 나중에 해당 문제의 변형을 해결해야하는 경우 나중에 설계를 리 팩터하여 해당 변형을 추가하지만 지금은 고려 하지 마십시오 .

즉, 즉각적인 작업을 계획하되 앞으로 더 계획하지 마십시오.