1:30-3:30 오후, 애자일에 관한 사내 세션을 들었다. 개인용으로 정리한 내용이고 키워드 위주로만 적었지만, 일부 수정해서 공개해본다.
목차
전통적인 개발방법론
애자일
XP
SCRUM
애자일의 오해
전통적인 개발방법론
문서
SRS: SW Requirement Specification
SDS
WBS ~= backlog
워터폴
req -> design -> imp -> verification -> maintenance
그 고객과 디자이너와 개발자와 비즈니스 그네 그림
커뮤니케이션을 못해서 이렇다.
애자일이란
SW 개발 방법, 무계획과 지나치게 많은 개발 사이에 타협을 찾는 방법
애자일 선언
“xx보다 ㅁㅁ을” 그 문장들
https://agilemanifesto.org/
12가지 원칙
- 가치있는 sw를 일찍 지속적으로 전달해서 고객을 만족시키는게 우리의 최우선
- 비록 개발의 후반부일지라도 요구사항 변경을 환영하라
- 작동하는 소프트웨어를 자주 작성하라
- 고객에게 자주 전달해서 확인받아라
- 너무 많은걸 작성해서 전달했다가
- 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 함께 일해야 한다
- 동기 부여하고 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라
- 정보를 전하는 가장 효율 효과적인 방법은 면대면 대화다
- 진척의 주된 척도는 작동하는 소프트웨어
- 애자일 프로세스는 지속 가능한 개발을 장려한다. 일정한 속도를 계속 스폰서, 개발자, 사용자는 유지할 수 있어야 한다.
- 기술적 탁월성, 좋은 설계에 대한 지속적 관심 -> 기민함을 높인다 안 하는 일의 양을 최대한 기술 - 단순성 - 필수다.
- 최고의 아키, 요구사항, 설계는 자기 조직적인 팀에서 창발한다
- 자기 조직적이란게 무슨 말일까
- 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
애자일을 하는 방법
XP와 스크럼의 장점을 혼합한 방법을…
XP
여러가지, 효과 좋은, 프랙티컬한 방법을 극한으로 실천하는 것
예시가 없으니 이해가 안됨
이건 그냥 특정 상황에서 쓰는 극단적일수도 있는 예시일까?
특징
- 5~10 개발자 고객과 함께 한 장소에서 개발한다.
- 점진적 개발, 각 단계마다 산출물의 기능을 덧붙여나감
- 요구사항 명세를 사용자의 스토리 형태로 구체적으로 작성한다.
- 개발자는 코딩 규칙을 준수하고 Pair TDD 개발한다.
- 요구사항, 아키, 디자인은 플젝 중간에 언제든지 생긴다.
- 주, 분기 단위 일을 계획하고, 지난 기간 진행상황을 검토한다.
이터레이션, 스몰 릴리즈.
다섯 가지 가치
커뮤니케이션
문제를 이미 해결법을 알고있는 경우가 많다.
문제 해결법이 당사자에게 전달 안 되는 경우가 만다.
단순성
피드백
용기
문제가 뭔지 안다면 그거에대해 뭐든 해보는 것
자기가 알고 있는것을 오픈하는것
존중
팀원의 기여를 존중하는것
원칙
인간성 경제성 상호 이익 자기 유사성 다른 원칙들
중복 Redundancy 어떤 문제에 중복되지만 여러 해결책을 만들어 놓으면 그중에 하나가 해결책이 될 수 있지
실패
품질 은 양보할 수 없다
잔걸음 → 이터레이션, 스몰 릴리즈
수용된 책임감 (Accepted Responsibility) 책임을 주면 권한도 주고
실천 방법 (프랙티스)
함께 앉기
하나의 팀
informative workspace - JIRA, WIki
열정적인 작업
질답
redacted
redacted
redacted
redacted
스크럼
특징
이론
- 투명도
- 검사
- 자주 검사
- 검사가 너무 잦아서 개발에 방해가 되지않도록
- 적응
가치
- 용기
- 집중력
- 헌신
- 존중
- 개방성
- 자신이나 팀에게 불리하더라도 숨기지 않고 오픈하는것
프로세스
[스크럼 프로세스 그림]
스크림 팀
프로덕트 오너
- 사용자 역할을 대변한다
- 스토리 정의한다
- 개발팀이 수행하는 업무의 가치를 최적화한다
- 백로그 항목을 개발팀이 이해하도록 설명한다
- 릴리즈 타이밍을 관리한다
- 이해관계자의 의사소통을 돕는다
개발팀
- 5-7명
- 전문가
- 팀 안에서 모든 문제를 해결할 수 있어야한다
스크럼 마스터
- 서포터
- 스크럼 팀 모든 사람이 이해하게 해준다 - 목표, 범위, 제품 도메인
- 개발팀에 있는 방해 요소를 제거한다
- 효과적은 제품 백로그 관리를 위한 기술을 습득한다
- 경험적 환경에서 하는 제품 계획을 이해한다
- 프로덕트 오너가 가치를 극대화하기 위해 백로그를 정렬하는지를 확인한다
유저 스토리
- 제품을 통해 고객에게 특정한 가치를 제공하는 방법을 명확하게 표현한다
- As a [type of user], I want [some goal], so that [some reason]
스프린트
- 스프린트 회의에 시간을 제한한다
- 1주 스프린트 - 2시간
- 2주 스프린트 - 4시간
- 1개월 스프린트 - 8시간
- 명확하고 측정 가능한 결과를 사용자 스토리에 추가
- 스토리는 에스티메이션 포인트 1-3
- 3이 넘으면 에픽으로 빼고 에픽에 여러 스토리를 담아준다
- 새로운 스프린트는 이전 스프린트가 종료된 직후에 시작한다
- 스프린트 중 품질 목표는 감소하지 않고, 스프린트 목표를 위태롭게 하는 변경은 하지않는다.
- 스프린트 중 목표가 필요없어진다면 스프린트를 중간에 끝낼 수 있다.
스프린트 계획
- PO가 스프린트 목표와 백로그를 설명한다
- ...
- 개발팀은 작업을 계획한다
- 백로그가 생긴다
스탠드 업 미팅
개발팀 또는 PO를 포함해서만 참석하고 스프린트 기간 동안 매일 진행하고 15분으로 시간제한을 두고 일어서서 진행한다.
다음 세 가지에 대해서만 이야기한다.
스프린트 리뷰
- 이해관계자가 참석한다
- PO는 백로그에서 완료한 항목, 안 완료한 항목을 설명한다
- 개발팀은 기간 동안 잘된 점, 뭐뭐 등에 대해서 논의한다
스프린트 회고
- 개선할 수 있는 기회
- 개선점에 대해서는 액션 아이템을 정하고 어사인까지 한다
제품 백로그
스프린트 백로그
인크리먼트
지라에서 쓸 수 있는 리포팅 차트
번다운 차트
[장애요소가 있는 스프린트의 차트]
[이상적인 번다운 차트]
린
칸반
애자일에 대한 오해
포괄적인 문서를 만들지 않아도 된다
→ 문서는 개발 중에 완성한다
변화에 대응해야 하고 스프린트 목표가 바뀔 수 없다
→ 스프린트 목표를 변화를 반영해서 만들고 스프린트 기간 안에 목표를 바꾸지 않는다
계획한 기능만 잘 작동하면 된다
→ 고객이 사용하는 관점에서 한 스토리가 잘 작동하도록 목표를 세운다
개발 중인 SW 진행상황을 고객에게 통보한다
→ 문서로 보고하는것보다 작동하는 SW를 전달한다; 이유는 피드백을 받아서 요구사항을 수정하기 위함이다
질답
redacted
redacted
redacted
redacted
redacted
redacted
redacted
redacted