- 애자일 선언문의 원칙들
- 애자일의 오해
- 스크럼(Scrum)
- User Story
- Estimation
- XP(eXtreme Programming)
- XP Practice #1 – TDD와 테스트 자동화
- XP Practice #2 – Refactoring, CI
- 애자일 사례 소개
Learn how Acceptance Test Driven Development (ATDD) provides the process for capturing detailed requirements as acceptance criteria and turn them into as test cases before development begins using Behavior Driven Development (BDD). The BDD approach and Gherkin format is the language used to create easy to understand and actionable scenarios that map from the functional level to the components and units. We will discuss the different approaches to TDD including a realistic approach leveraging BDD to a purest standpoint where TDD use the tests to drive the design of the application. Finally understand how the tools in Visual Studio and Team foundation Server to support BDD such as SpecFlow (Cucumber in .NET), Refactoring tools, and Test Cases in MTM.
- 애자일 선언문의 원칙들
- 애자일의 오해
- 스크럼(Scrum)
- User Story
- Estimation
- XP(eXtreme Programming)
- XP Practice #1 – TDD와 테스트 자동화
- XP Practice #2 – Refactoring, CI
- 애자일 사례 소개
Learn how Acceptance Test Driven Development (ATDD) provides the process for capturing detailed requirements as acceptance criteria and turn them into as test cases before development begins using Behavior Driven Development (BDD). The BDD approach and Gherkin format is the language used to create easy to understand and actionable scenarios that map from the functional level to the components and units. We will discuss the different approaches to TDD including a realistic approach leveraging BDD to a purest standpoint where TDD use the tests to drive the design of the application. Finally understand how the tools in Visual Studio and Team foundation Server to support BDD such as SpecFlow (Cucumber in .NET), Refactoring tools, and Test Cases in MTM.
회사 내부 교육(소개)용으로 만든
현재 팀이 일하고 있는 프로세스를 정리한 자료 - 의료 소프트웨어 제품
- Dev & Test Process(V-Model)
1) Review / Planning
2) Test Execution
3) Other types of Testing
4) Release / Operation
회사 내부 교육(소개)용으로 만든
현재 팀이 일하고 있는 프로세스를 정리한 자료 - 의료 소프트웨어 제품
- Dev & Test Process(V-Model)
1) Review / Planning
2) Test Execution
3) Other types of Testing
4) Release / Operation
상업적 이용 및 출처없는 무단전재를 금합니다.
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
애자일의 스크럼, XP에 대한 기본적인 소개와 스크럼 팀 안에서 테스트 역할자로써 사용자 스토리 리뷰, 테스트 설계, 짝 테스트, 테스트 자동화 등에 대한 내용을 사례 기반으로 소개하고 있습니다.
하얀 눈 위에 발자국은 반갑고 친구와 같은 느낌이었던 것 같습니다. 애자일 적용에 첫발을
내딛으려는 팀에게 도움이 되었으면 좋겠네요.
경기원, LG CNS
애자일을 통해 내가 하고 있는 무엇인가를 더 낫게 만들려는 욕심 있는 분들께 추천합니다.
신황규, 삼성SDS
현실을 부정하지 말고 일단 작게 시작하세요.
관찰하고 적응하세요. 특정 방법에 얽매이지 말고 애자일 선언문을 기억하세요. :-D
심우곤, LG전자
어제보다 나은 오늘을 만드는데 도움이 되었으면 좋겠습니다.
이승룡, 삼성SDS
애자일을 적용하려는 팀에 도움이 되었으면 좋겠어요!
채수원, NHN
여러분들이 애자일과 더 친해졌으면 합니다.
황상철, NHN
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 개발에서
이것들이 얼마나
중요한지를…