달력

01

« 2008/01 »

  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  

'2008/01/03'에 해당되는 글 1

  1. 2008/01/03 스케줄 관리를 위해 기본적으로 고려되어야 할 사항

손쉬운 스케줄 관리방법(조엘 온 소프트웨어 에서...)

1. 엑셀을 사용할 것.
    - 제가 보기에도 엑셀만큼 접근성이 좋고, 빠르게 업데이트 하여 팀원 모두가 공유할 만한 프로그램은 못봤습니다.
   

2. 단순하게 만들것.(개발자가 여러명일 경우 쉬트별로 작성)
    - 그렇지 않아도 복잡한 화면 개발하느라 머리 아픈데, 그것도 모라라서 복잡한 스케줄 관리 화면을 또 본다면....아 치가 떨립니다.
    - 단순한게 최고!! 입니다.

3. 하나의 기능은 여러 개의 작업으로 분해할 것
    - 예) 맞춤법 검사 기능 -> 여러 단계의 작업목록을 만든다.
    - 기능을 분해할 수록 만들어질 기능에 대한 요소가 명확해지고, 일정도 보다 정확하게 산출이 될 겁니다.
    - 우리는 이미 배보다 배꼽이 더 큰 상황을 많이 경험했으니깐요.^^;

4. 개발자가 직접 스케줄을 작성할 것.
   - 자기 스케줄은 자기가 직접 작성해야죠....^^; 안 그러면 피박 씁니다.

5. 작업단위를 세분화 한다.
    - 작업량은 날짜가 아닌 시간 단위로 계산 할 것.
    - 타임으로 계산하고 시간을 합쳐서 날짜단위로 기록한 후 도표화 하면 보기 편합니다.

6. 최초추정시간과 현재추정시간을 지속적으로 추적할 것
    - 처음 추정시간은 언제나 늘 그렇듯 수많은 인터럽트로 인해 시간이 더 오래 걸리기도 합니다.
    - 그 중에는 예측 불가능한 요소들도 많을 것이고요~ 결국 현재추정시간을 적다보면 언젠가는 명확해 지겠지요~

7. 경과시간을 매일 업데이트 한다.
   - 매일 업데이트 하는 것이 일주일 뒤에 업데이트 하는 것 보다는 덜 피곤할 겁니다.^^*

8. 디버깅 시간을 반드시 포함 할 것.
   - 개발하면서 디버깅 시간을 고려하지 않는다는 것은 자살 행위 입니다.
   - 디버깅 시간은 때론 개발 시간의 두 배를 잡아 먹기도 하니깐요.^^
   - 하지만 원칙적으로는 단위개발 - 디버깅 이 순서로는 맞습니다.

9. 통합 시간을 고려할 것.
   - 통합시간은 꼭 잡아야 합니다. 의외로 통합과정에서 밤새기도 하거든요.

10. 여분의 시간을 포함 시킬것(버퍼 타임)
   - 버퍼 타임은 추가적인 또는 변경되는 요구 조건을 수용하기 위한 타임입니다.
   - 그리고 일종의 보험 성격인데요, 개발 시간이 부족할 경우 버퍼 타임을 희생할 수 있을 겁니다.
   - 야금야금 말이죠.

11. 관리자가 시간을 단축할 것을 고려하여 새로운 컬럼(릭의 추정시간)을 추가한다.
   - 마지막으로 스케줄을 작성하다보니 정말 요소에 비해 개발 시간이 절대 부족한 경우도 있을 겁니다.
   - 이런 경우에는 어쩔수 없이 가짜 컬럼을 만듭니다.
   - 가짜라고 해서 거짓말은 아니고요... 릭이라는 가상의 인물을 만들고 그 사람이 작업할 량을 할당해 주라는 겁니다.
   - 필수가 아닌 옵션으로 말이죠.^^

Posted by -세티-