| Key Challenges | Solution Offered by Continuous Inspection |
|---|
| Too little, too late | - 팀은 품질 요구사항에 대항되는 품질에 대한 지속적인 피드백을 받는다.
- 버전 간 비교를 포함하여 시간이 지남에따라 명확하고 업데이트된 품질 향상 그림이 제공 된다.
- 팀은 소개로부터 이슈를 추적할 수 있고 피드백을 제공한다.
- 이해관계자는 품질 결합 생성 시 즉각 알림을 받는다.
- 품질 게이트는 매일 실행된다.
- 최종 품질 게이트 이터페이션은 비-이벤트가 된다.
- 개발자의 지속적인 교육은 개선의 선순환으로 이어진다.
|
| Pushback from development teams | - 품질 수행 계획은 팀 내에서 직접 생성되고 개발 프로세스에 통합된다.
- 소프트웨어 품질은 개발 프로세스의 일부이다.
- 리뷰에는 소프트웨어에 다른 번전과 버전과 다양한 변경을 포함하는 상황별과 히스토리 정보를 포함한다.
- 이해관계자는 소프트웨어 품질에 대한 의미 있는 정보에 실시간으로 액세스 할 수 있다.
- 개발 팀은 품질 결함을 추가하자마자 즉시 문제를 해결할 수 있도록 정보를 받는다.
- 팀은 더 나은 소프트웨어를 개발할 수 있는 능력을 얻는다.
|
| Lack of process ownership | - 코드 품질 소유권은 개발 팀 소유이다.
- 소프트웨어 품질은 개발프로세스에 내장된다. 그리고 모든 사람의 책임이 된다.
- 모든 이해관계자에게 접근가능한 소프트웨어 품질 도구가 조직 전역에 제공된다.
- 품질 요구사항은 팀 멤버에 따라 그리고 조직 전체에 공유되고 업데이트되고 리뷰될 수 있다.
- 품질 판단은 사전 조직에 게시된 객관적인 기준에 따라 자동화된 방식으로 이루어진다.
- 보고는 소프트웨어 유지보수가능성을 명확하게 보여주고 외부 컨설턴트가 필요없이 즉시 이해할 수 있다.
- 지속적인 교육을 통해 장기적으로 소프트웨어 품질이 크게 향상된다.
|
| Heterogeneous requirements | - 팀은 새로운 코드 및 변경된 코드 뿐만 아니라 전체 코드 기반에서 소프트웨어 품질을 측정할 수 있다.
- 팀은 새로운 문제의 주입을 추적할 수 있다.
|