난 할 수 있어

2009|0814 회의록

회의 발표자

• 김이사님

회의 안건

• 개발 프로세스 세미나 01

이슈 및 논의내용

• 스펙(사양) => 디자인(설계) => 코딩 => 테스트

• 기능과 스펙(specification 요구명세서)

  • 기능에서 기능적인 것 외에 더 상세히 적는 것이 스펙(spec)이다.

  • 스펙이 없을 경우 혼돈이 발생한다.

    • "숫자 3개를 주고 정렬하는 프로그램" 을 만들기로 하고 진행 중에 나오는 요구사항
    • -> 만약 실수 3개라면?
    • -> 만약 복소수 포함이라면?
    • -> 만약 핸드폰에 넣을 프로그램이라면?
  • 이와 같이 스펙이 명확하지 않으면 최악의 경우 모두 엎고 다시 만들어야 할 수도 있다.

  • 대부분의 개발자들은 방해받는 것을 싫어한다.

    • 다른 부서와의 명확한 의사소통을 하고 중복 의사소통을 피하기 위해 스펙을 상세히 쓰는 것이 좋다.

• 디자인 (설계)

  • 완성된 스펙으로 디자인을 시작한다.
  • 프로그래머에 대한 의존도를 최소화 한다.

  • 어떤 TOOL을 이용할 것인가?

    • 자신에 맞는 TOOL을 이용하여 설계한다. 너무 다루기 힘든 TOOL을 사용하려고 하면 TOOL 사용법을 배우는데 시간이 더 많이 든다.

• 개발

  • 20%의 코딩 + 80%의 예외처리(에러처리)

  • Peer Review

    • 종류 :

      • 설계 리뷰
      • 코드 리뷰 (checkin 하기 전 코드에 대한 review) 등등

    • 방법 :

      • 몇명 모여서 간단히.
      • 보통 상급 프로그래머 + 초급 프로그래머의 조합

    • 코드 리뷰의 목적 :

      • test 이전에 버그를 조기 발견할 수 있다.
      • 정보의 공유를 통해 개인 사정으로 부재시에도 별 문제가 없다.
      • 잘된 코드를 볼 수 있고, 잘못된 코드를 고쳐가면서 빨리 배울 수 있다.
      • 왜 이렇게 만들었느냐 하는 책임을 묻는 자리가 아니다.

• 테스트

  • Pre-Alpha test (개발버전)
  • Alpha test : 설치, 동작이 되고 주요기능 구현이 되어 있다.
  • Beta test : 모든 기능이 구현되어 있다.
  • RC (Release candidate) : 출시를 위해 만들어 버그가 거의없다.
  • RTM (Release To Manufacturing ==  GA(General Available)) 릴리즈 버전. RC의 마지막 버전

• 훌륭한 관리자의 역할

• 예상치 못한 것을 예상하라.

  • Back up Plan을 가지고 A가 안될 경우 B플랜을 실행한다.
  • 예상하는 것까지는 괜찮은 관리자, 예상하여 B플랜을 가지고 B로 하면 된다는 것까지 알고 있으면 훌륭한 관리자.

이 글은 스프링노트에서 작성되었습니다.