- “우리는 익스트림하니까 문서 같은 거 작성 안 해” 라고 호전적으로 말하는 것은 의사소통에 대한 경멸일 뿐이지 의사소통을 가치로 포용하는 행동이 아니다.- 우리의 목표는 성공적이고 만족을 주는 인간관계와 프로젝트이지, XP 클럽 회원이 되는 게 아니다.- 어떤 문제에 수많은 사람을 투입할 수 있다고 해서 그것이 그 문제를 푸는 가장 수익성 높은 방법이라는 뜻은 아니다.- 극적인 개선이 없다면, 소프트웨어 세계 시장은 제조업과 생명공학 분야에서 더 매력적인 투자처가 발견 됨에 따라 정체하게 될 것이다.
- 모든 단계에서 쓸모없이 낭비되는 노력을 제거한다.- 모든 사람이 품질에 책임을 진다는 뜻이다.- 별도의 품질 조직은 없다.- 만약 어떤 물건을 만들었는데 그것을 팔지 못하면, 그 물건을 만드는 데 들어간 노력은 사라져 버린다.- XP 가 문제를 해결해 주는 것이 아니다.- 물 속에 들어가는 단 하나의 올바른 방법 같은 것은 없다.- 조직이 다운사이징할 때 해고되는 팀은 XP 팀이다. 그 까닭은 다른 팀이 더 ‘헌신’ 한 듯 보였기 때문이다.- 스스로 시도하고 싶지 않은 일을 다른 사람이 하기를 기대하는 것은 무례할뿐더러 효과도 없다.- 먼저 자신을 변화시킨 다음, 그 변화의 열매를 다른 사람들에게 제공하라.- 어떤 말의 의미를 이해했다고 정말 그것을 이해했다고 할 수는 없다.나만 잘하면 전체가 나아지..
- 듣는 사람이 더 쉽게 이해할 수 있도록 아이디어를 그것이 만들어진 상황과 함께 전달하는 기능을 한다. 다음은 XP의 시작에 대한 내 이야기다. - 컨설팅에서 정말 자주 생기는 일이지만, 의뢰인은 이미 답을 알고 있다. 컨설턴트로서 내가 할 일 가운데 하나는 답을 아는 사람을 찾아 그 답을 권력 있는 사람에게 전달하는 일이다. - 면담을 계속 하면서, 면담을 한 번 할 때마다 나는 프로젝트 구조에 익숙해졌고, 그때마다 내 착상에 세부사항을 조금씩 더해갔다. - 말을 하면서 자체적으로 정리되는 경우를 경험해봐서 그런지 공감 되었다. - 하루가 끝날 때가 되자, 나는 XP 의 기본 틀을 잡았다. - XP 의 기본 틀이라는 게 무었일까? -> 고객이 고른 기능들이 정해진 심장박동에 따라 추가..
- 열세 팀을 하나로 통합하고, 아키텍처와 룩 앤 필을 통일하기 위해 XP 를 도입 했다.- XP 를 도입하고 결함율 감소와 생산성 증가를 경험 했다.- 완전히 XP 로 진행한 프로젝트에는 결함이 거의 없었다.- XP 적용에 대한 팀원들의 초기 반응은 다양했는데, 일부는 끝까지 XP 를 받아들이지 않았다.- XP 도입을 권장한다. 기능 단위로 계획을 세우고, 반복적인 계획과 릴리즈를 제안 한다.- 브래드 옌슨이 하고 싶은 말 - XP 도입이 결함 감소와 생산성 증가에 기여 한다. - XP 도입은 어렵지만 그만큼 효과가 크다. - 기능 단위로 계획하고 반복적인 릴리즈가 중요하다.
- 분할 후 정복 전략 대신 쓰는 정복 후 분할 전략이다.- 맹목적으로 적용한다면 반드시 회계에 왜곡이 생길 수밖에 없다.- 프로젝트 관리자는 정보를 조직이 흡수할 수 있는 형식으로 보여주어야 한다.- 풀 문제에 걸맞지 않게 시스템이 너무 크고 복잡하게 자라나는 경우도 생긴다.- 실천방법들은 현재 상황에 맞도록 수정할 수 있다.---XP 는 단순히 소규모 팀에만 적용되는 것이 아니고 다양한 환경과 조건에서도 성공적으로 적용해서 사용할 수 있겠다. XP 에서 얘기하는 의사소통, 피드백, 단순성, 용기, 존중 등은 팀의 규모와 무관하게 적용할 수 있다. 그리고 이를 통해 보편적으로 크다고 할 수 있는 팀에서 효과적인 소프트웨어 개발을 할 수 있겠다는 것도 재밌었다.100명 규모의 팀에서 매주 한 번 회의로 ..
- 설계란 상생 관계를 가진 요소들의 시스템→ 설계란, 시스템을 이루는 각각의 요소들이 단독으로 존재하지 않고 서로 관계를 맺으며 상호작용함으로써, 이 관계가 각 요소를 강화하여 홀로 있을 때보다 더 큰 힘을 발휘하게 하고, 시스템 전체를 개별 요소들로만 이해하는 것을 넘어서는 복잡하고 유기적인 구조로 만들어주는 과정을 포함하는 것.→ 설계란, 상호 강화 관계를 맺는 요소들이 모여 개별 이해를 넘어서는 시스템을 만드는 것이다.- 딱 피드백을 얻을 정도만 설계하고, 얻은 피드백을 이용해서 그 다음 피드백을 얻을 정도까지만 설계를 개선하기 위해서는 좋은 솜씨가 필요하다.- 문제는 설계를 하느냐 마느냐가 아니라 언제 설계를 하느냐다.- 설계 품질이 성공을 보장하지는 않지만, 설계 실패는 분명히 실패를 보장한다..
- 현실과 동떨어진 계획은 사람들 사이의 관계가 불명확하고 균형 잡히지 않았다는 사실을 드러낸다. → 현실과 동떨어진 계획으로부터 인간관계까지 유추할 수 있겠다는 것을 깨달았다. 그 역은 성립하지 않겠지만, 보통의 경우 대우는 성립하겠다고 생각 했다. - 프로젝트 관리의 세 가지 변수. 속도, 품질, 가격.- 제품의 품질을 낮춘다고 해서 해야 할 일이 줄어들지 않는다는 말에 공감 했다. 비슷하게 투입 된 인원이 많다고 해서 속도가 무한정 빨라지지 않는다.- 창조적인 일에서는 책상에 붙어 보내는 시간의 증가가 곧 생산성 증가를 뜻하지 않는다. → 통찰력 싸움이라는 말이 다시 한 번 생각 났다.
- 전체 시스템의 처리 능력을 키우려면 - 가능한 한 최대 속도로 가동 - 제약 지점의 성능 향상 - 제약 지점의 작업량 일부를 비제약 지점으로 덜기 - 제약 지점을 완전히 제거- 병목을 찾으려면 어디에 작업이 쌓이는지 보아야 한다.- XP 를 적용할 때에는 임원의 후원을 받고 팀 바깥 사람들과 튼튼한 관계를 맺는 것이 핵심- 보통의 경우 해왔던 업무 관성과 익숙함 때문에 병목지점을 잘 느끼지 못하는 것 같다. 거시적인 관점에서 어느 부분에 병목이 생기는지 꾸준한 관찰과 통찰이 필요하다고 느꼈다. 개발은 통찰력 싸움이라는 것을 봤었는데, 개발 뿐만 아니라 모든 일의 근본적인 해결책을 도출해내기 위해서는 필요한 능력이라고 생각 했다. 통찰력을 키우기 위해서는 경험도 중요하지만 경험을 ..
저자는 ‘효율적인 소프트웨어 개발이 이루어지려면 많은 사람의 시각을 반영해야 한다.’ 고 챕터를 열었다. 동시에 ‘기본 실천방법’ 에서 다룬 ‘전체 팀’ 을 언급 했는데, 내가 이해하고 있는 ‘전체 팀’과 다른 의미를 가지고 있었다.‘전체 팀’ 은 ‘프로젝트가 성공하기 위해 필요한 기술과 시야를 지닌 사람들을 전부 팀에 포함시켜라.’ 는 것은 많은 사람의 시각을 반영 하는 것과는 분명한 차이가 있다고 생각하기 때문이다.TDD 에서 부터 느낀 전체적인 큰 맥락은 ‘불필요한 군더더기를 제거한다.’ 는 것이다. 효율적인 부분을 취하려면 군더더기가 없어야 한다. 효율적이기 위해 많은 사람의 시각을 반영 한다면, 필요한 기술과 시야를 가지고 있지 않더라도 팀에 포함 시켜야 한다.필요한 기술적 시야를 가지고 있지 ..
진짜 고객 참여- 필요를 느끼는 사람들을 그 필요를 채워줄 수 있는 사람들과 직접 연결 시켜 노력의 낭비를 없애는 것이다.- 정확한 추정과 낮은 결함 비율근본 원인 분석- 같은 실수를 저지르지 않도록 하는 것이다.- 왜 이 결함이 생겼는지, 왜 결함이 이전에 잡히지 않았는지 알아낸다.- 결함의 중심부에는 사람 문제가 놓여 있다는 것을 알게 된다. (거의 언제나 사람 문제다.)코드 공유- 짝 프로그래밍은 팀 동료들이 서로에게 품질에 대한 자신의 헌신을 보여주고 좋은 품질을 구성하는 것이 무엇인가에 대한 서로의 기대치를 통일시키는 일에 도움이 된다.코드와 테스트- 다른 문서들은 코드와 테스트에서 생성되도록 한다.- 소프트웨어 개발에서 가치 있는 결정은 무엇을 할 것인가, 무엇은 하지 않을 것인가, 우리가 하..