Agile Principles

Agile principles 는 사용자에게 프로덕트를 전달하는 데 도움을 주며 여러분의 팀이 서로 소통(communicate)하고 함께 일하는 데에 도움을 준다. 아래의 12개로 정리할 수 있다.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

최우선 순위는 가치 있는 소프트웨어를 조기에 지속적으로 제공함으로써 고객을 만족시키는 것이다.

여기에는 세 가지 포인트가 있다.

고객 만족 (to satisfy customer) : PMO 나 QA 가 아닌 고객에 집중해야 한다.

조기에 지속적으로 (early and continuous) : 불완전한 것을 공유하고 싶지 않은 것이 인지상정이지만 프로덕트를 자주 공유함으로써 부족한 부분을 채워 나갈 수 있다. 수정해야 할 부분들을 나중에 발견하는 것은 더 큰 위험이 될 수 있다.

가치 있는 소프트웨어 (valuable software) : 결국 최종 목표는 고객에게 제공하는 프로덕트나 서비스가 될 것이다.

2. Welcome changing requirements, even late in development. Agile processes harness for the customer's competitive advantage.

개발 후반부라 하더라도 변화하는 요구 사항을 꺼리지 않는다. 고객의 경쟁 우위를 위해서 애자일 프로세스를 활용한다.

요구 사항을 당장 적용할 만한 적당한 방법이 없을 수도 있다. 그렇다 하더라도 이러한 요구 사항을 수집하는 것은 장기적으로 고객의 니즈(Needs)를 파악하는 데에 도움이 된다.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

2주에서 2개월 정도의 짧은 기간으로 소프트웨어를 자주 제공하는 것이 좋다.

프로덕트를 자주 공개하다 보면 그에 따른 고객의 피드백도 빠르게 자주 받아 볼 수 있어 프로덕트가 산으로 가는 경우를 방지하고 지속적인 프로덕트 통합에도 도움이 된다. 좀 더 보강할 기능과 그다 필요하지 않은 기능에 대한 판단도 빠르게 할 수 있으므로 더 가치 있는 프로덕트 또는 서비스를 제공하는 데에 도움이 된다.

4. Business people and developers must work together daily throughout the project.

비니스맨과 개발자는 프로젝트 내내 매일 같이 작업해야 한다.

비즈니스의 방향을 아는 것도 중요하다. 비즈니스팀은 단지 고객의 요구 사항을 수집하는 것을 넘어서 더 나아가 사업의 방향을 제시한다. 개발팀은 이러한 사업의 방향에 대해 적절한 솔루션을 제공해 줄 수도 있고 혹은 불가능한 것에 대해서는 대체 방법을 제시할 수도 있다. 이러한 이유로 비즈니스맨과 개발팀이 매일매일 함께 일하는 것은 중요하다.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

동기 부여된 구성원들을 중심으로 프로젝트를 구성한다. 그리고 구성원들에게 필요한 환경과 지원을 제공하고, 프로젝트를 완수할 수 있도록 구성원들을 신뢰한다.

구성원들이 어떤 심각한 결과를 초래한 것이 아닌 이상 그냥 사소한 실수를 말하는 것은 안 된다고 느낀다거나 극도로 오랜 시간 일해야 한다는 압박을 느낀다거나 일반적으로 자신이 하는 일이 신뢰받지 못한다고 느낀다면, 작업량이나 일의 질은 급격히 저하된다. 구성원들이 신뢰를 받고 있고 좋은 업무 환경을 제공받고 있다고 느낄 때 그 성과는 괄목할 만하다.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

개발팀 내외로 정보를 전달하는 가장 효과적이고 효율적인 방법은 대면 대화이다.

사람들이 요구 사항을 작성하게 되고 이 요구 사항을 바탕으로 설계를 하며 그 설계 바탕으로 개발을 진행하게 된다. 이에 관련한 사람들이 어떤 용어나 이런 요구 사항에 대해 동일하게 이해해야 같은 피처를(feature) 바라보고 이야기할 수 있을 텐데, 서로 다른 생각에 대해 논의하는 가장 좋은 방법이 바로 '대면하여 대화'하는 것이다. 직접 이야기를 나누는 것이 가장 효과적이고 효율적인 방법이다.

7. Working software is the primary measure of progress.

동작하는 소프트웨어는 프로젝트 진행의 주요한 척도이다.

'동작하는 소프트웨어'라 함은 제대로 동작하거나 테스트할 수 있다는 의미인데 어떤 기능이 동작하지 않거 테스트할 수 없다는 것은 완료되지 않았다는 의미이다. 이러한 완료되지 않은 중간 결과물이나 부분적으로 완료된 작업은 외부에서 인정받을 수 없다.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to to maintain a constant pace indefinitely.

애자일 프로세스는 지속 가능한 개발을 촉진한다. 스폰서, 개발자와 사용자는 무한정 일정한 페이스를 유지할 수 있어야 한다.

애자일 메서드 장기적으로 가치를 극대화하기 위해 노력한다.

장시간에 걸쳐서 작업하는 팀들의 문제점은 사람들이 여러모로 소진되기 쉽고 그러다 보면 실수를 저지르기 시작한다는 것인데, 애자일 메서드는 팀 구성원이 일과 삶의 균형을 유지할 수 있는, 지속 가능한 페이스를 유지하는 것에 가치를 둔다.

시간 긴장되게 일하면서 팀 구성원들이 탈진하게 되어 조직을 이탈하게 되는 것은 조직에서도 손해이다. 새 멤버를 고용해서 팀에 투입한다 하더라도 그것은 고비용의 과정이 될 것이다.

9. Continuous attention to technical excellence and good design enhances agility.

기술과 좋은 설계 대한 지속적인 관심은 애일리티(Agility)를 향상시킨다.

우리는 개발팀이 열심히 일하고 많은 가치를 제공하기를 바라지만, 설계를 명확하고 효율적으로 유지하고 변경 사항에 대해 열린 마음을 유지하는 것도 항상 염두에 두어야 한다.

코드가 한 번 헝클어지기 시작하면 조직은 요구 사항에 대응하는 능력을 상실하게 된다. 따라서 우리는 개발팀에게 리팩리토링에 대한 시간을 충분히 제공할 필요가 있다. 리팩토링(Refactoring)이란 코드를 안정적이면서도 장기간 유지될 수 있도록 정리하고 단순화하는 과정이다.

프로젝트는 가치를 창출하는 것과 설계에 대한 꾸준한 관심 사이의 균형을 맞추는 것에 노력해야 한. 유지, 변경, 확장이 어려운 환경은 장기적인 가치를 만들어낼 수 없다.

10. Simplicity - the art of maximizing the amount of work not done - is essential.

단순함 - 완료되지 않은 작업량을 극대화하는 기술 - 은 필수적이다.

가장 신뢰할 수 있는 기능(feature)은 사실 아직 만들어지지 않은 것이다. 아직 만들지 않은 기능은 잘 못 될 수 있는 가능성이 없기 때문이다.

보통은 만들어진 기능 중 최대 60% 정도가 실제로는 자주 사용되지 않거나 전혀 사용되지 않는다. 해서, 처음부터 시스템을 복잡하게 만드는 것은 각 기능을 신뢰할 수 없게 만들 가능성도 커지기 때문에 애자일에서는 가능한 단순하고 간단함에 집중하려고 한다. 이는 진짜 필요한 것들로 시스템을 채워나간다는 것을 의미하기도 한다.

복잡한 프로젝트는 완성하는 데 오랜 시간이 걸리고, 이는 불안한 요소를 점점 키워 갈 수 있는 가능성도 커지게 된다. 그래서 애자일에서는 '간단하고 명확하게 동작하는 것' 추구한다. 확장이 불가능하나 프로덕트가 정교하지 않다는 의미가 아니다. 쉽게 이야기하자면, '아주 기본적인 것부터 만들자' 것이다. 이는 스크도 줄일 뿐 아니라 프로덕트의 뢰에도 도움을 준다.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

최상의 아키텍처, 요구 사항, 설계는 자기구조화(self-organizing) 팀에서 나타난다.

자기구조화(self-organizing) 팀이란 스스로 자기 관리를 할 수 있는 팀이라고 할 수 있겠다. 어떤 해결 방법과 구성원과의 관계, 환경 등을 스스로 관리할 수 있는 것을 말하는 것이라고 볼 수 있다.

구성원들은 서로 이해하고 지원해 주고, 이런 것들이 바탕이 되어 결론적으로는 더 나은 작업을 가능하게 한다. 스스로를 관리할 수 있는 팀은 좀 더 높은 레벨의 주인의식을 가질 수 있는데, 주인의식을 가지고 있다면 최상의 아키텍처, 요구 사항, 설계 등을 주도해 나가고 기술의 세세한 부분까지도 신경 쓰게 된다. 이것은 곧 프로덕트나 프로세스 등 여러 가지 면에서 개선할 수 있는 많은 가능성을 내포하게 되고 더 나은 프로덕트를 생산해 낼 수 있게 된다.

12. At regular intervals, the team reflects on how to become more effective, the tunes and adjusts its behavior accordingly.

팀은 정기적으로 좀 더 효과적인 방법을 반영하고 그에 따라 행동을 조정한다.

프로젝트를 모두 마친 후 교훈(lessons learned)을 수집하는 것보다 일이 진행되는 중간간교훈을 수집하는 것이 더 효율적이다. 왜냐하면 프로젝트를 다 마치고 - 즉, 프로젝트 완료된 후 - 어떤 변경이나 개선점을 적용하는 것보다 아직 일이 진행되는 중에 적용하는 것이 더 수월하기 때문이다.

각 주기(iteration)마다 회고를 하는 것이 좋은데 이의 장점은 세부사항을 놓치지 않을 수 있다는 것에 있다. 프로젝트가 끝나는 무렵에 한 번 하는 회고에서는 몇 달 전 혹은 1년 이상의 예전의 것을 기억해 내야 하기도 한다. 자주자주 회고를 한다면 이런 놓칠 수 있는 세부사항을 놓치지 않고 이슈가 발생할 수 있는 부분을 챙길 수 있게 된다.