2002년 6월 27일 6시에 ProjectZephyrus 에 관해 정리하는 시간을 가졌다.

1. 진행 방법

  1. 프로젝트를 진행하면서 '잘된점' 에 대해 나열해 나갔다. (이 때는 잘된점만 이야기함) 처음엔 한명씩 돌아가면서 이야기했고, 한바퀴 돈 다음 생각나는대로 이야기했다.
  2. 프로젝트를 진행하면서 '잘못된점' 에 대해 나열해 나갔다. (이 때는 잘못된점만 이야기함) 역시 처음엔 한명씩 돌아가면서 이야기했고, 한바퀴 돈 다음 생각나는대로 이야기했다.
  3. 각각의 경우들에 대해서 그 원인을 파악하고, 대안을 생각해보았다. (시간이 조금 많이 흘러서 모든 경우들에 대한 대안은 내지 못하였다. 하지만, 이는 계속 해 볼 일이다. 그당시 잘 했던 점은 더 잘하기 위해, 잘못했던 점은 다시 실수하지 않기 위해)

2. 잘된점

  • deadline 을 잘 맞췄다. - 6월 10일까지 완료하기로 한 약속을 지켰다.
  • 서버팀의 문서화가 잘 되었다. - ProjectZephyrus/Server 참조.
  • Server Architecture 디자인이 잘 되었다. - 자신이 맡은 클래스에만 충실하면 되었다.
  • Pair Programming 에 신경을 썼다. - Pair Programming 을 위한 진행 전략이 있었다.
  • WORA 를 경험해볼 수 있었다 - 윈도우즈에서 개발/테스트 한 서버 프로그램을 별다른 수정없이 linux 서버인 ZeroPageServer 에서 돌릴 수 있었다.
  • CVS을 사용하면서 CVS의 유용함을 경험해볼 수 있었다.
  • 후기 기록이 잘 되었다.

3. 잘못된점

  • server 팀과 Client 팀의 전체 meeting 이 거의 전무했다.
  • 팀원들의 스케줄 관리가 어려웠다. (농땡이를 피우거나, 사람들이 프로젝트 외의 기타일로 바빠서 공동작업을 하는데 어려움)
  • IDE 가 팀별/개인별로 달라서 프로젝트 화일등을 업데이트해주어야 했다.
  • 클라이언트 파트가 Doc Convention 을 지키지 않았다.
  • Server Program의 Design Evaluation 을 못하는데에 대한 스트레스 - 현재 나의 디자인이 올바른 디자인인지 평가받지 못하여서 불안하다.
  • PP를 너무 지나치게 했다 - 서버팀의 경우 후반으로 가면서 '이건 차라리 각자 프로그래밍하는게 더 효율적이였을텐데' 하는 생각이 들었다.
  • 공부라는 본래의 목표보다 결과에 치중 - Program Output 이 본 목적이 아님에도 불구하고, 후배들과 끝까지 같이 진행하지 못하고 중간중간 단독진행을 하였다.
  • 초기 SPEC이 너무 추상적이였다. - 프로젝트 중간에 합류한 상규의 경우 프로젝트의 스펙을 이해하지 못했고, 완성된 Output 에 대한 그림을 그리지 못했다.
  • 초기 목적이 구체적이지 못했다.

4. 잘된 경우에 대한 원인 분석

  • deadline 을 잘 맞췄다.
    - 초기 모임시에 Spec 을 최소화했고, 중간에 Task 관리가 잘 이루어졌다. 그리고 Time Estimate 가 이루어졌다. (ProjectZephyrus/Client) 주어진 자원 (인력, 시간)에 대해 Scope 의 조절이 비교적 잘 되었다.

  • 서버팀의 문서화가 잘 되었다.
    - 서버팀 진행자인 neocoin 의 성실성

  • Server Architehcute 디자인이 잘 되었다.
    - 초기 Up Front Design 에 신경을 썼다. Design Pattern 의 도입으로 OCP (OpenClosedPrinciple) 가 잘 지켜졌다.

  • PairProgramming 에 신경을 썼다.
    - PairProgramming 전에 진행 전략을 세웠다. (5분 PP 라던지, PP 순서시 간단한 Modeling 뒤, Sequence Diagram 등을 그리고 난 뒤 진행을 한다던지, 후배들에게 프로그래밍이 완성되었을 경우에 어떠어떠하게 돌아갈 것이다 라고 미리 그 결과를 생각해보게끔 유도)

  • WORA 를 경험해볼 수 있었다.
    - Java Language 의 특성.

  • CVS을 사용하면서 CVS의 유용함을 경험해볼 수 있었다.
    - ZeroPageServer 에 CVS Web Client 를 설치하고, CVS에 대해 비교적 잘 아는 사람들이 다른 사람들과 PP를 하면서 그 장점을 목격하게끔 했다.
    - 추후 개인적 소스 컨트롤 (RCS 등을 이용)도 같이 실천하도록 하자.

  • 후기를 썼다.
    - 선배들이 후기 기록에 솔선수범하였고, 그러면서 사람들이 후기 기록이 장점을 인식하게 되었다.

5. 잘못된 경우에 대한 원인 분석

  • server 팀과 Client 팀의 전체 meeting 이 거의 전무했다.
    - 밑의 항목인 '팀원들의 스케줄 관리가 어려웠다' 와 관계됨. 팀원들의 열의가 부족했다. (특히 초반 프로젝트 참가자들), 팀원들이 '스케줄 조정' 에 대해 미숙했다.
    -

  • 팀원들의 스케줄 관리가 어려웠다.
    - 팀원들의 열의 부족과 연관. 우선순위에 대한 자각 부족. 체계적 시간관리능력의 부재.

  • IDE 가 팀별/개인별로 달라서 프로젝트 화일등을 업데이트해주어야 했다.
    - 개인들 별로 IDE 의 선호가 달랐다. (Eclipse, IntelliJ, JCreator )
    - 처음부터 고려하여 각 IDE별 Setting 화일을 업데이트 시켜주기. Batch File 등으로 자동화하기. IDE 의 통일 고려.

  • 클라이언트 파트가 Doc Convention 을 지키지 않았다.
    - 1002 의 성실성 부족. JavaDoc 의 시선분산 문제. 잦은 디자인 수정에 따른 잦은 Documentation 수정문제. 서버팀과의 대화 부족.
    - JavaDoc의 시선 분산 여부는 개인차와 주석에 대한 의견을 프로그램내에서의주석에서 토론되었다.

  • Server Program의 Design Evaluation 을 못하는데에 대한 스트레스
    - Design Evaluation 의 방법을 몰랐다.
    - Design Evaluation 을 꼭 해야 한다는 강박관념이 있다.
    - 선배의 입장에서 후배들에게 나쁜 디자인을 보여주면 안된다는 무언의 PairPressure 경험
    - DE를 공부하여 확인한다.
    - 꼭 DE 가 필요하진 않다. '개발을 진행해 나가면서 문제점이 발견되었을때' 디자인을 수정해도 늦지 않다.
    - egoless Programmer. 현재의 코드는 '나만의 것' 이 아니다. 같이 개발했으므로 그 팀의 책임일 뿐이다.

  • PP를 너무 지나치게 했다.
    - 서버팀에서 일의 작업량과 수준을 잘못 측정해서 과도한 PP가 있었다.

  • 공부라는 본래의 목표보다 결과에 치중, 초기 목적이 구체적이지 못했다.
    - 프로젝트의 목적이 공부 라는 인식의 부족. 공부한 부분에 대해서 (Swing, Java Network 등)에 대한 문서화가 없었다. SPEC 과 Output 에 치중한 점이 있다.

  • 초기 SPEC이 너무 추상적이였다.
    - SPEC 에 대한 구체적 문서화 부족. 초기 문서화 대신에 팀의 모임시 대화로 대체하였는데, 후에 추가 멤버가 제시한 의견, 문서화도 부족했지만, 후속 멤버의 피드백 역시 부족하였다.


  • (아직 정리하지 못한 내용에 대해 추후 기억을 위한 키워드) - 추측록, 신기통, 최한기, Vision, Propose, Problem, Solution
Retrieved from http://wiki.zeropage.org/wiki.php/ProjectZephyrus/Afterwords
last modified 2021-02-07 05:24:06