[익스트림 프로그래밍] 1부 5장 원칙
인간성
현대에 나와 있는 개발론들은 인간의 약점을 인정하지 않은채 강점 만을 내세우며 이상만을 따지는 경우가 많다. 이런 비인간적인 프로세스는 팀의 관계를 해친다. 높은 이직률은 많은 비용과 업무 중단을 초래하며, 사람의 창조럭을 발휘할 기회도 놓치게 만든다.
- 기본적인 안전 - 배고픔, 물리적 상해, 사랑하는 사람에 대한 위협에서 자유로워야 한다. 실직에 대한 두려움은 이 욕구를 위협한다.
- 성취감 - 자신이 속한 사회에 기여할 수 있는 기회와 능력
- 소속감 - 어떤 집단에 자신이 속함을 느끼고, 그 집단에서 자신의 존재 이유와 책임감을 끌어내며, 그 집단 구성원들이 공유하는 목표에 기여할 수 있는 능력
- 성장 - 자신의 기술과 시야를 확장할 수 있는 기회
- 친밀감 - 다른 사람을 깊게 이해하고 다른 사람들에게도 깊이 이해 받을 수 있는 능력
비즈니스 욕구와 개인적 욕구
XP의 실천 방법은 이러한 욕구들을 모두 채울 수 있다. 팀외에서 개인적 욕구를 채울 수 있다면 이러한 좋은 영향은 비즈니스 욕구에서도 좋은 결과를 나을 것이다. XP를 지속적을 실천한다면 팀 구성원들 간 신뢰를 쌓은 후 함께 일하는 것의 결과로 자신에게 더욱 충실해질 자유가 생긴다는 것을 깨달을 수 있다.
하지만 신뢰를 쌓기 위해 너무 사적인, 개인적인 이야기는 하지말자. 이런 이야기를 듣고 좋아해줄 사람은 몇 없다.
경제성
경제성을 인정하지 않는 소프트웨어 개발은 '기술적 성공'이라는 공허한 승리만 얻을 위험이 있다.
하는 일에 빚니스 가치를 지니고, 그 목표에 부합하며, 비즈니스 필요를 충족하는 지 확실하자. 프로젝트에서 우선순위가 가장 높은 비즈니스적 필요부터 해결한다면, 그 프로젝트의 가치는 극대화된다.
돈의 시간적 가치, 그리고 시스템과 팀의 선택적 가치가 소프트웨어 개발에 영향을 주는 경제성의 두 측면이다.
돈의 시간적 가치란, 오늘의 천원이 내일의 천 원보다 가치가 있다는 것이다. 돈은 더 일찍 벌어들이고 비용은 최대한 늦게 지불하는 소프트웨어 개발은 가치가 더 있다.
점진적 설계 실천 방법에서는 돈 쓰는 일을 미루기 위한 노력의 일환으로, 명시적으로 설게에 대한 투자를 끝내 해야만 하는 순간 last responsible moment까지 미룬다. 사용한 만큼 비용을 지불하는 실천방법pay-per-use, PPU은 어떤 기능이 배치되자 마자 그것에서 수익을 실현시켜낼 수 있느 방법을 제공한다.
시스템과 팀의 선택적 가치는 미래의 선택사항을 늘리는 데 오는 가치다. 리팩터링 같은데 사용되는 시간을 말하는걸까?
꼭 필요하지 않은 유연성에는 투자하지 않는 방법으로 돈의 시간적 가치에 신경 쓰면서도 동시에 소프트웨어와 팀 둘 다의 선택적 가치를 높이려는 의도가 있다.
상호 이익
모든 활동은 그에 관련된 사람에게 이익이 되어야 한다. 시간이 급박할 수록 한 쪽에게 이득이 되면 다른 한 쪽은 손해를 입는 방법을 택하기 쉬운데 장기적으로 따지면 손해다. 이러한 해결책을 사용했을 때 생겨나는 편치 않은 감정들은 팀원간의 신뢰를 손상 준다.(모두에게 도움이 되는 방안이라는게 세상에 있을까..?)
예) 소프트웨어 내부 설명 문서를 대량으로 작성하는 것이 예다. 장래 누군지 알지도 모르는 사람이 코드를 유지보수할 수 있지 모르니 그것을 쉽게 해주기 위해서 지금 내 개발 속도를 현저하게 떨어드리라는 뜻이다. 그 사람에겐 이익이 될 수 있지만 현재의 이익은 없다.
- 더 나은 설계와 구현을 하도록 도와주는 자동화된 테스트를 작성한다.
- 우발적 복잡성 제거 위해 신중한 리팩터링을 진행.
- 일관성 있고 명시적인 메타포 집합에서 네이밍을 한다.
의견을 제안했을 때 다른 사람들이 수용하기 원한다면, 그것이 야기하는 문제의 수보다 그것이 해결해 주는 문제의 수가 더 많아야 한다.
자기유사성
세상엔 유사한 모델들이 많으니 한 부분에서 좋은 결과를 보였던 행위는 비슷한 모델에서도 유효할 가능성이 높다. 테스트 주도 개발을 예로 드는데 이러한 방식이 유효할 경우가 많을 수 있다 한다.
개선
완벽은 없다, 완벽해지려 노력할 뿐
'최선은 차선의 적'이란 말은 완벽을 기다리는 것보다 평범한 것이라도 있는 게 낫다는 뜻이다. 이 표현은 XP의 요점을 놓치고 있다. XP란 개선을 통해 탁월한 소프트웨어 개발에 도달하는 것이다. XP의 주기는 오늘할 수 있는 최선을 다하고 내일 더 잘하기 위해 깨달음과 이해를 구하려 노력하는 것이다. 점진적 발전, 개발이다.
발전된 기술은 소모적 노력을 제거하려 하지만, 개발 조직에서 끊임없이 심해지는 완고성과 사회적 구조의 분화는 점점 더 소모적이 되어 간다. 개선의 열쇠는 이 둘을 조화시키는 것. 완벽해질 때까지 기다리지 말고 개선을 실천하라. 어떤 것부터 시작하면 좋을 지 찾아보고, 일단 시작한 다음 거기서 부터 차츰 개선하도록 한다.
다양성
구성원들이 다 비슷비슷한 사람이라면 같이 지내기는 편아해도 개발에는 효과적이지 않다. 문젯거리와 함정들을 발견하려면, 문젯거리들을 해결할 방법을 여러 가지 생각해내려면 , 생각해낸 해결책드을 실제로 구현하려면, 팀안에 다양한 종류의 기술, 사고방식, 시야들이 모여 있어야 한다. 즉 팀에 다양성이 필요하다. 물론 이에는 갈등도 따라온다. 감정싸움 같은게 아닌 "이걸 해결하기 위한 방법은 두 가지야" 가은 종류의 갈등이다. 어떤 설계에 대한 생각이 두 가지 나왔다면, 이것은 문제가 아니라 기회다. '다양성'의 원칙은 프로그래머가 문제를 해결하기 위해 협동할 것과, 두 의견을 모두 존중할 것을 권한다.
갈등이 없는 팀은 없다. 관건은 갈등을 생산적으로 풀 수 있는가다. 다른 사람을 존중하면서 자신에 충실하다면 스트레스가 쌓이는 상황에서도 원활한 의사소통을 할 수 있다.
다양성이란 원칙은 전체 팀이란 실천방안으로 표현되는데 이것은 다양한 기술과 시야를 지닌 사람들을 끌어 모아 팀을 만들라는 실천방법이다. 다양한 계획 주기 역시 다른 시야를 지닌 사람들이 정해진 시간 내에 가장 값진 소프트웨어를 만드는 목적을 가지고 사오 작용할 수 있도록 장려한다.
반성
좋은 팀은 그저 일만 하지 않고, 어떻게 일하는지 왜 일하는지도 생각한다. 그들은 자신들이 왜 성공했으며 왜 실패햇는지 분석한다. 좋은 팀은 실수를 숨기려 하지 않고 오히려 실수를 드러내어 거기에서 배운다. 분기별 주기와 일주일별 주기에는 짝 프로그래밍과 지속적인 통합 뿐 아니라 팀 반성의 시간도 포함된다. 배움이란 행동이 반성을 거친 것이다.
흐름
소프트웨어 개발에서 흐름이란, 개발의 모든 단계를 동시에 작업함으로 가치 있는 소프트웨어를 흐르듯이 끊임 없이 제공하는 것이다.
이에 관한 원칙으로 일일 빌드, 배치가 있다. 만약 흐름에서 떠나게 될때마다 반드시 다시 돌아오겠다고 결심해야 한다.
기회
가끔은 생각을 전환해서 문제를 기회로 보는 방법을 배우자.
문제를 기회로 전환할 기회는 개발 과정 곳곳에서 생긴다. 장기 계획을 정확하게 짜기가 어렵다면 분기별 주기를 실천하고 주기 안에서 장기 계획을 가다듬으면 된다. 혼자 일할 때 실수가 많다면 짝 프로그래밍을 해라.
잉여
잉어킹. 개발에서 핵심적이면서도 해결하기 어려운 문제에는 해결방법을 여러 개 마련해 놓아야 한다. 그러면 방법 중 하나가 완전히 실패하더라도 다른 것들 덕에 재앙을 면할 수 있다. 소프트웨어의 결함은 신뢰를 훼손한다. 그런데 신뢰는 자원의 허비를 막기에 가장 좋은 수단이다. 결함은 핵심적이면서도 해결하기 어려운 문제다. 따라서 XP에는 결함 문제를 다루는 실천방법이 여러 개 들어 있다. 짝 프로그래밍, 지속적인 통합, 함께 앉기, 진짜 고객의 참여, 매일 배치가 그 예다. 우리가 할 수 있는 것은 팀 안에서 신뢰를 지탱하고 고객과도 신뢰를 유지할 정도까지 결함의 수를 억제하는 것 뿐. 잉여를 만들려면 자원이 소모되긴 한다. 그래도 정당한 목적이 있는 잉여를 제거하지 않도록 조심해야 한다. 개발 종료된 다음에 하는 테스트 단계는 분명 잉여다. 그렇더라도 결함이 하나도 발견되지 않는 성공적 배치가 실전에서 여러 번 연속되어 이것이 진짜로 잉여적인 것으로 판명나기 전까지는 그만두면 안된다.
실패
어떠한 방법이 옳을지 판단이 안될때는 일단 시도하고 실패해라.
품질
품질을 내린다고 개발속도가 증가하는 경우는 흔하지 않다. 품질을 올렸을 때 오히려 개발속도가 나아지는 경우가 있었다.
품질이 향상될 수록 생산성이나 효율성 같은 다른 바람직한 프로제그의 속성들도 개선되었다.
아기 발걸음
변화는 안정을 뒤흔든다. 사람들이 변할 수 있는 속도에는 한계가 있다. 단계를 잘게 쪼갤 때 생기는 부하가 , 큰 변화를 시도했다가 실패해서 다시 원상태로 돌아갈 때 드는 낭비보다 훨씬 작다는 사실을 인정하는것이다.
받아들인 책임
책임감은 책임질 마음이 있는 사람이 받아들일 수 있는 것이다.
내용들이 아직까지 추상적인 느낌이 강하다 다음 장에서 등장하는 실천방법들이 기대된다. 나는 생각보다 사람과의 관계를 외시한 것 같다는 생각이 든다. 이 책은 좋은 책이다. 완벽히 모든 프로젝트에 적용하긴 힘들겠지만 납득가능 이야기들이 많다.