프로젝트 이해 관계자에게 주어진 권리

  1. 개발자는 비즈니스와 목표에 대해 배운다.
  2. 개발자는 자신들이 사용하는 언어로 배우고 말한다.
  3. 개발자는 요구 사항을 인식하고 이해한다.
  4. 프로젝트 이해 관계자와 함께 일하는 작업의 일환으로 개발자가 사용하는 창조물에 대해 설명한다. 창조물에는 생성을 위한 모델(예: 사용자 스토리, 핵심적인 UI 프로토타입)이나 표현 결과물(예: UML 배포 다이어그램) 등이 있다.
  5. 개발자를 존중하기를 기대한다.
  6. 요구사항을 위한 아이디어와 대안을 듣는다.
  7. 제품을 쉽게 사용하도록 특징을 기술한다.
  8. 재사용을 허용하고, 개발 시간을 단축하거나 개발 비용을 줄이도록 요구사항을 조정할 기회를 제공한다.
  9. 선의에서 나온 추정값을 제공한다.
  10. 기능과 품질 요구를 충족하는 시스템을 제공한다.

프로젝트 이해 관계자에게 주어진 책임

  1. 프로젝트 팀에게 자원(시간, 돈, ...)을 제공한다.
  2. 개발자에게 비즈니스에 대한 교육을 진행한다.
  3. 요구사항을 제공하고 명확하게 하기 위해 시간을 투자한다.
  4. 요구사항을 구체적이고 정확하게 만든다.
  5. 시의적절한 결정을 내린다.
  6. 비용과 가능성이라는 개발자 추정을 존중한다.
  7. 요구사항 우선 순위를 정한다.
  8. 개발자가 만들어낸 유효한 작업과 관련해 시의적절한 검토와 피드백을 제공한다.
  9. 요구사항 변경이 일어나면 바로 알려준다.
  10. 조직에 필요한 소프트웨어 프로세스를 직접 만든다. 프로세스를 따르는 동시에 필요할 때 수정하도록 적극적으로 도와준다.


출처 : IBM Developer Woks

Posted by spponge

댓글을 달아 주세요

  1. Favicon of http://youlsa.com BlogIcon youlsa 2008.09.01 01:26  댓글주소  수정/삭제  댓글쓰기

    참 당연한건데 실생활에서는 무시되는 경우가 너무 많은 것 같습니다. 조금씩 나아지고는 있습니다만... 우리나라의 소프트웨어 산업이 전체적으로 낙후된 데에는 이런 원인이 꽤 큰 역할을 하고 있는 것 같습니다.

  2. Favicon of https://portno80.tistory.com BlogIcon spponge 2008.09.06 08:59 신고  댓글주소  수정/삭제  댓글쓰기

    그렇죠... 실속 없이 비대해진 IT 산업 구조에서 원인과 결과가 꼬리를 물고 도는 형국이라 현실을 개선하기란 참 어렵습니다. 그렇거나 말거나 노력은 개속 되어야죠. 그것이 우리의 희망이니까요. :D