애자일: Difference between revisions
From IT Wiki
No edit summary |
|||
Line 1: | Line 1: | ||
[[분류:프로젝트 관리]][[분류:경영학]][[분류:소프트웨어 공학]] | [[분류:프로젝트 관리]] | ||
[[분류:경영학]] | |||
[[분류:소프트웨어 공학]] | |||
;Agile | ;Agile | ||
== 개요 == | ==개요== | ||
* 1990년 소프트웨어 비즈니스 변화에 따르게 대응하기 위해 시작 | |||
* 2001년 애자일 소프트웨어 개발 선언문(The Manifesto for Agile Software Development) 발표 | *1990년 소프트웨어 비즈니스 변화에 따르게 대응하기 위해 시작 | ||
* 4가지 가치(Value), 12가지 원칙(Principle)으로 구성 | *2001년 애자일 소프트웨어 개발 선언문(The Manifesto for Agile Software Development) 발표 | ||
*4가지 가치(Value), 12가지 원칙(Principle)으로 구성 | |||
==4가지 가치== | |||
*1. 프로세스와 도구보다는 개인과 개인간의 상호작용에 더 큰 가치를 둔다. | |||
:Individuals and interactions over processes and tools | :Individuals and interactions over processes and tools | ||
* 2. 포괄적 문서화보다는 동작하는 소프트웨어에 더 큰 가치를 둔다. | |||
*2. 포괄적 문서화보다는 동작하는 소프트웨어에 더 큰 가치를 둔다. | |||
:Working Software over comprehensive documentation | :Working Software over comprehensive documentation | ||
* 3. 계약 협상 보다는 고객과의 협력에 더 큰 가지를 둔다. | |||
*3. 계약 협상 보다는 고객과의 협력에 더 큰 가지를 둔다. | |||
:Customer collaboration over contract negotiation | :Customer collaboration over contract negotiation | ||
* 4. 계획을 따르는 것 보다는 변화 대응에 더 큰 가치를 둔다. | |||
*4. 계획을 따르는 것 보다는 변화 대응에 더 큰 가치를 둔다. | |||
:Responding to change over following a plan | :Responding to change over following a plan | ||
== 12가지 원칙 == | ==12가지 원칙== | ||
* 1. 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다. | |||
: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. | *1. 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다. | ||
* 2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다. | |||
: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. | :Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. | ||
* 3. 작동하는 소프트웨어를 자주 전달하라. 2주 ~ 2개월 정도의 간격으로 하되 더 짧은 기간을 선호하라. | |||
: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. | *2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다. | ||
* 4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다. | |||
: Business people and developers must work together daily throughout the project. | :Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. | ||
* 5. 동기가 부여된 사람들을 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라. | |||
: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. | *3. 작동하는 소프트웨어를 자주 전달하라. 2주 ~ 2개월 정도의 간격으로 하되 더 짧은 기간을 선호하라. | ||
* 6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다. | |||
: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. | :Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. | ||
* 7. 작동하는 소프트웨어가 진척의 주된 척도이다. | |||
: Working software is the primary measure of progress. | *4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다. | ||
* 8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다. | |||
: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. | :Business people and developers must work together daily throughout the project. | ||
* 9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다. | |||
: Continuous attention to technical excellence and good design enhances agility. | *5. 동기가 부여된 사람들을 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라. | ||
* 10. 단순함 -- 즉 하지 않는 일의 양을 최대화하는 기술이 -- 본질이다. | |||
: Simplicity--the art of maximizing the amount of work not done--is essential. | :Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. | ||
* 11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다. | |||
: The best architectures, requirements, and designs emerge from self-organizing teams. | *6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다. | ||
* 12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다. | |||
: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. | :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. | |||
== 같이 보기 == | |||
* [[애자일 방법론]] | |||
* [[SCRUM]] | |||
* [[익스트림 프로그래밍]] |
Latest revision as of 13:56, 19 May 2022
- Agile
개요[edit | edit source]
- 1990년 소프트웨어 비즈니스 변화에 따르게 대응하기 위해 시작
- 2001년 애자일 소프트웨어 개발 선언문(The Manifesto for Agile Software Development) 발표
- 4가지 가치(Value), 12가지 원칙(Principle)으로 구성
4가지 가치[edit | edit source]
- 1. 프로세스와 도구보다는 개인과 개인간의 상호작용에 더 큰 가치를 둔다.
- Individuals and interactions over processes and tools
- 2. 포괄적 문서화보다는 동작하는 소프트웨어에 더 큰 가치를 둔다.
- Working Software over comprehensive documentation
- 3. 계약 협상 보다는 고객과의 협력에 더 큰 가지를 둔다.
- Customer collaboration over contract negotiation
- 4. 계획을 따르는 것 보다는 변화 대응에 더 큰 가치를 둔다.
- Responding to change over following a plan
12가지 원칙[edit | edit source]
- 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. 작동하는 소프트웨어를 자주 전달하라. 2주 ~ 2개월 정도의 간격으로 하되 더 짧은 기간을 선호하라.
- 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.