Agile
애자일(Agile)은 소프트웨어 개발 및 프로젝트 관리를 위한 반복적이고 유연한 방법론 및 철학을 지칭하는 용어입니다.
애자일 방법론은 초기 계획보다는 변화에 민첩하게 대처하고 고객의 피드백을 적극 수용하며 작은 단위의 작업을 반복적으로 수행하여 제품을 개선하는데 중점을 두는 개발 방법론입니다.
미리 정해진 몇 개의 단계에 따라 엄격한 순서대로 이루어지는 워터폴(Waterfall) 프로세스와 비교가 많이 되는 반대 개념입니다.
워터폴은 작은 단위의 작업을 신속하게 완료하는데 주력하는 애자일과 달리 몇 달 또는 몇 년이 걸리는 전체 프로젝트에 집중합니다.
애자일은 지속적으로 테스트하는 반면 워터폴은 프로젝트가 끝난 후에야 QA를 실행합니다.
마지막에 테스트를 진행하므로 개발자는 개발 중에 발생하는 새로운 요구 사항을 다루지 않습니다.
원칙
애자일은 일을 빠르게 하기 위해서가 아니라 고객과 시장의 변화에 빠르게 대처하기 위한 방법입니다.
애자일 선언을 통해 애자일 개발론의 원칙을 제시하나 이를 보안하기 위한 12가지 원칙을 제시합니다.
- 초기부터 지속적으로 고객 만족:
- 우리의 최우선 과제는 가치 있는 소프트웨어를 조기에 지속적으로 제공하여 고객을 만족시키는 것입니다.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- 요구사항 변경 수용
- 개발 후반에도 요구 사항 변경을 환영합니다. 민첩한 프로세스는 고객의 경쟁 우위를 위해 변화를 활용합니다.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- 짧은 배포 간격
- 더 짧은 기간을 선호하여 몇 주에서 몇 달까지 작동하는 소프트웨어를 자주 제공합니다.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- 기획자/현업과 개발자는 함께 일하기
- 비즈니스 담당자와 개발자는 프로젝트 전반에 걸쳐 매일 함께 작업해야 합니다.
- Business people and developers must work together daily throughout the project.
- 동기부여된 팀원들로 프로젝트팀 만들기
- 의욕이 넘치는 개인을 중심으로 프로젝트를 구축하십시오. 그들에게 필요한 환경과 지원을 제공하고 그들이 일을 완수할 것이라고 믿으십시오.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- 얼굴보고 대화하기
- 개발팀 내에서 그리고 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- 동작되는 소프트웨어로 진도 측정
- 작동하는 소프트웨어는 발전의 주요 척도입니다.
- Working software is the primary measure of progress.
- 지속 가능한 개발 속도 유지
- 민첩한 프로세스는 지속 가능한 개발을 촉진합니다. 스폰서, 개발자, 사용자는 무한정 일정한 속도를 유지할 수 있어야 합니다.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- 좋은 기술, 설계에 관심
- 기술적 우수성과 좋은 디자인에 대한 지속적인 관심은 민첩성을 향상시킵니다.
- Continuous attention to technical excellence and good design enhances agility.
- 단순성
- 단순성(완료되지 않은 작업의 양을 최대화하는 기술)은 필수적입니다.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- 자기 조직화 팀
- 최고의 아키텍처, 요구 사항 및 디자인은 자체 구성 팀에서 나옵니다.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- 정기적으로 효율성 제고
- 정기적으로 팀은 어떻게 하면 더 효과적으로 일할 수 있을지 생각해 본 다음 그에 따라 행동을 조정하고 조정합니다.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
라이프사이클
Plan
계획 단계에서는 프로젝트 목표와 요구사항을 정의하고 프로젝트 일정과 예산 등과 세부 사항을 정의합니다.
고객 및 사용자가 원하는 요구사항의 타당성을 조사하고 SW 제약 조건을 정의하고 Task를 이해합니다.
또한 팀을 구성하고 역할을 할당하며 프로젝트 계획서를 작성하고 프로젝트의 범위, 목표 설정합니다.
Design
설계 단계는 시스템 또는 소프트웨어의 아키텍처와 디자인을 수립합니다.
UI & UX를 기획하고 시스템 또는 소프트웨어의 전체 구조를 계획하며 요구사항을 충족시키는 설계 문서를 작성합니다.
Develop
개발 단계는 설계에 따라 코드를 작성하고 소프트웨어나 제품을 개발합니다.
프로그래밍 언어와 개발 도구를 사용하여 기능을 구현하고 모듈을 개발하고 코드 작성과 동시에 버전 관리 시스템을 사용하여 변경 사항을 추적하며 협업 및 코드 리뷰를 수행합니다.
Test
테스트 단계는 소프트웨어나 제품의 품질을 검증하기 위한 다양한 테스트를 수행합니다.
단위 테스트, 통합 테스트, 시스템 테스트 및 성능 테스트를 실행하여 버그를 찾고 수정합니다.
품질 확보와 사용자 요구 사항을 충족시키기 위한 품질 보증(QA) 활동을 수행합니다.
Deploy
배포 단계는 개발된 소프트웨어나 제품을 실제 환경에 배포합니다.
사용자 또는 고객에게 제품을 제공하며 설치 및 설정을 수행합니다.
배포 후에는 모니터링 및 유지 보수를 계속하고 업데이트 및 보완을 수행합니다.
Review
검토 단계는 프로젝트의 마무리 단계로 전반적인 결과물과 프로젝트 진행 상황을 검토하며 이해 관계자의 평가 및 피드백을 수용합니다.
테스트 결과와 기획에 따라 수정할 부분을 제시하며 이를 검토합니다.
오탈자 및 오류 내용을 댓글 또는 메일로 알려주시면, 검토 후 조치하겠습니다.
'Software Architecture' 카테고리의 다른 글
[Dev] BDD(Behavior-Driven Development) (0) | 2023.08.08 |
---|---|
[Term] State vs Status (0) | 2023.07.25 |