MSN Live Messenger :
미완성 작업의 예 (83 ~ 84쪽)
1. 코드로 옮기지 않은 문서
2. 동기화하지 않은 코드
3. 테스트하지 않은 코드
4. 문서화되지 않은 코드
5. 배포되지 않은 코드
1. 코드로 옮기지 않은 문서
2. 동기화하지 않은 코드
3. 테스트하지 않은 코드
4. 문서화되지 않은 코드
5. 배포되지 않은 코드
낭비. 코딩을 하지 않고 아이디어만 갖고 있는 것도 낭비란 생각이 든다. 비단 프로그래밍 영역에만 국한시키지 않는다고 하면, 생각만 하고 실천하지 않는 것들도 모두 낭비이다. 시간을 낭비하는 버릇에 몸에 가득 배어 있는데... 예전에 누군가 말했던 것처럼 담백해져야 한다.
지연delays
1. 내가 원하는 것이 무엇인지 내가 정확하게 알 때가지 나의 문제를 풀지 않고 기다리기
2. 프로젝트 승인을 얻을 때까지 수개월간 기다리기
3. 개발자가 배정될때까지 하염없이 기다리기
4. 배정된 개발자들이 가용한 상태가 될 때까지 기다리기
5. 골치아픈 변경 승인 프로세스. 나를 몇 달간 가다리게 해놓고, 그동안 나의 상황이 변하지 않고 그대로 있을 것으로 생각합니까?
6, 전체 시스템이 완성될 때까지 기다리기. 지금 당장 나에게 필요한 핵심 기능들만 받아볼 수는 없을까요?
7. 코드가 테스트를 통과할 때까지 기다리기. 이것이 왜 그렇게 오래 걸리나요?
8. 새로운 소프트웨어가 기존 프로그램을 뒤죽박죽으로 만드는 것을 멈출 때까지 기다리기.
1. 내가 원하는 것이 무엇인지 내가 정확하게 알 때가지 나의 문제를 풀지 않고 기다리기
2. 프로젝트 승인을 얻을 때까지 수개월간 기다리기
3. 개발자가 배정될때까지 하염없이 기다리기
4. 배정된 개발자들이 가용한 상태가 될 때까지 기다리기
5. 골치아픈 변경 승인 프로세스. 나를 몇 달간 가다리게 해놓고, 그동안 나의 상황이 변하지 않고 그대로 있을 것으로 생각합니까?
6, 전체 시스템이 완성될 때까지 기다리기. 지금 당장 나에게 필요한 핵심 기능들만 받아볼 수는 없을까요?
7. 코드가 테스트를 통과할 때까지 기다리기. 이것이 왜 그렇게 오래 걸리나요?
8. 새로운 소프트웨어가 기존 프로그램을 뒤죽박죽으로 만드는 것을 멈출 때까지 기다리기.
6번은 예전에 참여한 프로젝트에서 목격했다. 시스템의 존재 가치를 뒤흔들 정도로 중요한 요건을 구현 전에 먼저 검증해보자고 고객이 요구했다. 그러나, 개발팀은 그럴 수는 없다는 것이다. (문서 작업으로) 검증하다가 개발이 늦어진다는 것이다. 과연 그럴까? 왜 개발팀은 고객 요구사항에 부합하여 가고 있는지 확인할 수 없는 방향으로 진척을 해야 할까?
1번과 유사한 상황도 예전에 포착했다. 분석가 A는 현업 담당자가 출장이라고 손을 놓고 있었고, 개발자 B는 설계 가이드가 없다고 설계를 못한다 하고, 개발자 C는 작명지침이 없어서 개발을 못한다고 한다.
빠른 인도주기의 이점 (110쪽)
1. 학습 능력의 엄청난증가
2. 버그를 고치지 않으면 못버티기 때문에 버그 투성이 소프트웨어가 사라진다.
3. 설치 과정 바로 잡는다. 한해 45번의 릴리즈를 설치해야 하는데 설치가 쉽지 안하면 버텨내지 못한다.
4. 업그레이드 과정이 향상된다. 끊임없는 업그레이드는 필수사항이다. 업그레이드를 쉽게 만들어야 한다.
5. 지속가능한 페이스를 유지하게 만든다. 그러지 않고서는 지구전을 버티지 못한다.
1. 학습 능력의 엄청난증가
2. 버그를 고치지 않으면 못버티기 때문에 버그 투성이 소프트웨어가 사라진다.
3. 설치 과정 바로 잡는다. 한해 45번의 릴리즈를 설치해야 하는데 설치가 쉽지 안하면 버텨내지 못한다.
4. 업그레이드 과정이 향상된다. 끊임없는 업그레이드는 필수사항이다. 업그레이드를 쉽게 만들어야 한다.
5. 지속가능한 페이스를 유지하게 만든다. 그러지 않고서는 지구전을 버티지 못한다.
'티끌 모아 태산', '복리' 같은 어구나 단어가 떠오른다. 추후 PM이나 팀장 역할을 할 때, 꼭 기반 철학으로 사용해야겠다.1
1. 복리(?) 버그 수정
2. 설치 편리성 복리로 강화
3. 확장성 복리로 강화
4. 페이스 조절/학습 강화
위에 이점이라면 방안은?
주기 시간 줄이기(116쪽)
1. 일의 양이 고르게 도착하도록 하라.
2. 진행중인 작업의 수를 최소화하라.
3. 진행중인 작업의 크기를 최소화하라.
4. 일정한 리듬을 가져라.
5. 일의 양을 할 수 있는 만큼으로 제한하라.
6. 당김 스케줄릴pull scheduling을 사용하라
1. 일의 양이 고르게 도착하도록 하라.
2. 진행중인 작업의 수를 최소화하라.
3. 진행중인 작업의 크기를 최소화하라.
4. 일정한 리듬을 가져라.
5. 일의 양을 할 수 있는 만큼으로 제한하라.
6. 당김 스케줄릴pull scheduling을 사용하라
익숙하지 않으면 TDD에서 todo 정의하는 것이나 프랭클린 다이어리에서 todo 정의하는 것이 똑같이 어렵다. 왕도가 없는 진정한 관리 역량이 아닐까 싶다.
여기에 더하여
지금 가지고 있는 '할일 목록'이 너무 길어요. 어떻게 줄일 수 있을가요? (119쪽)
1. 현실적으로 한번도 고려해보지 못한 것들이 몇 개나 있는가?
2. 5점 척도로 파레토 분석을 하자. 3점 이하는 과감히 삭제.
3. 적절한 작업량인가? 인원이나 지원 보충이 필요한가?
4. 목록을 비현실적으로 유지하는 다른 이유가 있을지 모른다. 목록을 두 개로 구분하여 하나는 외부에 보여주는 용도로 쓰고, 다른 하나는 짧게 만들어 작업에 활용하는 용도로 사용하라.
1. 현실적으로 한번도 고려해보지 못한 것들이 몇 개나 있는가?
2. 5점 척도로 파레토 분석을 하자. 3점 이하는 과감히 삭제.
3. 적절한 작업량인가? 인원이나 지원 보충이 필요한가?
4. 목록을 비현실적으로 유지하는 다른 이유가 있을지 모른다. 목록을 두 개로 구분하여 하나는 외부에 보여주는 용도로 쓰고, 다른 하나는 짧게 만들어 작업에 활용하는 용도로 사용하라.
수많은 즐겨찾기 목록을 저 기준으로 잘라내 버리고 싶다. ㅡㅡ;
일찍 시험하고 빨리 실패하라
데밍의 경영을 위한 14가지 포인트
1. 단기적 이윤이 아니라 사업 지속을 위한 경쟁력 강화와 직무창출을 목적으로 하라.
2. 기존에 용납됐던 지연이나 실수, 부실한 작업, 보잘 것 없는 서비스는 더 이상 수용해선 안된다.
3. 품질 검사에 대한 의존 중단. 제품을 만드는 과정에 품질을 내재화. 통계적 공정 관리
4. 최저가 입찰이 아니라 신뢰를 기본으로 한 장기적인 협력관계 형성으로 전체 비용을 낮추라.
5. 개선은 일회성 운동이 아니다. 모든 활동을 지속적으로 개선하라.
6. 훈련 제도화
7. 리더십 제도화
8. 회사를 위해 최서을 다하는 것과 지금 당장 수행하는 작업 간에 충돌이 있어서는 절대로 안된다. 안정감을 느껴야 효율적으로 일한다.
9. 부서간 장벽을 허물고, 교차기능 팀을 만들어 모두가 서로의 관점을 이해할 수 있도록 하라. 개인 별 성과 보상은 팀 전체 협력 저해할수 있다.
10. 결함은 작업자가 아니라 시스템이 만들며, 시스템을 변화시키는 것은 경영자의 책임이다.
11. 작업할당량, 목표수치를 없애라. 이는 두려움과 공포를 이용한 관리이다. 진정한 리더십을 발휘하라.
12. 성과 등급 평가를 없애라. 작업자의 자부심을 빼앗는 요인을 제거하라.
13. 교육과 자기 개선을 장려하라. 미래를 보장하는 열쇠다.
14. 변화transformation를 달성하기 위해 직접 움직여라. 최고 경영진은 참여를 통해 변화를 이끌어야지 지원만 해서는 안된다.
1. 단기적 이윤이 아니라 사업 지속을 위한 경쟁력 강화와 직무창출을 목적으로 하라.
2. 기존에 용납됐던 지연이나 실수, 부실한 작업, 보잘 것 없는 서비스는 더 이상 수용해선 안된다.
3. 품질 검사에 대한 의존 중단. 제품을 만드는 과정에 품질을 내재화. 통계적 공정 관리
4. 최저가 입찰이 아니라 신뢰를 기본으로 한 장기적인 협력관계 형성으로 전체 비용을 낮추라.
5. 개선은 일회성 운동이 아니다. 모든 활동을 지속적으로 개선하라.
6. 훈련 제도화
7. 리더십 제도화
8. 회사를 위해 최서을 다하는 것과 지금 당장 수행하는 작업 간에 충돌이 있어서는 절대로 안된다. 안정감을 느껴야 효율적으로 일한다.
9. 부서간 장벽을 허물고, 교차기능 팀을 만들어 모두가 서로의 관점을 이해할 수 있도록 하라. 개인 별 성과 보상은 팀 전체 협력 저해할수 있다.
10. 결함은 작업자가 아니라 시스템이 만들며, 시스템을 변화시키는 것은 경영자의 책임이다.
11. 작업할당량, 목표수치를 없애라. 이는 두려움과 공포를 이용한 관리이다. 진정한 리더십을 발휘하라.
12. 성과 등급 평가를 없애라. 작업자의 자부심을 빼앗는 요인을 제거하라.
13. 교육과 자기 개선을 장려하라. 미래를 보장하는 열쇠다.
14. 변화transformation를 달성하기 위해 직접 움직여라. 최고 경영진은 참여를 통해 변화를 이끌어야지 지원만 해서는 안된다.
주옥 같구만... 구구절절
 | 린 소프트웨어 개발의 적용 -  메리 포펜딕 외 지음, 엄위상 외 옮김/위키북스 |
최고의 책이지만... 별 넷을 준 이유는... 번역서는 오타나 잘못된 번호 매김이 있고, 번역 내용도 그리 매끄럽지는 못해서이다. 그럼에도 불구하고, 원서 자체가 빛나니까 추천할만하다.
2008/01/22 - [네티즌 라이프/책읽고 나서 소통하기] - 린 소프트웨어 개발의 7가지 원칙
- 일단 암기하고 적용해서 내 경험으로 만들어 진짜 철학으로 만들어보기를 기대한다. [본문으로]
이올린에 북마크하기
이올린에 추천하기
