Manifesto for Agile Software Develipment

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

애자일 선언문


우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다

Principles behind the Agile Manifesto

We follow these principles:

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

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

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

  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.

  7. Working software is the primary measure of progress.

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

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

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

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

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

1. 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.

소프트웨어는 고객이 있기에 존재한다. 고객은 너그럽지도 기다려 주지도 않는다. 따라서 우리의 가치를 측정할수 있는 데이터를 수치화해서 고객을 만족시키려 노력해야한다. 그 어느것도 이보다 우선되지는 않는다.

2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

요구사항의 변경은 그리 반가운일이 아니다. 하지만, 요구사항은 변경되기 마련이다. 이 현실은 인정하고 극복방법을 찾아보자.

3. 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.

고객의 요구사항은 언제 바뀔지 모른다. 따라서 우리는 가능한 빠르게 고객의 피드백을 받고 이를 다시 제픔에 반영할 수 있어야 한다. 이를 위해 빌드배포자동화가 되어있어야 한다.

4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.

같은 공간에서 밀접하게 일하면 커뮤니케이션의 비용은 상당히 적고 서로의 언어를 더 잘 이해할 수 있다.

5. 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.

Trust & Respect

6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.

Slack, Trello, Github, GoogleCalendar, GoogleDocs, Email 등커뮤니케이션 수단은 많지만, 면대면으로 이야기하는 것보다 더 효율적인 의사소통 수단은 없습니다. 필요에 따라 짝 프로그래밍도 필요하다. 주로 새로 합류한 개발자 혹은 기존 개발자 중에서도 주로 다루지 않았던 코드에 대한 작업이 필요할 때 진행합니다.

7. 작동하는 소프트웨어가 진척의 주된 척도이다.

매 스프린트 리뷰시간에는 각자 5분씩 그간 개발해온 기능을 가볍게 공유한다. 서로 궁금한 점을 질문하기도 한다.

8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다.

보통 하루에 개발에만 집중할 시간은 5시간으로 했을때, 2주일기준 50시간 정도의 업무량은 가진다고 가정한다. 개발과제의 난이도나 작업량을 고려하여 스스로 업무를 산정하고 장애처리나 예상치 못한 상황에 대한 버퍼를 고려하여 30~40 시간 정동의 일감을 스프린트에 올립니다. 밤을 세워 개발하는 것은 절대로 자랑스러운 일이 아니다. 밤을 세울수 밖에 없다면 스스로 계획 실폐이거나 사장님이 나쁜거다. 단기간의 성과보다 지속적이고 예측가능한 성과가 장려되어야 한다.

개발자는 엉덩이로 개발하기 보단 머리로 개발해야 한다.

9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.

필요한 사항은 언제든지 시작을 한다. 나중으로 미루면 절대로 시작하지 않는다. 그럼에도 기술부채가 남을 수 있다. 이를 위해 3회 스프린트 후 1회 유지보수 스프린트를 진행할 수 있다.

10. 단순성이 필수적이다 = 안 하는 일의 양을 최대화하는 기술이 필수 적이다.

요구 사항을 이해하고 구현하는데 있어서 최대한 시간을 절약하고 단순화하는게 중요하다.

11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.

12. 어떻게 하면 더 효과적일지 정기적으로 숙고하고 팀을 조율한다.

매 스프린트 마무리에 일감에 대한 리뷰와 데모가 끝나면 회고를 통해 발전시켜 나간다.

애자일은…

애자일은 방법론도 프로세스도 아니다. 소프트웨어를 개발함에 있어 어디에 더 중요한 가치를 두어야 하는가에 대한 철학이다.

사람들이 좋다고 해서 무조건 받아들이는 것은 바보 같은 행동이다.

Links

출처 : 개발자의 입장에서 본 버즈빌의 개발 문화: 애자일 소프트웨어 개발