린 소프트웨어 개발 - 애자일 실천 도구 22가지
메리 포펜딕.톰 포펜딕 지음, 김정민.김창준 외 옮김
인사이트 | 2007-09-07 | ISBN 8991268099
( 3.5 / 2 )
내서재담기리뷰쓰기가격비교

p.277
hey 린 원칙은 많은 실행을 통해 시도되고 증명되었음을 보증한다. 또한 적절히 활용하면, 소프트웨어 개발에 효과적임을 보증한다. 적절히 활용한다는 말은 모든 린 원칙을 사용하고, 그것을 환경에 적합한 애자일 실천방법으로 변환하는 데 사고 도구thinking tool를 사용한다는 의미이다. 실천방법을 타 학문이나 다른 영역에서 별 생각 없이 직접적으로 가져 왔거나, 혹은 팀에게 권한을 위임하라는 원칙과 통합성을 구축하라는 원칙이 무시되었을 경우에는 이 제품보증서는 무효이다. 2007-10-27   (0)

p.274
hey 사람들은 자신의 업무 영역에서 무엇이 잘못되고 있으며 그것을 어떻게 고치는지는 보통 알고 있으나, 단지 변화시킬 권한이나 용기를 갖지 못할 뿐이다.
----
용기가 없다는 데 동감한다. 해본 적이 없고 두려워하고 있다. 2007-10-27   (0)

p.274
hey 동시에 너무 많은 일을 처리하려고 하거나, 같은 기간에 모든 것을 개선하려 하지 말라. 다른 누구보다 잘 할 수 있는 한 가지 일을 찾아내서 여러분의 모든 능력을 거기에 집중하라. 그 폭을 넓히려면 다른 사람들과 협력하라.
----
내 문제 2007-10-27   (0)

p.249
hey 고정가격-불행한고객
"저는 금액과 일정을 초과한 적이 없다는 자부심을 갖고 소프트웨어 개발 업체를 운영했습니다. 3년 동안 우리는 78개의 프로젝트를 수행했는데, 그 중 77개를 기간과 예산과 계약 범위 내에서 종료했습니다. 그리고 고객 설문을 해 보았는데 그 중 누구도 만족하지 않았다는 사실을 알게 되었습니다. 우리가 개발한 시스템이 그들의 문제를 해결하지 못했던 것입니다. 물론, 우리는 기간과 예산 범위 내에 개발을 완료함으로써 스스로를 방어하긴 했지만, 그 결과 고객이 진정으로 원하는 것을 해내지 못했습니다. 이것이 제가 사업을 다른 사람에게 넘긴 이유입니다." 2007-10-27   (0)

p.242
hey 결함의 근본원인을 찾아내는 방법은 전체 개발 조직이 문제를 찾는데 협력하도록 격려하는 것이다. 결함을 개인의 탓으로 돌리는 것은 이와 같은 협력에 방해가 된다. 반면, 결함을 개인적인 문제로 추적하지 않고 전체적인 문제로 통합하는 정보 측정informational measurement을 하면 그 원인을 밝히는 데 도움이 된다. 2007-10-27   (0)

p.240
hey 중요한 모든 것을 남김없이 측정할 수 없어 일부만 측정한 것은 앞서 언급한 부분 최적화의 측정 기준이 될 가능성이 매우 높다. 전체적인 비즈니스 목표를 최적화하는 데 필요한 모든 것을 측정할 수 없다면, 그 부분 최적화된 측정 기준을 제외시키는 것이 더 나을 것이다. 그렇지 않다면, 부분 최적화 활동을 독려하는 심각한 위험에 빠질 것이기 때문이다. 2007-10-27   (0)

p.220
hey 리팩터링은 낭비가 아니다. 오히려 리팩터링이야말로 비즈니스 가치를 고객에게 제공할 때 낭비를 제거하는 핵심 방법론이다. 잘 설계된 코드 기반은 개발할 때만이 아니라 시스템이 수명을 다하기까지 고객의 요구에 대응할 수 있는 기초가 된다.
리팩터링과 나란히 따라가면서 사실랑 리팩터링을 가능하게 하는 도구가 바로 자동화된 테스트다.
----
이래서 사실상 리팩터링이 어렵다. 2007-10-27   (0)

p.219
hey 자, 여러분은 개발을 멈추고 설계를 개선할 시간이 도저히 나지 않는다고 말할 수도 있다. 우리는 리팩터링을 '하지 않을' 시간이 없다고 주장한다. 코드가 복잡해지고 모호해질수록 작업은 더 느려지기만 할 것이다. 2007-10-27   (0)

p.218
hey 소프트웨어 제품 중에서도 사용자가 볼 수 있는 기능요소인 경우에는 이렇게 학기가 아주 어렵다. 어딘가에서 어떤 사용자가 그 기능요소를 쓰고 있을지도 모르기 때문이다. 그렇기 때문에 더욱더, 처음부터 만약을 대비한 기능요소를 추가하지 않는 것이 중요하다.
----
조금 모자란 듯한 기능. 스크럼웍스, 미투데이. 2007-10-27   (0)

p.217
hey 똑같은 코드가 두 곳 이상에 있어서는 안된다. 중복이 있다는 것은 패턴이 출현하고 있다는 의미이며, 그것은 곧 설계를 정제해야 한다는 신호탄이나 다름없다.
----
중복은 설계를 고치라는 의미이다. 2007-10-27   (0)

p.216
hey 주소 입력과 같은 기능요소를 몇 군데 추가하면서 동시에 각각 조금씩 변화를 준다면, 시스템은 개념 통합성을 잃게 될 것이다. 무식하게 달려드는 식의 접근 방법은 지양하고 아키텍처 성능을 확장하는 방법을 택하라. 지저분한 땜질이 시스템에 쌓이다 보면, 통합성은 점차 훼손될 것이고, 결국은 그 대가를 치러야 할 것이다.
----
새로운 요구 사항이 기존 설계와 맞지 않는다면 어떻게 하는가? 요구 사항을 고치거나 예외 처리를 하지 않는가? 느리더라도 설계를 다시 해야 한다. 리팩토링은 설계를 다시 하는 것이다. 애자일 프로그래밍은 설계를 하지 않는 것이 아니고 설계를 계속 하는 것이다. 2007-10-27   (0)

p.206
hey 어떤 시스템에 대한 내재화된 기억을 유지하는 것은 그 시스템의 장기적 통합성을 확보하는 열쇠다. 이를 위해 많은 사람이 설계 과정에서 나온 문서를 이용해 보려고 했다. 하지만, 실제로 시스템이 다 구축되면 설계 문서는 거의 그 특징을 제대로 반영하지 못하기 때문에 유지보수 프로그래머들은 대부분 이 문서를 무시한다. 2007-10-27   (0)

p.204
hey 고객과 개발자는 같은 개념을 말하고 있다면 반드시 같은 언어로 말해야만 한다. 그리고 보통 이 언어는 해당 도메인이나 그 도메인과 동일한 의미를 환기시키는 메타포에서 끌어낸 언어가 된다. 모델을 번역하거나 서로 다른 언어를 사용하게 되면 많은 정보가 왜곡, 누락될 것이다. 한편, 도메인 모델을 직접적으로 반영한 소프트웨어는 순수한 기술적 이유 때문에 상이한 내부 구조를 택한 소프트웨어보다는 비즈니스 요구의 변화에 훨씬 든든히 버틸 수 있다. 2007-10-27   (0)

p.203
hey 용어집은 해당 도메인 모델에 있는 용어들을 정의해서 팀이 일관된 언어로 말할 수 있게 한다.
----
흔히 기획/프로그램만이 아니라 심지어 클라이언트/서버 프로그래머도 다른 용어를 사용한다. 심각한 문제다. 2007-10-27   (0)

p.181
hey 프로젝트 리더가 처음 해야 할 일은 쓸데없는 부분을 알아차리고 현재 개발 프로세스의 가치 흐름도를 그린 다음 가장 심각한 병목 부분을 공략하는 것이다. 프로젝트 리더는 반복 주기별 계획회의와 일일상황 점검회의를 주관하고, 정보 방열기를 제공하고, 팀이 약속을 지키기 위해 필요한 자원을 얻을 수 있도록 한다. 여러 팀 간의 조화를 굳건히 하여 균형을 잡는다. 개발 환경에 소스 관리나 테스트 자동화와 같은 표준화된 도구를 사용하고 리팩터링과 통합 인수테스트를 확실히 하게 만든다. 회계 지식을 갖고 경제 모델을 수립해서 팀이 트레이드오프 결정을 잘 할 수 있도록 한다. 동기를 부여하는 환경을 제공하고 회의론자들을 견제하고, 축하 행사를 챙기고 밤에는 팀원들을 가족의 품으로 돌려보낸다. 2007-10-27   (0)

p.174
hey 영웅주의보다는 적당한 절제를 장려하는 편이 낫다. 헌신적인 팀은 지속 가능한 속도로 일하고 있다가 긴급 상황이 발생하면 바로 달려들 수 있다. 만약 이미 심각할 정도로 오버페이스에 빠져 있다면, 긴급 상황에 대응할 수가 없을 것이다. 2007-10-27   (0)

p.173
hey 열정적인 팀은 목적을 달성하기 위해 오랜 시간을 일하고 야근을 밥 먹듯이 한다. 이것이 좋은 것인지 나쁜 것인지에 대해서는 논쟁이 뜨겁다. 어쨌든 이런 사람들은 자신이 하고 싶어 하는 일을 하고, 스스로 오랜 시간 일하기를 선택한 것이다.
----
열정적인 사람들이 자발적으로 극단적으로 일하기 시작하면 어떻게 할 것인가? 말려야 한다고 본다. 2007-10-27   (0)

p.172
hey 아무리 동기 유발이 아주 잘되어 열심히 일하는 팀이라 하더라도, 팀원들이 무엇인가를 이뤘다는 성취감을 느끼지 못하면 얼마 안 가 지칠 것이다. 이런 감각은 목적을 다시 견고히 하고 의욕을 고취시킨다. 만일 소프트웨어를 각 반복 주기로 나누어 개발할 다른 이유가 없다 하더라도(사실 많다!), 이것 자체만으로도 아주 강력한 이유가 된다.
----
일일빌드를 시도했던 이유가 바로 이것이었다. 2007-10-27   (0)

p.170
hey 오늘날의 업무 환경에서는 팀으로 일해야 대부분의 목적을 이룰 수 있다. 튼튼한 팀이라면 모든 팀원이 목표가 무엇인지 명확히 알고 팀의 성공을 위해 헌신한다.
----
그렇지 않다면? 튼튼하지 않은 팀은 어떻게 튼튼하게 만들까? 2007-10-27   (0)

p.168
hey * '회의론자를 멀리 하라' 이 세상에서 가장 빨리 목표를 무너뜨릴 수 있는 사람은 그 목표가 불가능하다고 말하고 그럴 듯한 근거를 잔뜩 댈 수 있는 사람이다. 그런 얘기를 들을 필요는 없다.
----
쫓아내라는 소린가? 조직의 철학에 적합하지 않은 직원을 처리하는 방법에 대해서도 방법론이 필요하다. 2007-10-27   (0)
1 2 3
저자의 다른 책
회원들이 등록한 표지