린과 애자일로 진행하기 - tool4Free/okjob GitHub Wiki
차이점과 공통점
애자일은 '생산' 맞춰져 있고 린 방법은 '학습'에 초점이 맞춰져 있다.
공통점은 '사용자의 피드백'이다.
이미지 출처: http://smartbooks1.tistory.com/233
린을 첨가하기
애자일 : 사용자 요구 -> 사용자 스토리 백로그 -> 화면 작업 -> 개발 -> 이해관계자 리뷰 -> 반복
린 : 아이디어 -> 만들기 -> 제품출시 -> 측정 -> 데이터 -> 학습 -> 아이디어
소스코드로 구현이 완료된 제품으로 사용자의 피드백을 받는 것은 아주 비싼 활동이다. 애자일에서는 이해 관계자 리뷰 때 "이거 아닌데요" 하는 말에 이전의 모든 노력이 물거품 되어 버린다.
최소한의 제품(MVP)으로 아이디어 검증 먼저 하기
애자일의 요구 -> 화면작업 두 단계가 린의 한 싸이클과 같다. 개발 전에 이미 한차례의 검증을 끝내서 실제 코딩 및 기타 제작 비용을 줄이는 것이다.
아이디어를 구체화하고, 최소한의 제품(프로토타입)을 작성하고 이 프로토타입으로 소비자에게 검증받고 이것을 통해 데이터를 만들고 학습한다.
즉, 아이디어-프로토타입(화면작성)제품 출시-> 측정 -> 피드백 학습 -> 검증완료 싸이클을 먼저 돌고나서
검증된 아이디어를 사용자 스토리로 구체화한다.
검증된 아이디어를 사용자 스토리로 구체화 하기
이제 사용자 스토리를 작성한다.
- 바뀔 가능성이 조금이라도 있다면 사용자 스토리조차도 상세하기 정의하지 않는다.
사용자 스토리는 어떤 개발자가 보더라도 궁금한 사항이 없을 정도로 구체적으로 정의한다.
- 제목 기재 뒤, 사용자가 얻을 수 있는 가치를 기재한다.
- 그 다음 구현이 완료된 시점에 수행되는 인수 테스트 조건을 Given When Then 형싟으로 작성해서
- 어떤 화면이 주어졌을 때 사용자가 어떤 이벤트를 발생시키느냐에 따라 어떤 결과가 나온다는 것을 보여준다.
- 이 인수 테스트는 테스트 케이스 작성시 그대로 사용되며 최초 기획과 의도를 벗어나는 경우 최소화할 수 있다.
- 개발자나 디자이너에 전달하고자 하는 내용도 추가로 작성한다.
- 또한 이미 화면이 개발되었기 때문에 구현이 완료된 모습과 똑같은 화면 디자인의 링크를 첨부한다.
출처 : https://www.pivotaltracker.com/blog/principles-of-effective-story-writing-the-pivotal-labs-way/
개발 완료 유무는 사용자 스토리를 작성한 사람이 판단한다.
스토리 작성 주체가 개발 완료 유무를 확인한다. 즉 자기 기능을 개발한 사람이 충분히 이해한 상태로 사용자 스토리를 작성해야, 나중에 개발을 해놓고 스스로 제대로된 개발을 인지하고 마무리 지을 수 있다.
요구 사항에 대해서 깊이 고민을 하면 재작업 없이 해당 백로그 구현을 마무리 할 수 있게된다. 요구사항을 미처 제대로 작성하지 못했거나 놓친 사항이 있더라도 인수 테스트 과정에서 대부분 도출해낼 수 있다.
즉, 커뮤니케이션 비용을 크게 줄일 수 있다.
테스트 주도 개발과 페어 프로그래밍
최고한 사용자 스토리에 기재되어 있는 인수 테스트 조건은 소스 코드로 작성되어 '스펙'이 되어야 한다. 이렇게 먼저 작성된 테스트 케이스를 기준으로 제품 코드를 작성한다. 이는 테스트 자동화를 통한 품질 향상에 도움을 주며, 소스 코드간의 의존성을 제거하면서 설계적으로 훌륭한 제품을 만드는데 기여한다.
페어 프로그래밍을 하면 실시간 코드리뷰가 되고 서로의 실력향상에도 도움이 된다. 만약 팀 전체가 매일 짝을 바꾸며 작업을 한다면 기술적으로나 비즈니스적으로 얻은 통찰들을 실시간으로 공유하는데 기여한다.
참조 : http://media.fastcampus.co.kr/knowledge/lean-startup-agile-software-programming/