3. Agile &
전통 방법론
개요
Project 성공 비율
크기 방식 성공 실패
전체
Agile 39% 9%
Waterfall 11% 29%
대형
Agile 18% 23%
Waterfall 3% 42%
중형
Agile 27% 11%
Waterfall 7% 25%
소형
Agile 58% 4%
Waterfall 44% 11%
4. Agile &
전통 방법론
전통 방법론
Waterfall 방법론
• 초기에 요구사항을 완벽히 정하는 것이
가능할까?
• 요구사항에 대한 변경/수정 요구는 얼마나?
• 정확한 일정에 대한 예측이 가능 할까?
• 개발 완료 후 정상적으로 System 통합이
될까?
• 2년 후 완료 되는 프로젝트의 현재 요구
사항이 그 당시에도 타당할까?
7. Agile &
전통 방법론
Agile
Manifesto for Agile SW 개발
The Agile Alliance (http://agilemanifesto.org), 2001
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기 보다 변화에 대응하기를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
9. Agile &
전통 방법론
Agile
Agile 원칙
• 우리의 우선적인 목표는 가치 있는 SW를 지속적으로 조기에 제공하는 것이다.
• 우리는 개발 후반부의 요구사항 변화도 환영한다. 애자일 프로세스는 고객의 경쟁력을 위해서 변화를 수용한
다.
• 짧은 스케줄을 선호하여 동작 가능한 SW를 2주에서 2달 간격으로 제공을 한다.
• 업무 담당자와 개발자는 매일 같이 프로젝트 기간 동안 일해야 한다.
• 동기 부여된 사람들로 프로젝트 팀을 구성한다. 그들에게 적절한 환경과 자원을 지원해 주고 일을 잘 할 수
있도록 믿어 준다.
• 가장 효과적인 의사소통 수단은 직접 만나서 의사소통 하는 것이다.
• 진척사항을 나타내는 중요한 척도는 작동 가능한 SW이다.
• 애자일은 지속 가능한 개발을 촉진한다. 후원자, 개발자, 사용자는 일정한 속도를 지속적으로 유지해야 한다.
• 뛰어난 기술과 좋은 설계에 대한 지속적인 관심은 기민성을 강화시킨다.
• 단순함(꼭 필요하지 않은 것을 최대한 덜 개발하는 기술)은 필수이다.
• 최고의 아키텍처, 요구사항, 설계는 자율적인 팀에서 나온다.
• 정기적으로 팀이 어떻게 하면 보다 효과적이 될 수 있는지 조율하고 수정한다.
13. Scrum
개요
Scrum 5 Values
• Commitment : 팀과 Sprint의 목표에 대한 약속을 달성
• Courage : 투명함에 대한 노력과 잘못을 인정하는 용기
• Focus : Sprint의 목표 달성에 집중
• Openness : 문제가 있을 경우 공개적으로 공유
• Respect : 자신의 강점을 알리면서 다른 사람들의 부족한
점을 비판하지 않음