[애자일 개발: 프로세스보다 사람이 중요하다] 소프트웨어 애자일 개발 프로세스

전통적인 소프트웨어 개발 방법에 비해 애자일 개발은 소프트웨어 개발에서 사람의 역할에 더 많은 관심을 기울이고 변화하는 비즈니스 요구 사항을 충족하기 위한 신속한 반복, 지속적인 통합 및 테스트 중심 개발을 강조합니다. 1960년대에 시작된 소프트웨어 위기는 소프트웨어 개발에 대한 사람들의 생각을 촉발시켰고, 이에 따라 "소프트웨어 공학"이라는 학문이 탄생했습니다. 소프트웨어 개발을 요구 사항 분석, 설계, 코딩, 테스트 및 유지 관리와 같은 여러 단계로 나눕니다. 폭포형 소프트웨어 개발 방법은 오늘날 대부분의 소프트웨어 개발 조직에서 여전히 사용됩니다. 그러나 '소프트웨어 공학'과 그 폭포수 개발 방식은 소프트웨어 위기를 완전히 해결하지 못했다. 끊임없이 변화하는 소프트웨어 요구 사항을 충족하는 방법은 항상 기존 소프트웨어 개발 방법으로는 해결할 수 없는 문제였습니다.

위 문제를 해결하기 위해 애자일 개발이 제안되었는데, 2001년 애자일 개발 방식이 공식적으로 등장한 이후 점점 더 많은 개발자들이 이 방식을 받아들이기 시작했고, 애자일 개발 기업들의 집단이 등장했다. 시장. 주요 접근 방식이 개발인 소프트웨어 개발 및 컨설팅 서비스 회사입니다. ThoughtWorks는 최근 ThoughtWorks China의 총괄 책임자인 Guo Xiao를 인터뷰하여 애자일 개발 구현 방법과 기타 문제에 대해 소개해달라고 요청했습니다.

Subversion

전통적인 소프트웨어 개발 방식

개발 방식으로서의 애자일 개발은 2001년부터 시작되었습니다. 당시 소프트웨어 개발 명인은 10명이 넘었습니다. 우리는 당시 등장한 새로운 프로그래밍 방법 중 일부를 요약하기 위해 함께 모였고, 이러한 유사한 방법 프로세스를 요약하기 위해 Agile이라는 단어를 사용했습니다.

“소프트웨어 개발 접근 방식이 애자일의 4가지 원칙(즉, 프로세스와 도구에 대한 개인과 상호 작용, 철저한 문서에 대한 작업 소프트웨어, 계약 협상에 대한 고객 협업, 변화에 대한 대응)을 따르는 한 계획을 따르십시오. ), 심지어 민첩한 개발 방법도 있습니다. 예를 들어 ThoughtWorks의 자체 업무에서는 이 두 가지 방법을 결합한 스크럼과 익스트림 프로그래밍을 통합합니다.”라고 Guo Xiao는 기자들에게 말했습니다.

궈샤오는 1990년대부터 익스트림 프로그래밍 등 애자일 개발 방식을 접하기 시작해 10년 넘게 애자일 개발에 종사했고, 이후 소프트웨어 개발 관리 분야에 종사하면서 높은 수준에서 시작하세요. 높은 수준에서 애자일은 대부분의 프로그래머에게 아직 상대적으로 익숙하지 않은 개발 방법입니다. Guo Xiao는 Agile 선언문에 두 가지 핵심 아이디어가 있다고 믿습니다.

하나는 프로세스보다 사람이 더 중요하다는 것입니다. 애자일 개발 방법과 전통적인 개발 방법의 가장 큰 차이점은 전통적인 소프트웨어 개발 방법이 20세기 대규모 산업 생산의 아이디어를 따른다는 것입니다. 프로세스가 완벽하게 설계되는 한 모든 사람이 이 조립 라인의 작업에 책임이 있습니다. 이것도 중요하지 않습니다. 이것은 "소프트웨어 공학"이 추구하는 영역이기도 합니다. 사실 소프트웨어 개발은 ​​지식을 기반으로 하는 창의적인 작업이므로 조립라인을 완전히 모방하는 것은 불가능합니다. 애자일 개발은 소프트웨어 개발 역량을 갖춘 사람들이 모여 팀을 구성한다는 점을 강조하며, 팀이 어떤 애자일 방식을 사용할지는 전적으로 팀의 특성에 따라 결정됩니다. 이는 프로세스가 사람들에게 도움이 된다는 점을 강조하고 사람들의 가장 큰 창의성을 활용하는 것을 강조합니다.

다른 하나는 문서화보다 작동하는 소프트웨어의 가치가 더 중요하다는 것입니다. 전통적인 소프트웨어 개발 방식은 요구사항 분석, 설계, 코딩 등 여러 단계로 나누어 담당하며, 문서는 원동력 역할을 하며, 서로 다른 역할은 문서를 사용하여 서로 전달하고 상호작용합니다. 애자일 개발은 문서가 소프트웨어에 도움이 된다고 믿으며, 지금까지 개발된 소프트웨어를 기반으로 다양한 역할을 맡은 사람들이 직접 소통할 수 있도록 신속한 반복과 지속적인 통합을 강조합니다. 이는 빠른 피드백과 긴밀한 협업이라는 두 가지 이점을 제공합니다.

“전달에 대한 강조, 긴밀한 협업 및 신속한 피드백은 애자일 개발이 변화하는 요구 사항을 충족할 수 있도록 보장합니다.”라고 Guo Xiao는 말했습니다. 소프트웨어의 성공 여부는 요구 사항 분석이 미래의 요구 사항을 고려할 만큼 장기적인 관점에서 이루어졌는지 여부에 달려 있지만 실제로는 거의 불가능합니다. ”

프로그래밍. >프로그래밍이 필요한가요?

애자일 개발에 관해 이야기하면 페어 프로그래밍을 빼놓을 수 없습니다. 애자일 개발에서는 두 사람이 동시에 코드 작성에 참여해야 하며, 두 사람이 동일한 컴퓨터, 키보드 및 컴퓨터를 사용해야 합니다. 생쥐. 인터뷰에서 기자는 궈샤오에게 “페어 프로그래밍이 필요한가?”라는 질문을 구체적으로 물었습니다.

궈샤오는 기자들에게 대부분의 경우 페어 프로그래밍이 적합하다고 말했다. 일반적인 상황에서 프로그래머는 코드를 입력하기 위해 하루 종일 키보드를 치는 것이 아닙니다. 실제로 키보드를 치는 시간은 20~30%에 불과하다는 사실을 생각해야 합니다. 따라서 두 사람이 동시에 같은 컴퓨터를 사용한다고 해서 효율성이 떨어지는 것은 아닙니다. 애자일 개발에서는 한 사람이 코드를 작성하고 다른 사람은 코드를 검토하여 코드가 올바른지, 더 나은 작성 방법이 있는지 평가한 후 서로 소통해야 합니다. 이런 식으로 작성된 코드의 품질은 한 사람이 작성한 코드보다 훨씬 높습니다.

페어 프로그래밍의 또 다른 이점은 프로젝트 위험 감소입니다. 현대 소프트웨어 개발의 분업은 매우 세부적이며, 각 소프트웨어 개발자는 한 부분을 독립적으로 책임집니다. 프로그래머가 이직하거나 직업을 바꾸면 소프트웨어 개발에 매우 ​​해로울 것입니다.

페어 프로그래밍에서는 각 코드 조각을 최소한 두 사람이 이해하므로 프로젝트 담당자가 변경될 위험이 훨씬 낮습니다.

페어 프로그래밍의 또 다른 이점은 가르치고, 돕고, 이끄는 데 도움이 된다는 것입니다. 페어 프로그래밍을 통해 프로젝트 신규 참여자들이 쉽게 통합될 수 있으며, 이 과정에서 코드 수를 잃지 않고 지식 공유 등의 이점도 가져올 수 있습니다.

Guo Xiao는 민첩한 개발이 민첩한 프로그래밍을 강조하지만 기계적으로 코드를 쌍으로 완성해야 한다고 요구하지는 않는다고 덧붙였습니다. 매우 간단하고 잘 알려진 일부 코드의 경우 한 사람만 책임을 질 수 있습니다.

실제로 기자는 ThoughtWorks의 소프트웨어 개발 사이트를 방문한 적이 있다. 기자는 대부분의 회사에서 흔히 볼 수 있는 칸막이실이 사라지고 커다란 직사각형 원형 테이블로 대체된 것을 보았습니다. 여기 개발자들은 두 명씩 팀을 이루어 작업합니다. 각자 앞에 모니터가 있지만 둘 중 한 명은 코딩하고 다른 한 명은 검토 중입니다.

“우리의 실제 경험도 이 방법의 발전을 입증합니다. 우리 직원 중 일부는 짝 프로그래밍이 업무 부담을 증가시킨다고 보고했습니다. 두 사람이 짝을 이루면 업무와 관련 없는 일은 거의 할 수 없기 때문입니다.” 그거요." 궈샤오가 웃으며 말했다.

애자일 개발

얼마나까지 갈 수 있나요?

소프트웨어 개발 방법으로서 애자일의 진보와 합리성은 의심할 여지가 없는데, 이 방법의 적용 범위는 어디까지인가? 대규모 소프트웨어 개발 조직에서 채택하기에 적합한가요?

“2001년 애자일 개발이 공식적으로 제안되었을 때 일부 사람들은 대규모 소프트웨어 개발팀이나 장기 프로젝트에는 적합하지 않다는 지적을 해왔습니다. 실제로 이러한 주장은 수년 동안 지속적으로 제기되었습니다. 궈 샤오는 "물론 애자일 자체가 점점 더 넓은 범위에 적응하기 위해 지속적으로 확장되고 있다"고 말했다. 궈 샤오는 ThoughtWorks 자체가 애자일 개발을 100명과 함께 진행했다고 말했다. 사실 이것이 ThoughtWorks가 애자일 개발과 연관되게 된 이유입니다.

1999년에 ThoughtWorks는 단지 소프트웨어 개발에 종사하는 회사였습니다. 당시 100명이 넘는 인원이 참여하는 대규모 프로젝트가 소극적인 입장에 빠졌고, 업계에서 잘 알려진, 훗날 '세계의 대부'로 알려진 마틴 파울러와 워드 커닝햄을 초청할 수밖에 없었다. 민첩한 개발, 컨설팅 업무를 수행합니다. 그들은 민첩한 개발을 도입하여 회사를 어려움에서 구했습니다. 이를 통해 ThoughtWorks는 민첩한 개발 방법의 마법을 느낄 수 있습니다. 또 다른 예는 인도에 18,000명의 개발팀이 있고 영국 및 기타 지역에 수만 개의 개발팀이 있는 British Telecom(BT)입니다.

물론 소프트웨어 개발 방식으로서의 애자일 개발은 만능은 아니며 한계도 있다. 즉, 애자일 개발의 성공을 보장하기 위해서는 몇 가지 전제 조건이 필요합니다.

궈샤오는 "애자일 개발에는 고객 피드백을 지속적으로 얻기 위해 고객과 긴밀한 소통이 필요하다. 사실 고객은 대개 매우 바쁘고 많은 시간을 할애할 수 없다. 또한 일부 제품 개발은 고객 피드백에 의존한다"고 말했다. 제품 관리자는 요구 사항을 이해하지만 실제로는 고객이 아니기 때문에 애자일 개발에 어려움을 겪습니다.”

또한 개발자에 대한 고객의 전적인 신뢰도 애자일의 성공에 매우 중요합니다. 발전에는 반드시 필요한 조건이 있습니다. 민첩한 개발을 위한 최상의 적용 시나리오는 사용자가 계속해서 새로운 요구 사항을 제시하고 프로젝트 계약 가격이 필요에 따라 지속적으로 조정되는 경우입니다. Guo Xiao는 이것이 실제 개발 과정에서 문제가 된다고 말했습니다. 특히 처음으로 함께 작업할 때 고객은 프로젝트의 최종 비용에 대해 매우 걱정할 것입니다. 그리고 회사 자체 개발팀이라면 문제가 되지 않습니다. 이러한 관점에서 볼 때 애자일 개발의 가장 큰 시장은 회사의 내부 개발팀입니다.

“어쨌든 최근 몇 년 동안 점점 더 많은 사람들이 애자일 개발 아이디어를 받아들이고 있다는 것을 확실히 느꼈습니다. 이러한 추세는 우리에게 컨설팅 서비스를 요청하는 고객의 수에서 볼 수 있습니다. , 애자일 개발은 소프트웨어 개발 분야에서 확실히 그 자리를 확고히 할 것입니다.”라고 Guo Xiao는 자신감을 갖고 말했습니다.