Agile Software Development
Rapid Software Development(↔Plan-driven development)
Rapid Software Development and delivery is now often the most important requirement for software systems.
빠른 소프트웨어 개발과 배포는 최근 소프트웨어 시스템에서 가장 중요한 요구사항이 된다.
Software must evolve quickly to reflect changing business needs. Plan-driven development, However, does not meet these business needs.
소프트웨어는 빠르게 변화하는 사업 환경에 맞춰 진화해야하는데, 계획 주도형 개발방법은 그런 사업적 요구를 충족시켜줄 수 없다.
Agile development methods emerged in the late 1990s to radically reduce the delivery time for working software systems.
Agile개발 방법론은 90년대에 소프트웨어 시스템의 배포 시간을 급격하게 줄이기 위해 합쳐진 방법론입니다. 이는 Agile개발 기술과 Agile프로젝트를 서포트하는 Agile Project Managenment를 포함합니다.
Features of Agile development:
- The system is developed as a series of versions or increments with stakeholders involved in version specification and evaluation
- Frequent delivery of new versions for evaluation: 평가를 위해 새로운 버전이 매우 자주 만들어집니다.
- Extensive tool support(e.g., automated testing tools): CICD나 CTIP과 같이 Agile을 support하는 방대한 지원 도구들이 있습니다.
- Minimal documentation to focus on working code: 문서화를 최소화합니다.
Plan-Driven (Waterfall) vs Agile Development
이때, 주의할 점으로, Agile은 Software Requirement Specification, SRS를 만들지 않는다는 것 뿐이지, Requirement Engineering을 하지 않는다는 것은 아닙니다. 단지 공식문서화 하지 않는다는 것 뿐, 그 수많은 요구사항들을 머릿속에 넣을 수는 없습니다.
Agile Methods
Motivation:
- Dissatisfaction with the overheads involved in software design methods of the 1980s and 1990s (Waterfall): 기존 폭포수 모델은 잦은 요구사항 변경에 있어서 매우 취약하고 Documentation을 하는데 많은 시간을 쏟는다는 overhead가 있었습니다.
- To reduce overheads in the software process and to be able to respond quickly to changing requirements without excessive rework: 이러한 overheads들을 줄이기 위해, 다시 돌아가지 않고 빠르게 변화하는 요구사항에 맞추기 위해서 Agile method가 만들어졌습니다.
Agile methods
- Focus on the code rather than the design: 디자인 보다는 코드에 집중합니다. 이를 위해 clean-code나 refactoring개념이 생겼습니다.
- Based on an iterative approach to software development: 반복형 접근 방식에 기초합니다.
- Intend to deliver working software quickly and evolve this quickly to meet changing requirements: 변화하는 요구사항에 맞춰 빠르게 소프트웨어를 만들고, 진화시킵니다.
Two types of Agile methods
- Agile Development Techiques
- Agile Project Management
Agile Manifesto
"We are uncovering better wats of developing software by doing it and helping others do it, Through this work we have come to value."
Appicability of Agile Method
Development of small or medium-sized product for sale. so, almost all software products and apps are now developed using an agile approach.
중~소 사이즈의 판매를 위한 제품의 개발에서 사용됩니다. 이때 중~소 사이즈란 개발 팀의 인원이 최대 15명 정도를 말합니다. 만약 넘어가서 big-sized가 된다면 waterfall이 적합합니다. 각각의 부서는 문서로 소통해야하기 때문에 requirements를 적어놓은 documents(* SRS)가 필요하고, 이를 통해 유지 보수도 가능하기 때문입니다.
판매를 위한 제품은 일반적으로 요구 사항의 변경이 많고, 유지 보수가 필요없다는 특징을 갖습니다. 그 예로, 게임을 들 수 있습니다.
Custom system development within an organization where clear commitment from customers to become involved in the development process and few external rules and regulations that affect the software.
기업 혹은 조직이 고객이 개발 단계에 포함될 수 있다는 명확한 약속이 있고, 소프트웨어에 대한 규칙이나 제약이 적은 경우에 사용할 수 있습니다.
Agile vs DevOps
Agile은 오직 개발 방법에 대한 umbrella term입니다. 유지 보수에 관한 방법은 존재하지 않습니다. 하지만 DevOps의 경우 Development와 Maintenance가 계속 반복되는 구조를 띕니다. 또한 Agile은 배포하면 끝이지만 DevOps의 경우는 개발과 유지 보수가 계속 반복됩니다.
DevOps는 이런 개발과 유지 보수가 반복되는 일종의 현상? 개념이지만, Agile은 하나의 개발 방법론에 해당합니다.
Agile Development Techniques
Extreme Programming
Extreme Programming (XP) takes an 'extreme' approach to iterative development.
반복형 개발 방법에 대한 강력한 접근이 XP입니다.
- New version may be built several times per day
- Increments are delivered to customers every 2 weeks
- All tests must be run for every build and the build is only accepted if tests run successfully → Test First Development (TFD)
The XP principles
- Incremental development is supported through small, frequent system releases: 작게 자주 배포함으로써 발전적 개발을 수행합니다.
- Customer involvement means full-time customer engagement with the team: 고객은 그 팀에 항상 참여해있어야 합니다.
- Collective ownership through pair programming: pair programming을 통한 공통의 ownership을 형성합니다. pair programming을 통해 매일 파트너를 바꿔가며 개발하게 되면 하나의 프로그램에 대한 공통의 ownership을 가질 수 있기 때문입니다. 이를 위해서는 clean-code와 refactoring이 필요합니다.
- Change supported through regular system releases: 정기적인 배포를 통해 변화에 맞출 수 있습니다.
- Maintaning simplicity through constant refactoring: 기능은 똑같이 유지하되, code를 조금 더 이쁘게 고치는 refactoring을 통해 간결함을 유지합니다. 기능을 똑같이 유지하는지를 확인하기 위해서는 unit-test를 수행해야 하고, 이를 위해 CICD나 CTIP환경이 필요합니다.
XP Practices
'[학교 수업] > [학교 수업] Software Engineering' 카테고리의 다른 글
| [Software Engineering] 6주차 (1) (1) | 2024.10.07 |
|---|---|
| [Software Engineering] 5주차 (2) (5) | 2024.10.04 |
| [Software Engineering] 4주차 (2) (1) | 2024.09.27 |
| [Software Engineering] 4주차 (1) (0) | 2024.09.23 |
| [Software Engineering] 3주차 (2) (0) | 2024.09.20 |
