[HARD CODE] 3. 비능률 박멸
Upcoming SlideShare
Loading in...5
×
 

[HARD CODE] 3. 비능률 박멸

on

  • 1,597 views

 

Statistics

Views

Total Views
1,597
Views on SlideShare
1,186
Embed Views
411

Actions

Likes
1
Downloads
6
Comments
0

9 Embeds 411

http://parkpd.egloos.com 144
http://opnote.tistory.com 140
http://ohyecloudy.com 83
http://andstudy.com 17
http://www.hanrss.com 11
http://www.andstudy.com 9
http://asdf.ismine.net 3
http://0.0.0.0 3
http://www.parkpd.x-y.net 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

[HARD CODE] 3. 비능률 박멸 [HARD CODE] 3. 비능률 박멸 Presentation Transcript

  • HARD
    CODE
    비능률 박멸inefficiency Eradicated
    아꿈사(http://cafe.naver.com/architect1.cafe)
    ohyecloudy(http://ohyecloudy.com)
  • 막판 명세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?
  • 명세서는 끔찍
    쓰기 어렵고 읽기 어려우며 유지하기도 어렵다.
    항상 불충분하고 체계적이지 못하며, 검토도 부실하다.
  • 훌륭한 명세서란?
  • 훌륭한 명세서
    쉽고 단순해야 한다
    조항 세 개와 메타데이터만 있으면 충분
    요구 사항 - 기능이 존재하는 이유는?
    설계 – 기능이 동작하는 방식은?
    문제점 – 결정이 필요한 사안, 위험, 장단점은?
    메타데이터 – 제목, 간단한 설명, 작성자, 기능팀, 우선순위, 비용, 상태
  • 빈틈이 없어야 한다
    테스트 방법을 명시하지 못한다면?
    요구사항을 충족시키지 못한다는 뜻
    명세서에서 빼야 한다.
    필수적인 요구사항?
    테스트가 가능할 때까지 요구사항을 다시 작성한다.
  • 피드백을 주고받기 쉬워야 한다
    셰어포인트에 올려서 변경을 추적하고 버전을 관리
    화이트 보드에 공개, 위키에 넣어둔다.
  • 품질 점검
    품질 점검 목록으로 다뤄야 한다.
    보안성. 사생활 보장 등
    명세서 별도 조항으로 추가하지 말 것
  • 누구 탓일까?나쁜 습관과 허술한 도구
  • 몇 가지 사소한 버릇을 고치고 크게 단순화한 템플릿을 사용명세서와 그룹 간 의사소통과부서간 관계는크게 개선될 것이다.
  • 토론