728x90

반성 Reflection

‘좋은 팀은 그저 일만 하지 않으며, 어떻게 일하는지 왜 일하는지도 생각 한다.

‘반성은 행동 다음에 온다. 배움이란 행동이 반성을 거친 것이다.’

흐름

‘’흐름’의 원칙은 개선을 위해 가치를 조금씩, 점진적으로, 계속해서, 자주 배치하라고 권한다.’

운전 메타포가 다시 생각 났다. 만약 운전을 하는데, 10초에 한 번 앞을 볼 수 있다고 해보자. 주위에 아무도 없이 혼자 운전을 한다고 해도 분명 사고가 난다. 계속 앞을 주시하면서 조금씩 방향을 바꿔가야 목표한 곳으로 사고 없이 갈 수 있다. 그런 관점에서 피드백 주기와 배포 주기를 짧게 가져가는 게 올바른 방향으로 향할 수 있는 방법이겠다는 생각을 했다. 피드백도 모아서 한 번에 받는 것 보다, 그 때 그 때 조금씩 받아야 과부하가 걸리지 않는 것 같다.

기회

‘어떤 문제가 오더라도 그것을 기회, 곧 개인적 성장의 기회, 더 깊은 인간관계를 맺을 기회, 더 개선된 소프트웨어를 만들 기회로 전환하겠다고 의식적으로 결심하는 것은 익스트림한 행동의 일부다.’

어떤 문제에 대해 더 깊은 인간관계를 맺을 기회라고 생각은 해보지 못했다. 나만 잘하면 전체가 나아지는 XP 라는 얘기를 들은 기억이 있는데, 모두의 집합에 속한 개인들 모두 ‘나’만 잘하면 전체가 나아지는 XP 라는 생각을 해야 하는 걸까. 이 얘기를 하면서 XP 를 하면 나 혼자 하던가, 모두가 같이 하던가 아니면 내가 나간다는 얘기도 있었던 기억이다. 도미노 게임이 생각 났다. 도미노가 잘 쓰러지려면 처음 시작이 필요하고, 다음 조각이 영향을 받아 잘 쓰러져야 완성된 그림을 볼 수 있다. 첫 번째 조각은 아니지만, 구성원으로서 중간에 낀 조각의 역할을 잘 해야 팀과 조직이 그리는 완성된 그림을 볼 수 있겠다는 생각을 했다.

잉여

‘정당한 목적이 있는 잉여를 제거하지 않도록 조심해야 한다.’

정당한 목적이 있는 잉여에는 무엇이 있을까?

실패

‘프로그래밍 시간을 낭비하고 싶지 않아서 대신 토론 시간을 낭비했다.’

목적과 행동이 일치하는 것을 경계하는 편이다. 예를 들어 회의를 위한 회의. 운동을 위한 운동. 그 나름대로 의미가 있을 수 있지만, 단순하게 생각했을 때 재미도 없고 힘이 많이 들어간다. 그리고 무엇보다도 ‘무엇인가 했다.’ 는 위로감에 성취한 것 없이 피로감을 느낀다고 생각하기 때문이다.

품질

‘어떻게 품질을 더 끌어올릴까에 대한 우리 이해의 한계만이 있다.’

‘범위는 미리 정확하게 알 수 없기 때문에, 좋은 관리 수단이 된다.’

아기 발걸음

‘올바른 방향이라고 알아챌 수 있는 일 중 당신이 할 수 있는 최소한은 무엇입니까?’

받아들인 책임

‘책임감은 오직 책임질 마음이 있는 사람이 받아들일 수 있을 뿐이다.’

물가로 끌고 갈 수 있어도 먹이지는 못한다는 말이 생각 났다.

결론

‘원칙은 어떤 실천방법이 무슨 목적을 달성하려고 존재하는지 여러분이 더 잘 알게 해준다.’

 

 

 

 

728x90
728x90

 

“의사소통이 글을 통해 이루어진다면 사람들은 그것을 의심할 여지 없는 사실로 받아들이거나 아예 완전히 거부해 버리기 쉽다.”

의사소통을 글로 하는 것과 대화로 하는 것의 장단점에 대해 특별히 고민을 해본 적이 없는 것 같다. 막연하게 글은 대화와 달리 감정을 담아내기 어렵기 때문에 오해할 가능성이 비교적 높겠다고 생각 했다. 반면 글을 남기는 것에 대해서는 대화를 했을 때와 달리 근거와 이력을 남기기가 편하다는 장점을 가지고 있다고 생각 해왔다. 저자가 말하는 것처럼 글은 대화와 달리 단방향 의사소통이라고 생각하지는 못했다.

이 부분에서 의심할 여지 없는 사실로 받아들이거나 완전히 거부하는 경우에 대해, 확인하지 못한 글들이 쌓이는 경우 빈번하게 발생한다고 생각 했다. 특별히 민감한 주제가 아니라고 (예를 들면 보안, 인증 등) 생각이 되면 기계적인 긍정의 피드백을 남기는 경우가 잦다. 반대로 민감한 주제라면 생각할 시간을 벌기 위해서라도 일단 안된다고 하는 것 같다.

인간성

“나는 내 삶을, 배우자하고만 이야기하는 사적인 일들, 내가 신뢰하는 사람들하고만 이야기하는 개인적인 일들, 누구와 이야기해도 상관없는 공적인 일들로 구분하려고 노력한다.”

친구와 있을 때, 사회 모임에 있을 때, 직장에 있을 때의 나의 모습은 모두 다르다고 생각 한다. 조금씩 이라도 서로 다른 페르소나는 각자가 주로 다루는 주제가 다르다. 평소에 그런 생각을 종종 해왔기 때문에 이 말이 조금 더 쉽게 이해가 되었다. 다른 사람들도 그렇겠지만, 나 역시 장소에 따라 사람에 따라 다루는 주제가 다르고 또 다르게 하려고 노력하기 때문이다.

경제성

“경제성을 인정하지 않는 소프트웨어 개발은 ‘기술적 성공’ 이라는 공허한 승리만 얻을 위험이 있다.”

상호 이익

문서에 대해서는 항상 고민을 많이 한다. 있으면 좋겠는데 잘 관리 할 자신이나 확신이 없기 때문이다. 방향성이 조금 다를 수 있지만 문서라는 것에 대해 RTFM 이라는 격언을 상기하고는 한다. 제발 매뉴얼을 읽으라는 것인데, 가끔 ‘누군가는 이것을 읽어주길 바라는 마음으로 고민 끝에 써내린 문장이겠으니 잘 읽어봐야겠다.’ 는 생각으로 의도적으로 매뉴얼을 정독 한다.

비교적 최근 TDD 를 접하고 api 문서를 RESR Docs 로 작성 하면서 코드 스스로 설명하는 self-descriptive 하다는 것에 대한 생각을 하게 되었다. 황호성PL님이 테스트 코드 작성을 권유 해주셨을 때, 잘 작성된 TC 가 있으면 그 자체로 문서가 될 수 있겠다는 것을 언급 해주신 적이 있었다. 다시 한 번 그때가 떠오르면서 보다 경제적이고 군더더기 없는, 스스로 설명하는 코드를 작성하는 것 그 자체가 좋은 문서이고 현재와 미래를 아울러 이익이 되는 행위겠다고 생각 했다.

자기 유사성

닭 잡는 데 소 잡는 칼을 쓰지는 않지만, 어쨌든 칼을 쓰는구나 생각 했다. 모난 것은 모난 대로 알맞게 필요한 곳이 있다고 생각 한다. 개인적으로 이 부분이 원칙이라는 것에 대해 앞서 정리한 것을 보다 잘 설명하고 있다고 느꼈다. 나는 원칙을 어떠한 공식과 같은 것이라고 개념을 정리 하였는데, 자기 유사성이라는 것 역시 구체적인 실천 방법은 아니지만 하나의 방법론으로 필요에 따라 다양한 곳에 적용한다는 점에서 상응하는 부분이 있다고 느꼈다.

개선

“소프트웨어 개발에서는 ‘완벽하다’는 없고, ‘완벽해지도록 노력한다.’만 있다.”

운전 메타포가 다시 한 번 떠올랐다. 완벽하게 차선의 정중앙으로 갈 수 없지만, 정중앙을 달리며 목표 지점에 도착하도록 해야 한다. 도로를 벗어나 자갈 위도 달리고 웅덩이에 빠질 수 있겠지만, 로드맵을 믿고 계속 핸들을 바로 잡으며 중앙을 유지할 수 있도록 노력해야 한다. 오늘 작업한 것이 내일은 버려야 할 것이 될 수 있다. 완벽을 고집하면, 홀가분 할 수 있지만 보통은, 그런 순간에 더욱 기운이 빠지는 것 같다. 완벽에 빠져 개선을 두려워 하지 말고, 완벽해지기 위해 언제든 개선할 수 있다는 마음 가짐을 가질 수 있도록 해야겠다.

다양성

이것을 염두에 둔 것은 아니었지만, 가끔 엉뚱하더라도 해결할 수 있는 방법을 가볍게 얘기 해보고는 한다. 그 방법으로 문제 해결을 바라는 마음 보다는, 그것을 시작으로 얘기 하다 보면 새로운 해결 방법을 떠올릴 수 있지 않을까 하는 기대를 가지고 있기 때문이다. 너무 허무맹랑한 경우 질타를 받기도 하지만 (적어도 나는) 그 나름대로 의미가 있었다고 생각하려고 한다.

 

 

 

 

728x90
728x90

“내가 가치 있게 생각하는 것과 정말로 가치 있는 것 사이의 차이에서 낭비가 생긴다.”

가끔 길을 잃은 기분이 들 때면 ‘모노크롬’ 이 부른 ‘니가 진짜로 원하는게 뭐야’ 를 찾아 듣고는 한다. 다양한 관점에서 생각해볼 수 있겠지만, 일을 할 때 ‘그래서 내가 진짜 하고 싶은게 (해야 하는게) 무엇이었을까?’ 를 고민한다.

그래서 사실 TDD 의 작업 순서와 할일 목록을 작성하는 것에 깊은 인상을 받았었다. 특히 TDD 같은 경우 눈에 보이는 명확한 pass/fail 을 마주하고 pass 하기 위한 최적의 방법을 고민하기 때문이었다. 다시 말해 군더더기 없는 결과물을 만든다는 게 인상 깊었다. 다시 생각해보면 기본적인 것이지만 깊이 빠져들면 온갖 걱정거리가 들러붙어 정말 내가 하고 싶었던 것은 무엇이었는지 방향을 잃어버리고는 했기 때문이다.

문장에서 말하는 것은 전체적인 방향성에 대한 내용을 담고 있지만, 어쨌든 목표와 관련 없는 것들은 다 낭비라고 생각 한다.

하루에 한 번 이상 곱씹는 말이 있다. ‘할 수 있을 때, 할 수 있는 것을, 할 수 있는 만큼 하자.’ 여기에 낭비를 만들지 말자는 살을 붙여야겠다.

“XP 는 개발을 이끌기 위한 다섯 가지 가치를 포용한다. 그것들은 의사소통, 단순성, 피드백, 용기, 존중이다.”

 

의사소통

“누군가는 이미 그 문제의 해결책을 알고 있는 경우가 정말 많다.”

해를 거듭 하면서 경험은 무시하지 못한다는 것을 점점 많이 느끼고 있다. ‘아는 사람의 한 마디가 많은 시간을 절약 해준다.’ 는 것을 믿는다. 한편으론 혼자서 충분히 고민 해 볼 시간도 필요하다는 입장이기 때문에, 후배 개발자를 만나면 습관적으로 ‘잘 안풀리면 1~2시간 정도는 고민할 수 있지만. 그래도 모르겠으면 그건 진짜 모르는 것일 수 있으니까 고민하면서 고통 받지 말고 물어보라’ 는 말이다. 그렇다고 해서 내가 명쾌한 답을 바로 줄 수 있는 것은 또 모르지만 적어도 같은 문제를 고민하는 사람이 있다는 사실 만으로도 심리적 위로가 될 수 있다고 생각한다.

 

단순성

또 다시 EJB 와 Spring 이 생각 났다. 책에서 얘기하는 단순성도 어떻게 보면 군더더기 없이 현재 할 수 있는 가장 단순한 방법을 말하는 것으로, 결코 단순한 결과가 아닐지언정 주어진 상황에 할 수 있는 가장 단순한 것을 말하는 것 같다.

 

피드백

“경험해 보기 전에 정해진 방향은 특히 수명이 짧다.”

“한번에 완벽하게 해결하기를 바라는 것보다 점진적 개선에 만족하기 때문에 우리는 피드백을 이용해 목표에 점점 더 가까이 다가간다.”

 

용기

저자가, 아니면 옮긴이가 이 내용을 서술할 때 조금 산만했을까 싶은 생각이 들었다.

문단의 말미에는 문장들 사이에 개연성이 있어 보인다기 보다, 설명 할 수 있는 생각나는 말들을 나열한 것 같은 느낌을 받았다. 문단이 뚝뚝 끊어지는 듯한..

저자가 생각하는 용기라는 것은 “문제가 무엇인지 안다면, 그것에 대해 무슨 일이든 해보는 것” 에 대한 모든 종류의 것을 말하는 듯하다. 심지어 문제에 맞서기 위해 출근하는 것도 하나의 용기라고 할 수 있겠다.

 

존중

“나도 중요하나 사람이고 당신도 중요한 사람이다.”

 

다른 가치들

“팀이 신봉하는 가치에 팀의 행동이 어울리도록 만드는 것이다.”

내가 속한 팀이 추구하는 가치는 무엇일까?

“제일 중요한 것은 팀이 신봉하는 가치에 팀의 행동이 어울리도록 만드는 것이다. 그렇게 하면 여러 가치 집합을 동시에 유지하려고 노력할 때 생기는 낭비를 최소로 줄일 수 있다.”

XP 는 개인보다는 팀의 방향성에 더 많은 비중을 두는 것 같다. 그렇다고 개인을 무시하지 않고, 건강한 개인이 모여 단단한 팀을 구성하는 느낌이다.

이 부분에서 특히 ‘노력할 때 생기는 낭비’ 라는 구가 눈에 들어왔다. 앞서 낭비란 ‘내가 가치 있게 생각하는 것과 정말로 가치 있는 것 사이의 차이에서 발생’ 한다고 했다. 크게 봤을 때 팀의 방향성, 작게 봤을 때 당장 내가 오늘 할 일에 대해 생각해 보았다. 팀이 나아가는 방향 (로드맵) 과 다른 방향성을 가지거나, 오늘 할 일을 달성하지 못하는 일들을 하는 것은 명백하게 낭비를 생산하는 일이라는 것을 머리로는 알고 있었지만 글로 정리하는 것은 처음이다.

‘가치는 소프트웨어를 개발할 때 무엇을 해야 하는지 구체적으로 충고해 주지는 않는다.”

금잔화 예시와 함께 가치, 원칙 그리고 실천 방법에 대해 조금 더 구체적으로 이해할 수 있는 말이었다. 가치는 순수하고 고결하여 더럽혀지지 않고 지켜져야 하는 것으로, 이 목적을 달성하기 위해 할 수 있는 모든 행동 양식이 실천 방법에 속한다고 이해 했다. 그리고 원칙은 오랜 경험을 통해 도출해낸, 어떻게 보며 절대 불변의 진리와 같은, 지침과도 같다고 이해했다.

한편으론 실천 방법과 원칙이 ‘가치를 지키기 위해 마땅히 해야 하는 것’ 이라는 공통점을 가지고 있다고 느껴져서 이해 하기에 어려움이 있겠다고 생각 했다.

 

 

 

 

728x90
728x90

 

“변화를 극복하지 못하는 우리의 무능력이 문제다.”

변화에 유연하게 대응할 수 있는 설계를 하고 애플리케이션을 만들어야 한다는 것에 대해서는 그렇게 고민과 노력을 하면서 왜 큰 의미의 변화에 대해서는 인지하지 못했을까? 변화에 유연하게 대응하는 애플리케이션을 만들려는 것처럼 왜 나 자신에 대해서는, 내가 속한 팀에 대해서는 유연하게 대응할 수 있도록 준비할 생각을 하지 못했을까?

 

“실천사항 하나하나가 효율성, 의사소통, 자신감, 생산성을 개선하는 실험이다.”

‘실험’ 이라는 말을 사용한 것이 조금씩 방향을 고치면서 간다는 것의 연장선에 놓여있다고 생각 했다.

 

“실천방법, 즉 우리가 실제로 하는 것들이라고 부르기로 하자. 실천방법은 여러분이 매일 하는 일이다.”

책에서는 실천방법을 실제로 우리가 하는 것들이라고 했다.

일을 할 때 자신만의 루틴이 있는지 궁금

 

“내가 가지치기를 제대로 할 수 있는 능력을 자랑스러워하는 동안, 폴은 그 나무를 이 정원에서 뽑아버리는 편이 더 낫다는 것을 느낄 수 있다.”

가끔 하나에 몰두하다 보면 나도 모르는 사이에 숲 속으로 깊이 들어가는 경우가 있다. 타래를 하나씩 풀어나가다 보면 스스로 뿌듯함과 만족감이 차오르기도 하는데, 사실 그 일을 하는 본질을 알고 나서는 전부 지우는 게 낫다고 생각할 때가 있다. 조금 다른 얘기일 수 있지만, 숲 속을 헤매는 나를 꺼내주는 것은 건강한 통찰을 가진 동료의 리뷰라는 생각을 했다.

 

“가치는 우리가 보고, 생각하고, 실행하는 것을 판단하기 위해 사용하는 큰 규모의 척도다.”

 

“가치는 실천 방법에 목적을 부여한다.”

 

“내가 금잔화를 딸기 옆에 심어야 한다는 지식을 알지도 모른다. 하지만 폴은 인접한 식물이 서로 약점을 보완해야 한다는 ‘같이 심기companion planting’의 원칙을 이해하고 있다.”

수학에서 공식을 암기하는 것과 유사하다고 생각 했다. 공식을 암기하면 문제 풀이에 적용해서 손쉽게 답을 도출할 수 있지만, 근본적인 내용을 알고 공식을 유도할 줄 안다면(그 공식의 가치를 이해한다면) 정원사 폴과 같은 고도로 발달된 감각을 지녔다고 할 수 있겠다고 생각 했다.

 

 

 

 

728x90
728x90

 

xp 는 ~ 이다. 라는 말을 많이 하면서 설명 하는 것으로 보아 xp 라는 것은 간결한 한 문장으로 정의하기엔 내포하고 있는 이야기가 많다고 느꼈다.

 

"어떤 사람들에게는 이렇게 하는 것이 믿을 수 없을 만큼 두려운 일이겠지만, 다른 사람들에게는 그저 일상일 뿐이다."

다른 사람들은 좋다고 많이들 사용 하는데, 굳이 사용하지 않아도 괜찮다는 생각으로 새로운 것을 받아들임에 주저하는 경우가 있었다. 막연하게 새롭다라는 것에 거부감이었을 수도 있고, 시도하기엔 현재 문제가 없었기 때문이었을 수도 있다. 혹은 불편하지 않았다거나. 관점을 달리 하면, 불편하지 않았던 것이지 편한것은 아니었다. 이 문장을 보고, xp 를 적용할지는 둘쨰 치고, 보다 열린 마음으로 이해해보겠다고 다짐 했다.

 

"XP는 가볍다"

Spring 프레임워크가 생각 났다. 경량 프레임워크라고 했지만 사실 가볍지 않았다. 하지만 경량이라고 부르는 근거는 군더더기가 없다는 것이었다. TDD 에서도 목적을 명확하게 하여 필요한 코드만을 작성하는 느낌을 받았는데, 베스트 프랙티스라고 하는 것들에 대한 공통점이라고 생각 했다.

 

"하지만 최선을 다해 프로그램을 작성했는데도 사람들이 그 프로그램을 좋아하지 않는다면, 나는 여전히 자신에 대해 만족감을 느낄 수 있다. 이런 태도를 취한다면 상황이 어떻든 안전함을 느낄 수 있다. 내가 어떻게 느끼는지가 내가 최선을 다했느냐 아니냐에 달려있다면, 최선을 다하기만 한다면 언제나 자신에 대해 만족감을 느낄 수 있기 때문이다."

정말 나 스스로 만족으로 괜찮을까? 얼마전 요리 프로그램에서 어떤 게스트가 한 말이 생각났다. 만약 입맛에 맞지 않으면 어떡하냐는 질문에, 요리사는 ‘최선을 다했습니다’ 라고 대답 했다. 그러자 게스트는 어처구니 없다는 듯이, 식당에 가서 돈주고 밥을 먹었는데 맛이 없어서 뭐라고 하니 최선을 다했다고 하는게 말이 되냐는 것이었다. 지나가는 우스갯소리였지만 그 요리사는 인상 찌푸린 고객의 얼굴을 보고서도 ‘나는 최선을 다했으니까’ 라고 위로 받을 수 있을지에 대해 생각 해보며 나의 상황에 대입해 보았다.

 

"자신이 왜 소프트웨어 개발을 하게 되었고, 어떻게 이 일에서 만족을 찾을 것인지 더 깊이 이해하게 되기를 바란다."

 

XP 에서 말하는 실패라는 것은 무엇일까

 

 

 

 

728x90
728x90

 

기억에 남는 내용

- 익스트림 프로그래밍 Extreme Programming, XP 의 목표는 뛰어난 소프트웨어 개발이다.
- 처음 이 책이 출판될 때에는 극단적으로 보이던 실천방법들이 이제는 일반적인 것이 되었다. 앞으로 5년 후라면 이 책에 들어 있는 실천방법들은 분명히 보수적으로 보일 것이다.
- 여러분들의 비결 목록에 넣을 만한 검증된 실천방법들을 제시한다.
    - 지금 상황과 상관없이 여러분은 언제나 더 나아질 수 있다.
    - 더 나아지는 일은 언제나 스스로부터 시작할 수 있다.
    - 더 나아지는 일은 언제나 오늘부터 시작할 수 있다.

 


 

후기

극단적이게 보이던 것들이 시간이 지나 보수적으로 보인다는 말에 공감했다.

모든 창의적인 것은 시간이 지나면 식상해지기 마련이고, 지금의 번뜩이는 아이디어는 시간이 지나면 당연한 것이 된다고 생각하기 때문이다.

당장 생각나는건 스마트폰이 그랬고 카카오톡이 그랬다.

 

그런 관점에서 극단적이라는 실천방법이 긍정적인 효과를 가져온다면, 그게 새로운 문화가 되고 당연하다 못해 마땅해 해야하는 것이 되기 때문에 결국 보수적이 된다.

그러면 또 새로운 극단적인 실천 방법이 유행을 탈거라 생각 한다.

마치 사무실이 아닌 집에서 일은 한다는 것을 상상할 수 없었는데, 이제는 당연히 할 수 있는게 된 것처럼 말이다.

 

책의 서문에서 가장 놀랐던 내용은 XP 가 어느 한 개인의 연구라는 사실이다.

 

 

 

 

728x90
728x90

 

기억에 남는 내용

- 최초에 탄탄한 설계를 갖추어도 어차피 시간이 프르면 각종 요구사항의 증가와 변화로 프로그램에 기능을 추가하거나 수정하기 마련

- 리팩토링은 수년간의 경험을 통해 발견한 구체적인 소프트웨어 개선 방법들의 공통 해결책을 발견해 일반화한 추상 개념이다.

- 리팩토링은 기존의 소스코드를 가독성 readability, 재활용 reusability, 체계적 구조 well-structured 측면에서 개선하는 총괄 작업을 뜻한다.

 


 

후기

여기까지만 보더라도 리팩토링이 왜 해야하는 활동인지 어느정도 이해한것 같다.

옮긴이의 말을 보면서 한가지 걱정되는 부분이 생겼다.

내용은 어떨지 봐야 알겠지만, 이분의 문장 호흡이 긴 편이라고 느꼈다.

문장이 길면 한 문장을 온전히 이해하는데 아무래도 시간이 더 필요하다.

 

가볍게 읽히기를 바라는 것은 아니지만, 저자의 의도가 안전하게 전달될지 조금 걱정된다.

 

 

 

 

728x90

'생각을 적바림 > 리팩토링' 카테고리의 다른 글

001 리팩토링 '서문'  (1) 2024.01.18
728x90

 

기억에 남는 내용

- XP 실천방법 가운데 일부를 우리는 아래와 같이 적용합니다. -애리히 감마

 

    - 초기에, 자주, 자동화해서 테스트하라.
    최신 빌드에서는 녹색 체크 표시를 받으려면 테스트를 21,000개 이상 통과해야 합니다.


    - 점진적 설계
     우리는 매일 설계에 일정 자원을 투자합니다. 하지만 우리에게는 API를 안정되게 유지해야 한다는 추가 제약이 있습니다.


    - 매일 배치 deploy
     컴포넌트마다 적어도 하루에 한 번은 배치하고, 즉각 피드백을 받고 문제도 초기에 잡기 위해 배치된 코드 위에서 개발을 진행합니다.


    - 고객 참여
     적극적인데다 지속적으로 피드백을 보내주는 활발한 사용자 공통체가 있다는 점에서 우리는 운이 좋습니다. 우리는 그들에게 귀를 기울이고 최대한 빨리 피드백 하려고 노력합니다.


    - 끊임없는 통합
     최신 코드가 매일 밤 빌드됩니다. 매일 밤 빌드는 컴포넌트간 통합에 대한 통찰력을 제공해줍니다. 일주일에 한 버너 우리는 모든 컴포넌트가 잘 통합되는지 확인하려고 통합 빌드를 수행합니다.


    - 짧은 개발 주기
     비록 우리 주기가 XP가 권장하는 1주일 주기보다 길긴 하지만, 그 목적은 동일합니다. 우리의 6주 주기는 마일스톤 빌드로 끝나는데, 이것이 우리 프로젝트의 심장 박동 역할을 합니다. 모든 마일스톤 빌드의 목적은 진전 상황을 보여주고(이것 때문에 우리는 정직해질 수밖에 없습니다) 우리 공동체가 실제로 사용할 수 있 피드백을 내놓을 수 있는 정도로 수준 높은 제품을 전달하는 것입니다. (이것 때문에 우리는 훨씬 정직해질 수밖에 없습니다.)


    - 점진적 계획
     릴리즈를 하고 나면 배아 단계의 전반적인 계획을 만들고 그걸 릴리즈 주기를 통틀어 진화시켜 나갑니다. 이 계획은 사용자 공동체도 대화에 참여할 수 있도록 우리 웹 사이트에 일찍 올라갑니다. 마일스톤들은 예외인데, 이것들은 우리 프로젝트의 심장 박동 역할을 하기 때문에 최초의 계획 반복에 고정되어 있습니다.

 


 

후기

1판과 비교했을 때 2판이 완전히 새롭게 써졌다고 해서 1판도 찾아서 봐야하나 싶다.

아직은 XP 라는 것에 대해 알지 못하지만, 추천사를 쓰신 '에리히 감마' 님이 적용중이라는 XP 실천 방법에 대해 책을 끝까지 본 다음 다시 되돌아 보려고 한다.

다양한 실천 방법들이 있는것 같은데, 그 중에서 고른 실천 방법이기 때문에 조금 더 관심을 가져보기 위함이다.

 

내용을 완전히 이해 했다고 하더라도 책에 실린 XP 실천 방법 모두를 적용 할 수는 없을 것 같다.

다양한 실천 방법 중 내가 처한 현실에 적합한 방법들을 골라서 상황에 최적화 된 우리 팀만의 XP 를 해보고 싶다.

 

 

 

 

728x90

+ Recent posts