- 진행 : 김창준
- 참여자 : 강석천, 류상민, 이상규, 이영서
1. 진행 방법 ¶
- 프로젝트를 진행하면서 '잘된점' 에 대해 나열해 나갔다. (이 때는 잘된점만 이야기함) 처음엔 한명씩 돌아가면서 이야기했고, 한바퀴 돈 다음 생각나는대로 이야기했다.
- 프로젝트를 진행하면서 '잘못된점' 에 대해 나열해 나갔다. (이 때는 잘못된점만 이야기함) 역시 처음엔 한명씩 돌아가면서 이야기했고, 한바퀴 돈 다음 생각나는대로 이야기했다.
- 각각의 경우들에 대해서 그 원인을 파악하고, 대안을 생각해보았다. (시간이 조금 많이 흘러서 모든 경우들에 대한 대안은 내지 못하였다. 하지만, 이는 계속 해 볼 일이다. 그당시 잘 했던 점은 더 잘하기 위해, 잘못했던 점은 다시 실수하지 않기 위해)
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 의 조절이 비교적 잘 되었다.
- 서버팀의 문서화가 잘 되었다.
- Server Architehcute 디자인이 잘 되었다.
- PairProgramming 에 신경을 썼다.
- PairProgramming 전에 진행 전략을 세웠다. (5분 PP 라던지, PP 순서시 간단한 Modeling 뒤, Sequence Diagram 등을 그리고 난 뒤 진행을 한다던지, 후배들에게 프로그래밍이 완성되었을 경우에 어떠어떠하게 돌아갈 것이다 라고 미리 그 결과를 생각해보게끔 유도)
- WORA 를 경험해볼 수 있었다.
- CVS을 사용하면서 CVS의 유용함을 경험해볼 수 있었다.
- ZeroPageServer 에 CVS Web Client 를 설치하고, CVS에 대해 비교적 잘 아는 사람들이 다른 사람들과 PP를 하면서 그 장점을 목격하게끔 했다.
- 추후 개인적 소스 컨트롤 (RCS 등을 이용)도 같이 실천하도록 하자.
- 후기를 썼다.
- 선배들이 후기 기록에 솔선수범하였고, 그러면서 사람들이 후기 기록이 장점을 인식하게 되었다.
5. 잘못된 경우에 대한 원인 분석 ¶
- server 팀과 Client 팀의 전체 meeting 이 거의 전무했다.
- 밑의 항목인 '팀원들의 스케줄 관리가 어려웠다' 와 관계됨. 팀원들의 열의가 부족했다. (특히 초반 프로젝트 참가자들), 팀원들이 '스케줄 조정' 에 대해 미숙했다.
-
- 팀원들의 스케줄 관리가 어려웠다.
- 팀원들의 열의 부족과 연관. 우선순위에 대한 자각 부족. 체계적 시간관리능력의 부재.
- 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
