'프로젝트 로그'에 해당되는 글 143건

  1. 2008/10/06 업무수행능력의 세 가지 차원
  2. 2008/10/02 Agile Context in Development라... 그림 좋네 (3)
  3. 2008/09/30 이슈트래커(trac) 설정 + 마이린(Mylyn) 연결
  4. 2008/09/18 비전문에 꼭 필요한 내용
  5. 2008/08/26 프로세스의 필요성(a.k.a 매뉴얼의 필요성) (2)
  6. 2008/08/08 이슈트래커(trac) + Mylyn의 효용성 (1)
  7. 2008/07/25 도와주세요! 팀장이 됐어요
  8. 2008/07/08 Xper 메일링 리스트 쓰레드
  9. 2008/07/02 [자료] Business Process Maturity (2)
  10. 2008/06/27 소프트웨어 엔지니어링이란? (1)
  11. 2008/06/25 애자일 선언 in Practice (3)
  12. 2008/06/19 뒤늦은 애자일 논쟁 합류 > 다같이 모여서 터놓고 얘기하는 것보다 > 완전 동의 (2)
  13. 2008/06/18 실용주의자 in 형식주의 공화국(?) (4)
  14. 2008/06/14 난데 없는 애자일 논쟁? (2)
  15. 2008/06/14 애자일 진영의 초대 (11)
  16. 2008/06/13 SI 프로젝트에서도 애자일 프로세스는 가능하다 (3)
  17. 2008/06/05 회의에서의 의사진행 기법 (1)
  18. 2008/06/05 회고(Retrospective)를 회고하기 (1)
  19. 2008/05/31 프로젝트 전체 클래스 개수/Loc 등을 헤아리기
  20. 2008/05/23 이터레이션(Iteration)과 진화(Evolution) (4)
  21. 2008/05/22 작업(Task) 관리 진화
  22. 2008/05/15 반복의 중요성을 반복해서 거론하다
  23. 2008/05/15 한번쯤 정리해둘 내용 (4)
  24. 2008/05/09 4. 이해관계자 네트워크 (4)
  25. 2008/05/01 팀 협업의 중요성
  26. 2008/04/29 뻔한 얘기 같으나
  27. 2008/04/25 진정한 의미의 리비전? (4)
  28. 2008/04/25 꼬리에 꼬리를 무는 '쾌적한 프로젝트 수행 환경' 만들기
  29. 2008/04/10 지루한 회의? 효과적인 커뮤니케이션 (1)
  30. 2008/04/07 공동작업시 묵비권 행사를 자제해주세요 (5)

업무수행능력의 세 가지 차원

프로젝트 로그 2008/10/06 13:24
Three Dimensions of High Performance 을 보면 공식을 정의하고 있고

Performance = Ability * Passion

패턴을 정의하고 도식화 했다.
http://leadinganswers.typepad.com/.a/6a00d834527c1469e201053549e7e1970b-pi
설명해가는 방식이 효과적으로 보인다.

자세한 내용은 Three Dimensions of High Performance 을 보시라
이올린에 북마크하기(0) 이올린에 추천하기(0)
Performance, 업무성과
트랙백 0 : 댓글 0

Agile Context in Development라... 그림 좋네

프로젝트 로그 2008/10/02 13:39

좋아...

http://photos.smugmug.com/photos/384746511_Un8EL-L.gif


이건 한방에 와닿지는 않지만, 경험이 없어서 그런 것 같고...

http://photos.smugmug.com/photos/384746474_PvgoW-L.gif

출처: Agile Product Management: Providing Context

이올린에 북마크하기(0) 이올린에 추천하기(0)
agile, Agile Product Management
트랙백 1 : 댓글 3

이슈트래커(trac) 설정 + 마이린(Mylyn) 연결

프로젝트 로그 2008/09/30 12:36
사용자 삽입 이미지
Trac에서 사용하는 개념들. 다른 것들에 비해 고민 필요한 속성이 두 가지 있다.

Component - The project module or subsystem this ticket concerns.
Milestone - When this issue should be resolved at the latest. [각주:1]

컴포넌트를 다음과 같이 나눠보았다.

사용자 삽입 이미지
구현 제품의 세 가지 버전을 별도로 관리하지 않고, 컴포넌트로 분류한 것이다.

사용자 삽입 이미지

마일스톤 수립은 트랙 로드맵[각주:2]을 참조해서 정책을 결정했다. 아래 보이는 것처럼 trac의 Admin 메뉴를 통해서 설정을 변경한다.

사용자 삽입 이미지
복수의 버전 정책을 유지하면 여러 개의 시계열을 함께 보기 때문에 복잡하긴 하지만, 전체 버전을 함께 관리해야 하는 소규모 팀에는 이런 방법이 적절할 듯 하다.
사용자 삽입 이미지

이제 마이린으로 연결해보자. 가니메데를 설치하면, 기본적으로 trac connector는 없다. Mylyn Extra 업데이트 사이트에서 trac connector를 찾을 수 있다.


Connector를 설치하고 나서 Task Repositories 뷰에서 Add Task Repository 메뉴를 클릭한다.


이제 Repository type 선택창에서 Trac이 뜬다.



관련글:
2008/08/08 - [프로젝트 로그] - 이슈트래커(trac) + Mylyn의 효용성2007/11/29 - [알립니다/IBM DW 리뷰] - [리뷰] 이슈 트래커 개발자가 들려주는 이슈 트래커 이야기, Part 1: 무엇을 어떻게 골라쓸까
2008/05/02 - [자바 프로그래밍/이클립스 노하우] - Mylyn 버전 문제로 인한 로그인 오류
2008/05/07 - [프로젝트 로그] - 작업(Task) 관리 진화


  1. 설명 출처: http://trac.edgewall.org/wiki/TracTickets [본문으로]
  2. http://trac.edgewall.org/roadmap [본문으로]
이올린에 북마크하기(0) 이올린에 추천하기(0)
Trac, 이슈트래커
트랙백 0 : 댓글 0

비전문에 꼭 필요한 내용

프로젝트 로그 2008/09/18 17:13
프로젝트 초반 비전문(vision)을 작성할 때, 구성 즉, 주요 내용에 대해서 고민을 했다. 그런데 실제 비전은 산개해서 표현되는 경우가 많다. 오히려 비전문 보다는 구전으로 전파되는 경우가 흔하고, 사업계획서나 착수보고서에 묻어나기도 한다. 정작 비전문을 Well-formed(?)로 써서 제출해버리고 마는 경우도 종종 있었다. 그럴 바엔 애자인 선언처럼... 짧은 경구가 효과적일런지도 모른다...

여튼.. 다음에 비전/비전문을 기술할 때 참조할만한 내용이 있어 옮겨둔다.

Document the vision with what success is, why it's important, and how you know you've achieved it.

그리고 체크 리스트용 질문

Questions
  • Discussing the vision has led to contentious arguments. Should we stop talking about our vision?
  • Our organization already has a template for vision statements. Can we use it?
  • Our visionary finds it very difficult to communicate a cohesive vision. What can we do when it changes?
  • Can individual iterations and releases
  • Isn't it a risk to reduce the amount of documentation?

출처: The Art of Agile Development: Vision
이올린에 북마크하기(0) 이올린에 추천하기(0)
Vision, 비전, 비전문
트랙백 0 : 댓글 0

프로세스의 필요성(a.k.a 매뉴얼의 필요성)

프로젝트 로그 2008/08/26 15:21
외국물 먹은 분들이 조직을 세팅하면 두드러지게 강조하던 것이 매뉴얼이다. 대학원 랩 교수님도 그런 부류에 속하는 분이었기에, 워크숍 매뉴얼을 만들었던 기억이 있다. 얼마전 TV에서 모리오카 냉면 양산에 성공한 재일동포 사업가를 다루는 프로가 있었다. 냉명회사 사장님은 역시나 매뉴얼을 강조했다. 누가 만들어도 똑같은 맛을 내기 위해서...

zdnet에 프로세스 관련 기사가 올라왔는데 아래 내용이 눈에 띈다. 누가 프로세스 혹은 매뉴얼 작성에 대해 거부감을 나타낼때 참조할만하다.
IT에서는 프로세스가 없는 경우 어떤 현상이 나타날까? 경험에 의하면 프로세스가 없는 IT조직은 다음과 같은 특징을 보인다.
. 신입사원들이 할 일이 없다.
. 요청한 사항이 어떻게 처리되고 있는지 또는 누락이 되었는지 내부에서는 알 길이 없다.
. 새로운 장비가 들어오거나 장애가 발생하면 그제야 바쁘게 움직인다.
. 업무노하우는 IT부서의 고참만이 알고 있다.
. 유능한 직원에게는 전화도 몰린다. 따라서 바쁜 사람만 늘 바쁘다.
. 며칠 동안 열심히 IT 업무를 했지만 그 노력은 어디에도 나타나지(심지어 월간보고에도) 않는 경우가 있다.
. 업무의 시작과 끝이 불분명하여 늘 찜찜하다.
. 다른 팀으로 넘기거나 문의한 업무가, 처리 되거나 피드백이 왔는지 또는 무시되었는지 파악하기가 어렵다.

프로세스 정의의 본질은 매뉴얼 작성과 다르지 않다.

이올린에 북마크하기(0) 이올린에 추천하기(0)
매뉴얼, 프로세스
트랙백 2 : 댓글 2

이슈트래커(trac) + Mylyn의 효용성

프로젝트 로그 2008/08/08 15:00
효용성을 내가 혹은 팀이 수고한 만큼 대가를 받느냐 차원에서 얘기해보자. 얼마전 기술이슈에 대한 논의 중에 CI 효력이 크지 않다는 얘기를 한 적이 있다. 물론, 거기에는 상황적인 이유가 있었다. 'CI가 효과가 없다.' 혹은 '있다'고 하는 것을 무턱대고 일반화 할 수는 없다. 이전에도 언급한 바 있지만, CI 환경을 구성하고 프로젝트에 적용하면서 얻은 교훈(Lessons Learned)은 예상과 많이 달랐다. 애초에 의도했던 일종의 진보된 딜리버리 프로세스 구축은 만만하지 않았다. 두드러진 장벽(challenge)를 공유해보면
  • 환경 독립적이고 테스트가 필요한 부분을 효과적으로 테스트하는 것의 어려움(배포 대상 WAS, 배포 IP, 연동이 필요한 경우 상대 서버/클라이언트 정보 등)
  • 의존하는 라이브러리(걔가 또 의존하는 라이브러리, 또 걔가 ...)의 체계적 관리
  • 변경 반영 > 패키징(Packaging) > 릴리즈(Relase) 프로세스 관리와 관계자에 대한 공지
  • 이슈트래커를 통한 작업 관리와 조직/고객사 대상 보고 체계에 따른 작업 관리 수준의 불일치 혹은 일관성 결여
물론, 여기에는 사람의 문제는 아예 뺐다. 새로운 것을 거부하는 사람들을 설득하기 류는...

5개월째 적용하면서 예상치 못하게 얻은 것은
  • 빠른 피드백 루프
  • 요구사항의 정밀한 관