MS Project

크게 3단계로 Agile Team 구성과 Agile Project를 수행합니다. 각 단계의 세부 사항은 다음에 다룰 예정입니다. 이 글은 코칭 자료의 일부이며 아래와 같이 프로젝트 목적과 팀 환경 구성 그리고 프로세스와 결과물의 밸런스를 애질리티하게 유지하는 것입니다. 마지막 단계는, 정형화된 Agile process도 중요하지만 팀의 애질리티한 마인드와 접근방식이 핵심입니다. 한마디로 무경계 접근방식이 변화에 적극적으로 대응할 수 있고 Agile Mindset의 본질입니다.

제가 만약, MS Word 프로그램의 메뉴와 사용법을 100% 완벽하게 숙지하고 자유자재로 사용할 수 있다고 해도, 제가 멋진 드라마 대본을 쓴다거나 베스트셀러 소설가가 되지는 않습니다. 늘 말씀 드리는 부분이, MS Project는 프로젝트 관리 이론과 방법론을 그대로 구현한 소프트웨어입니다. 프로젝트 관리 이론, 방법론 등을 알고 계시면 MS Project가 얼마나 높은 생산성을 제공해 드리는지 그 가치를 쉽게 느끼실 수 있습니다. MS Project 365 버전(간편 설치, 구독 제품)의 경우 Agile Scrum과 Kanban을 지원하고 있습니다. JIRA 하위 버전(저렴버전)이나 Notion의 보드와 같이 보드를 지원하는데, 이들과 다른 점은 블랙홀 증후군을 완벽하게 해결할 수 있다는 장점이 있..

※ 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...