패왕넷

운동은 피할 수 없는 삶의 한 부분입니다.  싫든 좋든 건강을 유지하려면 운동이 필요합니다. 그런데 건강을 유지하기 위해서는 어떤 운동을 하느냐보다 운동의 원칙을 지키는 것, 즉 유연성을 키우는 운동, 유산소 운동, 무산소 운동의 조화가 훨씬 더 중요합니다. 소프트웨어 개발 프로세스도 운동과 비슷합니다. 정해진 개발 프로세스를 정확히 따르는 것보다 프로세스의 원칙을 지키는 것이 더 중요합니다. 이러한 측면은 특히 민첩한 개발에서 두드러집니다.

"민첩한" 개발로 간주되는 소프트웨어 개발 프로세스에는 여러 가지가 있습니다. 예를 들면 스크럼(프로젝트 관리용), XP(Extreme Programming), FDD(Feature-Driven Development)가 있습니다. 처음 배울 때는 각 프로세스에서 미리 정해진 단계를 따르는 것이 좋지만 현실에서 모든 소프트웨어 프로젝트와 팀은 제각기 다르므로 대개 상황에 맞게 조정하는 과정이 필요합니다. 필요에 맞게 프로세스를 바꾸는 것은 좋습니다. 사실 변화의 수용은 민첩한 개발의 기본 원칙 중 하나입니다. 단, 이러한 변화가 민첩한 개발의 기반이 되는 인프라를 훼손해서는 안 됩니다.

민첩한 소프트웨어 개발의 기본 원칙 또는 본질은 무엇일까요? 민첩한 개발은 다음 사항에 주안점을 둡니다.

단순성.  민첩한 개발 프로세스는 그 자체가 단순할 뿐만 아니라 단순한 소프트웨어 디자인을 장려합니다. 소프트웨어 디자인을 단순하게 유지하면 관리 용이성이 향상되며 과잉 엔지니어링을 피할 수 있습니다. XP의 TDD(테스트 기반 개발) 방식에서는 테스트를 통과할 수 있는 최소한의 코드만 작성할 것을 권장합니다. 이러한 방식에 기존 코드 디자인을 기능 변경 없이 지속적으로 리팩터링 또는 개선하는 과정을 결합하면 소프트웨어 복잡성을 최소화할 수 있습니다.

변화 수용.  소프트웨어 개발에서 두 가지 확실한 사실은 인간은 실수를 저지른다는 점(버그)과 요구 사항이 변경된다는 점입니다. 민첩한 개발자들은 변화를 꺼리지 않으며 항상 변화에 대한 준비가 되어 있습니다. 많은 경우 사용자들은 개발 주기의 막바지에 새로운 기능을 요구합니다. 민첩한 개발자는 사용자의 요구를 경청하고 TDD, 지속적인 통합 및 리팩터링과 같은 방식을 사용하여 최소한의 작업으로 이러한 변화를 수용합니다.

증분 반복.  전달하기 쉬운 작은 기능을 고객에게 자주 제공하고 고객 평가를 자주 수행하면 개발을 순조롭게 진행하는 데 도움이 됩니다. 또한 전체적인 그림을 정해 놓은 상태에서 개발 작업을 작은 부분으로 제한하면 품질에 초점을 맞출 수 있습니다. 스크럼(Scrum)에서 반복 작업 단위는 대개 30일이며 이를 "스프린트(sprint)"라고 합니다. 스프린트의 각 결과물은 높은 품질을 유지해야 합니다. FDD는 대개 2주 간격으로 실질적인 작업 결과를 산출합니다.

지속적인 피드백 및 개선.  민첩한 개발에서는 개발 기법 개선을 위해 작업 결과를 자주 반영할 것을 권장합니다. 스크럼에서는 각 스프린트가 끝날 때마다 검토 회의를 갖습니다. XP는 내부 디자인의 개선 및 단순화를 위한 지속적인 코드 리팩터링을 장려합니다. 일일 스크럼 회의를 통해 매일 평가를 업데이트하는 등 피드백 기반 메커니즘을 활용하여 교육을 보강하고 프로젝트의 정확한 그림을 일관되게 제공합니다.

공동 작업.  민첩한 개발에서는 팀원 간, 팀 간 그리고 고객과의 의사 소통 채널을 항상 열어 두도록 강조합니다. 프로젝트 관리자, 개발자, 테스터, 고객 간의 정기적인 의사 소통은 모든 사람들이 한 방향으로 나아가게 하고 막힌 문제를 신속하게 해결하는 데 도움이 됩니다. XP의 일일 스크럼 회의(Daily Scrum meeting)와 짝 프로그래밍(Pair Programming)은 팀 안팎의 공동 작업을 개선하는 방법의 좋은 예입니다.

낭비 제거.  낭비 제거는 민첩한 개발과 한 쌍을 이루는 경우가 많은 린 소프트웨어 개발(http://www.poppendieck.com/)에서 차용한 개념입니다. "낭비"는 고객이 원하거나 필요로 하는 사항과는 거리가 먼 작업 또는 노력(예: 기능)입니다. 예를 들어 세부적인 요구 사항 분석이나 초기부터 지나친 설계 치중은 개발 주기의 후반에 변경이 발생하면 쓸모 없어지는 경우가 많으므로 낭비라고 할 수 있습니다. 따라서 상위 수준부터 시작하여 차츰차츰 세부 사항을 처리해 나가는 것이 좋습니다.

스크럼, XP, FDD를 비롯해 어떤 민첩한 프로세스를 따르든 이러한 민첩한 개발의 핵심 원칙을 따르면 사용자와 높은 품질에 중점을 둔 올바른 결정을 내릴 수 있습니다. 운동에서도 이러한 원칙이 그대로 적용됩니다. 다양한 활동을 규칙적으로 하면 좋은 결과를 얻을 수 있으며, 마당을 정리하거나, 친구의 이사를 돕는 것도 이러한 활동에 포함됩니다. 즉, 기본 원칙만 준수하면 되는 것입니다.

이러한 기본 원칙에 대한 자세한 내용은 www.agilemanifesto.org/principles.html을 참조하십시오. 이제 민첩한 개발을 직접 실천하시기 바랍니다. 핵심 원칙을 준수하면 몸과 소프트웨어 프로젝트 모두 건강한 상태를 유지할 수 있습니다.