Extreme Programming의 개요에 대해 설명한 문서입니다. 여기 나와있는 그림은 (넘기고) 이 책의 2장의 첫번째 페이지에서 나오는 그림인데요, 저는 처음 이 그림의 밑에 나와있는 설명을 보고 무슨 말인지 전혀 이해하지 못했습니다. 한국어로 직역하면, 개발자로서 우리는 extreme programmin이 마을의 유일한 게임이 아님을 기억해야한다, 입니다. 이게 도대체 무슨 말인가 싶어서 검색해보았더니/only game in town은 일종의 관용어구로 유일한 선택지나 최선의 선택지라는 뜻이 있었습니다. 즉, 개발자로서 우리는 extreme programming이 유일한 선택지가 아니라는 것을 기억해야한다는 말이죠. 이게 무슨 말인지 이제부터 알아보겠습니다./위키에 의하면, Extreme Programming은 계속해서 변화하는 고객의 요구사항에도 높은 퀄러티의 소프트웨어를 개발하고, 개발 팀의 삶의 질을 보장하는데 목적이 있는 애자일 소프트웨어 개발 프레임워크입니다. /Extreme Programming은 소프트웨어 요구사항이 동적으로 변화하는 경우, 새로운 기술로 마감 시한이 정해져있는 프로젝트를 하는 경우, 소규모의 공동으로 개발하는 팀의 경우 등의 상황에서 사용하기 적합한 방법입니다. 아까 Introduction에서 말씀드렸던 것 처럼 XP가 모든 상황에서 적합한 방법은 아닙니다. 이 페이지의 두번째 링크를 보면, XP가 언제 적합하지 않은지 나와있으니 궁금하신 분은 후에 확인하셔도 좋을 것 같습니다. /Extreme Programming은 팀워크를 강조하는데요, Extreme Programming이 소프트웨어의 퀄러티를 개선시키는데는 다섯가지의 방법이 있습니다. 의사소통과 단순성, 피드백, 존중 그리고 용기입니다. 일종의 핵심 가치라고도 할 수 있습니다. /Extreme Programming의 핵심가치를 하나씩 설명해보겠습니다. 첫번째로 커뮤니케이션, 소프트웨어 개발은 본질적으로 축구나 야구와 같은 팀 스포츠와 같다고 볼 수 있습니다. 우리는 충분한 의사소통을 통해, 팀 구성원 한명 한명이 다른 팀 구성원들에게 지식을 전달해야합니다. 의사소통이 제대로 되지 않는 팀은 쉽게 어긋나고 말죠. 두번째로 단순성은 우리가 할 수 있는, 알고 있는 요구사항만을 다루는 것을 의미합니다. 고객이 어떤 것을 요구할 것 같다는, 미래를 예측하는 행동을 하지 않는 것입니다. 이는 낭비를 가능한 한 피하고, 가능한한 시스템설계를 단순하게 유지하는 등 절대적으로 필요한 일만을 하는 것입니다. 세번째로 피드백은, 팀원 각자들이 해온 노력들을 꾸준히 피드백을 함으로써 어떤 분야를 더 개선해야 할지 발견할 수 있게 하는 것입니다. 마지막으로 용기와 존중입니다. Extreme Programming에서 Extreme은 한국어로 하면 ‘극단적인＇이라는 의미를 가지고 있습니다. 팀의 효율성을 저하시키는 조직의 문제를 제기하려면 용기가 필요합니다. 또한 작동하지 않는 것을 개발하는 것을 멈추고 다른 것을 시도하는 것 또한 용기를 필요로 합니다. 수락하기 어려운 경우에도 피드백을 수락하고 그를 행동으로 옮기는 데도 용기를 필요로 합니다. 팀원들은 서로 의사소통을 하고 피드백을 제공하고 수락하며 협력하기 위해 서로를 존중해야 합니다. /(Practice : 관행) 이 페이지에 나와있는 12가지의 리스트는 소프트웨어 개발 관행입니다. 전부 다 소개하기에는 너무 많은 것 같아서 우리에게 익숙한 Refactoring에 대한 상세 설명만 준비했습니다. 나머지 관행들에 대해서는 책을 읽으시면 자세한 설명을 찾을 수 있습니다. /(Practice : 관행) 아마 대부분의 분들이 많이 들어봤을 단어인데요, 코드를 작성하고나면 종종 내가 왜 이런식으로 코드를 짰지? 하고 당황할정도로 엉망진창인 코드를 발견하게 되기도 합니다. extreme programming은 잦은 리팩토링을 통해 코드를 최대한 깨끗하고 단순하게 유지합니다. 리팩토링이란 시스템의, 프로그램의 동작에는 영향을 주지 않으면서 프로그램의 구조에는 변화를 주는 개선 방식입니다. 각각의 변화는 사소한 것이며, 우리는 리팩토링을 완료한 후에 우리가 어떤 동작에 영향을 주지 않았는지 확인을 하기 위해 유닛 테스트를 진행합니다. 리팩토링은 개발도중 지속적으로 진행되며, 이를 통해 아까 언급했던 것처럼 코드를 최대한 깨끗하고 단순하게 유지할 수 있습니다. /마지막으로 결론입니다. extreme programming은 앞에서 소개한 다섯가지의 가치를 기반으로한 소프트웨어 개발 방법론입니다. 이 가치들은 팀을 하나로 묶어주며, 서로에게 충분한 피드백을 함으로써 현재 팀원 자신의 위치를 직시하게 하고, 관행들을 고유한 상황에 맞게 조율할 수 있도록 합니다. 프로젝트를 진행하는 대부분의 팀들이 XP를 그대로 사용할 수 있지만, 몇몇 팀들은 관행을 추가하거나 수정함으로써 적용시킬 수 있습니다.

1. Overview of Extreme Programming
B.S. 4th Yejin Park
(o0o2211915@gmai.com)
Hanyang Univ.
Software Technology and Architecture Research Lab.
1

2. Contents
 Introduction
 Extreme Programming
 When applicable…
 Values
 Pactices
 Conclusion
2 / x

3. Introduction
3 / x
© Jennifer M. Kohnke
“As developers we need to remember
that XP(extreme programming) is not
the only game in town.”
- Pete McBreen

4. Introduction(Cont.)
4 / x
© Jennifer M. Kohnke
“As developers we need to remember
that XP(extreme programming) is not
the only game in town.”
- Pete McBreen
the only available, desirable, or valuable thing

5. “Extreme Programming (XP) is an agile software
development framework that aims to produce higher
quality software, and higher quality of life for the
development team.”
“Extreme Programming (XP) is a software development
methodology which is intended to improve software
quality and responsiveness to changing customer
requirements.”
- Wikipedia
Extreme Programming
5 / x

6. • Dynamically changing software requirements
• Risks caused by fixed time projects using new
technology
• Small, co-located extended development team
• The technology you are using allows for automated
unit and functional tests
When Applicable…
6 / x
1) http://www.extremeprogramming.org/when.html
2) http://wiki.c2.com/?WhenIsXpNotAppropriate

7. • Extreme Programming emphasizes teamwork.
Managers, customers, and developers.
• It improves a software project in five essential ways;
communication, simplicity, feedback, respect, and
courage.
Values
7 / x
https://www.codeproject.com/Articles/604417/Agile-software-
development-methodologies-and-how-t

8. • Communication – “Team Sport”
• Simplicity – “What is the simplest thing that will
work?”
• Feedback
• Courage
• Respect
Values(Cont.)
8 / x

9. • The Planning Game
• Small Releases
• Metaphor
• Simple Design
• Testing
• Refactoring
• Pair Programming
• Collective Ownership
• Continuous Integration
• 40-hour week
• On-site Customer
• Coding Standard
Practices
9 / x

10. • Refactoring
• Code tends to rot. As we add feature after feature and deal with bug after
bug, the structure of the code degrades. Left unchecked, this degradation
leads to a tangled, unmaintainable mess.
• XP teams reverse this degradation through frequent refactoring.
Refactoring is the practice of making a series of tiny transformations that
improve the structure of the system without affecting its behavior. Each
transformation is trivial, hardly worth doing. But together, they combine
into significant transformations of the design and architecture of the system.
• After each tiny transformation, we run the unit tests to make sure that we
haven't broken anything. Then we do the next transformation, and the next,
and the next, running the tests after each. In this manner, we keep the
system working while transforming its design.
• Refactoring is done continuously rather than at the end of the project, the
end of the release, or the end of the iteration, or even the end of the day.
Refactoring is something we do every hour or every half hour. Through
refactoring, we continuously keep the code as clean, simple, and expressive
as it can be.
Practices(Cont.)
10 / x

11. • Extreme Programming is a discipline of software
development based on values of simplicity,
communication, feedback, and courage.
• It works by bringing the whole team together in the
presence of simple practices, with enough feedback to
enable the team to see where they are and to tune the
practices to their unique situation.
• XP is a good general-purpose method for developing
software. Many project teams will be able to adopt it
as is. Many others will be able to adapt it by adding
or modifying practices.
Conclusion
11 / x

12. Reference
12 / x
- Martic C. Robert, Martin Micah . Agile Principles, Patterns, and Practices in C#
- Beck, Kent. Extreme Programming Explained, Embrace Change, Second Edition.
Boston: Addison-Wesley, 2004.
- Beck, Kent. Test-Driven Development by Example. Boston: Addison-Wesley,
2003.
- https://www.dictionary.com/browse/only-game-in-town--the
- https://ronjeffries.com/xprog/what-is-extreme-programming/