애자일을 할 생각도 없고 잘 알지도 못합니다. 오히려 애자일이란 말만 들으면 뭔가 무섭고 거리를 두고 싶어집니다. 이런 사람이 여러 해 개발 조직을 이끌면서 문제를 만날 때마다 애자일의 아이디어를 참고해서 고비를 넘고 성과내는 조직으로 조금씩 성장하도록 이끌 수 있었던 이야기를 풀어보려 합니다.
14. SI 프로젝트 성공 사례
모바일 교보문고 구축 프로젝트
● 명시적으로 애자일을 하자고 했던 첫 & 유일한 경험
● 당시 주관사 L사 내부에 애자일을 강조하는 분위기, 지원도 받을 수 있었음
● PM을 비롯해 모두 애자일 경험 전무, 스크럼의 기본 실천법 적용
● 초반만 일하려던 디자인 업체 설득(협박?), 끝까지 참여
● 고객, 이렇게 성공적으로 진행된 프로젝트를 본 적이 없었다는 평가
● XPer에서 사례 공유(참석 안함)
17. 개발 조직의 두가지 함정
alignment
trap
enabled
growth
maintenance
zone
well oiled
효율
사업
밀착도
18. Product Owner(Scrum)
사업 제품 개발
Biz 기획자 제품 개발팀
Biz PO 제품 개발팀
Biz PO 제품 개발팀
기획자
시
장
I
II
III
● 프로덕트 목표를 세우고 명쾌하게 소통
● 프로덕트 백로그 아이템을 생성하고 분명하게 소통
● 프로덕트 백로그 아이템을 우선순위에 따라 정렬
● 프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만듬
20. 팀이 정말 팀인가?
● 상대평가와 줄세우기
● 개인별 업무 목표와 KPI
● 이름만 팀일 뿐, 작업 그룹
● 조직 개편, 개인 단위 소속 이동
● 팀웍 = 좋은 분위기
● 소프트웨어에 적대적인 문화
유용한 소프트웨어를 만드는데 방해가 되는
21. 완전한 팀(Whole Team)
“The Whole Team suggests that a variety of people work together in interlinking ways
to make a project more effective.”
● 다양한 기술 스텍
● 서비스 기획자
● 디자이너
● 테스팅 엔지니어
● 데이터 엔지니어
● 데이터 과학자
● DevOps
+ 다양한 성향
●
공동의 목표
●
협력
●
공동 책임 / 공동 소유
22. 버스 인자(Bus Factor)
● 개인 업무를 팀 공통 업무로 만들기
○ Q: “담당자가 누군가요?” A: “저에게 말하세요"
○ Q: “담당자를 알아야 평가하지않나?” A: “우리 모두가 같이 합니다.”
● 핵심 개발자 없이 서비스 안정화
● 업무 교대
● 여러 업무를 여러명이 담당
● 코드 리뷰와 짝코딩
● 문서화
● 협업 체계 지속적 강화
23. 목표 다지기
형식적인 일일 스크럼 회의, 회의 목표 환기
팀 공동의 목표가 잘 진행되는지, 위험은 없는지 같이 점검하는 시간
야크 쉐이빙 방지 & 도움 요청
26. 실시간 O2O 스타트업의 특징
● 극심한 경쟁
● 예측할 수 없는 사업 방향 (“Plans are useless, but planning is essential” 아이젠 하워 나쁜놈)
● 아무도 가보지 않은 길 (생각하고 다르네? 이 산이 아닌가벼)
● 상충되는 사업 가치를 모두 추구
● 변경의 여파가 실 세계에 그대로 반영
27. 오늘 하던 일을 못하게 되어도...
● incremental < iterative < evolutionary
● 매번 의미 있는 가치를 고객에게 전달하자
● 어느날 우선순위가 바뀌어 지금하는 일이 중단되어도 버려지는 작업을 최소화하자
● 일을 최소한의 의미있는 단위 만드는 연습
● 유저스토리 매핑
28. 일이 일을 만들게 하지 말자
● 만트라
● 일을 하면 할 수록 그 다음 일이 눈에 보이는 법
● 기획은 어느덧 태산, 개발은 금칠
● 딱 필요한 만큼만 하기, 최대한 일 덜하기
30. Agile에 관심이 없는 이유
● 애자일 커뮤니티가 소프트웨어 개발에서 멀어짐 (또는 애자일의 타 분야 응용)
● 개발자의 대상화 - 스크럼 중심
● 신화가 되는 애자일
● 만병통치약? 무슨 말을 하든 "애자일하자!"
● 버즈워드, 비자발적 강요, 형식주의 - 안 좋은 경험의 확산
34. 고통 주도 개발
(Pain Driven Development)
vs
원칙 주도 개발
(Principle Driven Development)
35. 트라우마와 애자일
Agile is the ability to create and respond
to change. It is a way of dealing with, and
ultimately succeeding in, an uncertain
and turbulent environment.
애자일이란?
애자일은 변화를 만들고 그에 대응하는 능력이다. 애자일은
불확실성과 혼란스러운 환경에 대처하고 궁극적으로 성공하는
길이다.
36. 요즘 애자일
“(Product) outcome is measured by whether the customers
and users see you try and use it, and keep using it,”
- Jeff Patton
37. 애자일 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은
방법들을 찾아가고 있다.