1. 애자일
안 한 이야기

2. 오늘의 이야기
삶의 여러 국면에서 애자일과 만나 영향을 받은 일에 대해

3. 저는...
개발자 출신의 조직 리더 (=사람 관리 못한, 공감 능력 바닥, 일 중심)
영세기업 직원
순수 개발자
영세기업 대표
경영 & 개발 리드
2000 ~
1990~ 2010 ~
관리 비중
기술 비중
큰기업 중간 관리자
개발 조직 관리자

4. 트라우마(?)
제록스 PARC 이야기 HBR 기고문

5. 트라우마(?)
내가 하는 소프트웨어 개발은 쓸모가 있는가?
(내 삶은 의미 있는가?)

6. 애자일과 첫만남

7. 당시 고민..
“너희를 위한 방법론은 없어”

8. 버즈 워드들
TDD
애자일
지속적 통합
빌드 성공 박수
일일 스텐드업 미팅
짝코딩
익스트림 프로그래밍
실용주의 프로그래머
소프트웨어 장인정신
단위 테스트
리팩터링
요구사항 변경을
환영하라고?
난 돈만 받고 도망할 건데?
고객도 재구축을 더 좋아해

9. OpenUP
경량 RUP, “테일러링 된 애자일 버전”이라고 주장
망했어요

10. 첫 영향

11. 객체지향의 재발견
두 번의 개발자로서 자존심 상하는 큰 실패
용기 단방향설계

12. 객체지향의 재발견
설계 활동으로서의 코딩, 리팩터링, 창발적 설계
개발자 테스트(=단위 테스트)
진화하는 아키텍처 (스프링 프레임워크)
짝코딩, TDD 등 연습 요구사항 변경을
환영할 정도로 용기를
가질 수 있도록

13. 애자일 성공 사례

14. SI 프로젝트 성공 사례
모바일 교보문고 구축 프로젝트
● 명시적으로 애자일을 하자고 했던 첫 & 유일한 경험
● 당시 주관사 L사 내부에 애자일을 강조하는 분위기, 지원도 받을 수 있었음
● PM을 비롯해 모두 애자일 경험 전무, 스크럼의 기본 실천법 적용
● 초반만 일하려던 디자인 업체 설득(협박?), 끝까지 참여
● 고객, 이렇게 성공적으로 진행된 프로젝트를 본 적이 없었다는 평가
● XPer에서 사례 공유(참석 안함)

15. 진짜 성공 이유
현장 상주 고객
(On-Site Customer)

16. PARC의 실패 이유?
사업 기술

17. 개발 조직의 두가지 함정
alignment
trap
enabled
growth
maintenance
zone
well oiled
효율
사업
밀착도

18. Product Owner(Scrum)
사업 제품 개발
Biz 기획자 제품 개발팀
Biz PO 제품 개발팀
Biz PO 제품 개발팀
기획자
시
장
I
II
III
● 프로덕트 목표를 세우고 명쾌하게 소통
● 프로덕트 백로그 아이템을 생성하고 분명하게 소통
● 프로덕트 백로그 아이템을 우선순위에 따라 정렬
● 프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만듬

19. 큰기업

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. 목표 다지기
형식적인 일일 스크럼 회의, 회의 목표 환기
팀 공동의 목표가 잘 진행되는지, 위험은 없는지 같이 점검하는 시간
야크 쉐이빙 방지 & 도움 요청

24. 0
자율적 팀
목적은 알려주고
해법은 같이 논의하고
구체화 방법은 알아서
Why
How
What

25. O2O 스타트업

26. 실시간 O2O 스타트업의 특징
● 극심한 경쟁
● 예측할 수 없는 사업 방향 (“Plans are useless, but planning is essential” 아이젠 하워 나쁜놈)
● 아무도 가보지 않은 길 (생각하고 다르네? 이 산이 아닌가벼)
● 상충되는 사업 가치를 모두 추구
● 변경의 여파가 실 세계에 그대로 반영

27. 오늘 하던 일을 못하게 되어도...
● incremental < iterative < evolutionary
● 매번 의미 있는 가치를 고객에게 전달하자
● 어느날 우선순위가 바뀌어 지금하는 일이 중단되어도 버려지는 작업을 최소화하자
● 일을 최소한의 의미있는 단위 만드는 연습
● 유저스토리 매핑

28. 일이 일을 만들게 하지 말자
● 만트라
● 일을 하면 할 수록 그 다음 일이 눈에 보이는 법
● 기획은 어느덧 태산, 개발은 금칠
● 딱 필요한 만큼만 하기, 최대한 일 덜하기

29. 애자일 안 한 이야기

30. Agile에 관심이 없는 이유
● 애자일 커뮤니티가 소프트웨어 개발에서 멀어짐 (또는 애자일의 타 분야 응용)
● 개발자의 대상화 - 스크럼 중심
● 신화가 되는 애자일
● 만병통치약? 무슨 말을 하든 "애자일하자!"
● 버즈워드, 비자발적 강요, 형식주의 - 안 좋은 경험의 확산

31. 그건 Agile이 아니야!
● 애자일이 목표가 됨
● 껍데기만 남는 애자일 - 형식주의
● 무엇이 애자일인지 끝없이 논쟁

32. 저의 첫 애자일

33. 네, Agile 아닙니다.agile 입니다.
Agile vs 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. 애자일 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은
방법들을 찾아가고 있다.

38. 애자일과 저의 삶

39. 生卽苦
삶은 질고다