Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
HARD <br />CODE<br />비능률 박멸inefficiency Eradicated<br />아꿈사(http://cafe.naver.com/architect1.cafe)<br />ohyecloudy(http://...
막판 명세Late specs: Fact of life or genetic defect노는 손Idle hands우리가 만나는 날The day we met명세서는 그만 쓰고 기능팀을 한곳으로 Stop writing spec...
명세가 없어서 코드가 명세라 여기고 이미 구현그런데 막판에 명세가 나왔다.<br />
명세가 늦게 나온다.구현을 시작하는 시점까지 명세를 완성 못한다.혹은 검토와 검사를 끝내지 못한다.<br />
1. 명세에 허점2. 코드에 허점3. 지적4. 임시 회의5. 코드를 작성6. 허점 발견(임시 회의때 빠진 사람)7. goto 4<br />
어떻게 해결할 수 있을까?<br />
복도 회의<br />명세 허점을 발견하는 즉시 당사자들끼리 회의<br />회의 결과는 두 사람만 공유<br />
위원회 회의<br />책임자들이 모인다<br />결론은 명확하지만 시간을 많이 뺏는다<br />
명세 변경 요청<br /><ul><li>명세를 변경해야 하면 메일을 쓴다.</li></ul>‘강력한 반대가 없으면 이를 명세로 간주합니다.’<br />TO : 영향 받는 사람들(PM, 개발팀…)<br />변경을 기록하고...
예방이 최선<br />
T-I-M-E 차트<br />고차원으로 기술<br />ex) UI와 기능, 각 기능이 맞물리는 방식 정의<br />이후 진행에서 더 구체적으로 들어간다.<br />이후에 명세서와 기능은 이전에 작성했던 명세서를 참조<b...
막판 명세Late specs: Fact of life or genetic defect노는 손Idle hands우리가 만나는 날The day we met명세서는 그만 쓰고 기능팀을 한곳으로 Stop writing spec...
무반동 버그ZBB, Zero Bug Bounce<br />병목 지점이 테스트 팀으로 넘어간다.<br />테스트 팀으로 코드를 넘긴 후<br />처음 두어주는 밀려오는 버그로 정신이 없다.<br />점차 테스트 팀으로 병...
개발자가 저지르는 대형 사고<br />버그를 훔친다<br />보고 안 된 버그를 고친다.<br />미뤄둔 버그를 고친다.<br />‘스파게티’ 코드를 다시 짠다.<br />구현 스타일로 싸움을 벌인다.<br />
노는 손 활용<br />버그를 분석한다.<br />그룹이 사용할 도구를 제작한다.<br />설계 아이디어로 프로토타입을 구현해 PM을 기쁘게 한다.<br />새로운 기술을 익힌다.<br />연구팀과 대화한다.<br />...
막판 명세Late specs: Fact of life or genetic defect노는 손Idle hands우리가 만나는 날The day we met명세서는 그만 쓰고 기능팀을 한곳으로 Stop writing spec...
왜 모였죠?<br />주제를 벗어나지 말 것<br />목적이 뭐죠?<br />결정? 정보 공유? 아이디어?<br />저 사람들은 왜 참석했죠?<br />반드시 필요한 사람만 초대<br />왜 이제서야 말하죠?<br />...
막판 명세Late specs: Fact of life or genetic defect노는 손Idle hands우리가 만나는 날The day we met명세서는 그만 쓰고 기능팀을 한곳으로 Stop writing spec...
명세서 좀 그만 써라<br />내 시간을 까먹고 그룹 시간을 까먹고 회사 시간을 까먹는다.<br />개발자도 개발 명세서를 그만 써야 한다.<br />테스터도 테스트 명세서에서 손을 놓아야 한다.<br />
명세서가 사라진다면<br />“무슨 기능을 구현할지 어떻게 알죠?”<br />“PM에게 물어봐”<br />“PM이 하루 종일 제 곁을 지켜주지는 않습니다.명세서가 필요합니다. 명세서를 검토하고 수정하고 갱신해야 한다고요...
명세서 검토, 수정, 갱신이문제가 아니라 PM과 언제든지 토론하지 못해서 문제다.<br />
같은 기능 집합을 구현하는 개발팀과 테스트 팀이 한곳에 모여 있고 PM이 이들과 같은 공간에 화이트보드에 뭔가를 잔뜩 서놓고 하루종일 곁에 있어 준다면? 그래도 공식 명세서가 필요한가?<br />
하나에 집중한다<br />한 곳에 모으고 화이트보드를 잔뜩 안겨준다.<br />한 번에 한 기능만 집중해서 끝낸다.<br />결정은 디지털 카메라로 기록한다.<br />후공정팀에 필요한 문서는 목적에 맞게 작성한다.<b...
린 소프트웨어 개념이떠오르지 않는가?맞다!낭비를 줄이면 린이 남는다.<br />
막판 명세Late specs: Fact of life or genetic defect노는 손Idle hands우리가 만나는 날The day we met명세서는 그만 쓰고 기능팀을 한곳으로 Stop writing spec...
명세서는 끔찍<br />쓰기 어렵고 읽기 어려우며 유지하기도 어렵다.<br />항상 불충분하고 체계적이지 못하며, 검토도 부실하다.<br />
훌륭한 명세서란?<br />
훌륭한 명세서<br />쉽고 단순해야 한다<br />조항 세 개와 메타데이터만 있으면 충분<br />요구 사항 - 기능이 존재하는 이유는?<br />설계 – 기능이 동작하는 방식은?<br />문제점 – 결정이 필요한 사...
빈틈이 없어야 한다<br />테스트 방법을 명시하지 못한다면?<br />요구사항을 충족시키지 못한다는 뜻<br />명세서에서 빼야 한다.<br />필수적인 요구사항?<br />테스트가 가능할 때까지 요구사항을 다시 작성...
피드백을 주고받기 쉬워야 한다<br />셰어포인트에 올려서 변경을 추적하고 버전을 관리<br />화이트 보드에 공개, 위키에 넣어둔다.<br />
품질 점검<br />품질 점검 목록으로 다뤄야 한다.<br />보안성. 사생활 보장 등<br />명세서 별도 조항으로 추가하지 말 것<br />
누구 탓일까?나쁜 습관과 허술한 도구<br />
몇 가지 사소한 버릇을 고치고 크게 단순화한 템플릿을 사용명세서와 그룹 간 의사소통과부서간 관계는크게 개선될 것이다.<br />
토론<br />
Upcoming SlideShare
Loading in …5
×

[HARD CODE] 3. 비능률 박멸

1,468 views

Published on

Published in: Technology, Business
  • Be the first to comment

[HARD CODE] 3. 비능률 박멸

  1. 1. HARD <br />CODE<br />비능률 박멸inefficiency Eradicated<br />아꿈사(http://cafe.naver.com/architect1.cafe)<br />ohyecloudy(http://ohyecloudy.com)<br />
  2. 2. 막판 명세Late specs: Fact of life or genetic defect노는 손Idle hands우리가 만나는 날The day we met명세서는 그만 쓰고 기능팀을 한곳으로 Stop writing specs, co-located feature crews나쁜 명세서, 누구 탓인가? Bad specs: Who is to blame?<br />
  3. 3. 명세가 없어서 코드가 명세라 여기고 이미 구현그런데 막판에 명세가 나왔다.<br />
  4. 4. 명세가 늦게 나온다.구현을 시작하는 시점까지 명세를 완성 못한다.혹은 검토와 검사를 끝내지 못한다.<br />
  5. 5. 1. 명세에 허점2. 코드에 허점3. 지적4. 임시 회의5. 코드를 작성6. 허점 발견(임시 회의때 빠진 사람)7. goto 4<br />
  6. 6. 어떻게 해결할 수 있을까?<br />
  7. 7. 복도 회의<br />명세 허점을 발견하는 즉시 당사자들끼리 회의<br />회의 결과는 두 사람만 공유<br />
  8. 8. 위원회 회의<br />책임자들이 모인다<br />결론은 명확하지만 시간을 많이 뺏는다<br />
  9. 9. 명세 변경 요청<br /><ul><li>명세를 변경해야 하면 메일을 쓴다.</li></ul>‘강력한 반대가 없으면 이를 명세로 간주합니다.’<br />TO : 영향 받는 사람들(PM, 개발팀…)<br />변경을 기록하고 검토하되 프로젝트 진행을 방해하지 않는다.<br />
  10. 10. 예방이 최선<br />
  11. 11. T-I-M-E 차트<br />고차원으로 기술<br />ex) UI와 기능, 각 기능이 맞물리는 방식 정의<br />이후 진행에서 더 구체적으로 들어간다.<br />이후에 명세서와 기능은 이전에 작성했던 명세서를 참조<br />처음에 만들었던 명세서를 기준으로 명세서 일정 추정<br />
  12. 12. 막판 명세Late specs: Fact of life or genetic defect노는 손Idle hands우리가 만나는 날The day we met명세서는 그만 쓰고 기능팀을 한곳으로 Stop writing specs, co-located feature crews나쁜 명세서, 누구 탓인가? Bad specs: Who is to blame?<br />
  13. 13. 무반동 버그ZBB, Zero Bug Bounce<br />병목 지점이 테스트 팀으로 넘어간다.<br />테스트 팀으로 코드를 넘긴 후<br />처음 두어주는 밀려오는 버그로 정신이 없다.<br />점차 테스트 팀으로 병목이 이동<br />들어오는 새 버그를 후딱 해치우곤 빈둥거린다.<br />
  14. 14. 개발자가 저지르는 대형 사고<br />버그를 훔친다<br />보고 안 된 버그를 고친다.<br />미뤄둔 버그를 고친다.<br />‘스파게티’ 코드를 다시 짠다.<br />구현 스타일로 싸움을 벌인다.<br />
  15. 15. 노는 손 활용<br />버그를 분석한다.<br />그룹이 사용할 도구를 제작한다.<br />설계 아이디어로 프로토타입을 구현해 PM을 기쁘게 한다.<br />새로운 기술을 익힌다.<br />연구팀과 대화한다.<br />특허 명세서나 백서를 작성한다<br />경력을 관리한다.<br />
  16. 16. 막판 명세Late specs: Fact of life or genetic defect노는 손Idle hands우리가 만나는 날The day we met명세서는 그만 쓰고 기능팀을 한곳으로 Stop writing specs, co-located feature crews나쁜 명세서, 누구 탓인가? Bad specs: Who is to blame?<br />
  17. 17. 왜 모였죠?<br />주제를 벗어나지 말 것<br />목적이 뭐죠?<br />결정? 정보 공유? 아이디어?<br />저 사람들은 왜 참석했죠?<br />반드시 필요한 사람만 초대<br />왜 이제서야 말하죠?<br />중요한 사안이라면 핵심 인물을 놀래키지 말아야 한다.<br />다음 단계는 뭐죠?<br />다음 단계를 결정. 문서로 정리해서 발송<br />TO : 회의 참석자 전체, CC: 회의 결과로 영향 받을 사람들<br />
  18. 18. 막판 명세Late specs: Fact of life or genetic defect노는 손Idle hands우리가 만나는 날The day we met명세서는 그만 쓰고 기능팀을 한곳으로 Stop writing specs, co-located feature crews나쁜 명세서, 누구 탓인가? Bad specs: Who is to blame?<br />
  19. 19. 명세서 좀 그만 써라<br />내 시간을 까먹고 그룹 시간을 까먹고 회사 시간을 까먹는다.<br />개발자도 개발 명세서를 그만 써야 한다.<br />테스터도 테스트 명세서에서 손을 놓아야 한다.<br />
  20. 20. 명세서가 사라진다면<br />“무슨 기능을 구현할지 어떻게 알죠?”<br />“PM에게 물어봐”<br />“PM이 하루 종일 제 곁을 지켜주지는 않습니다.명세서가 필요합니다. 명세서를 검토하고 수정하고 갱신해야 한다고요.”<br />
  21. 21. 명세서 검토, 수정, 갱신이문제가 아니라 PM과 언제든지 토론하지 못해서 문제다.<br />
  22. 22. 같은 기능 집합을 구현하는 개발팀과 테스트 팀이 한곳에 모여 있고 PM이 이들과 같은 공간에 화이트보드에 뭔가를 잔뜩 서놓고 하루종일 곁에 있어 준다면? 그래도 공식 명세서가 필요한가?<br />
  23. 23. 하나에 집중한다<br />한 곳에 모으고 화이트보드를 잔뜩 안겨준다.<br />한 번에 한 기능만 집중해서 끝낸다.<br />결정은 디지털 카메라로 기록한다.<br />후공정팀에 필요한 문서는 목적에 맞게 작성한다.<br />
  24. 24. 린 소프트웨어 개념이떠오르지 않는가?맞다!낭비를 줄이면 린이 남는다.<br />
  25. 25. 막판 명세Late specs: Fact of life or genetic defect노는 손Idle hands우리가 만나는 날The day we met명세서는 그만 쓰고 기능팀을 한곳으로 Stop writing specs, co-located feature crews나쁜 명세서, 누구 탓인가? Bad specs: Who is to blame?<br />
  26. 26. 명세서는 끔찍<br />쓰기 어렵고 읽기 어려우며 유지하기도 어렵다.<br />항상 불충분하고 체계적이지 못하며, 검토도 부실하다.<br />
  27. 27. 훌륭한 명세서란?<br />
  28. 28. 훌륭한 명세서<br />쉽고 단순해야 한다<br />조항 세 개와 메타데이터만 있으면 충분<br />요구 사항 - 기능이 존재하는 이유는?<br />설계 – 기능이 동작하는 방식은?<br />문제점 – 결정이 필요한 사안, 위험, 장단점은?<br />메타데이터 – 제목, 간단한 설명, 작성자, 기능팀, 우선순위, 비용, 상태 <br />
  29. 29. 빈틈이 없어야 한다<br />테스트 방법을 명시하지 못한다면?<br />요구사항을 충족시키지 못한다는 뜻<br />명세서에서 빼야 한다.<br />필수적인 요구사항?<br />테스트가 가능할 때까지 요구사항을 다시 작성한다.<br />
  30. 30. 피드백을 주고받기 쉬워야 한다<br />셰어포인트에 올려서 변경을 추적하고 버전을 관리<br />화이트 보드에 공개, 위키에 넣어둔다.<br />
  31. 31. 품질 점검<br />품질 점검 목록으로 다뤄야 한다.<br />보안성. 사생활 보장 등<br />명세서 별도 조항으로 추가하지 말 것<br />
  32. 32. 누구 탓일까?나쁜 습관과 허술한 도구<br />
  33. 33. 몇 가지 사소한 버릇을 고치고 크게 단순화한 템플릿을 사용명세서와 그룹 간 의사소통과부서간 관계는크게 개선될 것이다.<br />
  34. 34. 토론<br />

×