Origin: iansommerville.com/software-engineering-book/
ch3 Agile Software Development
Plan-driven development
분리된 개발 단계에 기반하여, 각 단계들은 미리 계획된 아웃풋들이 있다.
꼭 워터폴모델은 아니고, 점진적인 개발도 가능하다
Iteration occurs within activities
- 무엇을, 언제, 누가 -> 다 플랜함
Agile development
스펙상세, 디자인, 구현, 테스팅이 사이사이에 있고, 개발 과정에서 각 개발 아웃풋들은 네고가 가능하다.
애자일 방법론
디자인보다는 코드에 집중한다.
소웨 개발의 반복적인 접근에 기반한다.
동작하는 소웨의 빠른 배포, 변화하는 요구사항에 빠르게 맞추어 진화하기 위한 의도이다.
소웨 프로세스에서의 오버헤드를 줄이기 위함이다.
The principles of agile methods (애자일 방법론의 원리)
1. Customer involvement (고객이 계속 요구사항을 반복적으로 주어야함)
2. Incremental delivery (점진적으로 고객 요구사항을 계속 반영해야함)
3. People not process (규정된 프로세스 없이 멤버마다의 방식이 살아있어야한다)
4. Embrace change (요구사항 변경울 염두하고 수용할 수 있게끔 디자인 되어야함)
5. Maintain simplicity (소웨 개발 시 계속 단순함을 유지하고, 가능할 때마자 복잡도를 제거해주어야함)
고객 시스템 개발 시, 규정이나 지침이 별로 없는 경우에는 고객의 참여가 꼭 필요하다.
Agile development technique
Extreme programming(XP): 새로운 버전이 하루에도 여러번 나옴. 매 2주마다 고객에게 점진적으로 전달됨. 매 빌드마다 테스트함.
- Pair programming
- Collective ownership
- Continuous integration
- Sustainable pace (야근 x)
- On-site customer (풀타임으로)
- 작고 빈번한 시스템 릴리즈
- 리팩토링을 통해 단순성을 유지함
Influential XP practices
1. User stories for specification
2. Refactoring
3. Test-first development
4. Pair programming
Scrum
- Sprint cycle: 일단 정해지면, 스크럼마스터를 통해서만 외부(고객)와 커뮤니케이션 한다. (외부 방해로부터 보호)
- 대규모의 프로젝트 경우에는 Distributed Scrum
Scaling up and Scaling out (Agile)
스케일링 업은 대규모 프로젝트
스케일링 아웃은 대규모 조직
애자일 방법론을 스케일링 할 때는, 애자일 기본을 유지하는 것이 중요하다. (유동적인 계획, 빈번한 릴리즈, 지속적인 통합, TDD, 팀 커뮤니케이션)
애자일 방법론들의 실제적인 문제들
- 애자일 개발론의 informality는 큰 회사들한테 흔한 계약서 정의에 대한 접근이 잘 맞지 않는다.
- 새로운 소웨 개발에 적합하고, 유지보수에는 잘 맞지 않는다. (큰 회사들은 유지보수에서 비용이 많이 나온다)
- 애자일 방법론은 원래 작은 팀들을 위해 만들어 졌지만 요새는 세계적으로 분산된 팀들이 많다.
애자일 방법론은 점진적인 개발론으로, 바른 소웨 개발, 빈번한 배포, 문서 최소화와 코드퀄리티를 높여서 오버헤드를 줄인다.
애자일 개발의 실제는
- User stories for system specification
- Frequent releases of the software
- Continuous software improvement
- Test-first development
- Customer participation in the development team
스크럼은 애자일 방법론에서 프로젝트 관리의 프레임웍을 제공한다. (스프린트 세트들의 센터)
plan-based and agile 은 섞여있다.
큰 시스템에 스케일링 하기는 어렵다.