일반적인 소프트웨어 개발 환경에서 프로젝트 마감 은 프로젝트의 끝을 나타냅니다.
마지막 단계는 선택 사항이지만 참가자에게는 매우 동기가됩니다. :-)
이것을 스크럼과 대조하십시오. 나는 스크럼이 백 로그의 스토리에서 실행된다는 것을 알고 있습니다. 따라서 기술적으로 모든 반복은 특정 이야기를 닫습니다. 여기에 두 가지 질문이 있습니다.
또는 프로젝트 마감 기간이 T & M 프로젝트 에 전혀 적용되지 않습니까?
답변:
여러 개의 동시 프로젝트에서 작업하는 그룹의 경우 프로젝트 마감은 어떻게 적용됩니까?
첫째, "복수의 동시 프로젝트"는 정말 나쁜 생각으로 간주됩니다. 스크럼의 요점은 질주하고 수행하는 것입니다. 다른 스프린트를 시작하기 위해 프로젝트를 전환하는 것은 지장을줍니다. 한 번에 두 개의 프로젝트를 수행하는 것은 스프린트가 아닙니다. 엉망입니다.
그러나 스크럼은 민첩하지 않은 (폭포) 방법과 다르지 않습니다. 백 로그가 약 0으로 줄어도 여전히 완료된 것입니다. 민첩한 접근 방식 대신 폭포 접근 방식을 사용하는 것처럼 완료됩니다.
백 로그가 0이 아닌 경우도 있지만 고객은 기뻐하며 더 이상 원하지 않습니다. 그래서 당신은 끝났어. 일반적으로 폭포보다 더 빠르고 저렴하게 수행됩니다 (모든 것을 구축해야하며 아이디어조차도 쓸모없는 것으로 판명되었습니다).
여러 그룹이 포함 된 프로젝트의 경우이 개념이 어떻게 적용됩니까?
여러 그룹이있는 비 스크럼 프로젝트와 동일합니다. 사람들에 대한 변화는 없습니다. 그들은 여전히 좋은 파티를 좋아합니다.
또는 프로젝트 마감 기간이 T & M 프로젝트에 전혀 적용되지 않습니까?
청구가 업무의 성격이나 마지막 행사에 대해 왜 변경합니까?
나는 일반적으로보다 체계적인 프로젝트 관리 프레임 워크 내에서 스크럼 관행과 같은 민첩한 방법을 봅니다. 이것은 전혀 모순되지 않습니다. 애자일은 제공을 위해 노력하며, 목표는 올바른 소프트웨어를 더 빠르게 제공하는 것입니다. 개발자와 지분 보유자 간의 상호 작용에 도움이됩니다. 고정 기간 프로그램의 일부로 또는 개방형 향상을 위해 사용할 수 있습니다.
따라서 PM이 타임 라인, 비용 및 기타 종속성을 관리하는 방식으로 나머지 프로젝트 관리를 전통적인 방식으로 관리 할 수없는 이유는 없습니다. 완료되면 평소와 같이 폐쇄 이벤트가 있습니다.
나는 금융 분야에서 일하고 있으며 때로는 새로운 규제가 발생하거나 새로운 거래소가 나타나고 우리는 돌로 정해진 날짜에 대한 라이브 날짜를 가지고 있습니다. 우리는 여전히 딜리버리를 위해 애자일 방법을 사용하지만보다 전통적인 프로젝트 관리 에이전트 프레임 워크 내에서 제 시간에 전달되도록합니다.
작업 단위를 추정하고 사용 가능한 시간 내에 달성 할 수있는 솔루션을 선택하면 훌륭한 개발자가 될 수 있습니다 (내가 말해야 할 것 중 하나).
스크럼에서 모든 애자일 기술과 마찬가지로 프로젝트는 사소한 일이지만 팀은 함께 있습니다. 따라서 "프로젝트 클로저"의식은 없습니다. 다른 왁스가있는 동안 프로젝트가 울리는 대신에. 백 로그 항목의 흐름은 점진적으로 서로 바뀝니다. 팀은 그 차이를 거의 알지 못합니다.
실제로, 팀은 동시에 두세 가지 다른 프로젝트를 수행하고있을 수 있습니다. 다시, 그들은 차이를 거의 알지 못합니다. 백 로그 항목은 각 스프린트 시작시 팀에 들어 와서 팀이 구현합니다. 그것들은 모두 하나의 프로젝트에 속하거나 여러 프로젝트로 균등하게 분할 될 수 있습니다. 팀은 상관하지 않습니다. 팀은 제공된 백 로그 항목 만 구현합니다.
비즈니스가 프로젝트 우선 순위를 변경해야하는 경우 백 로그 항목의 흐름을 팀으로 변경하기 만하면됩니다.
여기서 논의하고있는 것 중 일부는 외부 트리거를 기다리지 않고 당연히 자주 발생하는 문서 및 릴리스와 같은 대부분의 민첩한 프로세스에 포함됩니다. 물론 고객 유형과 비즈니스 유형에 따라 항상 그런 것은 아닙니다. 예를 들어 외부 기관이 소유 한 더 큰 시스템의 단일 부분을 만드는 경우, 일반적으로 프로세스를 진행하는 날짜가 있으며 해당 날짜는 추가 하우스 키핑 및 파티를 수행하기에 적절한 시간입니다. 다른 경우, 고객이 내부 고객 인 경우에도 비즈니스는 비즈니스 이정표 / 주요 산출물 / 기타 완료를 인식하여 프로젝트 종료 / 파티 종료를 다시 요구할 수 있습니다. 회사가 릴리스 계획에 참여하는 경우 자연스러운 중단 점을 제공하지만 그렇지 않은 경우에도 비즈니스 중심의 성공 척도를 확보하는 것이 좋습니다. 즉, 프로젝트는 더 이상 엔지니어링 프로세스의 기능이 아닐 수 있지만 확실히 비즈니스의 일부가 될 수 있으며 프로젝트와의 축하 / 거래는 회사 문화의 일부가 될 수 있으며 여전히 그래야합니다.