Transcript Agile Programming, EXTREME PROGRAMMING, & SCRUM

Combacsa’s SPARCS Web Seminar
SOFTWARE DEVELOPMENT #1:
SE, AGILE, XP
AIMs…
 Let you know these terminologies
 Software Engineering
 Agile Software Development
 eXtreme Programming
 Let you think about
 How to run a programming team
 How to cooperate effectively
Software Engineering
Agile Software Development
eXtreme Programming
Software Engineering (SE)
 is an area of Computer Science dedicated to
 Designing,
 Implementing,
 and Modifying software
 so that it is of
 Higher quality,
 More affordable
 Maintainable,
 and Faster to build.
Waterfall Model (Short)
 Fix what customer want
prior to the beginning of the development
 Draw UML Diagram
 to fix the SPECIFICATION of the program
 to share interface between programmers
 Then do everything according to UML
Waterfall Model
Requirements
Design
Implementation
Verification
Maintenance
“We need a program which
manages Shipping business.”
“Each shipping has origin &
destination site & order.”
“Order consists of items, which
is described by one-line
description. Weight and Tax
should also be needed.”
“To represent site, address will
be used.”
“OK. Let’s draw UML diagram.”
“Let’s decide the deadline.”
“Let’s write down source code.”
“After that, clients will be happy.”
Typical Process
Clients (Customer)
Developer
 Requirements
 UML Diagram  SPEC
 Functionality
 Implementation
 User Interface
Clients (Customer)
Developer
 Watching the result
 Get money
 Happy
 Quit
Sounds very good in theory.
But what really happen is …
Typical Process Done
Clients (Customer)
Developer
 Requirements
 UML Diagram  SPEC
 Which is not organized
 Made by interpretations
done by Developers
Clients (Customer)
Developer
 Watching the result
 Can’t leave the office
 Which is different from what
they expected
 Painful, stressful life
Hey, Waterfall Method is good!
 Microsoft’s success proves it
 They always begin with UML
 The only thing we need is
definite expectation
 Without good preparation, nothing comes out
 So
 Give much more efforts on planning!
 It is your fault, not Waterfall Method’s fault!
No, Waterfall Method is bad!
 We are all human being
 Preparation for everything? It’s impossible!
 Even sometimes clients’ requirements vary!
 Waterfall Method can’t handle CHANGE
 So, it is definitely Waterfall Method’s fault.
SUMMARY
Software Engineering, aka SE, is an area of CS,
teaches “How a team create program”.
Waterfall Method, the typical SE strategy, says
we must prepare for every possible cases,
such as drawing UML diagram correctly.
If any small change happens,
then team will be very unhappy.
Software Engineering
Agile Software Development
eXtreme Programming
Agile in dictionary
Before censoring
 Adjective
 Easy of movement
 Quickness
 Lightness
 in Korean
 기민한
 날랜
12 hours later
Manifesto for Agile Software Development
We are uncovering better ways of developing software
by doing it and helping others do it.
Through this work we have come to value:
Individuals and Interactions
Processes and Tools
Working Software OVER Comprehensive Documentation
Customer Collaboration
Contract Negotiation
Responding to change
Following a plan
That is,
while there is value in the items on the right,
we value the items on the left more.
http://agilemanifesto.org/
Let’s compare those eight values.
Processes and Tools
 Processes
 Predefined rules to strictly obey
 Eg) Boss is the highest authority. No claim!
 Vertical structure is preferred
 Tools
 Members must use predefined tools only
 Stabilized team organization
Individuals and Interactions
 Individuals
 Who create the program?
 Processes? No! Individuals!
 We must respect each members, not only processes!
 Interactions
 Without the interaction between individuals,
nothing comes out
 Even if we had good enough tools.
Comprehensive Documentation
 Blueprint
 Without blueprint, we can’t build a building
 It must be comprehensive enough to be understood
 Must contain everything about the building
 Prior to the actual construction begin
 Without proper documentation,
 No one could write down any single line.
 Creating a software == Building a house
Working Software
 Who need such blueprint?
 Our customer?
 No, they need “Working” software.
 We, programmer?
 In fact, we know by nature that some parts could be
implemented without writing down details about it.
 Still, we partially need it to start writing.
 But we don’t need to invest whole lifetime on
documentation. It is necessary only to get “Working
Software”.
 Creating software != Building a house
Contract Negotiation
 Contract
 Between our customer and negotiator
 What programmer do is writing down a program,
not participating contract negotiation
 It’s their job, not our job
 Things should be fixed
 Everything according to the contraction
 If change is needed, further negotiation is only way
Customer Collaboration
 Does our product manager properly
understood everything customer want?
 It is impossible – since s/he is not mind-reader!
 Even the contract could miss something
extremely important …
 Is programmer a machine which can’t
understand natural language?
 No! We are human. We can have a conversation
with customer directly, if we both want!
Following a plan
 Schedule can’t be changed
 One must prepare, expect hard to let everything
done by its scheduled due-date
 Both schedule planning and obeying schedule
must be done at the same time
 We are adult with responsibility
 We are responsible to obey what we said
Responding to change
 Things are change
 Newer technology suddenly strikes the world
 Maybe we should adopt it right now, even though it
was not planned to!
 Customer might change their mind
 Applying it makes customer happier, isn’t it?
 Team member could suffer some illness
 We are imperfect human being
 Anyone can’t prepare everything
 So we should have a way to encounter changes!
Agile Methodologies
 eXtreme Programming
 Scrum (Ken Schwaber / Jeff Sutherland)
 Test Driven Development
 Crystal (Alistair Cockburn)
 DSDM
 Lean Software Development
 Feature Driven Development
 XBreed
 Adaptive Software Development
There is no magic wand
 Different team needs different style
 Sometimes it is not possible to accommodate all
known agile methodologies at the same time
 We can’t always apply agile methodologies
 Eg) Military-related projects
 Any small changes on requirements are not allowed
 Strict command-obey relationship is necessary
SUMMARY
Agile Software Development is a set of different
methodologies on programming, concentrating
on facing the changes efficiently and producing
usable software quickly.
It values Individuals and Interaction, Working
software, Customer collaboration, and
Responding to change.
For some cases, Agile software development
might fail to be applied.
Software Engineering
Agile Software Development
eXtreme Programming
eXtreme Programming
 Agile Programming Family (of course!)
 Set of
 가치 Values
 원칙 Principles
 실천 and Practice
 Let developers to confidently respond to
changing customer requirements
Simple XP Diagram
Values
Synthetic and Abstract things agreed upon team members
Principle
Bridge between Values and Practice
Practice
How to actually develop software
 Software successfully created by our team! Yay 
Values
Communication
Simplicity
Feedback
Courage
Respect
Principle
Humanity
Improvement
Economicaleffectiveness
Benefit
Self-Similarity
Reflection
Flow
Opportunity
Failure
Quality
Practice
Pair Programming
Short Release
ContinuousIntegration
Sit together
Standing Meeting
Gradual Design
Values in XP
 Value (가치)?
 팀이 중요하다고 생각하는 것 (항상 지켜야)
 상호 보완적 (동시에 지켜야)
 Values in XP
 대화 Communication
 단순 Simplicity
 피드백 Feedback
 용기 Courage
 존중 Respect
Communication : 대화
 Interaction between two or more individual
 What it means when somebody in a team not
talking to somebody else about something?
 뭔가 문제가 있는데 말하기 싫다는 것
 이렇게 숨기다가 문제는 오히려 커진다!
 대화가 필요해!
 서로 자신만의 추측으로 일을 진행하지 않도록!
Simplicity : 단순
 Why not so simple?
 진짜로 복잡하니까?
 or, 더 쉬운 방법을 찾지 않아서?
 Simple is the best!
 Do the simplest thing that could possibly work!
 일단 작동되면, 그거로 충분하잖아?
 다른 가치들이 Simplicity 의 단점을 보완함!
Feedback : 피드백
 Human being is not always perfect!
 일단 불완전하지만 작업을 진행하고, 피드백을
통해 점진적으로 완벽을 향해 다가가면 된다
 피드백의 예
 내가 짠 소스코드에 대해 다른 사람들의 의견은?
 우리가 만든 프로그램의 현재에 대한 고객 생각?
 Concrete Feedback gives more opportunity
to steer our effort
Courage : 용기
 팀 내에서 발생하는 대표적인 두려움
 이렇게 코드를 짰다가 문제가 생기지 않을까?
 이런 질문을 하면 멍청하다고 혼나지 않을까?
 Don’t be afraid!
 누군가 Feedback 을 해 주면 괜찮으니까!
 소통하지 않아 발생하는 문제를 줄일 수 있잖아!
Respect : 존중
 Don’t have to blame other’s fault.
 실수할 수도 있는 거다
 사정을 이해하고 용기를 북돋아주자
 솔직하게 모른다고 말할 수 있도록 도와주자
 우리 모두는 동등한 인격체
 후배라고, 선배라고 업신여길 필요가 없다
XP 의 가치만이 진리는 아니다
 국가 기밀과 관련된 프로그램을 개발하는
팀에서는 무엇이 중요한가?
 안전성
 보안
 예측가능성
 위계질서
 결국 XP 는 XP 의 가치들을 중요하게 생각할
수 있을 때에 적용해야만 효과를 볼 수 있다!
XP 의 가치들을 따르는 예
 내가 2주 전에 짠 코드에서 버그를 발견한다
 주저하지 않고 팀원들에게 이를 알린다
 팀원들은 나를 존중해 주니까 내 실책을 비난하는
것만으로 시간을 낭비하지 않는다
 내가 지금 대화에 응해야 팀의 일이 잘 진행된다
 그러니 내 실수를 알릴 용기가 나에게는 있다
 만약 XP 의 가치들이 지켜지는 팀이 아니라면,
 팀원들의 비난이 두려운 나는 존중받지 못할 게 뻔
한 실수를 감추기 위해 대화하지 않고 숨겠지.
XP 의 가치들을 따르는 예
 고객의 요구조건이 난해하다
 고객에게 우리가 이해하지 못했음을 알린다
 우리의 이해도에 대한 피드백을 고객에게 주고
 고객은 좀더 단순하게 요구조건을 설명해 준다
 만약 XP 의 가치들이 지켜지는 팀이 아니라면,
 우리는 고객의 피드백을 물어보지도 않을 것이고
고객들 또한 더 단순한 설명을 할 필요를 모르겠지
Simple XP Diagram
Values
Synthetic and Abstract things agreed upon team members
Principle
Bridge between Values and Practice
Practice
How to actually develop software
 Software successfully created by our team! Yay 
Values
Communication
Simplicity
Feedback
Courage
Respect
Principle
Humanity
Improvement
Economicaleffectiveness
Benefit
Diversity
Reflection
Opportunity
Failure
Quality
…
Practice
Pair Programming
Short Release
ContinuousIntegration
Sit together
Standing Meeting
Gradual Design
Principle
 XP 에서 원칙의 역할
 XP의 가치들을 지킬 수 있도록 하는 지침
 솔까말 “가치” 들은 제법 추상적이어서
 예제를 들지 않고서는 설명하기 힘들고
 예제로 설명한다고 하더라도 예제가 상징하는 한
계 안에 갇혀버릴 수 있다
 가치 + 원칙의 실현이 “실천” 이다
XP 의 원칙들 (I)
 Humanity (인간성)
 프로그램은 인간이 개발한다는 걸 잊지 말자
 Improvement (개선)
 프로그램 개발의 진행은 결국 프로그램을 계속
개선시키는 것임을 잊지 말자
 Economical Effectiveness (경제성)
 꼭 필요한 일에만 노력할 수 있도록 하자
XP 의 원칙들 (II)
 Benefit (상호 이익)
 자신에게는 물론,
다른 팀원들에게도 도움이 되는 일을 하자
 Diversity (다양성)
 여러 가지 가능성이 있음을 인정하고
그 가운데 더 나은 선택을 할 수 있도록 노력하자
 Reflection (반성)
 왜 성공했는지, 왜 실패했는지 자주 분석하자
XP 의 원칙들 (III)
 Opportunity (기회)
 문제가 발생하면, 미래에 발생할 뻔했던 것을
지금 고칠 기회를 잡은 것이라 생각하자
 Failure (실패)
 아무것도 할 수 없을 것처럼 보일 때, 차라리 실패
할 것을 알더라도 저질러서 뭔가 배울 수 있다
 Quality (품질)
 어떤 경우에도 우수한 결과물을 개발하도록 하자
그 밖의 XP 의 원칙들
 받아들인 책임 : Accepted Responsibility
 아기 발걸음
 잉여 : Slack
 흐름 : Flow
 자가유사성 : Self-Similarity
 사실 나도 뭐가 더 중요한지 잘 모르겠음
 어쨌든 … 가치를 지키기 위한 것이 원칙임.
Simple XP Diagram (Recall!)
Values
Synthetic and Abstract things agreed upon team members
Principle
Bridge between Values and Practice
Practice
How to actually develop software
 Software successfully created by our team! Yay 
Values
Communication
Simplicity
Feedback
Courage
Respect
Principle
Humanity
Improvement
Economicaleffectiveness
Benefit
Diversity
Reflection
Opportunity
Failure
Quality
…
Practice
Pair Programming
Short Release
ContinuousIntegration
Sit together
Standing Meeting
Gradual Design
Practice (실천)
 eXtreme Programming 이 eXtreme 인 이유?
 가치와 원칙들을 지키기 위해
eXtreme 한 실천방법들을 제시하기 때문!
 따라서,
 가치들에 대해서는 반드시 완벽하게 동의하고
 원칙들 또한 대체로 동의한 이후에야
 실천방법들을 사용할 수 있음을 주의하자.
Practice (실천)
 Pair Programming
 Short Release
 Continuous Integration
 Automated Testing
 Standing Meeting
 Gradual Design
Pair Programming
 기본적인 방법
 두 사람이 한 조가 되어 한 대의 컴퓨터를 갖고
프로그래밍한다.
 예1
 한 사람이 주도적인 프로그래밍을 하고,
다른 한 사람은 오타 검사나 다음 내용을 말한다
 예2
 한 사람이 계획을 세워 계속 말로 전달하고
다른 한 사람은 그 계획대로 코딩을 한다
Pair Programming pro/con
 Pros
 실수를 극단적으로 줄일 수 있다
 한 사람의 눈보다는 두 사람의 눈이 오타를 줄인다
 해당 코드의 의미를 아는 사람이 많아진다
 Pair Programming 을 하지 않으면 당장은 한명뿐.
 Cons
 뛰어난 실력자들에게는 오히려 생산성을 저하
 각자 다른 부분을 작업하는 쪽이 효율적이다
Short Release
 Release란?
 작동되는 프로그램을 내놓는 것을 뜻함
 고객에게 “작동되는 프로그램”을 전달함
 Short Release?
 고객에게, “작동되는 프로그램”을 자주 전달
 그래서 고객이 더 많은 Feedback 을 주게 하고
 우리가 놓치는 버그들을 고객들이 찾아주게 하자
Gradual Design
 방법
 프로그램의 전체적인 구조를 처음부터 전부 그
리고 시작하는 게 아니라, 이번 작업기간동안 작
업할 부분의 디자인만 우선 해보고, 시간이 흐르
면서 점점 더 세부적인 부분의 디자인이 되도록
일을 진행한다
 효과 (Short Release 와 병행시)
 고객의 요구조건이 바뀌는 것은 결국 우리가 진
행해온 “점진적인 설계 개선” 과 다르지 않게 됨.
Continuous Integration
 Integration 이 필요한 때
 각자가 서로 다른 부분을 개발할 때
 서로가 작업한 부분을 하나로 합친다
 서로가 어떻게 코딩한 것인지 잘 모를 때
 서로의 작업내용을 서로에게 이해시킨다
 Continuous Integration?
 최대한 자주, 프로젝트가 분리되어 진행되고 있
는 상황을 통합 진행으로 만든다
Automated Testing
 Testing?
 지금 내가 작성한 소스 코드가 정상적으로 작동
하는지 검사하는 일
 Automated Testing?
 각자가 작성한 소스 코드가 정상적으로 작동하
는지, 혹시 프로젝트의 다른 부분에 영향을 주지
않았는지를 “자동화된 테스트” 가 검증하도록
하자
 Testing 코드가 제대로 준비되면 걱정할 것이 없다
Standup Meeting
 방법
 회의를 일어선 채로 진행한다
 효과
 다들 신체가 피곤한 걸 알기 때문에,
꼭 해야 할 말만 조리있게 간추려서 하게 된다
 팀원들 모두 적절한 수준의 긴장을 유지하게 됨
 말했잖아 … eXtreme 하다니까 …
Sit Together
 방법
 팀원들이 서로 가까운 자리에 앉게 한다
 효과
 다른 팀원들에게 뭔가 물어볼 것이 있을 때 매우
빠르게 물어볼 수 있게 된다
 대안
 최소한 Messenger 같은 것으로라도 연결되게 …
Collective Code Ownership
 방법
 각각의 개발자가 소스 코드의 특정 부분에 대해
자신만의 코드라고 생각하지 않도록 한다
 그 대신, 소스 코드 전체가 팀 전체의 공동 소유
라고 생각하고, 누구든지 작업할 수 있도록 이해
하기 쉽게 작성한다
 효과
 점점 더 공동작업이 쉬워지고
 팀원이 교체되어도 타격이 없다
Ten-minute build
 방법
 프로그램의 빌드에 걸리는 시간을 어떻게든
10분 이내로 줄인다
 효과
 프로그램을 거리낌없이 빌드하게 되어 혹시나
문제점이 생기지는 않았는지 테스트하는 것을
꺼리지 않게 된다
Viral Working Time
 방법
 각 개발자는 활기차게 일할 수 있는 시간동안에
만 일하고, 그렇지 않은 시간은 강제로라도 쉰다
 효과
 피곤함을 억지로 참으면서 효율 없는 코딩과 씨
름하는 괴로움으로부터 팀원들을 구해준다
 극단적인 팀의 작업효율을 불러온다
그 밖의 XP 실천방법들
 Informative Workspace
 Whole Team Approach
 Real customer collaboration
 Small size team
 Team member continuity
 Real reason diagonosis
 Single Repository
 Negotiated Scope Contract
다른 방법론에서 커버될 XP 실천
 Scrum
 User Story
 Planning Game
 1-week Iteration
 Slack
 Test-Driven Development
SUMMARY
eXtreme Programming (XP) 이란 가치, 원칙, 실
천방법으로 구성되는 프로그래밍 방법론으로,
팀원 모두가 공유하는 가치, 가치를 따르기 위
해 항상 지키는 원칙, 그리고 원칙을 실현하는
극단적인 실천방법들을 통해 변화에 빠르게 대
처할 수 있는 팀 운영방법을 제시하고 있다.
중요한 5대 가치는 대화, 단순, 피드백, 용기, 존
중이다. 원칙과 실천방법들은 이들 가치들을
지킬 수만 있다면 어떤 조합도 무방하다.
차회예고
SCRUM
- 회의는 이렇게 하자 –
Test-Driven Development
- 테스트 코드부터 짜라! -
References
 http://www.slideshare.net/aniruddha.chakrab
arti/agile-practices-extreme-programming
 http://www.slideshare.net/jdrumgoole/introd
uction-to-extreme-programming-1776586
Recommended Readings …
 익스트림 프로그래밍 2판
 Kent Beck 저, 김창준 역
 http://agile.egloos.com/
 애자일 이야기 블로그, 김창준 운영
 http://angel927.tistory.com/88
 잘못된 애자일의 다섯 가지 증상