software development #1: se, agile, xp

SOFTWARE DEVELOPMENT #1:SE, AGILE, XP

Combacsa’s SPARCS Web Seminar

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 Engineer-

ing

Agile Software Devel-

opment

eXtreme Programming

Software Engineering (SE)

is an area of Computer Science dedi-cated 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 wantprior to the beginning of the de-

velopment

Draw UML Diagram to fix the SPECIFICATION of the program to share interface between programmers

Then do everything according to UML

Waterfall Model

Require-ments

De-sign

Implementa-tion

Verification

Mainte-nance

“We need a program which manages Shipping business.”

“Each shipping has origin & destination site & or-der.”

“Order consists of items, which is described by one-line description. Weight and Tax should also be needed.”

“To represent site, ad-dress will be used.”

“OK. Let’s draw UML dia-gram.”

“Let’s decide the dead-line.”

“Let’s write down source code.”

“After that, clients will be happy.”

Typical Process

Clients (Customer) Developer

Requirements Functionality User Interface

UML Diagram SPEC Implementation


Watching the result Happy

Get money Quit

Sounds very good in theory.

But what really happen is …

Typical Process Done


Requirements Which is not organized

UML Diagram SPEC Made by interpretations

done by Developers


Watching the result Which is different from

what they expected

Can’t leave the office Painful, stressful life

Hey, Waterfall Method is good! Microsoft’s success proves it

They always begin with UML

The only thing we need isdefinite 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 strat-egy, sayswe 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


opment

eXtreme Programming

Agile in dictionary

Adjective

Easy of movement Quickness Lightness

in Korean 기민한 날랜

Before censor-ing

12 hours later

Manifesto for Agile Software De-velopmentWe are uncovering better ways of developing

softwareby doing it and helping others do it.

Through this work we have come to value:

Individuals and Inter-actions

Working SoftwareCustomer Collabora-

tionResponding to change

OVER

Processes and ToolsComprehensive Documen-tationContract NegotiationFollowing 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 Interac-tions Individuals

Who create the program? Processes? No! Individuals!

We must respect each members, not only processes!

Interactions Without the interaction between individ-

uals, nothing comes out Even if we had good enough tools.

Comprehensive Documenta-tion Blueprint

Without blueprint, we can’t build a building It must be comprehensive enough to be un-

derstood 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 pro-

gram,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 ex-

tremely important …

Is programmer a machine which can’t understand natural language? No! We are human. We can have a conversa-

tion 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 Suther-

land) 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 accom-

modate all known agile methodologies at the same time

We can’t always apply agile method-ologies Eg) Military-related projects

Any small changes on requirements are not allowed

Strict command-obey relationship is nec-essary

SUMMARY

Agile Software Development is a set of different methodologies on pro-gramming, concentrating on facing the changes efficiently and produc-ing usable software quickly.It values Individuals and Interaction, Working software, Customer col-laboration, and Responding to change.For some cases, Agile software devel-opment might fail to be applied.

Software Engineering


opment

eXtreme Program-

ming

eXtreme Programming

Agile Programming Family (of course!)

Set of 가치 Values 원칙 Principles 실천 and Practice

Let developers to confidently re-spond to changing customer re-quirements

Simple XP Diagram

Values PracticePrinciple

Communi-cationSimplicityFeedbackCourageRespect

Pair Program-mingShort ReleaseContinuous-IntegrationSit togetherStanding MeetingGradual Design

HumanityImprove-mentEconomical- effective-nessBenefitSelf-Similar-ity

ReflectionFlowOpportu-nityFailureQuality

ValuesSynthetic and Abstract things agreed upon team members

PrincipleBridge between Values and Practice

PracticeHow to actually develop software

Software successfully created by our team! Yay

Values in XP

Value ( 가치 )? 팀이 중요하다고 생각하는 것 ( 항상 지켜야 ) 상호 보완적 ( 동시에 지켜야 )

Values in XP 대화 Communication 단순 Simplicity 피드백 Feedback 용기 Courage 존중 Respect

Communication : 대화

Interaction between two or more in-dividual

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 op-portunity 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


Communica-tionSimplicityFeedbackCourageRespect


HumanityImprove-mentEconomi-cal- effec-tivenessBenefitDiversity

ReflectionOpportu-nityFailureQuality

…





Principle

XP 에서 원칙의 역할 XP 의 가치들을 지킬 수 있도록 하는 지침

솔까말 “가치” 들은 제법 추상적이어서 예제를 들지 않고서는 설명하기 힘들고 예제로 설명한다고 하더라도 예제가 상징하는 한계

안에 갇혀버릴 수 있다

가치 + 원칙의 실현이 “실천” 이다

XP 의 원칙들 (I)

Humanity ( 인간성 ) 프로그램은 인간이 개발한다는 걸 잊지 말자

Improvement ( 개선 ) 프로그램 개발의 진행은 결국 프로그램을 계속

개선시키는 것임을 잊지 말자

Economical Effectiveness ( 경제성 ) 꼭 필요한 일에만 노력할 수 있도록 하자

XP 의 원칙들 (II)

Benefit ( 상호 이익 ) 자신에게는 물론 ,

다른 팀원들에게도 도움이 되는 일을 하자

Diversity ( 다양성 ) 여러 가지 가능성이 있음을 인정하고

그 가운데 더 나은 선택을 할 수 있도록 노력하자

Reflection ( 반성 ) 왜 성공했는지 , 왜 실패했는지 자주 분석하자

XP 의 원칙들 (III)

Opportunity ( 기회 ) 문제가 발생하면 , 미래에 발생할 뻔했던 것을

지금 고칠 기회를 잡은 것이라 생각하자

Failure ( 실패 ) 아무것도 할 수 없을 것처럼 보일 때 , 차라리

실패할 것을 알더라도 저질러서 뭔가 배울 수 있다

Quality ( 품질 ) 어떤 경우에도 우수한 결과물을 개발하도록 하자

그 밖의 XP 의 원칙들

받아들인 책임 : Accepted Responsibil-ity

아기 발걸음 잉여 : Slack 흐름 : Flow 자가유사성 : Self-Similarity

사실 나도 뭐가 더 중요한지 잘 모르겠음 어쨌든 … 가치를 지키기 위한 것이 원칙임 .

Simple XP Diagram (Re-call!)


Communica-tionSimplicityFeedbackCourageRespect


HumanityImprove-mentEconomi-cal- effec-tivenessBenefitDiversity

ReflectionOpportu-nityFailureQuality

…





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 Develop-

ment- 테스트 코드부터 짜라 ! -

차회예고

References

http://www.slideshare.net/aniruddha.chakrabarti/agile-practices-extreme-programming

http://www.slideshare.net/jdrumgoole/introduction-to-extreme-programming-1776586







Recommended Readings …

익스트림 프로그래밍 2판 Kent Beck 저 , 김창준 역

http://agile.egloos.com/ 애자일 이야기 블로그 , 김창준 운영

http://angel927.tistory.com/88 잘못된 애자일의 다섯 가지 증상

http://agile.egloos.com/

http://angel927.tistory.com/88

software development #1: se, agile, xp

Documents

agile software developmentwe

agile programming

waterfall methods fault

scrum software development

waterfall model shortfix

programming teamhow

organizeduml diagram

development draw uml