'하나님'이 누구인지 이해했다면, 하나님에 대해 인내해야 합니다. 일반적으로 이공계 전공자들은 논리적 사고력이 뛰어나지만, 이해관계자 입장에서는 꼭 그렇지는 않습니다. 한번은 아카이빙 작업을 하고 있는 이해관계자를 만난 적이 있는데, 요구 사항을 이해하자 그는 막연하게 횡설수설했습니다. 1분 동안 명백히 거부되었던 방식이 다음 1분에 다시 제안되었습니다. 나는 화를 잘 낸다고 생각했지만 결국 화를 낼 뻔했습니다. 다행히 나는 마침내 살아남을 수 있었다. 이번 사건을 겪고 나면 인내심 지수가 많이 좋아질 것 같아요.
제가 존경하는 동료가 있는데, 그는 웹사이트 프로젝트에서 시스템 분석을 담당했습니다. 그는 웹사이트 프로젝트 담당자와 꼬박 3일을 보냈다. 최종 시스템 분석을 마치고 정신은 좋았으나 담당자는 죽어가고 있었다. 물론 이것은 단지 농담일 뿐, 모두가 열심히 하라고 격려하는 것은 아닙니다. 일과 휴식의 균형은 여전히 매우 중요합니다. 신체는 혁명의 수도입니다. 하지만 이는 인내심이 부족하면 수요에 성공하기 어렵다는 것을 말해준다. 예를 들어 비즈니스 모델링 세미나에서 높은 수준의 요구 사항을 논의할 것이라고 약속했지만 참가자들은 항상 사소한 문제에 대해 때때로 논쟁을 벌이게 됩니다. 당신은 무엇을 해야 합니까? 나는 이런 상황이 매우 흔하다고 생각합니다.
인내심은 결국 의사소통에 반영됩니다. 오직 인내심 있는 의사소통을 통해서만 욕구의 베일을 밝힐 수 있습니다. 사람들의 행동은 항상 그들의 생각에 따라 결정됩니다. 이해관계자의 매듭을 풀 수 없다면 그가 정말로 필요한 것이 무엇인지 이해할 수 없을 것입니다.
내 프로젝트 이해관계자 중 한 명이 매우 이상하게 행동합니다. 그녀는 항상 한 가지만 말합니다. 자동으로 보고서를 생성하고 싶다는 것입니다. 그녀의 요구 사항은 이 범위에 속하는 것 같았지만 나는 그녀에게서 그 외에는 거의 아무것도 듣지 못했습니다. 이때 그녀에게서 더 이상 정보가 없을 수도 있다는 생각에 포기하기로 결정했습니다. 하지만 직장에서 보고서 처리에 많은 시간이 걸린다는 사실을 알고 마음이 바뀌었습니다. 보고서 처리에 대한 그녀의 생각을 명확히 설명하는 데 시간을 보낸 후 그녀는 다른 측면에서도 나에게 많은 도움을 주었습니다. XP 방식의 중요한 실천은 "현장 고객"을 홍보하는 것입니다. 즉, 고객은 항상 개발자와 함께 정보를 제공하고 결정을 내려야 합니다. 그리고 이 고객 역시 해당 분야의 전문가여야 하며, 권위를 가지고 의사결정을 내릴 수 있어야 합니다.
현장 고객들은 대부분의 국내 소프트웨어 기업이 이를 할 수 없다고 믿고 있습니다. 하지만 우리는 이 점에 있어서 열심히 노력해야 합니다. 제 생각에는 현장 고객에는 두 가지 유형이 있습니다. 하나는 프로젝트 이해관계자이고 다른 하나는 업계 전문가입니다. 실제로 많은 소프트웨어 회사에는 업계 전문가인 경영 컨설턴트가 있습니다. 통계에 따르면 광둥성 소프트웨어 회사의 컨설턴트 대 개발자 비율은 3:1에 달했습니다. 나는 이것이 좋은 것이라고 생각합니다. 프로젝트 이해관계자는 자신의 작업의 거래 측면을 깊이 이해하는 경우가 많지만 이를 이론적인 수준으로 끌어올리는 것은 어렵습니다. 현재 일부 업계 전문가의 도움이 필요합니다. 업계 전문가와 프로젝트 이해관계자가 함께 논의하도록 하면 프로젝트 이해관계자가 결코 생각하지 못했던 측면을 생각하도록 영감을 줄 수도 있습니다. 이것이 바로 '잠재수요'의 발전이다. 한편, 참여는 프로젝트 이해관계자가 비즈니스 모델링 프로세스에 온 마음을 다해 헌신하고 열정을 동원할 수 있어야 함을 의미하기도 합니다. 따라서 너무 복잡한 프로세스는 이해관계자의 참여를 방해할 수 있습니다. 따라서 비즈니스 모델링을 위해 고객이 수용할 수 있는 몇 가지 간단한 아티팩트를 사용할 필요가 있습니다. 앞에서 논의한 "주인공"과 "사용 사례"는 이론이며 개발자가 볼 수 있도록하여 개발자가 명확한 아이디어를 가질 수 있도록 말한 것입니다. 이해관계자들에게 보여주면 이해해줄까요? 그들이 이 메커니즘을 이해할 때쯤에는 원추리의 식어버릴까 두렵습니다. 사용자 스토리, 기능 및 CRC 카드는 모두 매우 좋은 아티팩트이며 간단하고 요구 사항을 충족할 수 있습니다. 지식 포인트: 재료와 기능 모두 사용자의 간단한 요구 사항을 표현하며 짧은 시간 내에 완료할 수 있습니다. XP 방식에서는 재료가 가공물이고, FDD 방식에서는 형상이 가공물입니다.
CRC는 Class(클래스), Responsibility(책임), Collaborator(협력자)의 약자로 클래스 이름, 클래스의 책임, 클래스 간의 협력 관계를 각각 표시한 세 부분으로 나누어진 카드입니다. 고객과 매우 가깝고 게임 중에도 카드를 작성할 수 있어 강력한 고객 참여를 가져올 수 있습니다. 나는 이것이 개발자들로부터 만장일치로 비판을 받을 것이라고 생각한다. 결국, 요구 사항 변경은 개발자가 가장 싫어하는 것 중 하나입니다. 응, 나도 싫어. 그런데 우리가 흔히 “울어도 문제가 해결되지 않는다”고 말하듯이, 미워하는 것도 문제를 해결할 수 있을까요? 고객의 변경 요청을 거부하고 고객에게 요구 사항 사양에 서명하도록 요구합니다. 이러한 관행은 역효과를 낳을 뿐입니다. 긍정적인 의미는 없습니다.
필요한 요구사항 변경 관리가 중요합니다. 끝없이 통제되지 않는 변화는 필연적으로 막대한 자원 낭비를 초래하기 때문입니다. 그러나 반면에 수요 변화를 수용하는 기준은 "합리적인지 여부"여야 하며, 수요 변화는 요구 사항, 설계, 구현 및 기타 단계를 포함하여 개발 작업을 반복적으로 수행해야 합니다. 이렇게 하면 변경 위험을 최소화할 수 있습니다. 이에 대해서는 특정 요구사항 모델링을 논의할 때 더 자세히 논의하겠습니다.
변화 수용의 다음 단계는 변화를 미리 예측하는 것입니다. 가능한 변경 사항을 문서화하기 위해 가능한 변경 사항 목록을 개발합니다. 가장 간단한 예는 기업이 구매, 판매, 재고 시스템을 개발한 후, 이에 연결하기 위한 회계 시스템을 개발하고자 하는 것입니다. 미리 예견을 남겨주시면 많은 수고를 덜 수 있을 거라 믿습니다. 변화를 추정하는 또 다른 방법은 패턴을 사용하는 것입니다. 하지만 패턴을 과도하게 사용하지 마십시오. 이것은 여담이며 기회가 있으면 다른 기사에서 이 측면에 초점을 맞출 것입니다. 7. 비즈니스 모델링 실습 (Practice) 회의는 비즈니스 모델링의 가장 중요한 수단입니다. 중국에서는 회의가 항상 오명을 받았지만 잘 조직된 회의는 매우 효과적인 의사소통 수단입니다. 모델회의는 대규모 회의, 즉 관련자가 모두 참석해야 하는 회의이다. 비즈니스 모델링 기간 동안 주요 목적은 시스템에 대한 높은 수준의 요구 사항을 설정하는 것이므로 요구 사항의 폭을 보장하기 위해 많은 프로젝트 이해 관계자의 공동 참여가 필요합니다. 따라서 모델링 컨퍼런스의 규모는 상당히 큽니다. 자금 제공자, 고위 관리자, 관리자, 직접 사용자, 개발자 등 모두가 모델링 회의에 참석하거나 대표자를 파견해야 합니다.
대규모 회의에 참여해 본 적이 있다면, 회의 규모가 클수록 의사결정 효율성이 떨어진다는 사실을 아실 겁니다. 이것은 정상입니다. 왜냐하면 혼자 있을 때 의사소통이 필요 없고 의사결정이 가장 효율적이기 때문입니다. 두 사람이 함께 있을 때 의사결정을 하기 위해서는 의사소통의 시간이 필요합니다. 세 사람이 있으면 의사소통하고 합의에 도달하는 데 시간이 더 오래 걸립니다. 4명, 5명, 심지어 10명, 20명이 있다면 대부분의 시간은 의사소통에 소비됩니다. 게다가 여전히 사람들 사이에는 생각의 차이와 이해상충이 존재합니다. 따라서 회의의 효율성과 효율성을 보장하려면 다음과 같은 특정 규칙을 따라야 합니다.
· 준비하십시오: 회의를 할 예정인데 참가자가 내용조차 알지 못하는 경우, 무엇을 해야 할까요? 당신은 할 것인가? 먼저 회의의 목적을 설명하는 데 많은 시간을 투자해야겠죠? 회의의 주제와 의제는 회의 공지와 함께 참석자들에게 미리 전송되어야 회의가 시작될 때 신속하게 준비하고 요점에 도달할 수 있습니다.
·최대한 많은 사람을 초대하라: 모델 회의는 최대한 폭넓은 의견을 듣지 못하면 성공적인 회의가 아니라고 말했다. 그러나 실제로는 이를 달성하기 어려운 경우가 많습니다. 고객으로서 대상 조직은 종종 매우 강압적이기 때문에 회의의 중요성을 완전히 이해하기 전에 모든 사람이 참석하는 것은 불가능합니다. 객관적으로 말하면 출장, 휴가, 중요한 일 등으로 인해 이를 불가능하게 만드는 이유가 있을 수 있습니다. 여기서는 한편으로는 대상 조직의 의사결정자들의 이해관계와 피해를 명확히 하고 그들이 이에 주의를 기울이도록 해야 합니다. 한편, 프로젝트 이해관계자들이 적극적으로 참여하도록 초대해야 합니다. 모든 사람을 초대하는 것은 불가능하므로 최대한 많은 사람을 초대하도록 하세요.
·참석자 등급 분리: 저는 내부 서클과 외부 서클이 있는 회의실을 정말 좋아합니다.
제가 모든 사람을 초대하는 것은 불가능하기 때문에 먼저 핵심 직원이 모두 참석하여 안쪽 서클에 앉을 수 있도록 하고, 그 다음 보조 직원이 바깥쪽 서클에 앉도록 해야 합니다. 핵심 인력은 프로젝트와 밀접하게 관련된 사람들입니다. 예를 들어, 금융 시스템에서는 재무 이사가 핵심 인력입니다. 핵심인력은 모두 확보해야 하며, 보조인력은 완전할수록 좋다.
·바닥부터 시작하라: 중국인은 나쁜 습관이 있다. 즉, 상사가 하나라고 하면 절대 두 개를 말하지 않는다는 것이다. 그러므로 맨 아래 단계의 사람이 먼저 말하고, 그 다음 중간 단계의 사람, 그다음에 높은 단계의 사람이 말하게 하십시오. 개발자는 말하지 않고, 모든 사람이 말하도록 듣거나 안내합니다. 처음부터 리더들에게 강의를 하게 된다면 밑에 있는 사람들은 더 이상 말할 필요가 없을 것입니다.
·모든 이해관계자의 의견을 모두 나열합니다. 먼저 모든 사람이 새로운 시스템에 대해 자유롭게 말할 수 있도록 한 다음 모든 의견을 화이트보드에 나열합니다. 여기에 우스꽝스러운 아이디어가 있을 수도 있지만 괜찮습니다. 그냥 적어보세요. 이는 브레인스토밍 과정이므로 새로운 아이디어가 떠오르기 쉽습니다. 호스팅 개발자의 주요 임무는 모든 사람이 더 많은 아이디어를 표현하고 기록하도록 안내하고 격려하는 것입니다. 여기서 조금 다른 이야기를 하자면, 대부분의 중국 사람들은 회의에서 자신의 의견을 표현하는 것을 꺼린다고 하는데, 이런 모델 회의에서는 그다지 걱정할 필요가 없다고 생각합니다. 왜 그럴까요? 프로젝트 이해관계자가 자신의 발언에 대해 어떤 책임도 질 필요가 없기 때문입니다. 말하지 않는 사람은 헛된 일이 될 것입니다.
·카테고리 아이디어: 프로젝트 이해관계자들은 약간 피곤할 것이고 그들의 아이디어는 거의 사라졌으며 화이트보드는 아마도 꽉 찼을 것입니다. 그런데 화이트보드에 적힌 아이디어를 보면 반복되는 것도 많고 비슷한 것도 많습니다. 따라서 이러한 아이디어를 분류하려면 논리적 개념을 사용해야 합니다. 또한 모든 사람이 이 일을 하도록 지도할 수도 있습니다.
·우선순위 지정: 아이디어의 우선순위를 지정하는 것도 중요한 위험을 식별하고 반복 계획을 개발할 때 지침을 제공하는 데 도움이 될 수 있습니다. 다시 말하지만, 이 작업은 프로젝트 이해관계자에 의해 결정되어야 합니다.
·주요 비즈니스 로직 조사: 주요 비즈니스 로직은 무엇입니까? 여기에는 회사의 주요 비즈니스 프로세스, 주요 비즈니스 규칙 및 주요 알고리즘이 포함됩니다. 이는 처음에 명확하게 설명하고 모델링 세션에서 이해해야 하는 모든 정보입니다. 물론 프로젝트 이해관계자에게 다음으로 주요 비즈니스 로직에 대해 이야기해 보도록 말할 수는 없습니다. 아래 이해관계자들은 머리를 긁적여야 합니다. 여전히 이해관계자를 안내하고 그들의 말에서 필요한 정보를 포착해야 합니다.
·회의 시간에 주의하십시오. 사람은 기계가 아니므로 피곤할 것입니다. 따라서 회의 시간을 조절하는 것이 중요합니다. 일반적으로 이런 종류의 회의는 4~5시간 동안 진행됩니다. 통계에 따르면 2시간 이내에 회의를 해도 피로감을 느끼지 않습니다. 따라서 회의는 짧은 부분으로 나누어야 합니다. 또한, 회의 진행 상황에 따라 각 단기 회의에 참여할 인원을 결정할 수도 있습니다. 왜냐하면 회의가 진행됨에 따라 일부 참석자의 중요도가 낮아지기 때문입니다.
·세부 사항 피하기: 모델링 세션의 주요 목표는 높은 수준의 요구 사항을 설정하는 것입니다. 사소한 문제를 논의하는 데 너무 많은 시간을 소비한다면 그것은 모두의 시간 낭비가 될 것입니다. 이 시점에서는 요구 사항의 세부 사항을 조사하는 것이 거의 의미가 없습니다. 아직 많은 것을 이해하지 못했고 더 깊이 탐구해야 하기 때문입니다. 이 시점에서 자세한 내용은 별로 도움이 되지 않습니다.
·기술 회피: 모델링 미팅에서 기술을 담당하는 이해관계자를 만났습니다. 그는 항상 시스템의 기술 아키텍처에 대해 질문하고 자신의 디자인 컨셉을 홍보했습니다. 기술적인 문제는 따로 논의할 시간을 마련할 것이라는 점을 여러 번 거듭 말씀드리고 싶습니다. 나는 기술자가 더 나은 아이디어를 가지고 있어야 하고 잘 수행하기를 희망해야 한다고 생각합니다. 하지만 지금은 기술을 논의할 때가 아닙니다. 요구 사항이 아직 명확하지 않습니다. 기술 구현에 대한 논의는 말보다 중요하지 않습니까?
·기록을 유지하라: 좋은 기억은 나쁜 글쓰기보다 나쁘다는 속담이 있다. 그래서 회의 중에 메모를 잘 하는 것이 매우 중요합니다. 이러한 회의에는 비용이 많이 들기 때문에 프로젝트 이해 관계자가 매일 일하지 않고 회의에 동행하는 것은 불가능합니다. 그러므로 회의 결과를 최대한 활용하기 위해서는 우수한 속기사가 반드시 필요하다.
또한, 연구에 따르면 녹음기를 사용하면 참가자들이 말하기를 꺼려하게 되므로 녹음기를 사용하지 마십시오. 요구 사항의 초기 단계에서 테스트를 언급하는 것이 이상하게 느껴질 수도 있습니다. 모든 프로젝트에는 항상 성공 여부를 평가하는 기준이 있습니다. 여기서 테스트는 소프트웨어 프로젝트의 성공 여부를 평가하기 위한 실행 목표를 의미합니다.
이 목표는 소프트웨어 개발이 갖춰야 할 최종 조건이자 소프트웨어의 성공 여부를 판단하는 기준이 될 것이다. 많은 기업은 정보 기술을 구축할 때 상대적으로 명확한 목표를 갖고 있지 않습니다. 따라서 이 문제에 대해 질문을 받으면 내 목표는 기업의 ERP 시스템을 구축하고 기업의 정보 플랫폼을 구축하는 것입니다. 그러한 소프트웨어를 개발하는 방법은 무엇입니까? 끝나는 기준은 없습니다. 수수료가 모두 소진되면 종료되나요, 아니면 의사결정자가 중단하겠다고 하면 중단되나요? 목표에는 수량화할 수 있는 기준이 있어야 합니다. 예를 들어, 물류 시스템 개발의 목적은 제품 회전 주기를 단축하고 재고를 줄이는 것이고, 공급망 시스템 개발의 목적은 공급업체와의 연결을 강화하고 재고를 줄이는 것입니다. 특정 사업과 관련된 이러한 지표는 여러 하위 지표를 사용하여 정제되고 측정될 수 있으므로 달성할 수 있습니다.
우리는 이 목표를 테스트라고 부르는데, 이 목표를 달성하는 것이 최종 테스트로 간주되어야 함을 개발자에게 상기시키기 위한 것입니다. 아무리 좋은 소프트웨어라도 이해관계자가 원하는 것이 아니라면 무슨 소용이 있겠습니까? 이는 매우 단순한 진실이지만, 실제로 이해관계자와 개발자는 특정 요인으로 인해 이를 간과하는 경우가 많습니다. 사실 우리는 이전 기사에서도 이 목표에 대해 이야기했습니다. 당시 우리는 그것을 비전과 범위라고 불렀습니다. 본질적으로 동일합니다. 이 "실행 가능한 목표"는 다양한 요소를 사용하여 측정할 수 있습니다. 비즈니스 엔터티는 기업에서 핵심 역할을 하는 범주입니다. 고객, 공급업체, 직원, 주문, 바우처 등 이러한 사업체의 예는 많습니다. 시스템에서 비즈니스 엔터티를 운영하는 역할의 동작이 종종 비즈니스 엔터티에 할당되기 때문에 비즈니스 엔터티는 종종 매우 중요한 요소가 됩니다. 예를 들어 "주문에 따른 가격 계산"은 여러 비즈니스 엔터티가 서로 협력하여 완료됩니다. . 따라서 비즈니스 엔터티 디자인의 품질은 시스템에 큰 영향을 미칩니다.
비즈니스 엔터티 디자인의 주요 작업에는 비즈니스 엔터티를 찾고 비즈니스 엔터티의 속성과 동작을 결정하는 것이 포함됩니다.
비즈니스 엔터티를 결정하려면 먼저 역할을 결정하고 역할의 동작에서 비즈니스 엔터티를 찾아야 합니다. 역할을 수행하려면 대상 조직에 대해 논의해야 합니다. 내 개인적인 경험으로는 일반적으로 비즈니스 역할을 찾는 것이 더 쉽지만 한 사람이 여러 비즈니스 역할을 맡을 수 있다는 점을 기억하십시오. 비즈니스 역할의 동작을 통해 비즈니스 역할이 무엇을 처리하는지 알 수 있습니다. 이것이 우리에게 필요한 비즈니스 엔터티입니다. 사업체가 별도의 사업체인지 아니면 사업체의 속성인지 연구해볼 가치가 있습니다. 속성이어야 할 것이 사업자로 판단되면 약간의 오버헤드만 발생하게 되지만, 별도로 기재해야 할 사업자가 다른 사업자의 속성으로만 판단되면 큰 손해를 가져올 수 있습니다. 결과적으로 가장 큰 가능성은 시스템 확장이 어렵다는 것입니다.
인적 자원 관리 시스템에서 직원 클래스는 매우 중요한 비즈니스 개체일 수 있으며 많은 속성을 가질 수 있습니다. 구매, 판매, 재고 등 다른 시스템에서 직원 클래스는 기록 및 권한 관리 역할만 수행합니다. 또 다른 예로, 기업의 일부 내부 자동화 처리 시스템에서 고객은 단지 다른 개체의 속성일 수 있습니다. 그러나 고객 중심 디자인이 대중화되는 21세기에 이러한 디자인에는 치명적인 결함이 있습니다. 비즈니스 엔터티의 속성과 동작을 결정하는 것은 주로 각 클래스(비즈니스 엔터티)가 수행하는 작업을 결정하는 것입니다. 속성은 클래스와 클래스가 수행하는 작업을 더 잘 설명하기 위한 것입니다. CRC 카드를 사용하는 것이 좋습니다. CRC는 "class", "responsibility" 및 "collaborator"의 약어입니다. 이러한 정보는 종종 카드에 표시됩니다.
클래스 이름 Responsibility 1 Responsibility 1 Auxiliary 1 of Responsibility 1 Responsibility 2 Auxiliary 2 of Responsibility 2... 이러한 CRC 카드를 만들면 각 사업체의 행위(책임)와 속성(보조)을 더 쉽게 알 수 있습니다. 모든 문제를 해결하는 대신 속성과 동작만 알아내는 것이 어떻냐고 물을 수도 있습니다. 이 문제는 우리가 강조해온 것입니다. 모델링 단계에서 우리는 컴퓨터 기술을 전혀 이해하지 못하는 이해관계자와 마주하게 됩니다. 따라서 모든 사람이 쉽게 받아들일 수 있는 방법을 사용하면 요구 사항이 완전하고 정확하다는 것을 확인할 수 있습니다. 소프트웨어 개발에는 계획에 대한 두 가지 극단적인 오해가 있습니다. 일부 소프트웨어 조직에서는 일반적으로 계획이 수립되지 않거나 일반적이고 쓸모없는 계획이 수립됩니다. 일부 개발자는 계획을 세우는 것은 소용이 없으며 실용적인 일을 하는 것이 더 낫다고 믿습니다. 프로젝트 관리자에게는 이 상황을 처리할 방법이 없거나, 발표된 계획의 개발자가 계획에 반대하여 계획을 데드 레터로 만듭니다. 프로젝트 실행에는 자의성이 크고, 방향에서 벗어나는 일이 자주 발생합니다.
다른 조직에서는 기획을 최우선 과제로 여기며 많은 시간과 인력이 필요하고, 만들어진 계획은 상세하고 철저하다고 설명할 수 있다. 그리고 그러한 계획을 작성할 수 있는 프로젝트 관리자도 선배 인재로 평가됩니다. 개발자는 "프로그램 쓰는 사람이 문서 쓰는 사람만큼 못하더라"며 한숨을 쉬었다. 그러나 실행 과정에서 원래의 정교한 계획은 허점으로 가득 차 있었고, 프로젝트 진행은 계속해서 지연되었습니다. 우리 모두는 다음과 같은 분명한 말을 알고 있습니다. 소프트웨어 개발에서는 프로젝트의 90%를 완료하는 데 90%의 시간이 걸리고 나머지 10%의 프로젝트를 완료하는 데 90%의 시간이 걸립니다. 왜? 그 계획은 비과학적이다.
경영에서 계획이란 "조직의 목표와 이를 달성하기 위한 전략, 수단, 단계 및 절차를 결정하는 프로세스"로 정의됩니다. 예를 들어, 상자를 어떤 곳으로 밀고 싶은 경우, 이 장소에 도달하려면 경로와 밀어야 하는 속도를 추정해야 합니다. 그런 다음 경로와 속도를 조정해야 하는지 확인하기 위해 때때로 원래 계획과 비교하기 시작했습니다. 이 견적이 계획입니다.
기획의 목표는 오류를 제거하는 것이 아니라 모든 오류를 신중하게 계획된 작은 오류의 모음으로 바꾸는 것입니다. 네 가지 디자인 방법을 연구한 끝에 결국 세 가지를 포기했습니다. 기껏해야 세 가지 작은 실수에 불과했습니다. 그러나 잘못된 디자인으로 인해 프로그램을 세 번 다시 작성하면 세 가지 큰 실수가 발생할 수 있습니다.
그런데 위에서 언급한 두 가지 극단은 왜 나타나는 걸까요? 첫 번째 상황은 실제로 소프트웨어 산업의 초기 형태입니다. 계획이 없고 리소스 할당이 혼란스럽고 소프트웨어 개발 프로세스가 혼란스럽고 무질서하며 자발적인 상태입니다. 프로젝트의 성공은 전적으로 프로젝트 구성원의 행운과 개인의 능력에 달려 있습니다. 두 번째 상황은 실제로는 고급 형태인데, 가장 대표적인 것이 앞서 언급한 폭포 모델이다. 그렇다면 이렇게 잘 계획된 계획이 왜 그렇게 쉽게 실패하는 걸까요? 그것은 간단합니다. 충분히 생각해 보았다고 생각하지만 실제로는 그렇지 않을 수도 있습니다. 나는 일주일에 7일이라는 일정을 가지고 잘 계획된 계획을 세웠다고 광고하는 사람들을 본 적이 있습니다. 애초에 개발자들에게 휴식을 줄 생각은 없었던 것 같습니다. 계획은 미래에 대한 추정입니다. 이제 6개월 후의 상황을 누가 정확하게 알 수 있을까요? 9.11 이전에 그날 이렇게 큰 일이 일어날 것이라고 예상한 사람이 몇 명이나 있었습니까? 그렇다면 반년, 심지어 1년 뒤에 무슨 일이 일어날지 예측하는 이유는 무엇입니까? 또한 개발자를 대신하여 계획을 세울 수 있을 만큼 개발자를 잘 알고 있습니까?
어떤 사람들은 계획이 빨리 바뀌지 않는다고 말합니다. 이 문장은 매우 정확합니다. 계획을 세우지 않는 것은 불가능하고 실행 가능한 계획을 세우는 것도 불가능하다는 점을 상기시켜 줍니다. 계획은 과시하기 위한 것이 아니라 실행하기 위한 것입니다. 계획을 세울 때 화려한 말이나 아름다운 아이디어는 필요하지 않습니다.
하지만 우리는 몇 가지 요소 없이는 살 수 없습니다:
·무엇(무엇): 목표를 달성하는 데 필요한 작업을 순서대로 나열합니다.
·언제(WHEN): 완료하는 데 필요한 것이 무엇입니까? 작업 시간,
·HOW-WELL: 완료해야 할 작업을 측정하는 기준,
·RESOURCES: 작업을 완료하는 데 필요한 사람/자금 등 ;
·누구(WHO): 작업을 완료하는 책임을 맡은 사람입니다.
그러나 우리는 여전히 현실과 계획의 괴리라는 문제에서 벗어날 수 없다. 지금으로부터 1년 후에 어떤 일이 일어날 것으로 예상되는지에 대해서는 확신할 수 없지만, 개발자들이 무엇을 생각하고 있는지에 대해서는 확신할 수 없습니다. 하지만 2주 후에 당신에게 무슨 일이 일어날지 생각해 보면, 여전히 꽤 잘 추측할 수 있을 것입니다. 이는 반복(iteration)의 개념을 가져옵니다. 프로젝트는 여러 개 또는 수십 개의 반복 주기로 구성되며 각 반복 주기는 상대적으로 예측하고 계획하기가 쉽습니다. 이것이 바로 반복(iteration)의 아이디어이자 소프트웨어 공학 기술의 큰 도약이다. 그러고 보니 다시 한 번 여러분의 식욕을 자극하고 싶습니다. 상세한 요구사항 모델링을 논의할 때 반복 계획의 구체적인 개발에 대한 논의는 다음 장으로 남겨두겠습니다. 훈련 없이 프로젝트가 어떻게 진행되는지 상상하기 어렵습니다. 군사서에는 '삼군은 움직이지 않지만 식량과 풀이 먼저다'라는 말이 있다. 프로젝트의 경우에도 마찬가지입니다. 처음에는 교육 계획을 명시하고 교육을 위한 시간을 따로 확보해야 합니다. 완벽한 팀이 아니면 구성원들이 이해하지 못하는 부분이 있을 거라 생각합니다. 훈련 계획도 없고 학습 과제가 개인에게 주어지면 프로젝트의 위험은 통제하기 어려워질 것입니다. 훈련이라고 하면 모두가 진지하게 앉아서 선생님의 말씀을 듣고 있다고 생각할 수도 있습니다. 여기서 언급된 교육은 일련의 교육일 수도 있고, 회의, 토론, 교류일 수도 있습니다. 목적은 팀 구성원이 프로젝트를 완료하는 데 필요한 충분한 지식과 기술을 갖추는 것입니다.