글
애자일 프랙티스와 실용주의 적용 발표 준비
2009 이야기
2009/02/26 21:37
지난번 프로젝트는 요구분석부터 구현까지 전담해서 우리 팀이 구현할 수 있는 첫 번째 기회였다. 프로젝트 관리자였으나 규모가 작은 터라 주로 참여했던 대규모 프로젝트의 PM과는 역할이 달랐다. 본질적으로 PM의 직무를 우선해서 수행했으나 PL 역할도 하고, 때론 QA도 하고, 간헐적으로는 아키텍트 역할도 했다. 경험은 고스란히 전달하기 어렵지만, 프로젝트를 마친 후에 간단한 기사를 기고하기도 했다.
프로젝트 관리자 관점에서 본 애자일 프랙티스(Agile Prcatices)의 적용 사례(상)
프로젝트 관리자 관점에서 본 애자일 프랙티스(Agile Prcatices)의 적용 사례(하)
성공적인 프로젝트 종료로 우리는 비슷한 성격의 프로젝트를 다시 수주했다. 팀 규모는 줄었지만 같은 고객, 같은 팀인 터라 또 많은 것을 배웠다. 나 자신도 거의 일 년에 걸친 경험 가운데에서 전달 가능한 부분을 정리하고 싶은 욕심이 있다. 그래서 인수인계를 앞둔 프로젝트 막바지에서 발표를 자청했다. 이런 이벤트가 없더라도 차분히 자신을 쌓아가는 든 사람이면 좋겠지만, 아직 나는 그렇지 못하다.
틈틈이 생각을 정리해두긴 했지만, 막상 주어진 짧은 시간 안에 발표자료를 만들어서 보냈다.
(발표 자료는 수정하여 다음 글에 넣었음)
하고 싶은 이야기의 화두만 올려두었지 실제 무슨 이야기를 할지 아직 확실치는 않다. JCO 특성상 다양한 눈높이와 관심사를 가진 청중이 있다. 대체로 프로젝트 경험과 환경 개선에 대한 고민이 있어야 공감할 수 있는 주제인 터라 도구나 기술에 대한 관심이 많은 분에게는 발표자료가 적절하지 않다. 그래서 향후 우리가 만든 제품을 인수인계 받아 잘 활용할 수 있도록 우리의 경험을 전달하는 과정에서 만든 산출물을 정리해서 이슈 트래커와 작업 관리 도구인 Trac/Mylyn 활용 팁을 추가했다. 데모 시연 시간을 줄이려고 화면 캡쳐를 하는데 스무 장이 넘는다. 적어도 20분은 걸리겠다.
블로그에 메모했던 내용을 모아봐야겠다. 그래야, 그때로 돌아가 경험을 꺼내올 수 있을 테니까.
2008년 프로젝트 로그
발표 순서에 맞게 해당 내용을 구분하고 섞어봐야겠다.
말에 갇히거나 가두지 말자
반복의 가치
협업의 가치
PM/팀장의 첫 경험
진화하는 시스템
애자일 개발 사례
개발자의 애자일
흠.. 이제 준비가 한결 수월할 듯 하다.
프로젝트 관리자 관점에서 본 애자일 프랙티스(Agile Prcatices)의 적용 사례(상)
프로젝트 관리자 관점에서 본 애자일 프랙티스(Agile Prcatices)의 적용 사례(하)
성공적인 프로젝트 종료로 우리는 비슷한 성격의 프로젝트를 다시 수주했다. 팀 규모는 줄었지만 같은 고객, 같은 팀인 터라 또 많은 것을 배웠다. 나 자신도 거의 일 년에 걸친 경험 가운데에서 전달 가능한 부분을 정리하고 싶은 욕심이 있다. 그래서 인수인계를 앞둔 프로젝트 막바지에서 발표를 자청했다. 이런 이벤트가 없더라도 차분히 자신을 쌓아가는 든 사람이면 좋겠지만, 아직 나는 그렇지 못하다.
틈틈이 생각을 정리해두긴 했지만, 막상 주어진 짧은 시간 안에 발표자료를 만들어서 보냈다.
(발표 자료는 수정하여 다음 글에 넣었음)
하고 싶은 이야기의 화두만 올려두었지 실제 무슨 이야기를 할지 아직 확실치는 않다. JCO 특성상 다양한 눈높이와 관심사를 가진 청중이 있다. 대체로 프로젝트 경험과 환경 개선에 대한 고민이 있어야 공감할 수 있는 주제인 터라 도구나 기술에 대한 관심이 많은 분에게는 발표자료가 적절하지 않다. 그래서 향후 우리가 만든 제품을 인수인계 받아 잘 활용할 수 있도록 우리의 경험을 전달하는 과정에서 만든 산출물을 정리해서 이슈 트래커와 작업 관리 도구인 Trac/Mylyn 활용 팁을 추가했다. 데모 시연 시간을 줄이려고 화면 캡쳐를 하는데 스무 장이 넘는다. 적어도 20분은 걸리겠다.
블로그에 메모했던 내용을 모아봐야겠다. 그래야, 그때로 돌아가 경험을 꺼내올 수 있을 테니까.
2008년 프로젝트 로그
발표 순서에 맞게 해당 내용을 구분하고 섞어봐야겠다.
말에 갇히거나 가두지 말자
반복의 가치
- SRS(Software Requirements Specification)를 작성할 때 유의할 점
- 프로세스의 필요성(a.k.a 매뉴얼의 필요성)
- 소프트웨어 엔지니어링이란?
- 이터레이션(Iteration)과 진화(Evolution)
- 반복의 중요성을 반복해서 거론하다
협업의 가치
- '이슈 트래커' 관련 글은 어디에...
- 이슈트래커(trac) 설정 + 마이린(Mylyn) 연결
- 이슈트래커(trac) + Mylyn의 효용성
- 꼬리에 꼬리를 무는 '쾌적한 프로젝트 수행 환경' 만들기
- 작업(Task) 관리 진화
- 팀 협업의 중요성
- 공동작업시 묵비권 행사를 자제해주세요
- 진정한 의미의 리비전?
- 한번쯤 정리해둘 내용
PM/팀장의 첫 경험
- 회의시간 절감을 위한 개발팀 회의 프로세스
- 회의에서의 의사진행 기법
- 지루한 회의? 효과적인 커뮤니케이션
- 회의 관리자?
- 비전문에 꼭 필요한 내용
- 뻔한 얘기 같으나
- 도와주세요! 팀장이 됐어요
- 회고(Retrospective)를 회고하기
- 이해관계자 네트워크
- 스크럼(Scrum) 적용 일지
- 계획의 어려움
- 누구를 위해 일하는지 기억하라
- 프로젝트 팀과 포메이션
진화하는 시스템
애자일 개발 사례
개발자의 애자일
흠.. 이제 준비가 한결 수월할 듯 하다.
