Extreme Programming Explained 2/E
1판 슬로건: 깨어 있으라, 적응하라, 변하라
2판 슬로건: 변화를 포용하라
XP 적용의 원칙
- 낮은 곳의 과일부터
- 가장 핵심적이고 괴로운 문제부터 (근본 원인 분석)
- 성공에 집중하기 (잘 안 되는 것보다 뭐가 잘 되는 지에 집중
- 잘 안 되면 방법을 바꿔서
- 문자에 집착하지 않고
- 점진적으로 (아기 걸음)
자신의 상황에 맞게 XP의 에자일 방식을 적용해보고 그 경험을 상기시키자.
즉각적인 피드백
추천인이 말하는 에자일 방법
- 초기에, 자주, 자동화해서 테스트하라: 최신 빌드에서는 녹색 체크 표시를 바등려면 테스트를 21,000개 이상 통과해야합니다.
- 점진적 설계: 우리는 매일 설계에 일정 자원을 투자합니다. 하지만 우리에게는 API를 안정되게 유지해야한다는 추가 제약이 있다.
- 매일 배치(deploy): 컴포넌트마다 적어도 하루에 한 번은 배치하고, 즉각 피드백을 받고 문제도 초기에 잡기 위해 배치된 코드 위에서 개발을 진행한다.
- 고객 참여: 적극적인데다 지속적으로 피드백을 보내주는 활발한 사용자 공동체가 있다는 점에서 우리는 운이 좋다. 우리는 그들에게 귀를 기울이고 최대한 빨리 피드백하려고 노력해야한다.
- 끊임없는 통합: 최신 코드가 매일 밤 빌드됩니다. 매일 밤 빌드는 컴포넌트간 통합에 대한 통찰력을 제공해준다. 일주일에 한 번 우리는 모든 컴포넌트가 잘 통합되는지 확인하려고 통합 빌드를 수행합니다.
- 짧은 개발 주기: 비록 우리 주기가 XP에서 권장하는 1주일 주기보다 길긴 하지만, 그 목적은 동일하다. 우리의 6주 주기는 마일스톤 빌드로 끝나는데, 이것이 우리 프로젝트의 심장 박동 역할을 한다. 모든 마일스톤 빌드의 목적은 진전 상황을 보여주고 (이것 때문에 우리는 정직해 줄 수밖에 없다) 우리 공동체가 실제로 사용할 수 있고 피드백을 내놓을 수 있는 정도로 수준 높은 제품을 전달하는 것이다.
- 점진적 계획: 릴리즈를 하고 나면 배아 단계의 전반적인 계획을 만들고 그걸 릴리즈 주기를 통틀어 진화시켜 나간다. 이 계획은 사용자 공동체도 대화에 참여할 수 있도록 우리 웹 사이트에 일찍 올라갑니다. 마일스톤들은 예외인데, 이것들은 우리 프로젝트의 심장 박동 역할을 하기에 최초의 계획 반복에 고정된다.
XP의 목표
뛰어난 소프트웨어 개발. 소프트웨어를 더 적은 비용으로, 더 적은 결함만 가지게, 더 높은 생산성으로, 훨씬 투자 대비 회수율이 높게 개발하는 것
XP의 의의
일반적인 개발 실천방법들을 '극단'까지 밀어붙이는 것
XP는 과거엔 통했지만 지금은 뒤쳐진 습관, 양식을 버리는 것. 우리를 보호하긴 해도 생산성을 떨어뜨리는 방어수단들을 포기하는 것이다.
사람을 사람으로써 대할 때 생산성이 올라간다.
서문까지 읽고 정리하자면
XP를 포함한 에자일 방법론은 모호하며 빠르게 바뀔 수 있는 비즈니스 요구사항에 빠르게 대처하도록
기능들을 최대한 의미있게 잘게 쪼개어 중요한 것 부터 짧은 주기로 릴리즈 하는 것 같다. 이러한 제품관련된 부분 뿐만 아니라
인간과 인간 사이의 관계도 중요하게 보는 것 같다. 서로의 외로움을 달랠 수도 있고 비즈니스 관계 상 늘 새로운 직원들이 올 수 있는데 그들이 적응하기 편하도록 대하는 것도 언급된다. 이러한 가까운 관계를 유지함으로 서로에 대한 피드백도 쉽게 가능해지니 짧은 주기의 릴리즈를 가진 이 방법론에 있어 필요한 분위기인 것 같다.
XP 탐험하기
먼저 XP를 운전으로 비유하며 시작한다. 운전을 할 때 핸들을 처음 올바르게 둔다하여 끝지점까지 올바르게 도착하는 것이 아니다.
끝지점에 도착할 때까지 지속적으로 핸들을 조향해야만한다. XP가 이러하다. 최종적인 목적만을 정해둔 채 그 과정은 지속적으로 변화나 변경이 잦을 수 있다. deploy 주기를 짧게 가진다. 고객은 시스템의 방향을 결정하며 개발자는 개발 프로세스의 방향을 결정한다.
추정치에 대한 의사소통에 있어서의 태도는 그 사람이 개발과정에서의 사회적 힘들이 어떻게 작용하는지에 대한 것을 투영한다. 누구라도 과거에 억울하게 비난을 받았더라면 책임을 지는 위치가 꺼려지지 않겠나.
가치를 명시하는 것은 중요한 일이다. 그렇지 않으면 기계적으로 생각없이 수행하는 것과 다를 바가 없다. 이 책에서는 몇 가지의 실천방법들이 제시된다. 실천방법을 행한다는 것은 유효한 시간 속에 그것을 해야하는 명확한 이유를 알고 수행한다는 것이다. 이것은 행위에 목적을 부여할 수 있다.
가치, 원칙, 실천 에 대해서 언급한다. 어렵다.
가치는 추상적이고 보편적이다.
실천은 가치의 증거다.
원칙은 가치와 실천을 이어준다.
가치있다 판단한다면 이를 실천해야하고 이 실천방식을 신뢰하고 쉽게 접근할 수 있도록 하는 것이 원칙이다. 로 해석했다.
어떤 것에 가치를 두는냐는 사람에 따라 다를 수 있다. 그것이 실질적으로 도움이 될 수도 있으면 그렇지 않을 수도 있다.
그래도 개발의 관점으로 정하자면 팀에 이로운 가치인가를 두고 판단할 수 있겠다. 예로 코딩스타일을 두는데 각자 자신이 좋다 판단하는 코딩스타일이 있을 수 있다. 허나 팀의 관점에서 볼 때 이 코딩스타일이 다르다면 팀에게 이로운가에 대해서 부정적인 답을 들을 수 있다.
그렇기에 코딩스타일은 통일하도록 하는 것이 좋아보인다.
의사소통에 대해서 말한다. 개개인이 어떠한 문제를 해결할 능력, 정보를 가지고 있음에도 불구하고 의사소통이 원만하지 못해 이 문제에 직접적인 권한을 가지고 이쓴ㄴ 사람에게 전달되지 못하는 경우가 있다. 그러니 편안하게 의사소통할 수 있는 분위기를 만드는 것이 중요하다. 얼핏보면 그저 친교모임처럼 보일 수도 있지만 팀이 고수하는 가치와 책임이 이러한 부분을 막을 것이다. 팀원들이 가치와 책임이 전제되는 것 가다. 무엇보다도 의사소통없는 움직임은 전진이 아니다.
단순함은 XP에서 다루는 가장 훌륭한 지적가치이다. 우아하다 느낄 정도의 단순함이다. 이 단순함은 우리가 구현해야할 가장 중요하고 가장 최소한 정도의 기능을 가지게 된다. 이 때 단순함은 환경에 따라 그 기준이 달라질 수 있다. 만약 우리의 서비스는 단순하게 구현하기에 보안이나 안전조건 때문에 단순하게 구현하기가 힘들다. 적어도 두 개의 프로세스를 구성하여 기능과 보안을 둘 다 잡아야한다는 것이다. 그렇다면 이 때의 단순함의 기준은 두 개의 프로세스만을 사용하여 이 조건을 충적하는 것이다. 이 보다 더 좋은 결과가는 하나의 프로세스만을 가지고 기능과 보안을 둘 다 잡는 것인데 이건 어려운 부분이지 않는가. 정말 필요한 기능만을 최소한으로 가지는 것이 단순함이다.
피드백에 대하여
경험해보기전의 방향은 달라질 가능성이 높다. 이 책에서는 처음부터 제대로된 설계를 하기보다는 점진적인 개선을 요구하는데
제대로된 설계를 꺼려하는데에는 다음과 같은이유가 있다
- 어떻게 하는 것이 제대로 하는 것인지 모를 수 있다. 결국 사람을 대상으로 하는 서비스니 그것이 유효할지도 모르고 주어진 문제를 해결할 방안이 떠오를 지 떠오르지 않을 지 모른다.
- 오늘 잘 돌아가는 것이 내일도 잘 될 지는 모르는 법이다. 워낙 구조가 복잡하니 어떤 변수가 있을지 제대로 파악하는 것은 어렵다.
- 오늘 제대로하는 것에 시간을 소모하여 내일 바뀌어버린 상황에 오늘 제대로 만든 것이 헛수고로 될 수 있다.
점진적 개선을 요구하기에 그 짧은 주기사이의 피드백의 가치는 상당하다.
이 피드백을 통해 목표에 더 가까워질 수 있는 것이다.
- 어떤 생각에 대한 여러분 자신 또는 팀 동료들의 의견은 어떤가
- 그 생각을 구현해 보았을 때 코드가 어떻게 보이는가
- 테스트를 쉽게 작성할 수 있는가 그렇지 않은가 (테스트를 쉽게 작성할 수있는 코드와 그렇지 않는 코드에 대해서 공부를 하고싶다.)
- 테스트가 돌아가는가 그렇지 않은가
- 어떤 아이디어를 구현, 배치한 후 어떻게 작동하는가
XP는 팀이 다룰 수 있는 한도 내에서 최대한 빨리 최대한 많은 피드백을 ㅏㅁㄴ들어낼 수 있게노력한다. 중간에 피드백이 너무 많이 생기는 상황에서 정말 중요한 부분을 신경쓰지 못할 상황까지 온다면 잠시 피드백의 주기를 늦추는 것도 하나의 방법이다.
용기
용기 혼자서는 위험하지만 , 다른 가치들과 조화를 이룰 때 강력해진다.
용기는 두려움에 직면했을 때 가장 효과적인 행동이다.
자신의 두려움을 어떻게 다루는지가 그들이 팀의 일원으로 효율적으로 기능하는 지 가르는 기준이된다.
어떤 경우에 용기는행동을 중시하는 형태로 나타난다. 문제가 무엇인지 안다면, 그것에 대해 무슨 일이든해보는 것이다. 어떤경우엔 용기가 인내로 나타나기도 한다. 문제가 있다는 것은 알지만 정확히 무엇인지 모를 경우, 그 문제가 뚜려하게 나타날 때까지 기다리는 데에도 용기가 필요하다. 결과를 예상하지 않고 행동하는 것은 효과적인 팀워크가 아니다. 두려울 때면 다른 가치들을 무엇을 해야 할지에 대한 가이드로 삼아 팀워크를 복돋아 주도록 한다. (여기서의 다른 가치가 뭐지? 앞서 말해오는 의사소통 , 단숨함 같은 것을 말하는 것 같다.)
진실을 말할 수 있는 용기는 의사소토오가 신뢰를 자라게 한다. 실패하는 해결책을 버리고 새로운 해결책을 찾아 나서는 용기는 단순함을 복돋운다. 진짜 답변, 구체적인 답변을 추구하는 용기는 피드백을 낳는다.
존중
팀의 구성원들이 서로를 고려하지 않고 다른 사람의 일에 신경 쓰지 않는다면, 제대로 XP를 할 수 없다. 팀원이 프로젝트를 소중하게 여기지 않는다면 어떠한 것도 그 프로젝트를 살릴 수 없다. 소프트웨어 개발에서 생산성과 인간성을 동시에 개선하려면, 팀에 속한 모든 개인의 기여를 존중해야 한다. 나도 중요한 사람 당신도 중요한 사람.
그외 다른 가치들
의사소통, 단순성, 피드백, 용기, 존중 만이 소프트웨어 개발을 성공적으로 이끄는 가치가 아니다. 이것들은 XP를 이끄는 것이며 조직, 팀, 자기자신에 따라 다른 가치드을 선택할 수 있다. 안전성, 보안, 예측가능성, 삶의 질 등이 해당될 수 있으며 이러한 가치가 들어갈 때 앞서 말한 XP의 방식과는 조금씩 형태가 달라질 것이다.
가치만으로는 소프트웨어 개발을 할 때 무엇을 해야 하는지 구체적으로 충고해주지 않는다. 가치와 실천방법은 다른 것이기 때문이다. 이 둘을 이어주기 위한 것이 원칙
원칙
가치는 너무 추상적이여 행동의 지침으로는 한계가 있다. 의사소통의 가치를 실현하기 위해 대화를 할수도 있고 문서를 남길 수도 있다.
대화를 통해선 다른 사람과 관계 맺고 싶어하는 인간의 기본 욕구를 충족할 수 있어 인간다움의 원칙에 따르자면 다른 조건이 동일하다는 전제하에 대화가 더 나은 방식이 될 수 있다. 문서의 경우 낭비 요소가 많다. 더 많은 사람에게 의사를 전달할 수 있긴 해도 단방향이며 대화에서 얻을 수 있는 즉각 피드백이나 브레인스토밍도 함께 할 수 없다. 의사소통이 글을 통해 이루어진다면 사람들은 그것을 의심할 여지가 없는 사실로 받아들이기 쉽고 아예 완전히 거부해 버리기도 쉽다. 개인적으로 문서는 (글)은 시간에제한되지 안흔ㄴ다는게 큰것 같다.
대화를 통한 의사소통의 장점이 꽤나 와닿는다. 팀원들의 의사도 중요하겠지만 이 글을 읽었을 때 부담스럽지 않는 선에서 대화를 통한 의사소통을 하는 것에 흥미가 생겼다. 즉각적인 피드백과 있는 그대로 받아들이기 쉬운 글의 특성을 피할 수 있다니 엄청나다!!!!!!!
이 책에서 개발을 할 때 요구되는 모든 원칙을 다루지는 않는다. 보안이 중요한 (Safety Critical) 시스템을 만들 때는 추적 가능(traceability)의 원칙을 지켜야 한다 . 어떤 시점에서든지 수행된 작업부터 사용자들이 명시적으로 표현한 요구까지 경로를 되짚어 올라갈 수 있어야한다. (스택의 공포가 떠오른다)
어떤 작업도혼자 저절로 수행되어서는 안 된다. 인증을 받기 위해서는 추적가능의 워닉을 지키는 거싱 중요하다. 모드느 소프퉤어에 적용할 만한 원칙은 아니므로, 이 책에 모든 원칙이 들어가지 않는다.
XX페이 같이 보안이 중요한 서비스의 경우 다른 서비스들과 다른 부분이 있다 들었는데 이런 부분이 해당되는 것 같다.
인간성