오늘 회의 시간에 애자일에 대한 이야기가 나왔었다.
애자일이 뭔가 궁금해서 찾아보았다.
개발 프로세스는 일반적으로 분석, 기획, 개발, 테스트, 출시, 피드백, 피드백 반영까지 순환한다.
개발 전에 요구사항을 제대로 분석했는지, 기획은 제대로 되었는지, 아키텍처는 잘 잡았는지 확인해야한다.
그런 이후 개발을 진행하고 개발 과정에서 테스트를 충분히 진행해 품질을 끌어올리고,
출시 후 모든 지표를 살펴볼 수 있도록 측정 도구를 준비해야한다.
그래야만 출시 뒤에 바로 지표를 보고 처음으로 돌아가 주기를 반복할 수 있다.
애자일 소프트웨어 개발 선언
우리는 소프트웨어를 개발하고,
또 다른 사람의 개발을 도와주면서
소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치있게 여긴다.
이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
애자일 선언 이면의 원칙
우리는 다음 원칙을 따른다.
우리의 최우선 순위는, 가치 있는 소프트웨어를
일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
비록 개발의 후반부일지라도 요구사항 변경을 환영하라.
애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
작동하는 소프트웨어를 자주 전달하라.
두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에
걸쳐 날마다 함께 일해야 한다.
동기가 부여된 개인들 중심으로 프로젝트를 구성하라.
그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장
효율적이고 효과적인 방법은 면대면 대화이다.
작동하는 소프트웨어가 진척의 주된 척도이다.
애자일 프로세스들은 지속 가능한 개발을 장려한다.
스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
단순성이 (안 하는 일의 양을 최대화하는 기술이) 필수적이다.
최고의 아키텍처, 요구사항 설계는
자기 조직적인 팀에서 창발한다.
팀은 정기적으로 어떻게 더 효과적이 될지
숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
