2001년도 선언된 애자일 원칙 (Agile Principle) 12가지 항목입니다. 이 12가지 원칙은 어떤 복잡한 software 개발에도 잘 적용이 된다고 알려져 있습니다. 여기 나오는 software라는 단어를 product라는 단어로 바꿔서 사용해도 의미가 같을 듯 합니다.
애자일 원칙 (Agile Principles)은 아래 site에서도 확인이 가능합니다.
한국어 번역이 좀 어색한 것도 같네요. 제가 책에서 자주 보던 Martin Fowler, Robert C. Martin, Kent Beck등의 저아 이름도 보여서 반갑네요.
Our highest priority is to satisfy the customer through early and continuous of delivery of valuable software.
가치 있는 software(product)를 지속적으로 전달함으로써 고객을 만족시키는 것을 최우선으로 한다. 저는 아직까지도 이 가치(value)라는 단어가 주는 모호함이 헷갈릴 때가 많습니다. 이 software의 어떤 기능이 고객에게 가치를 줄 수 있는 지 project 내내 고민할 때가 많습니다. 개발 할 때 이 가치에 대해 정확히 이해를 해야 정말로 가치가 있는 software를 고객에게 전달 할 수 있습니다. 그러려면 Product Owner와 Business people과의 지속적인 communication이 중요합니다.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
이 부분은 힘든 부분 중에 하나라고 생각됩니다. Project 초반에 많은 노력을 들여서 Plan을 하지만 시장은 지속적으로 변동이 되고 고객이 요구하는 것도 계속 변경이 됩니다. 우리 software가 변경이 힘든 구조가 될수록 이런 변경 요구 사항이 (개발자 입장에서는) project 후반 부에 수용하기 상당히 힘들어집니다. 하지만 우리는 고객의 요구 사항을 항상 적극적으로 받아들일 수 있어야 경쟁력 있는 software(product)를 개발할 수 있습니다. Agile 책을 읽어 보면 Testing code를 적극적으로 넣으면서 이러한 software 변경에 대해 자신감을 가질 수 있게 Guide 합니다.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
동작하는 software를 몇 주 또는 몇 달 주기로 고객에게 전달합니다. Demo를 통해서 고객에서 software(product)를 자세히 들여 다 보는 자리를 마련하는 것도 좋은 방법입니다. software를 본 고객은 project에 큰 전환 점이 될 수도 있는 중요한 feedback을 중간 중간 줄 수 있습니다. project 마지막 단계에 software를 고객에게 보여줘서 feedback을 받는 다면, 힘든 project를 예상해야 합니다.
Business people and developers must work together daily throughout the project.
사업가와 개발자 사이의 Gap을 줄이는 것이 제품 성공의 중요한 열쇠가 될 것입니다. 그러기 위해 가까운 위치에서 함께 일하면서 서로의 생각을 공유하는 것이 중요합니다. 그래서 회사에서는 자리부터 가까이에 배치해서 팀으로 일할 수 있게 끔 환경을 조성하는 경우가 많습니다.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
기술적으로 깊은 이해도를 같고 있는 팀을 구성하여 제품이 잘 만들어질 수 있도록 환경을 조성해 주고 지원해 줘야 합니다. project 개발 당시에는 기술에 대한 고민이 시간을 더 소모하게 만든다고 생각할 수 있지만, 시간이 지날 수록 기술에 대한 고민은 project 개발을 더 효율적으로 만들어 줄 것입니다.
The most efficient and effective method of conveying information to and within a development team is face to face conversation.
Global company의 경우 각 국가에 지사를 두고 연구소가 운영되는 경우가 많습니다. 현재 아무리 좋은 tool들이 많이 개발이 되었 어도 이렇게 멀리 떨어져서 함께 개발을 한다는 것은 쉬운 일이 아닙니다. 저도 몇번의 실패 사례를 경험 했습니다. 가급적 얼굴을 대고 일하는 것이 효율적인 communication을 위한 좋은 방법입니다.
Working software is the primary measure of progress
동작하는 software를 보여주는 것이 progress를 보여주는 가장 좋은 방법입니다. 여러가지 chart나 reporting tool이 존재하지만 고객에게 현재 상황을 보여주는 Physical Demo를 한 번 하는 것이 가장 효과적입니다.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
이 부분은 저도 참 많이 공감을 하는데요, 추가 근무를 없애야 높은 수준의 성과를 지속적으로 낼 수 있습니다. 정해진 시간안에 할 수 있는 모든 일을 쥐어 짜서 하는 일정을 잡는 것이 아니라, 정해진 시간안에 할 수 있는 일에만 집중합니다. 그러기 위해서는 work item들의 우선순위를 정하고 장애물을 제거해야 합니다. 물론 경우에 따라 추간 근무를 할 수는 있지만, 극히 예외적인 경우에만 해야 합니다.
Continuous attention to technical excellence and good design enhances agility
기술에 대한 관심과 좋은 설계에 대한 열정은 우리의 제품 개발을 더 빠르고 효과적으로 만듭니다.
Simplicity—the art of maximizing the amount of work not done—is essential
불필요한 일들을 가능한 줄여서 가능한 핵심만을 단순하게 만드는 것이 낭비를 줄여서 효율화 할 수 있습니다.
The best architectures, requirements, and designs emerge from self-organizing teams.
현재의 팀의 업무를 가장 잘 이해하고 있는 것은 팀 자체입니다.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Project가 마무리되고 lesson and learn을 하는 경우가 많은데 이것은 효과적이지 않습니다. 짧은 주기로 lesson and learn을 반복하는 것이 더 효과적입니다. 이 말은 Agile project의 구성 요소인 sprint review/retrospective 등의 형태로 process화 됩니다.
'프로세스 > Essential Scrum' 카테고리의 다른 글
| [Essential Scrum] '프로덕트 백로그'(Product Backlog)란? (0) | 2020.12.19 |
|---|