애자일, 스크럼, 다음을 제공하는 소프트웨어 작성을 위한 멋진 단어
어떤 관점에서 보더라도 일반적으로 비즈니스 응용 프로그램 소프트웨어 개발자는 평판이 좋지 않습니다. 시스템은 거의 필연적으로 늦게 제공되거나 전혀 제공되지 않습니다. 일반 회사의 일반 사용자는 자신들이 견뎌야 하는 컴퓨터 시스템에 대해 불평하는 데 매주 문자 그대로 몇 시간을 소비합니다. “왜 그랬어?”, “그게 대체 무슨 뜻이야?” 제가 매일 듣는 몇 가지 이야기입니다.
나는 비즈니스 시스템을 작성하는 데 수년을 보냈으며 대부분의 사용자는 자신이 얻고 사용하는 것에 대해 긍정적이었습니다. 시스템은 초기 사양에 맞춰 작성되고 철저한 테스트를 거친 후 필요한 경우 합의된 비용으로 필요할 때 조정됩니다. 클라이언트에 대한 지속적인 지원과 소프트웨어 회사의 지속적인 수입은 성공적인 조합이었습니다. 상세한 요구 사항 분석을 기반으로 한 초기 사양은 항상 기능 개요일 뿐이며 코드 세부 사항을 포함하지 않습니다. 한 번은 (게임을 작성할 때) 의사 코드를 사용한 것 같습니다. “이것이 우리가 해야 할 일입니다.”라는 말은 대개 나에게 충분했습니다. 그 외에는 일부 사용자 인터페이스 모형과 많은 데이터베이스 디자인이 있었고 이제 끝이 났습니다. 개발 수명 주기의 테스트 및 '조정' 단계는 모두 중요했습니다. 시스템은 일반적으로 정시에 인도되어 작동되었습니다.
요즘(내가 그렇게 말하게 될 줄은 몰랐습니다) 시스템과 관련된 모든 것은 계획, 더 많은 계획, 그리고 재사용성에 관한 것입니다. 나에게 매우 이질적으로 보이는 것은 이러한 계획의 대부분이 기능적 요구 사항을 충족하기 위한 것이 아니라 우리가 작성한 내용을 작성할 때 어떻게, 왜 작성하는지 자세히 설명하기 위한 것입니다. 그게 말이 되기를 바라나요? 2년 뒤에 다시 사용해야 할 “가능성”이 있는데 왜 1000년 안에 할 수 있는 일을 10줄로 작성합니까? 개인적으로 나는 2년 후에 더 잘 다시 쓸 수 없는 글을 쓴 적이 없습니다. 나는 항상 배우고 발전하고 있습니다. 12개월이 된 코드를 되돌아보면 종종 움츠러들곤 합니다. 구인 광고를 보면 요구되는 방법론과 기술에 대해 길을 잃기 쉽습니다. 한 사람이 자주 스스로에게 물어볼 정도로 많은 것을 아는 것이 인간적으로 가능합니까? 또 다른 질문은 그들이 제품을 생산합니까? 이 모든 계획과 코드 재사용에 대한 걱정으로 어떤 일이 완료됩니까? 나는 디자인에 집중하느라 너무 바빠서 제품이 거의 준비되기도 전에 회사가 파산한 학술 개발자를 고용한 회사를 알고 있습니다. 사람들이 얼마나 많은 지연을 견딜 수 있을 것으로 예상할 수 있습니까? 테스트 단계는 결코 문제가 되지 않았습니다! 왜 우리에게 제품 비용을 지불하는 회사가 해당 제품이 아닌 이후 프로젝트에서 반복해서 사용될 코드 비용을 지불해야 합니까?
오해하지 마십시오. 계획이 나쁘다는 것이 아닙니다. 계획은 시스템 개발의 필수적인 부분이지만 유일한 부분은 아닙니다. 어쩌면 나는 구식일지도 모르지만 내가 즐기는 부분은 실제로 시스템을 작성하고 작동시키는 것입니다. 네, 시스템이 점점 더 커지고 복잡해지고 있다는 것을 알고 있습니다. 대규모 개발자 팀이 일반적입니다. 단지 아무리 많은 계획을 세우고, 시각화하고, 브레인스토밍을 해도 무언가는 항상 놓치게 마련이라고 생각합니다. 우리는 불가능하고 완벽한 시스템을 위해 노력하고 있지만 최악의 경우 실제로는 시스템을 제공하지 못하고 있습니다. 나를 믿지 못합니까? 마이크로소프트를 보세요. 애플리케이션을 계획하는 데 소요되는 인력 시간을 상상해 보십시오. 새로운 버그나 취약점이 얼마나 자주 발견됩니까? 왜 이것들은 디자인 단계에서 폐기되지 않았습니까? 개발팀에서는 "취약성 X"가 발생할 수도 있다는 생각조차 하지 못했습니다. 간단히 말해서, 가장 기본적인 시스템 이상의 것을 사용하면 아무리 논리적이더라도 모든 만일의 상황에 대해 계획을 세우는 것은 거의 불가능합니다. 테스트 중에 왜 발견되지 않습니까? 여기서 해결책은 구식 개발, 계획(대화) 시간 감소, 작성 및 테스트 시간 증가입니까? 코드 재사용에 대해 걱정하는 시간을 줄이고 클라이언트와 고객에게 작동하는 제품을 제공하는 데 더 많은 시간을 투자하시겠습니까? Microsoft가 계획에 소요되는 시간을 줄이고 테스트에 더 많은 시간을 쏟는다면 더 좋아질까요, 아니면 나빠질까요? Microsoft의 방어에 있어서 그들은 패치에 매우 능숙합니다. 아마도 그들이 우리를 테스터로 이용하는 것으로 보일 수 있을 것입니다. 아마도 그들이 적절한 테스트를 수행하는 데 더 많은 시간을 소비한다면 우리는 그들을 테스트할 필요가 없을 것입니다.
내가 아직 접하지 못한 과잉 계획의 최악의 예는 내가 매일 사용하는 금융 시스템입니다. 이 시스템을 구현하는 데 수백만 달러가 들었고, 수년간의 계획이 필요했으며, 컨설턴트 수는 얼마나 되는지 아는 사람이 없습니다. 소프트웨어 업계의 가장 큰 기업 중 하나가 전문 소프트웨어 컨설팅 회사에 의해 각색되어 작성되었습니다. 그 결과 시스템은 사실상 사용할 수 없게 되었으며, 기성 제품으로 교체하는 데 그리 멀지 않은 상황이 되었습니다. 가장 낮은 수준에서는 너무 나빠서 마우스를 잘못 클릭해도 응용 프로그램이 중단됩니다. 이 시스템이 넘겨지기 전에 테스트를 거쳤다는 사실이 믿기지 않습니다. 예상보다 '기획주기'가 길어져서 그대로 전달이 너무 늦어졌습니다. 그것이 하는 일은 그렇게 복잡하지 않으며, 단지 구현이 급하게 생각된 지점까지 분명히 계획되었다는 것입니다. 이 모든 계획으로 인해 사용자의 기본 기능 요구 사항을 충족하는 시스템이 탄생하지 못했지만, 훗, 언젠가는 해당 코드를 재사용하게 될 것이라고 확신합니다.
어쨌든, 저는 여러 가지 다른 계획 전략을 사용하는 것이 왜 그렇게 중요한지 이해하는 데 도움을 주기 위해 졸업장을 시작했습니다. "제대로" 한 달 동안 보낼 수 있는 일을 왜 하루 만에 작성합니까? 나는 몇 년 후에 이 글을 읽고 내가 무슨 생각을 하고 있었는지 궁금할 것이라는 것을 알고 있습니다. 그렇지 않으면 "와, 그때 내가 쓰고 있던 것을 실제로 끝내곤 했었지"라고 스스로에게 말할 것입니다. 하지만 진지하게, 나는 그것이 끝날 때쯤에 내가 어디에서 잘못되고 있는지 깨닫게 될 것이라고 확신합니다. 그 동안 나는 내 RAD 스타일을 사용하여 애플리케이션 작성을 계속할 것입니다(이름이 있어서 기쁘네요!). 모든 사람의 취향에 맞는 것은 아니지만 나에게는 잘 작동합니다.
주의 개발에 대한 나의 접근 방식에 이름이 있다고 누가 짐작이나 했겠습니까? Agile Methodology로 분류됩니다! 다음은 설명하는 훌륭한 기사입니다. 민첩한 방법론 좀 자세히.