메뉴

애자일 선언 : 애자일 가치 및 원칙 이해

  • 메인
  • 다른
  • 애자일 선언 : 애자일 가치 및 원칙 이해

agile manifesto understanding agile values

문제를 제거하기 위해 도구를 사용해보십시오

Agile Manifesto 소개 :

에 대한 이전 튜토리얼 애자일 방법론 애자일 모델과 방법론에 대해 자세히 설명했습니다.

그러나 지금까지는 애자일이 애자일이 필요한 이유와 폭포 모델과 같은 기존 소프트웨어 개발 방법론의 단점을 애자일이 어떻게 극복했는지에 대해서는 다루지 않았습니다.

이 자습서에서는 애자일 및 애자일 선언문에 대해 자세히 알아 봅니다. 우리는 선언문이 무엇을 말하고 그 안에 내포 된 가치와 원칙이 무엇인지 볼 것입니다.

Windows 7을위한 최고의 무료 방화벽

애자일 매니페스트

학습 내용 :

소개

우리가 우리에서 보았 듯이 이전 튜토리얼 , 초기 개발 방법론은 너무 많은 시간이 걸리고 소프트웨어를 배포 할 준비가되었을 때 비즈니스 요구 사항이 변경되어 현재 요구 사항을 충족하지 못합니다.

그 당시 부족했던 변화의 속도는 많은 문제를 일으켰습니다. 서로 다른 개발 방법론의 리더들이 만나 앞으로 나아갈 길을 결정하고 더 나은 방법에 동의 할 수 있었고 선언문의 문구도 마무리 할 수있었습니다.

이것은 실무자들이 그것을 이해하고, 참조하고, 실천할 수 있도록 돕기 위해 4 가지 가치와 12 가지 원칙으로 포착되었습니다. 그리고 그 시점에서 그들 중 누구도 이것이 프로젝트 관리의 미래에 미칠 영향을 상상할 수 없었습니다.

애자일 선언

이 선언문은 애자일의 본질을 최소한의 단어로 표현하기 위해 매우 신중하게 작성되었으며 다음과 같이 읽습니다.

“우리는 소프트웨어를 개발하고 다른 사람들이 그렇게하도록 도와줌으로써 더 나은 소프트웨어 개발 방법을 찾고 있습니다. 이 작업을 통해 우리는 다음과 같은 가치에 도달했습니다.

  • 프로세스 및 도구에 대한 개인 및 상호 작용.
  • 포괄적 인 문서에 대한 작업 소프트웨어.
  • 계약 협상을 통한 고객 협력.
  • 계획에 따라 전환에 응답합니다.

즉, 오른쪽 항목에는 가치가있는 반면 왼쪽 항목에는 더 가치가 있습니다.”

보시다시피, 이것들은 매우 간결하고 간단한 진술이며 창립자들이 무엇을 홍보하고 싶었는지 명확하게합니다. 일반적으로 전통적인 프로젝트 계획은 엄격하고 절차와 일정을 강조하지만 애자일 선언문은 정확히 반대 방향으로 전파됩니다.

다음을 선호합니다.

  • 사람들
  • 생성물
  • 커뮤니케이션 및
  • 민감도

우리는 애자일 가치와 원칙에 대한 더 깊은 이해를 통해 창립자들이 세부적으로 홍보하고자했던이 새로운 패러다임을 탐구 할 것입니다.

4 가지 애자일 가치

12 가지 원칙과 함께 4 가지 가치가 민첩한 소프트웨어 제공을 안내합니다. 이제 각 값에 대해 자세히 설명하겠습니다.

애자일 가치

# 1) 프로세스 및 도구에 대한 개인 및 상호 작용

개인과 상호 작용이 프로세스와 도구보다 선호됩니다. 개인이 정렬되고 서로를 이해하면 팀은 도구 또는 프로세스와 관련된 문제를 해결할 수 있습니다.

그러나 팀이 맹목적으로 프로세스를 고수해야한다고 주장하면 개인간에 오해를 유발하고 예상치 못한 장애물을 만들어 프로젝트가 지연 될 수 있습니다.

그렇기 때문에 앞으로 나아갈 프로세스에 맹목적으로 의존하는 것보다 팀원간에 상호 작용과 의사 소통을하는 것이 항상 선호됩니다. 이를 달성하는 방법 중 하나는 개발 팀과 협력하여 작업하고 의사 결정을 내릴 수있는 관련 제품 소유자를 확보하는 것입니다.

개인이 스스로 기여할 수 있도록 허용하면 테이블에 가져올 수있는 것을 자유롭게 선보일 수 있습니다. 이러한 팀 상호 작용이 일반적인 문제를 해결하는 방향으로 진행될 때 결과는 매우 강력 할 수 있습니다.

# 2) 포괄적 인 문서를 통해 작동하는 소프트웨어

전통적인 프로젝트 관리에는 포괄적 인 문서화가 포함되어 수개월이 지연되었습니다. 이로 인해 프로젝트 제공에 부정적인 영향을 미치며 그 결과 지연이 불가피했습니다.

이러한 프로젝트를 위해 생성 된 문서의 종류는 매우 상세했고 너무 많은 문서가 생성되어 프로젝트 진행 중에 참조조차하지 않았습니다. 이것은 프로젝트 팀이 함께 살던 불필요한 악이었습니다.

그러나 이것은 또한 배달 문제를 악화 시켰습니다. 팀이 사양에 따라 100 % 완성 된 제품을 만들고 싶었 기 때문에 문서화에 집중했습니다. 그렇기 때문에 모든 사양을 세부적으로 캡처하는 데 중점을 두었습니다.

그러나 여전히 최종 제품은 예상과 상당히 다르거 나 관련성을 잃었을 것입니다. 그렇기 때문에 애자일은 작동하는 소프트웨어가 수많은 문서보다 고객의 기대치를 측정하는 데 훨씬 더 나은 옵션이라고 말합니다.

문서가 필요하지 않다는 의미는 아닙니다. 이는 작동하는 제품이 몇 달 전에 작성된 문서보다 고객의 요구와 기대에 부합하는 더 나은 지표라는 것을 의미합니다. 또한 팀이 스프린트가 끝날 때 클라이언트에게 작업 소프트웨어를 보여 주면서 팀이 필요에 따라 변경에 적응할 준비가되어 있음을 의미합니다.

스프린트 중에 제품을 테스트하지 못하면 다음 스프린트에서 다양한 비용과 노력이 필요합니다. 기능이 배포되면 이러한 변경 비용이 훨씬 더 많이 올라갑니다.

3. 계약 협상을 통한 고객 협업

협상은 세부 정보가 아직 캡처 중이며 확정되지 않았 음을 의미합니다. 재협상의 여지가 있습니다. 그러나 일단 협상이 끝나면 그것에 대해 논의 할 수 없습니다. 애자일이 말하는 것은 협상 대신 협업을 추구한다는 것입니다.

협업은 여전히 ​​토론의 여지가 있고 의사 소통이 진행 중임을 의미합니다.

한 번만은 아닙니다. 이것이하는 일은 두 배의 이점을 제공합니다. 팀이 초기 단계에서 필요한 경우 코스 수정을 수행하는 데 도움이되지만 클라이언트가 비전을 개선하고 필요한 경우 요구 사항을 재정의하는 데 도움이됩니다. 계획.

다른 측면은 기존의 소프트웨어 개발 모델이 문서화 및 협상 단계에서 개발이 시작되기 전에 고객을 포함하지만 프로젝트 개발 중에 관여하지 않는다는 것입니다.

요구 사항이 동결되면 제품이 준비되면 제품 만 볼 수 있습니다. 애자일은 전체 라이프 사이클 동안 고객의 참여를 허용함으로써 이러한 장벽을 극복합니다.

이를 통해 애자일 팀이 고객 요구 사항에 더 잘 부합 할 수 있습니다. 이를 달성하는 방법 중 하나는 팀을 설명하고 고객 우선 순위에 따라 작업을 조정하기 위해 실시간으로 팀을 도울 수있는 헌신적이고 참여적인 제품 소유자를 통하는 것입니다.

4. 계획에 따른 변화에 대한 대응

표준 사고 프로세스는 변경이 비용이 많이 들고 어떤 대가를 치르더라도 변경을 피해야한다는 것입니다. 타임 라인과 제품 사양을 고수하여 제공 할 문서와 정교한 계획에 불필요한 초점을 맞추는 것입니다.

그러나 경험이 우리에게 가르쳐 주듯이 변화는 대부분 불가피하며, 변화를 피하는 대신 수용하고 계획을 세워야합니다.

애자일을 통해 이러한 전환을 할 수 있습니다. 애자일은 변화가 비용이 아니라 프로젝트 개선에 도움이되는 환영 피드백이라고 생각합니다. 피하는 것이 아니라 가치를 더합니다.

애자일이 제안한 짧은 스프린트를 통해 팀은 빠른 피드백을 받고 짧은 시간에 우선 순위를 변경할 수 있습니다. 반복에서 반복으로 새로운 기능을 추가 할 수 있습니다.

우리는 왜 이것을합니까? 폭포수 방식을 사용하여 개발 된 대부분의 기능은 사용되지 않기 때문입니다. 이는 폭포 모델이 계획을 따르는 반면 우리가 가장 적게 아는 단계이기 때문입니다.

애자일도 계획을 세우지 만 필요할 때 계획이 충분히 수행되는 적시 접근 방식을 따릅니다. 그리고 계획은 스프린트가 진행됨에 따라 항상 변경 될 수 있습니다.

12 가지 애자일 원칙

팀이 애자일로 전환하는 것을 돕고 안내하고 그들이 따르는 관행이 애자일 문화와 일치하는지 확인하기 위해 선언문을 만든 후에 추가 된 12 개의 애자일 원칙이 있습니다.

다음은 Agile Alliance에서 2001 년에 발표 한 12 가지 원칙의 원본입니다.

#1) 우리의 최우선 순위는 귀중한 소프트웨어를 조기에 지속적으로 제공하여 고객을 만족시키는 것입니다.

#두) 개발 후반에도 변화하는 요구 사항을 환영합니다. 애자일 프로세스는 고객의 경쟁 우위를 위해 변화를 활용합니다.

#삼) 짧은 기간을 선호하여 2 주에서 2 개월까지 작업 소프트웨어를 자주 제공하십시오.

# 4) 비즈니스맨과 개발자는 프로젝트 내내 매일 함께 작업해야합니다.

# 5) 동기 부여 된 개인을 중심으로 프로젝트를 구축하십시오. 그들에게 필요한 환경과 지원을 제공하고 그들이 일을 완수 할 수 있도록 신뢰하십시오.

# 6) 개발 팀과 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다.

# 7) 작업 소프트웨어는 진행 상황의 주요 척도입니다.

# 8) 애자일 프로세스는 지속 가능한 개발을 촉진합니다. 후원자, 개발자 및 사용자는 무한정 일정한 속도를 유지할 수 있어야합니다.

# 9) 기술적 우수성과 우수한 디자인에 대한 지속적인 관심은 민첩성을 향상시킵니다.

# 10) 단순성 — 수행하지 않는 작업량을 최대화하는 기술은 매우 중요합니다.

#열한) 최상의 아키텍처, 요구 사항 및 디자인은 자체 구성 팀에서 나옵니다.

# 12) 정기적으로 팀은 더 효과적인 방법을 숙고 한 다음 그에 따라 행동을 조정하고 조정합니다.

이러한 애자일 원칙은 개발 팀에 실질적인 지침을 제공합니다.

12 가지 원칙을 구성하는 또 다른 방법은 다음 네 가지 개별 그룹으로 고려하는 것입니다.

  • 고객 만족
  • 품질
  • 팀워크
  • 프로젝트 관리

#1) 우리의 최우선 순위는 귀중한 소프트웨어를 조기에 지속적으로 제공하여 고객을 만족시키는 것입니다. 고객은 제품을 볼 수있는 모호한 대기 기간을 거치지 않고 모든 스프린트에서 작동하는 소프트웨어가 제공되는 것을보고 매우 기뻐할 것입니다.

여기서 고객은 프로젝트 후원자 또는 개발 비용을 지불하는 사람으로 정의 할 수 있습니다. 제품의 최종 사용자도 고객이지만 최종 사용자를 사용자라고하므로 둘을 구분할 수 있습니다.

#두) 개발 후반에도 변화하는 요구 사항을 환영합니다. 애자일 프로세스는 고객의 경쟁 우위를 위해 변화를 활용합니다. 전체 일정에 많은 지연없이 변경 사항을 통합 할 수 있습니다.

애자일 팀은 무엇보다 품질을 중요하게 생각하기 때문에 변경을 방지하고 비즈니스 요구 사항을 충족하지 않는 제품을 제공하는 것보다 변경 사항을 통합하고 고객 요구 사항에 따라 제공합니다.

#삼) 짧은 기간을 선호하여 몇 주에서 몇 달까지 작동하는 소프트웨어를 자주 제공합니다. 이것은 스프린트에서 작업하는 팀이 처리합니다. 스프린트는 타임 박스 반복이며 각 스프린트가 끝날 때 작동하는 소프트웨어를 제공하므로 고객은 정기적으로 진행 상황에 대한 아이디어를 얻습니다.

# 4) 비즈니스맨과 개발자는 프로젝트 전체에서 매일 협력해야합니다. 둘 다 공동으로 작업하고 코스 수정 및 변경 민첩성을 위해 둘 사이에 지속적인 피드백 루프가있을 때 더 나은 결정이 내려집니다. 이해 관계자 간의 커뮤니케이션은 항상 민첩한 핵심입니다.

# 5) 동기 부여 된 개인을 중심으로 프로젝트를 구축하십시오. 그들에게 필요한 환경과 지원을 제공하고 그들이 일을 완수 할 수 있도록 신뢰하십시오. 팀을 지원하고 신뢰하며 동기를 부여해야합니다. 동기 부여 된 팀은 최선을 다하지 않는 불행한 팀보다 성공할 가능성이 더 높고 우수한 제품을 제공 할 것입니다.

이를 수행하는 방법 중 하나는 개발 팀이 스스로 구성하고 스스로 결정을 내릴 수 있도록 권한을 부여하는 것입니다.

# 6) 개발 팀과 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다. 팀이 같은 위치에 있고 면담을 위해 얼굴을 맞대고 만날 수 있다면 의사 소통이 더 좋고 영향력이 있습니다. 그것은 신뢰를 구축하고 다양한 이해 관계자들 사이에 이해를 가져다줍니다.

# 7) 작업 소프트웨어는 발전의 주요 척도입니다. 작동하는 소프트웨어는 다른 모든 KPI를 능가하며 수행 한 작업의 가장 좋은 지표입니다.

# 8) 애자일 프로세스는 지속 가능한 개발을 촉진합니다. 후원자, 개발자 및 사용자는 무한정 일정한 속도를 유지할 수 있어야합니다. 전달의 일관성이 강조됩니다. 팀은 프로젝트 기간 동안 속도를 유지할 수 있어야하며 처음 몇 번의 스프린트 후에는 소진되지 않아야합니다.

# 9) 기술적 우수성과 우수한 디자인에 대한 지속적인 관심은 민첩성을 향상시킵니다. 팀은 변경 사항을 처리하고 고품질 제품을 생산하는 동시에 변경 사항을 통합 할 수있는 모든 기술과 우수한 제품 디자인을 갖추고 있어야합니다.

# 10) 단순성 — 완료되지 않은 작업량을 최대화하는 기술은 필수적이며 완료의 정의를 충족하기에 충분합니다.

#열한) 최고의 아키텍처, 요구 사항 및 디자인은 자체 구성 팀에서 나옵니다. – 자체 조직화 된 팀은 권한을 부여 받고 작업에 대한 소유권을 갖습니다. 이것은 팀원들간에 열린 의사 소통과 정기적 인 아이디어 공유로 이어집니다.

# 12) 정기적으로 팀은 더 효과적인 방법을 검토 한 다음 그에 따라 행동을 조정하고 조정합니다. 자가 개선은 더 빠른 결과와 더 적은 재 작업으로 이어집니다.

결론

고객 중심 성과 커뮤니케이션에 대한 집중은 오늘날 가시적 인 애자일의 성공을 가져 왔습니다.

이는 소프트웨어 제공뿐만 아니라 다른 산업에도 영향을 미치는 검증 된 기술이며 오늘날 그 자체로 산업이되었습니다.

이 시리즈의 다가오는 튜토리얼은 스크럼 팀의 역할과 함께 더 많은 것을 설명 할 것입니다 !!

이전 튜토리얼 | NEXT 튜토리얼

추천 도서

^