1 / 66

Software development #1: SE, AGILE, XP

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

tadita
Download Presentation

Software development #1: SE, AGILE, XP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. AIMs… • Let you knowthese terminologies • Software Engineering • Agile Software Development • eXtremeProgramming • Let you think about • How to run a programming team • How to cooperate effectively

  3. Software Engineering Agile Software Development eXtremeProgramming

  4. 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.

  5. 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

  6. Waterfall Model Requirements Design Implementation Verification Maintenance

  7. “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.”

  8. Typical Process Clients (Customer) Developer • Requirements • Functionality • User Interface • UML Diagram  SPEC • Implementation Clients (Customer) Developer • Watching the result • Happy • Get money • Quit

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

  10. Typical Process Done Clients (Customer) Developer • Requirements • Which is not organized • UML Diagram  SPEC • Made by interpretationsdone by Developers Clients (Customer) Developer • Watching the result • Which is different from what they expected • Can’t leave the office • Painful, stressful life

  11. 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!

  12. 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.

  13. SUMMARY Software Engineering, aka SE, is an area of CS, teaches “How a team create program”. Waterfall Method, the typicalSE 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.

  14. Software Engineering Agile Software Development eXtremeProgramming

  15. Agile in dictionary Before censoring • Adjective • Easy of movement • Quickness • Lightness • in Korean • 기민한 • 날랜 12 hours later

  16. 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: Individualsand 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/

  17. Let’s compare those eight values.

  18. 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

  19. 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.

  20. 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

  21. 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

  22. 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

  23. 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!

  24. 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

  25. 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!

  26. 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

  27. 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

  28. SUMMARY Agile Software Developmentis 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.

  29. Software Engineering Agile Software Development eXtremeProgramming

  30. eXtreme Programming • Agile Programming Family (of course!) • Set of • 가치 Values • 원칙 Principles • 실천 and Practice • Let developers to confidently respond to changing customer requirements

  31. Simple XP Diagram Values Practice Principle 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  Pair Programming Short Release Continuous- Integration Sit together Standing Meeting Gradual Design Communication Simplicity Feedback Courage Respect Reflection Flow Opportunity Failure Quality Humanity Improvement Economical- effectiveness Benefit Self-Similarity

  32. Values in XP • Value (가치)? • 팀이 중요하다고 생각하는 것 (항상 지켜야) • 상호 보완적 (동시에 지켜야) • Values in XP • 대화 Communication • 단순 Simplicity • 피드백 Feedback • 용기 Courage • 존중 Respect

  33. Communication : 대화 • Interaction between two or more individual • What it means when somebody in a team not talking to somebody else about something? • 뭔가 문제가 있는데 말하기 싫다는 것 • 이렇게 숨기다가 문제는 오히려 커진다! • 대화가 필요해! • 서로 자신만의 추측으로 일을 진행하지 않도록!

  34. Simplicity : 단순 • Why not so simple? • 진짜로 복잡하니까? • or, 더 쉬운 방법을 찾지 않아서? • Simple is the best! • Do the simplest thing that could possibly work! • 일단 작동되면, 그거로 충분하잖아? • 다른 가치들이 Simplicity 의 단점을 보완함!

  35. Feedback : 피드백 • Human being is not always perfect! • 일단 불완전하지만 작업을 진행하고, 피드백을 통해 점진적으로 완벽을 향해 다가가면 된다 • 피드백의 예 • 내가 짠 소스코드에 대해 다른 사람들의 의견은? • 우리가 만든 프로그램의 현재에 대한 고객 생각? • Concrete Feedback gives more opportunity to steer our effort

  36. Courage : 용기 • 팀 내에서 발생하는 대표적인 두려움 • 이렇게 코드를 짰다가 문제가 생기지 않을까? • 이런 질문을 하면 멍청하다고 혼나지 않을까? • Don’t be afraid! • 누군가 Feedback 을 해 주면 괜찮으니까! • 소통하지 않아 발생하는 문제를 줄일 수 있잖아!

  37. Respect : 존중 • Don’t have to blame other’s fault. • 실수할수도 있는 거다 • 사정을 이해하고 용기를 북돋아주자 • 솔직하게 모른다고 말할 수 있도록 도와주자 • 우리 모두는 동등한 인격체 • 후배라고, 선배라고 업신여길 필요가 없다

  38. XP 의 가치만이 진리는 아니다 • 국가 기밀과 관련된 프로그램을 개발하는 팀에서는 무엇이 중요한가? • 안전성 • 보안 • 예측가능성 • 위계질서 • 결국 XP 는 XP 의 가치들을 중요하게 생각할 수 있을 때에 적용해야만효과를 볼 수 있다!

  39. XP 의 가치들을 따르는 예 • 내가 2주 전에 짠 코드에서 버그를 발견한다 • 주저하지 않고 팀원들에게 이를 알린다 • 팀원들은 나를 존중해 주니까 내 실책을 비난하는 것만으로 시간을 낭비하지 않는다 • 내가 지금 대화에 응해야 팀의 일이 잘 진행된다 • 그러니 내 실수를 알릴 용기가 나에게는 있다 • 만약 XP 의 가치들이 지켜지는 팀이 아니라면, • 팀원들의 비난이 두려운 나는 존중받지 못할 게 뻔한 실수를 감추기 위해 대화하지 않고 숨겠지.

  40. XP 의 가치들을 따르는 예 • 고객의 요구조건이 난해하다 • 고객에게 우리가 이해하지 못했음을 알린다 • 우리의 이해도에 대한 피드백을 고객에게 주고 • 고객은 좀더 단순하게 요구조건을 설명해 준다 • 만약 XP 의 가치들이 지켜지는 팀이 아니라면, • 우리는 고객의 피드백을 물어보지도 않을 것이고 고객들 또한 더 단순한 설명을 할 필요를 모르겠지

  41. Simple XP Diagram Values Practice Principle 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  Pair Programming Short Release Continuous- Integration Sit together Standing Meeting Gradual Design Communication Simplicity Feedback Courage Respect Reflection Opportunity Failure Quality … Humanity Improvement Economical- effectiveness Benefit Diversity

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

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

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

  45. XP 의 원칙들 (III) • Opportunity (기회) • 문제가 발생하면, 미래에 발생할 뻔했던 것을지금 고칠 기회를 잡은 것이라 생각하자 • Failure (실패) • 아무것도 할 수 없을 것처럼 보일 때, 차라리 실패할 것을 알더라도 저질러서 뭔가 배울 수 있다 • Quality (품질) • 어떤 경우에도 우수한 결과물을 개발하도록 하자

  46. 그 밖의 XP 의 원칙들 • 받아들인 책임: Accepted Responsibility • 아기 발걸음 • 잉여 : Slack • 흐름 : Flow • 자가유사성 : Self-Similarity • 사실 나도 뭐가 더 중요한지 잘 모르겠음 • 어쨌든 … 가치를 지키기 위한 것이 원칙임.

  47. Simple XP Diagram (Recall!) Values Practice Principle 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  Pair Programming Short Release Continuous- Integration Sit together Standing Meeting Gradual Design Communication Simplicity Feedback Courage Respect Reflection Opportunity Failure Quality … Humanity Improvement Economical- effectiveness Benefit Diversity

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

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

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

More Related