5. Better Software ?
what Working, User/Client Happy, No Bug, …. and Awesome
why Client happy, Boss happy, Wife happy…. and I’m Happy
how Good people, Best infra, Best know-how… and California
Another How Agile
7. 1 무작정 따라하기
오류, 실패, 그리고 교훈
애자일
적용 2 Adaptive Practice
적용 pratice
이야기
3 Agile Worth Spreading
스며들기 시작하다
8. 1
애자일 Practice
무작정 따라하기
“머리 길고 도사 같이 생긴 아저씨 와서 인갂적이라고
하니 좋아 보이던데…”
“애자일로 성공을 많이 한다던데…우리도 한번 해보자! “
9. First Try – 5 years ago
애자일? 그게 뭐야? 한 문장으로 요약해서 말해봐
사용자들의 요구사항이 점점 복잡해지고, 그 변화가
매우 빈번하게, 그리고 빠른 속도로 일어나면서…
야, 그게 삼성에서 되냐?
그건 미국에서나 가능한 이야기구…!
그러니까 그걸 왜 하냐구?!
노키아에서는 product line 한다는데?!
11. 애자일 Practice 무따기 오류(1)
“Practice만 잘 따라 하면 된다.”
사례) TDD 무따기
- Device/Board Level 개발
- Embedded C
- 중규모 크기, 복잡도가 높지 안은 과제
- 소규모 개발자
- Architecture 및 플랫폼 작업 병행
“TDD is a design paradigm and as such is not tied to any
specific programming paradigm.” – by John Doe @ Microsoft
12. 애자일 Practice 무따기 오류(1)
■ Error & Fail
“ NO how “
누구도 TDD를 정확히 할 줄 아는 사람이 없었음
TDD 중도 포기
He said, “나도 솔직히 자바나 c#으로 개발
하면 TDD 하겠어요…”
13. 애자일 Practice 무따기 오류(1)
■ Lesson Learned
1. 모르고 덤비지 말자
- 애자일 코치는 정말 많이 앉아야 한다
2. Context를 파악하자
- 해당 프로젝트의 앞뒤 context와 주변 상황을 먼저 파악하라
3. 먼저 인정하고, 점짂적으로 개선하자
- 개발팀 고유의 문화와 방식을 인정하자 그리고 점진적으로 개선하자
점.짂.적.
14. 애자일 Practice 무따기 오류(2)
“데모를 사용하여 자주 피드백을 받아라.”
사례) 고객 데모 무따기
- Application 개발
- UI/UX가 중요시된 과제
- 중규모 크기, 복잡도가 높은 과제
- 여러 협력 업체 참여
15. 애자일 Practice 무따기 오류(2)
■ Error & Fail
“과유불급(過猶不及)“
너무 잦은 데모로 개발자의 심적 부담을 증가시켰고,
오히려 code qualtiy에 악영향을 주었음
개발자 저항감 극대화
“피드백을 너무너무너무 자주 받는다”
16. 애자일 Practice 무따기 오류(2)
■ Lesson Learned
1. 젂략이 필요하다
- 누구에게 어떻게 데모를 할건지에 대한 젂략 필요
- 데모는 stakeholder와 consensus를 이루는 것이 제일 중요
2. 데모도 Milestone이 필요하다
- 젂체적인 줄기 필요
3. Quality가 먼저다
17. 애자일 Practice 무따기 오류(3)
“Burndown Chart를 통해
팀의 짂행률 및 작업속도를 측정한다”
사례) Burndown & 백로그 무따기
- Embedded 개발
- 소규모 개발자
- 개발자들이 여러과제를 동시에 수행
18. 애자일 Practice 무따기 오류(3)
■ Error & Fail
“대략난감“
갑자기 처리해야할 중요한 일이 매일 발생하여,
Planning과 추정이 하나도 맞질 안았음
개발자 저항감 극대화
“중갂에 더 급한 일이 들어오는데
나보고 어쩌라구…”
19. 애자일 Practice 무따기 오류(3)
■ Lesson Learned
1. Practice의 목적은 무엇인가?
- 무작정 burndown을 그리는 것은 오히려 부담감만 가중
- 개발자의 Load Blance를 유지하는데 focus
2. 소통이 먼저다
- 작업속도가 중요한 것이 아니라, 왜 그런가가 더 중요
3. Flexible
20. 무따기 Risk
1 개발자 실망
무작정 수행해서 결과가 앆 좋으면
오히려 개발자의 실망과 저항만을 불러온다
2 선입견 형성
“방법론이 다 그렇지…”
3 향후 과제 도입 어려움
“나 그거 해봤는데, 별로 던데?”
22. 2
애자일
Adaptive Practices
“순수하게 해당 Practice를 적용해 보는 것이 의미가 있
겠지만, Project에 맞게 적용해보는 것도 어떨까요?”
23. Adaptive Practices – 회고
이렇게 해보니 좋았어요
- 다양한 기법 및 게임등을 사용
- 회고의 중요성을 끊임없이 강조
- 좋고 나쁜것을 이야기 하고 끝나는 것이 아니라,
정말 개선되는 것을 시각적으로 보여줌 (개선 chart등)
- 회고 시간을 이용하여, 서로의 칭찬 유도(예. Thanks to…)
이렇게 해보니 별로예요
- 과제기간 내내 Good,Bad 만 이야기
- 개선사항 check 앆함
- 빨리 간단히 끝냄
24. Adaptive Practices – Refactoring
이렇게 해보니 좋았어요
- “Clean Code” 열망 젂파
- 매 sprint마다 의무적으로 refactoring 수행(Demo후 반드시)
- Duplicate, 복잡도 개선, Coupling 개선등 주요 수치 선정
- “No Refactoring, No commit”
이렇게 해보니 별로예요
- Refactoring과 Unit Test를 deal 둘 다 앆하게 됨
- 샘플 없이 말로만 함
- “No Refactoring, No commit” commit을 앆함
25. Adaptive Practices – Planning
이렇게 해보니 좋았어요
- Project Objective 및 완료조건 명확히 설정 및 공유
- Demo 젂략/순서등 반드시 고려
- Project 초반은 길게, 후반은 Sprint 간격을 짧게 잡음
- 릴리즈 계획은 반드시 Scope과 방향을 정해줌
이렇게 해보니 별로예요
- 추정을 상급자 혼자서 마음대로 정함
- 보고용 계획과 내부용 계획이 따로 존잧
26. Adaptive Practices – Continuous Integration
이렇게 해보니 좋았어요
- CI는 정말 enabler 역할을 함(김창준님 인용)
- SCM과 Test Framework와는 반드시 연계
- 가능하면 binary output과도 연계
이렇게 해보니 별로예요
- 정말 빌드만 함
- SCM과 연동을 앆함
- 공유앆함 결과 Report 발송 앆함
27. Adaptive Practices – TDD
이렇게 해보니 좋았어요
- TDD를 적용하기 쉬운 부분을 target으로 시작하여 가치를 경험
- “고품질 Not 쾌속(?)개발”로 꼬싞다
- Test Coverage 목표를 현실적 잡는다
- 어차피 Unit Test 해야하는데, 이왕할거 TDD로 수행하자고 유도
이렇게 해보니 별로예요
- 동영상 보고, 당장 따라함
- 개발속도가 증가한다고 이야기
- Test Coverage 100% 달성 목표
28. Adaptive Practices – Pair Programming
이렇게 해보니 좋았어요
- 싞규 기술은 pair programming을 통해 빠르게 기술 습득 가능
- 선배/후배 개발자간 교육 및 know-how 젂수
- T/F나 새로 구성된 팀 스타일, consensus
이렇게 해보니 별로예요
- 일단 해본다
- 과제시작부터 완료때까지 Pair Programming을 한다
- 서로 pair를 선택하게 한다 “짝 프로그래밍”은 “짝”이 아니다
29. Adaptive Practices – Daily Meeting
이렇게 해보니 좋았어요
- PM이나 최고참이 없어도 무조건 진행
- 앇으면 끝이다. 반드시 서서 한다
- 간결하게 말하는 것을 계속 주지 시킴
- 무엇을 했나 보다, 무엇이 이슈인지에 더 focus 둠
이렇게 해보니 별로예요
- 가끔씩 시간을 지키지 안음
- 업무 보고도 살짝 곁들인다
30. “땅볼로 패스가 와도 헤딩한다?”
상황에 맞게 Practice를
응용하는 것도 중요하다
44. 애자일의 Core Value는
- 변화를 포용하려는 노력
- 상호 협력 하는 자세
- 참여를 통한 발젂
- 그리고, 실천을 통한 개선
가 아닐까요?
45. 애자일 Practice는
- Core Value를 달성하는 방법
- S/W를 잘 만들기 위한 행동
- 그리고, 역시 실천을 통한 개선
46. 우리의 궁극적인 Core Value는
Better Software
그리고, 이것을 도와주는 것
애자일 = Value Driven
47. They said,
애자일… 처음 할때는 별로 였는데, 다시 해보니까 뭔지
는 모르겠지만 괜찮은 것 같아요
데모때문에 스트레스를 좀 받기는 하는데, 점점 줄기
가 명확해지니까 더 좋은 것 같은데요.
Daily meeting을 하면서 서로 이해하는데
많은 도움이 됩니다.
회고를 하면서, 점점 개선 되어지는 모습을 보는 것은
정말 놀라운 경험이 었습니다.
솔직히 “이렇게도 할 수 있구나” 라고 놀랐어요…
48. 그리고 깨닫기 시작했습니다
- 변화를 포용하려는 노력
- 상호 협력
- 참여를 통한 발젂
- 소통, 그리고 동작하는 S/W
S/W 개발에서
이것들이 얼마나
중요한지를…