Agile 원칙 및 값(Jeff Sutherland)
Jeff Sutherland는 1993년에 Scrum을 발명했으며 Ken Schwaber와 함께 작업하여 OOPSLA'95에서 Scrum을 공식화했습니다. 두 사람은 많은 소프트웨어 회사에서 Scrum을 확장하고 개선했으며 Agile Manifesto를 작성하는 작업을 도왔습니다. http://scrum.jeffsutherland.com에 있는 Jeff의 블로그에는 Scrum의 기원과 최선의 구현 방법에 대해 수록되어 있습니다. |
Agile 개발은 Scrum, XP(Extreme Programming), DSDM(Dynamic Systems Development Method) 및 Crystal을 만든 사람들, 기능 중심의 개발 지지자, 그리고 소프트웨어 업계의 여러 사고 리더들로 구성된 그룹이 2001년에 작성한 Agile Manifesto에서 유래한 용어입니다. Agile Manifesto는 당대의 모든 개별 Agile 방법론에 대한 공통적인 최우선 가치 및 원칙을 설정했습니다. 팀이 높은 성과 사용 하기 위한 manifesto 세부 4 핵심 가치입니다.
개인 그리고 개인의 상호 작용
작동하는 소프트웨어 제공
고객 공동 작업
변화에 대응
이러한 핵심 가치는 Manifesto for Agile Software Development 웹 사이트에서 찾아볼 수 있는 12가지 원칙을 통해 지원됩니다.
이러한 가치는 Agile Manifesto를 만든 사람들이 별 의미 없이 단순히 립 서비스용으로 제시한 것이 아니라, 현실에서도 실질적인 효력이 있는 가치입니다. 각각의 Agile 방법론이 이러한 가치를 구현하는 방법은 조금씩 다르지만, 모두 이러한 가치를 하나 이상 실현하는 구체적인 프로세스와 방법을 갖고 있습니다.
개인 및 상호 작용
팀이 높은 성과를 얻기 위해서는 개인 및 상호 작용이 필수적입니다. 한 프로젝트를 대상으로 실시한 "커뮤니케이션 포화" 연구 결과, 커뮤니케이션 문제가 없을 경우에는 팀이 업계 평균보다 50배나 높은 성과를 얻을 수 있는 것으로 나타났습니다. 원활한 통신을 위해 agile 방법론 빈번한 조사 및 적용 주기를 사용 합니다. 이러한 주기는 몇 분(페어 프로그래밍의 경우), 몇 시간(연속 통합의 경우), 매일(일일 스탠드업 미팅의 경우) 또는 일정한 반복 기간(조사 및 검토의 경우)이 될 수 있습니다.
하지만 피드백 및 커뮤니케이션의 빈도를 높이는 것만으로는 커뮤니케이션 문제를 없애기에는 역부족입니다. 이와 같은 조사 및 적용 주기는 팀 멤버가 다음과 같은 핵심적인 태도를 실천할 때만 효과를 발휘합니다.
각자의 가치에 대한 존중
모든 커뮤니케이션에 있어서의 정직
모든 데이터, 작업 및 결정의 투명성
개개인이 모두 팀을 지원한다는 믿음
팀과 팀의 목표에 대한 헌신
이러한 태도를 촉진하기 위해 Agile 관리자는 협력적인 환경을 제공하고, 팀 코치는 보다 적극적인 참여를 유도하고, 팀 멤버는 이러한 행동을 명확하게 실천해야 합니다. 그럴 경우에만 팀이 모든 잠재력을 발휘할 수 있습니다.
이러한 유형의 동작을 얻기 위해 팀이 나타나지 않을 수 있습니다 것 보다 더 어렵습니다. 대부분의 팀은 문화적 규범이나 정직한 커뮤니케이션으로 인해 충돌을 겪은 과거의 부정적인 경험 때문에 정직함, 투명성 및 신뢰를 배제하고 있습니다. 이러한 경향을 바로잡기 위해 리더와 팀 멤버는 긍정적인 의견 충돌을 장려해야 합니다. 팀에 긍정적인 충돌을 사용할 경우는 생산성 문제를 보장할 뿐만 아니라 또한 다른 여러 가지 이점을 달성 하기 위해 작업:
프로세스를 향상시키기 위해서는 팀이 조직 내의 장애물이나 문제를 목록으로 작성하고, 이에 정면으로 대응하고, 우선 순위에 따라 이를 체계적으로 제거해야 합니다.
혁신 연구 하 고 아이디어가 Hirotaka 및 Ikujiro 될 때만 여 godfathers Scrum 문서화 하는 현상으로 충돌 하는 아이디어를 자유롭게 교환만 발생 합니다.
팀 공통 목표를 맞추고 자신의 관심사 및 잠재적인 충돌 표면 때 충돌 하는 안건의 해상도 발생 합니다.
헌신적인 협력은 사람들이 공동의 목표에 동의하고 각자 개인으로서 또한 팀의 일원으로서 성장하려고 노력할 때 비로소 이루어집니다.
마지막 내용인 헌신이 특히 중요합니다. 개인과 팀은 헌신적으로 작업할 때만 높은 가치를 제공하는 데 한 축을 담당하고 있다는 책임감을 느끼게 됩니다. 이것은 소프트웨어 개발 팀이 가져야 하는 기본적인 자세입니다. Agile 방법론 약정 및 자기 조직화 권유 팀원 우선 순위가 높은 작업 목록에서 항목을 가져올, 자신의 작업을 관리 하 고, 작업 방법을 향상에 집중 하 여 용이 하 게 합니다. 이러한 방법을 agile 팀에서 결과 달성 하기 위해 선도 하는 자기 조직화의 기본을 형성 합니다.
팀이 높은 성과를 얻을 수 있도록 Agile 방법론은 프로세스와 도구보다 개인 및 상호 작용을 중요하게 여깁니다. 모든 Agile 방법론은 사실상 빈번한 조사 및 적용 주기를 통해 커뮤니케이션과 공동 작업을 향상시키고자 합니다. 하지만 이러한 주기는 Agile 리더가 Agile 팀에서 정직, 투명성, 신뢰, 존중 및 헌신의 튼튼한 기반을 구축하는 데 필요한 긍정적인 충돌을 장려할 때만 효과를 발휘합니다.
포괄적인 문서화보다 작동하는 소프트웨어를 중시
Agile 개발이 가져다 주는 큰 차이점 중 하나가 바로 작동하는 소프트웨어입니다. Agile Manifesto에서 설명하는 모든 Agile 방법론은 실제로 작동하는 소프트웨어의 일부분을 일정한 간격으로 고객에게 제공하는 데 중점을 두고 있습니다.
모든 Agile 팀은 "작동하는 소프트웨어"에 대한 정의를 확립해야 합니다. 이를 가리켜 완성의 정의(Definition of Done)라고 합니다. 궁극적으로 기능은 모든 테스트를 통과하고 최종 사용자가 작동할 수 있는 상태가 되어야만 완성된 것으로 간주됩니다. 팀에서는 최소한 단위 테스트 수준을 넘어서 시스템 수준의 테스트를 실시해야 합니다. 가장 우수한 팀은 통합 테스트, 성능 테스트, 고객 수용 테스트까지 마쳐야 기능이 완성된 것으로 간주합니다.
낮은 오류 급여 중 하나는 세계에서 이미, 한 CMMI 수준 5 회사를 통해 광범위 한 데이터를 여러 프로젝트에 agile의 장점을 보여주었습니다. 체계적으로 생산의 속도 두 배로 하 고 다음과 같은 조치를 취 함으로써 결함을 40% 줄이는 수 있었습니다 특히:. 이 회사에서.
피쳐를 정의 하는 경우 승인 테스트를 정의 합니다.
및 우선 순위 기능을 구현 합니다.
구현 하는 즉시 수용 각 기능을 테스트 합니다.
가장 높은 우선 순위를 최대한 빨리 식별 되는 버그를 수정 합니다.
Agile Manifesto는 팀에서 작동하는 소프트웨어를 일정한 간격으로 제공할 것을 권장합니다. 성공에 한 팀으로 합의 하 여 수단 agile 팀 고성능 및 고품질이이 목표를 달성 하는 데 필요한 정보를 표시 하는 유용한 방법 중 하나입니다.
계약 협상보다 고객 공동 작업을 중시
지난 20년간 프로젝트 성공률은 전 세계적으로 두 배 이상 높아졌습니다. 이러한 향상 된이 기능에서 정기적으로 작동 하는 소프트웨어 피드백을 제공 하는 고객을 허용 하는 자주 배달 및 소규모 프로젝트의 결과로 발생 했습니다. Manifesto 작성자들이 소프트웨어 개발 프로세스에 고객을 참여시키는 것이 성공에 있어 필수적이라고 강조한 것은 확실한 근거가 있었기 때문입니다.
Agile 방법론은 고객 대표자가 개발 팀과 긴밀히 협력하도록 함으로써 이 가치를 더욱 강화합니다. 예를 들어 첫 번째 Scrum 팀은 수천 명의 고객을 보유하고 있었습니다. 모든 제품 개발 업체로 실현 되지 않았기 때문에, 제품 소유자 라고 고객이 프록시를 선택 합니다. 뿐만 아니라 모든 제품 소유자를 나타내는 고객 필드는 포함 되지만 관리, 영업, 지원, 클라이언트 서비스 및 기타 이해 관계자에. 제품 소유자는 팀이 작동하는 소프트웨어를 릴리스하는 4주마다 고객 및 관련자의 현실과 실제 피드백을 고려하여 요구 사항 목록을 업데이트해야 할 책임이 있었습니다. 활발 하 게 하는 데 도움이 고객에 게 모양 만든 소프트웨어입니다.
첫 번째 XP 팀은 내부 IT 프로젝트부터 시작했습니다. XP 팀 회사 최종 사용자가 자신의 팀 작업을 매일 할 수 있었습니다. 약 10%의 시간, 컨설턴트 및 내부 팀 팀과 일상적으로 사용할 수 있는 최종 사용자를 찾을 수 있습니다. 나머지 90%의 시간에는 대리자를 지정해야 합니다. XP 팀에서 고객이라고 부르는 이 고객 대리자는 최종 사용자와 협력하여 개발자가 구현해야 하는 기능의 명확한 우선 순위 목록을 제공합니다.
매일 고객 (또는 고객 대리자)가 공동 산업 데이터 표시 agile 프로젝트 성공률 전통적인 프로젝트의 두 배가 넘는 전세계 평균 있다고 합니다. Agile 방법론은 계약 체결을 인식 하기 때문에 이러한 장소에 특별히 고객 대표자를 위한 개발팀 만들었습니다.
계획 준수보다 변화에 대한 대응을 중시
고객을 주십시오 하 고 비즈니스 가치를 제공 하는 제품을 만드는 팀의 경우 팀 변경에 응답 해야 합니다. 업계 데이터에 따르면 60%가 넘는 제품 또는 프로젝트 요구 사항이 소프트웨어 개발 도중에 변경되고 있습니다. 전통적인 방식의 일반 프로젝트의 경우 제때에, 예산에 맞춰, 계획된 그대로 완료되어도 고객이 정확히 원하는 것이 아니기 때문에 고객을 만족시키지 못하는 경우가 종종 있습니다. " "험프리의 법칙"에 의하면 고객은 작동하는 소프트웨어를 보기 전에는 실제로 자신이 무엇을 원하는지 모릅니다. 고객이 프로젝트가 끝날 때까지 작동하는 소프트웨어를 보지 못하면 피드백을 적용하기에 너무 늦습니다. 제품 개발 중 팀 피드백과 새로운 정보를 통합할 수 있도록 agile 방법론 프로젝트 전반에 걸쳐 고객의 피드백을 받으십시오.
모든 Agile 방법론은 고객 또는 고객 대리자의 피드백에 맞춰 계획을 정기적으로 변경할 수 있는 프로세스를 기본적으로 갖추고 있습니다. Agile 방법론의 계획은 항상 최고의 비즈니스 가치를 가장 우선적으로 제공하도록 설계되었습니다. 일반적인 방식의 프로젝트는 대부분 예정보다 늦게 완료되는 반면, 20%의 기능에 80%의 가치가 있기 때문에 제대로 실행된 Agile 프로젝트는 조기에 완료됩니다. 따라서 고객의 만족도는 높아지고, 개발자는 보다 즐겁게 일할 수 있습니다. Agile 방법론은 성공하기 위해서는 변화를 위한 계획을 세워야 한다는 인식을 바탕으로 합니다. 그래서 검토, 소급 등 고객 피드백과 비즈니스 가치에 맞춰 우선 순위를 정기적으로 바꿀 수 있도록 특별히 설계된 프로세스를 구축한 것입니다.
Agile은 방법론 실현을 내포하는 포괄적인 개념
Agile 개발 자체는 방법론이 아닙니다. 이는 여러 개의 Agile 방법론을 지칭하는 포괄적 용어입니다. 2001년에 Agile Manifesto가 서명될 당시에는 Agile 방법론에 Scrum, XP, Crystal, FDD 및 DSDM이 포함되어 있었습니다. 이후에 Lean 방법론이 중요한 Agile 방법론으로 등장하여 이 항목의 뒷부분에 나오는 그림과 같이 Agile 개발의 범주에 포함되었습니다.
여러 컴퓨터 언어가 개체 지향 프로그래밍의 핵심 기능을 다양한 방식으로 매니페스트하듯이 각 Agile 방법론마다 서로 조금씩 다른 방법으로 Agile Manifesto의 핵심 가치를 구현합니다. 최근의 조사 결과에 따르면 Agile 방법론을 실행하는 팀 중 약 50%가 Scrum을 사용하고, 20%가 Scrum을 XP 구성 요소와 함께 사용하고, 12%가 XP만을 사용한다고 합니다. 전 세계적으로 80%가 넘는 Agile이 Scrum 또는 XP로 구현되어 있기 때문에 MSF for Agile Software Development v5.0은 Scrum 및 XP의 핵심 프로세스와 방법에 초점을 맞춥니다.
.png "Agile 우산")
Scrum은 Agile 개발 프로세스를 위한 프레임워크로, 특정한 엔지니어링 방법을 포함하고 있지 않습니다. 반대로, XP는 엔지니어링 방법에 초점을 맞추지만 개발 프로세스의 핵심 프레임워크는 포함하고 있지 않습니다. 그렇다고 해서 Scrum이 특정 엔지니어링 방법을 권장하지 않거나, XP에 프로세스가 없는 것은 아닙니다. 예를 들어, 최초의 Scrum은 현재 XP로 알려져 있는 모든 엔지니어링 방법을 구현했습니다. 하지만 소프트웨어 개발을 위한 Scrum 프레임워크는 팀이 2-3일 안에 시작하도록 설계된 반면, 엔지니어링 방법은 종종 구현되는 데 수 개월이 걸립니다. 따라서 각 팀에 대해 특정 방법을 구현해야 하는지 여부 그리고 구현한다면 언제 해야 하는지의 문제가 남습니다. Scrum 공동 제작자인 Jeff Sutherland와 Ken Schwaber는 Scrum 팀이 즉시 시작하고 장애 요소 목록과 프로세스 향상 계획을 작성할 것을 권장합니다. 엔지니어링 방법이 장애 요소로 식별되는 경우 팀은 XP 방식을 개선책으로 고려해야 합니다. 우수한 팀들은 Scrum을 XP 방식으로 보완하여 실행합니다. Scrum은 XP를 확장해 주고, XP는 Scrum이 제대로 작동하도록 해줍니다.
다음 표에서는 Scrum과 XP의 주요 용어를 어떻게 서로 대응하는지를 보여 줍니다.
Scrum |
XP |
|---|---|
제품 소유자 |
고객(Customer) |
Scrum 마스터 |
XP 코치 |
팀 |
팀 |
스프린트 |
반복(Iteration) |
스프린트 계획 회의 |
계획 게임 |
참고 항목
개념
Visual Studio ALM 및 TFS로 작업 추적