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