Software development #1: SE, AGILE, XP Combacsa’s SPARCS Web Seminar Software development #1: SE, AGILE, XP

AIMs… Let you know these terminologies Let you think about Software Engineering Agile Software Development eXtreme Programming Let you think about How to run a programming team How to cooperate effectively

Agile Software Development 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.” UML Diagram cited from http://www.ibm.com/developerworks/jp/xml/library/x-umlschem/ “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 Functionality User Interface UML Diagram  SPEC Implementation Clients (Customer) Developer Watching the result Happy Get money Quit

Sounds very good in theory. But what really happen is …

Typical Process Done Clients (Customer) Developer Requirements Which is not organized UML Diagram  SPEC Made by interpretations done by Developers Clients (Customer) Developer 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 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.

Agile Software Development Software Engineering Agile Software Development eXtreme Programming

Agile in dictionary Adjective Easy of movement in Korean Quickness Before censoring Adjective Easy of movement Quickness Lightness in Korean 기민한 날랜 Agile newspaper cartoon, cited from: http://capcold.net/blog/1075 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 Working Software Customer Collaboration Responding to change Processes and Tools Comprehensive Documentation Contract Negotiation Following a plan OVER 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 Tools 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 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 Things should be fixed 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 We are imperfect human being 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.

Agile Software Development 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 Communication Simplicity Feedback Courage Respect 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 Principle Practice Pair Programming Short Release Continuous- Integration Sit together Standing Meeting Gradual Design Communication Simplicity Feedback Courage Respect Humanity Improvement Economical- effectiveness Benefit Self-Similarity Reflection Flow Opportunity Failure Quality

Values in XP Value (가치)? Values in XP 팀이 중요하다고 생각하는 것 (항상 지켜야) 상호 보완적 (동시에 지켜야) 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? Simple is the best! 진짜로 복잡하니까? 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! 이렇게 코드를 짰다가 문제가 생기지 않을까? 이런 질문을 하면 멍청하다고 혼나지 않을까? 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 Communication Simplicity Feedback Courage Respect 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 Principle Practice Pair Programming Short Release Continuous- Integration Sit together Standing Meeting Gradual Design Communication Simplicity Feedback Courage Respect Humanity Improvement Economical- effectiveness Benefit Diversity Reflection Opportunity Failure Quality …

Principle XP 에서 원칙의 역할 가치 + 원칙의 실현이 “실천” 이다 XP의 가치들을 지킬 수 있도록 하는 지침 솔까말 “가치” 들은 제법 추상적이어서 예제를 들지 않고서는 설명하기 힘들고 예제로 설명한다고 하더라도 예제가 상징하는 한계 안에 갇혀버릴 수 있다 가치 + 원칙의 실현이 “실천” 이다

XP 의 원칙들 (I) Humanity (인간성) Improvement (개선) 프로그램은 인간이 개발한다는 걸 잊지 말자 Improvement (개선) 프로그램 개발의 진행은 결국 프로그램을 계속 개선시키는 것임을 잊지 말자 Economical Effectiveness (경제성) 꼭 필요한 일에만 노력할 수 있도록 하자

XP 의 원칙들 (II) Benefit (상호 이익) Diversity (다양성) Reflection (반성) 자신에게는 물론, 다른 팀원들에게도 도움이 되는 일을 하자 Diversity (다양성) 여러 가지 가능성이 있음을 인정하고 그 가운데 더 나은 선택을 할 수 있도록 노력하자 Reflection (반성) 왜 성공했는지, 왜 실패했는지 자주 분석하자

XP 의 원칙들 (III) Opportunity (기회) Failure (실패) Quality (품질) 문제가 발생하면, 미래에 발생할 뻔했던 것을 지금 고칠 기회를 잡은 것이라 생각하자 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 Principle Practice Pair Programming Short Release Continuous- Integration Sit together Standing Meeting Gradual Design Communication Simplicity Feedback Courage Respect Humanity Improvement Economical- effectiveness Benefit Diversity Reflection Opportunity Failure Quality …

Practice (실천) eXtreme Programming 이 eXtreme 인 이유? 따라서, 가치들에 대해서는 반드시 완벽하게 동의하고 원칙들 또한 대체로 동의한 이후에야 실천방법들을 사용할 수 있음을 주의하자.

Practice (실천) Pair Programming Short Release Continuous Integration Automated Testing Standing Meeting Gradual Design

Pair Programming 기본적인 방법 예 1 예 2 두 사람이 한 조가 되어 한 대의 컴퓨터를 갖고 프로그래밍한다. 한 사람이 주도적인 프로그래밍을 하고, 다른 한 사람은 오타 검사나 다음 내용을 말한다 예 2 한 사람이 계획을 세워 계속 말로 전달하고 다른 한 사람은 그 계획대로 코딩을 한다

Pair Programming pro/con Pros 실수를 극단적으로 줄일 수 있다 한 사람의 눈보다는 두 사람의 눈이 오타를 줄인다 해당 코드의 의미를 아는 사람이 많아진다 Pair Programming 을 하지 않으면 당장은 한명뿐. Cons 뛰어난 실력자들에게는 오히려 생산성을 저하 각자 다른 부분을 작업하는 쪽이 효율적이다

Short Release Release란? Short Release? 작동되는 프로그램을 내놓는 것을 뜻함 고객에게 “작동되는 프로그램”을 전달함 Short Release? 고객에게, “작동되는 프로그램”을 자주 전달 그래서 고객이 더 많은 Feedback 을 주게 하고 우리가 놓치는 버그들을 고객들이 찾아주게 하자

Gradual Design 방법 효과 (Short Release 와 병행시) 프로그램의 전체적인 구조를 처음부터 전부 그리고 시작하는 게 아니라, 이번 작업기간동안 작업할 부분의 디자인만 우선 해보고, 시간이 흐르면서 점점 더 세부적인 부분의 디자인이 되도록 일을 진행한다 효과 (Short Release 와 병행시) 고객의 요구조건이 바뀌는 것은 결국 우리가 진행해온 “점진적인 설계 개선” 과 다르지 않게 됨.

Continuous Integration 각자가 서로 다른 부분을 개발할 때 서로가 작업한 부분을 하나로 합친다 서로가 어떻게 코딩한 것인지 잘 모를 때 서로의 작업내용을 서로에게 이해시킨다 Continuous Integration? 최대한 자주, 프로젝트가 분리되어 진행되고 있는 상황을 통합 진행으로 만든다

Automated Testing Testing? Automated Testing? 지금 내가 작성한 소스 코드가 정상적으로 작동하는지 검사하는 일 Automated Testing? 각자가 작성한 소스 코드가 정상적으로 작동하는지, 혹시 프로젝트의 다른 부분에 영향을 주지 않았는지를 “자동화된 테스트” 가 검증하도록 하자 Testing 코드가 제대로 준비되면 걱정할 것이 없다

Standup Meeting 방법 효과 말했잖아 … eXtreme 하다니까 … 회의를 일어선 채로 진행한다 다들 신체가 피곤한 걸 알기 때문에, 꼭 해야 할 말만 조리있게 간추려서 하게 된다 팀원들 모두 적절한 수준의 긴장을 유지하게 됨 말했잖아 … 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 Test-Driven Development User Story Planning Game 1-week Iteration Slack Test-Driven Development

SUMMARY eXtreme Programming (XP) 이란 가치, 원칙, 실천방법으로 구성되는 프로그래밍 방법론으로, 팀원 모두가 공유하는 가치, 가치를 따르기 위해 항상 지키는 원칙, 그리고 원칙을 실현하는 극단적인 실천방법들을 통해 변화에 빠르게 대처할 수 있는 팀 운영방법을 제시하고 있다. 중요한 5대 가치는 대화, 단순, 피드백, 용기, 존중이다. 원칙과 실천방법들은 이들 가치들을 지킬 수만 있다면 어떤 조합도 무방하다.

Test-Driven Development 차회예고 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 잘못된 애자일의 다섯 가지 증상