비능률 박멸 inefficiency Eradicated

아꿈사(http://cafe.naver.com/architect1.cafe)

ohyecloudy(http://ohyecloudy.com)

2009.11.14

막판 명세 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?

명세가 없어서 코드가 명세라 여기고 이미 구현 그런데 막판에 명세가 나왔다.

명세가 늦게 나온다. 구현을 시작하는 시점까지 명세를 완성 못한다. 혹은 검토와 검사를 끝내지 못한다.

1. 명세에 허점 2. 코드에 허점 3. 지적 4. 임시 회의 5. 코드를 작성 6. 허점 발견 (임시 회의때 빠진 사람)

7. goto 4

어떻게 해결할 수 있을까?

복도 회의

• 명세 허점을 발견하는 즉시 당사자들끼리 회의

• 회의 결과는 두 사람만 공유

위원회 회의

• 책임자들이 모인다

• 결론은 명확하지만 시간을 많이 뺏는다

명세 변경 요청

• 명세를 변경해야 하면 메일을 쓴다.

– ‘강력한 반대가 없으면 이를 명세로 간주합니다.’

– TO : 영향 받는 사람들(PM, 개발팀…)

• 변경을 기록하고 검토하되 프로젝트 진행을 방해하지 않는다.

예방이 최선

T-I-M-E 차트

• 고차원으로 기술

– ex) UI와 기능, 각 기능이 맞물리는 방식 정의

• 이후 진행에서 더 구체적으로 들어간다.

• 이후에 명세서와 기능은 이전에 작성했던 명세서를 참조

• 처음에 만들었던 명세서를 기준으로 명세서 일정 추정

막판 명세 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?

무반동 버그ZBB, Zero Bug Bounce

• 병목 지점이 테스트 팀으로 넘어간다.

• 테스트 팀으로 코드를 넘긴 후

–처음 두어주는 밀려오는 버그로 정신이 없다.

–점차 테스트 팀으로 병목이 이동

–들어오는 새 버그를 후딱 해치우곤 빈둥거린다.

개발자가 저지르는 대형 사고

• 버그를 훔친다

• 보고 안 된 버그를 고친다.

• 미뤄둔 버그를 고친다.

• ‘스파게티’ 코드를 다시 짠다.

• 구현 스타일로 싸움을 벌인다.

노는 손 활용

• 버그를 분석한다.

• 그룹이 사용할 도구를 제작한다.

• 설계 아이디어로 프로토타입을 구현해 PM을 기쁘게 한다.

• 새로운 기술을 익힌다.

• 연구팀과 대화한다.

• 특허 명세서나 백서를 작성한다

• 경력을 관리한다.

막판 명세 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?

• 왜 모였죠? – 주제를 벗어나지 말 것

• 목적이 뭐죠? – 결정? 정보 공유? 아이디어?

• 저 사람들은 왜 참석했죠? – 반드시 필요한 사람만 초대

• 왜 이제서야 말하죠? – 중요한 사안이라면 핵심 인물을 놀래키지 말아야 한다.

• 다음 단계는 뭐죠? – 다음 단계를 결정. 문서로 정리해서 발송 – TO : 회의 참석자 전체, CC: 회의 결과로 영향 받을 사람들

막판 명세 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?

명세서 좀 그만 써라

• 내 시간을 까먹고 그룹 시간을 까먹고 회사 시간을 까먹는다.

• 개발자도 개발 명세서를 그만 써야 한다.

• 테스터도 테스트 명세서에서 손을 놓아야 한다.

명세서가 사라진다면

• “무슨 기능을 구현할지 어떻게 알죠?”

• “PM에게 물어봐”

• “PM이 하루 종일 제 곁을 지켜주지는 않습니다. 명세서가 필요합니다. 명세서를 검토하고 수정하고 갱신해야 한다고요.”

명세서 검토, 수정, 갱신이 문제가 아니라 PM과 언제든지 토론하지 못해서 문제다.

같은 기능 집합을 구현하는 개발팀과 테스트 팀이 한곳에 모여 있고 PM이 이들과 같은 공간에 화이트보드에 뭔가를 잔뜩 서놓고 하루종일 곁에 있어 준다면? 그래도 공식 명세서가 필요한가?

하나에 집중한다

• 한 곳에 모으고 화이트보드를 잔뜩 안겨준다.

• 한 번에 한 기능만 집중해서 끝낸다.

• 결정은 디지털 카메라로 기록한다.

• 후공정팀에 필요한 문서는 목적에 맞게 작성한다.

린 소프트웨어 개념이 떠오르지 않는가? 맞다! 낭비를 줄이면 린이 남는다.

막판 명세 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?

명세서는 끔찍

• 쓰기 어렵고 읽기 어려우며 유지하기도 어렵다.

• 항상 불충분하고 체계적이지 못하며, 검토도 부실하다.

훌륭한 명세서란?

훌륭한 명세서

• 쉽고 단순해야 한다

• 조항 세 개와 메타데이터만 있으면 충분

–요구 사항 - 기능이 존재하는 이유는?

–설계 – 기능이 동작하는 방식은?

–문제점 – 결정이 필요한 사안, 위험, 장단점은?

–메타데이터 – 제목, 간단한 설명, 작성자, 기능팀, 우선순위, 비용, 상태

빈틈이 없어야 한다

• 테스트 방법을 명시하지 못한다면?

–요구사항을 충족시키지 못한다는 뜻

–명세서에서 빼야 한다.

• 필수적인 요구사항?

–테스트가 가능할 때까지 요구사항을 다시 작성한다.

피드백을 주고받기 쉬워야 한다

• 셰어포인트에 올려서 변경을 추적하고 버전을 관리

• 화이트 보드에 공개, 위키에 넣어둔다.

품질 점검

• 품질 점검 목록으로 다뤄야 한다.

–보안성. 사생활 보장 등

–명세서 별도 조항으로 추가하지 말 것

누구 탓일까?

나쁜 습관과 허술한 도구

몇 가지 사소한 버릇을 고치고 크게 단순화한 템플릿을 사용 명세서와 그룹 간 의사소통과 부서간 관계는 크게 개선될 것이다.