일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 비용
- EVM
- 설치
- 달력
- 의존관계
- 단위
- 2010
- project server
- Sharepoint
- conf
- project server 2003
- 기간
- PROJECT
- 구성
- 2막1장
- PMBOK
- 일정
- ms project 2016
- EPM
- 2007
- 완료율
- PMP
- install
- ms project
- project server 2010
- MSP
- ff
- Server
- Outlook
- WBS
- Today
- Total
목록user story (2)
MS Project
※ User Story 작성 기준 - 6가지. 1. Independent – 상호 독립적. User Story의 Story Point 이중 추정을 방지하기 위해서 User Story 간에는 동일한 기능(작업 요소)이 포함서는 안됩니다. 서로 다른 User Story에 공통적인 작업 요소가 있다면 하나의 User Story에만 적용하고 다른 User Story에서는 그 요소를 가져다 활용합니다. 2. Negotiable – 변경 가능. User Story는 언제든지 폐기, 추가, 변경 등이 가능하도록 구성하며, 실제로 구현할 때 필요한 세부 내용은 해당 스프린트 계획 미팅에서 확정합니다. 3. Valuable – 가치. 개발자가 아닌 일반인(고객과 사용자)이 알 수 있는 용어로 기술합니다. 4. Estim..
스토리 포인트(SP)라는 녀석은 기존의 공수 산정을 할 때 들어난 단점들을 좀 커버해보자 하는 개념에서 출발했습니다. 기존의 산정 방법 중, 규모(소프트웨어 규모) 측정 단위는 LOC(Line of Code), FP(Function Point), 웹페이지 등이 있습니다. 기존 규모를 측정하는 것, 즉 이미 개발된 규모를 측정할 때 효과적입니다만 (사실 했던거 다시 하는 것은 쉽습니다) 그러나 요구사항의 불확실성이 높은 초기 단계에서 적용하면 정확도가 떨어지는 문제가 발생할 수 있고, 규모를 산정하는 사람의 기술적 역량과 실제 작업을 하는 사람의 기술적 역량이 다른 것도 정확한 산정에 문제가 됩니다. (초급, 중급, 고급, 특급 등 역량에 따라 작업 기간이 달라집니다.) 기존 산정 방법 단점 - 요약 1...