Upload
kihoon-kim
View
89
Download
4
Embed Size (px)
Citation preview
Agile fundamentals
Agile one day course
Who am i?Name : 김기훈
Company : Samsung SDS. ACT Lab
Role : Developer, Software Architect
Email : [email protected]
Agenda08:00 Introduction, 방법론
09:00 Agile Methodologies & Culture
10:00 Agile Project Approach
11:30 Lunch
13:00 Define the Project
14:00 Estimation
15:00 Engineering Practices
16:00 Communication
Agile이 무엇인지 느끼기
Team 으로 어떻게 일하는지 느끼기
Who are you?...
Programming 경험?
Team으로 일한 경험?
Agile이 뭔지 들어봤나요?
...
Drawing Game
analysts Developers
분석한 내용은 종이에만 작성하세요.
어떤 형식, 어떤 언어로 작성해도 괜찮아요.
단, 그림을 그리면 안되요.
문장이나 단어로만 작성하세요.
analysts 와 developers 는 서로 대화하면 안되요.
Review잘 그려졌나요?
뭐가 문제였나요?
분석한 내용은 종이에만 작성하세요.
어떤 형식, 어떤 언어로 작성해도 괜찮아요.
단, 그림을 그리면 안되요.
문장이나 단어로만 작성하세요.
analysts 와 developers 는 대화를 많이 하세요.
Learning pointIncremental development
Iterative development
Documented analysis results vs. communication with a customer/analyst
Collaboration
Self-organization of the team
Leadership vs. management
Early feedback
Changes are welcome
Time box
Result driven work
Retrospective/Process improvements
방법론이 뭐에요??
Methodology소프트웨어 개발 방법론은
정보시스템을 개발하기 위한 작업활동, 절차, 산출물, 기법 등을 체계적으로 정리한 것
Why???- 개발경험 축적 및 재활용을 통한 개발 생산성 향상- 작업의 표준화/모듈화 - 효과적인 프로젝트 관리- 정형화된 절차와 표준 용어의 제공- ...
waterfall
프로젝트에서 관한 세가지 진실프로젝트 초기에 요구사항을 모두 수집하기는 불가능하다.
수집한 요구사항들이 무엇이든 반드시 변하기 마련이다.
시간이나 비용이 허락하는 것보다 해야 할 일들이 항상 더 많다.
세가지 진실을 받아 들인다는 것은..프로젝트 초기에 요구사항을 모두 수집하기는 불가능하다.-> 수집한 요구사항을 모두다 알지 못하는 상태로 여행을 시작하는 것을 두려워하지 않는다는 것
수집한 요구사항들이 무엇이든 반드시 변하기 마련이다.-> 변화를 두려워하거나 피하려 하지 않는다는 것.
시간이나 비용이 허락하는 것보다 해야 할 일들이 항상 더 많다.
->주어진 시간과 자원보다 해야 할 일이 많더라도 스트레스에 시달리지 않는 다는 것.
Agilemethodologies & Culture
Agile manifestoIndividuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
http://agilemanifesto.org/iso/ko/
scrumPrimarily a project management method● Project planning● Release planning● User Stories● Daily stand-up● Story points● Velocity
Primarily a developer-centric approach○ Test Driven Development (TDD)○ Unit tests○ Pairing○ Continuous Integration (CI)○ Refactoring
Extreme programming (xp)
Lean Software Development
○ Optimize the whole○ Eliminate waste○ Build quality in○ Learn constantly○ Deliver fast○ Engage everybody○ Keep getting better
culture
#practice> discussManifesto for Agile Software Developmenthttp://agilemanifesto.org/iso/ko/
Twelve Principles of Agile Softwarehttp://agilemanifesto.org/iso/ko/principles.html
Agile project approach
Agile project is...● Adaptive● Evolutionary● Collaborative● Just-in-time● Start with a plan● …
Agile project lifecycle
Iteration & improvement
Agile project team
Product owner (customer)Provides vision for the solution
Single point of escalation for prioritization
Iteration manager / scrum master / agile coachFacilitates collaborative activity
Encourages and mentorsCarries water
Removes boulders
Agile team memberBusiness Analyst
UX Analyst
Developer
Tester(QA)
Agile team is..같은 공간에서 일하기
참여하는 고객(on site customer)
자기조직화(self-organizing)
교차기능팀(cross-functional)
책임감과 자율성
Define the project
모두 한 버스에 타는 법목표, 비전, 프로젝트의 현재 상태에 대해 모든 팀원들과 소통하기
Inception deck고객(사용자) 가치 기반의 상품을 만들기 위한 Ideation & Consensus
만들 제품 공감대 형성 : Vision Sharing, Elevator Pitch, Product Box
사용자에 대한 이해 : Persona
사용자 가치 기준 주요 Feature 정의 : Customer Journey Map, Stakeholder Map
Inception deckVision Sharing Elevator Pitch
Inception deckProduct Box Persona
Inception deckCustomer Journey Map
User story deck고객(사용자) 가치 중심의 요구사항 정의
사용자 가치 기준 주요 Feature 정의 : Roles & Goals
Feature 도출 및 우선순위 선정 : Feature Identification, Feature Pyramid
비지니스 흐름 도출 : Business Scenario
화면기반의 업무 흐름 이해 : Low-Fi Prototype
사용자 가치기준 요구사항 식별: User Story(Acceptance Criteria)
User story deckRoles and Goals
User story deckFeature Identification Feature Pyramid
User story deckLow-Fi Prototype User Story
User story 고객에게 가치를 전달할 수 있는 서비스의 기능을 기술한 내용
사용자 스토리는 기술적인 용어가 아닌 비즈니스 언어로 작성
INVEST 원칙에 따라 작성
Independent
Negotiable
Valuable
Estimable
Small
Testable
User story templateRole: As a…Goal: I want…Value: So that...
# StoryAs : 의사로서I want : 내 환자 리스트를 보고 싶다So that : 내 환자를 찾는 시간을 줄이기 위해서
VS
# Story환자 목록을 database에서 조회하여 jqgrid에 출력한다.
Acceptance criteria스토리의 완료 조건
The Context: Given…The Event: When…The Outcomes: Then…#A/CGiven 사용자가 로그인 상태가 아닌 경우When 쇼핑카트에 담기 버튼을 눌렀을 때Then 로그인 화면을 띄워 준다
Definition of Done개발자가 유저스토리를 완료(Done)했다고 말했는데,
Unit Test 코드가 없거나, VCS에 커밋하지 않았다면? QA가 해당 스토리는 테스트가 더 필요하다고 말한다면?
나중에 개발자가 소스코드를 다시 수정했다면?? 성능테스트를 해야되는 상황이라면??
완료(Done)의 의미를 정의할때, 개발자 뿐만아니라 PM, Architect, DA, UX, 보안담당자 등의 의견이 반영되어야 한다.
“거의다했어요!?” Almost Done은 Done 이 아니다!!
애자일 프로젝트에서 스토리는 작다. 그러므로 단순하게 Done / Not Done 으로만 관리 해라.
스토리가 고객에게 보여줄 준비가 되지 않았다면, 그건 Not Done 이다.
https://trello.com/ https://ko.atlassian.com/software/jira
estimation
planning...How much can we do?
How many iterations?
여기서 집까지 가까운가요?한 시간쯤 걸려요.
이 User story 개발하는데 얼마나 걸려요?
# StoryAs : 의사로서I want : 내 환자 리스트를 보고 싶다So that : 내 환자를 찾는 시간을 줄이기 위해서
Agile estimationBA/PM이 스토리에 대해 설명Dev는 해당 스토리에 대해 스토리포인트 산정동시에 자신의 스토리포인트를 던짐토론 및 설득다시 추정.. 모두가 동의 할 때까지
Planning poker Game
스토리의 크기는 다른 스토리에 상대적이다.
# Tip
가장 작아 보이는 스토리를 찾아라
그 스토리를 기준으로 크기를 측정하라
Planning game토론을 통해 여러 전문가의 의견을 모으는데 효과적
자신의 추정치에 대해 설득하며 정확도를 높여 나감
Team velocitythe amount of work that we can complete in an iteration
Team velocity = completed user-stories / iteration
How many iterations?Total Story Points / Team Velocity = Number of iterations
Burn down vs. burn up
Planning poker game
과일을 먹어봅시다주어진 모든 과일을 팀원들과 나눠서 먹으면 됩니다.
10분씩 나눠서 3번을 먹는 다고 가정해 봅시다.
(즉, 3번의 Iteration을 돌아요. 한 Iteration 당 10분)
과일 한 개/알/통(한 송이X)을 얼마만에 먹을 수있는지 추정해 봅시다.
피보나치 수로 포인트를 산정해 주세요.
1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144……
추정한 포인트를 팀간 비교하는게 맞는가?
이터레이션마다 velocity가 큰 차이가난다면 제대로 추정한것이 맞는가?
파보나치수가 의미하는 것이 무엇인가? 큰스토리는 작게 나누자
우리가 할 수 있는 일은 뭐가 있을까?- 사람을 더 투입?- 종료일 연기?- 품질 낮추기?- 일의 양(scope) 줄이기?
예상 종료일실제 종료일
Engineering practices
Primarily a developer-centric approach○ Test Driven Development (TDD)○ Unit tests○ Pairing○ Continuous Integration (CI)○ Refactoring
Extreme programming (xp)
잘못 된 것을 언제 알게 될까??잘못된 설계로 개발했다면?
오류가 있는 코드를 커밋했다면?
내가 고친 코드가 다른 팀에 영향을 준다면?
Tdd - Test Driven development
계산기 모듈 좀 짜주세요!!
let’s TDD
실수로 잘 못 고쳤더라도..
The Three Rules Of Tdd - uncle bob1.You are not allowed to write any production code
unless it is to make a failing unit test pass.
2.You are not allowed to write any more of a unit test
than is sufficient to fail;
and compilation failures are failures.
3.You are not allowed to write any more production code
than is sufficient to pass the one failing unit test.
refactoring소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것
refactoring리팩토링을 장려하는 문화가 필요리팩토링을 위해서 테스트가 기반되어야 됨Collective Code Ownership
Continuous integration
Pair programming품질 향상, 지식 공유, 심리적 안정감
피곤함, 생산성
끊임 없이 대화 하기
서로 신뢰, 존중 하기
communication
Daily stand up- What did you do yesterday?- What are you going to do today?- What obstacles or impediments are
preventing you from making progress?
Daily stand up오직‘돼지’만이 스크럼 스탠드 업 미팅에 참석하는 것이 허용된다.
닭 : 우리 식당 같이 해보지 않을래 ?돼지 : 좋은 생각이야. 그런데 그 식당 이름은 뭐라고 하지 ?닭 : “햄과 달걀” 이라고 부르는 것이 어떨까!돼지 : 글쎄.. 좋은 생각이 아닌 것 같아. 난 희생해야 하는데 넌 단지 관여만 하려고 하잖아!
Showcase각 Iteration이 끝날때마다 잘 작동하는 Software를 갖는 것이 목표
설계나 브레인스토밍을 하는 시간이 아니다.
지난 스토리에 대해 피드백을 얻을 수 있다.
피드백은 새로운 스토리로 작성한다.
Chickens을 위한 자리다.
Iteration planning meeting다음 Iteration에서 스토리를 어떻게 작업할지 계획
개발자들에게 스토리를 설명해준다.
개발자들은 스토리별로 스토리 포인트를 산정한다.
경우에 따라 스토리의 우선순위를 결정한다.
이슈나 장애물이 있는지 파악한다.
retrospective각 Iteration이나 Release가 끝나는 시점에 진행
지난 일들을 되돌아보고 개선할 일들을 생각하는 것
Good / BadKeep / Problem / TryKeep doing / Stop Doing / Start Doing
retrospective
Wrap up
Agile manifestoIndividuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
http://agilemanifesto.org/iso/ko/
애자일 프로젝트로 안내해 줄 지도같은건 없다. 여러분 스스로 여러분의 팀과 프로젝트에 맞는 최고의 방법이 무엇인지 알아내야 한다.
누구를 설득하려고 하지 말자. 다른 사람들에게 그들이 무슨일을 해야 한다고도 말하지 말자. 그 대신, 행동을 보여주자. 다른 사람들이 항상 보고 있지는 않겠지만, 그저 여러분이 해야할 일을 해나가는 것이다.
애자일은 여행의 과정이지 목적지가 아니다.
애자일화 되는 것이 목적이 아니라
훌륭한 제품을 개발해서 고객에게 최상의
서비스를 제공하는 것이 목적이라는 것을
꼭 기억하도록 하자.
실천법에 너무 목매지 말자. 여러분만의 상황과 맥락에 적합하게 적용하기 바란다. 그러다가도 여러분이 과연 애자일을 잘 실천하고 있는지 궁금해진다면 다음의 두 가지 질문을 스스로에게 해보자.
우리는 매주 가치 있는 것을 고객에게 전달는가?
우리는 계속 발전하기 위해 노력하고 있는가?
만약 이 질문에 네라고 대답할 수 있다면,
여러분은 애자일을 하고 있는 것이다.
Thank you.