[DesignPattern] Agile Development

* 이 글은 Agile Software Development, Principles, Patterns, and Practices - Robert Martin

책 내용을 번역 및 요약하여 작성하였습니다.

 

The Agile Alliance

소프트웨어 개발 프로젝트에서 명확한 지침이나 효과적인 접근 방식의 부재로 인해 예측 불가능성, 반복된 오류 및 낭비가 발생합니다. 일정 지연, 예산 증가 및 저품질로 인해 클라이언트는 실망하고, 개발자는 더 많은 노력을 기울일수록 점점 나쁜 소프트웨어를 생산하게 됩니다.

소프트웨어 개발 프로젝트는 몇 가지 제한사항과 결과물만으로는 완벽하다고 볼 수 없습니다. 오류가 계속 발생하면 그 오류를 진단하고 앞으로의 오류를 방지하기 위해 더 많은 제한사항과 결과물을 도입합니다. 많은 프로젝트 이후에 프로그램은 거대하고 무겁게 느껴지는 프로세스로 가득 차게 되는데, 이로 인해 소프트웨어 품질이 크게 저해될 수 있습니다.

Agile Alliance란 용어는 소프트웨어 프로젝트 팀이 빠르게 작업하고 변화에 대응할 수 있는 가치와 원칙을 기반으로 등장하게 되었습니다.

The manifesto of the Agile Alliance.

Agile Development 는 다음을 중요시합니다.

- Individuals and interactions over processes and tools (과정과 도구보다 개인과 상호 작용)

- Working software over comprehensive documentation (포괄적인 문서보다 작동하는 소프트웨어)

- Customer collaboration over contract negotiation (계약 협상보다 고객 협력)

- Responding to change over following a plan (계획 따르기보다 변화 대응)

Individuals and interactions over processes and tools.

팀 구성은 개발 환경 구축보다 더 중요합니다. 많은 팀과 관리자들이 개발 환경을 먼저 구축하고 팀이 자동으로 조화를 이루기를 기대하지만 이는 좋은 기대가 아닙니다. 좋은 팀을 구성하도록 노력하고, 그런 다음 팀이 필요에 따라 환경을 구성하도록 해야합니다.

Working software over comprehensive documentation.

이해하기 좋은 문서화를 통해 팀이 시스템을 이해하도록 해야합니다. 그렇지만 너무 많은 문서량은 오히려 좋지 않습니다. 문서 구조를 유지하돼, 간단하고 명료햐게 해야합니다.

Customer collaboration over contract negotiation. 

회사의 관리자들은 종종 개발 팀에 자신들의 요구 사항을 말한 다음 시간이 지나 그 요구 사항을 만족하는 시스템으로 돌아올 것으로 기대합니다. 그러나 이러한 운영 방식은 품질과 실패로 이어집니다.

성공적인 프로젝트에는 고객 피드백이 정기적이고 빈번하게 포함됩니다. 계약이나 작업 명세서에 의존하는 대신 소프트웨어의 고객은 개발 팀과 긴밀하게 협력하여 그들의 노력에 대한 빈번한 피드백을 제공합니다.

프로젝트의 요구 사항, 일정 및 비용을 지정하는 계약은 근본적으로 결함이 있습니다. 대부분의 경우, 그것이 지정하는 조건들은 프로젝트가 완료되기 훨씬 전에 무의미해집니다. 최고의 계약은 개발 팀과 고객이 함께 일할 방식을 규제하는 계약입니다.

Responding to change over following a plan.

소프트웨어 프로젝트의 성공 또는 실패를 결정하는 것은 변화에 대응할 수 있는 능력입니다. 계획을 세울 때 비즈니스와 기술의 변화에 유연하게 대응할 수 있는지 확인해야 합니다.

실제로 일어나는 일은 차트의 구조가 변형되는 것입니다. 팀이 시스템에 대한 지식을 쌓고 고객이 필요한 것을 파악함에 따라 일부 작업은 불필요해질 수 있습니다. 다른 작업들이 발견되어 추가되어야 할 것입니다. 즉, 계획은 단순히 날짜만 변경되는 것이 아니라 모양도 변경됩니다.

더 나은 계획 전략은 다음 두 주 정도의 상세한 계획을 작성하고, 다음 세 달 정도의 대략적인 계획을 그리며, 그 이후에는 매우 대략적인 계획을 가져가는 것입니다. 우리는 다음 두 주 동안 작업할 작업을 알아야 합니다. 다음 세 달 동안 작업할 요구사항을 대략적으로 알아야 합니다. 그리고 1년 후 시스템이 무엇을 할지에 대해서는 대략적인 아이디어만 있어야 합니다.

이 계획의 해상도를 줄여 나가는 것은 직접적인 작업에 대해서만 상세한 계획을 세우는 것을 의미합니다. 상세한 계획이 세워지면 팀은 큰 탄력과 헌신을 가지게 되므로 변경하기 어렵습니다. 그러나 그 계획은 몇 주치에 해당하는 시간만을 관리하므로 나머지 계획은 유연하게 유지됩니다.

Conclusion

모든 소프트웨어 개발자와 개발 팀의 전문적인 목표는 고용주와 고객에게 최대한의 가치를 전달하는 것입니다. 그럼에도 불구하고 우리의 프로젝트는 놀라운 비율로 실패하거나 가치를 제공하지 못합니다. 선의로 한든 프로세스 확대의 상승 스파이럴은 이러한 실패 중 일부에 책임이 있습니다. Agile software developement의 원칙과 가치는 프로세스 확대의 사이클을 깨고 목표 달성을 위한 단순한 기술에 집중하는 팀들을 돕기 위해 형성되었습니다.