프로젝트 진행 상황 (애자일)을 고용주 (프로그래머가 아닌 사람)에게보고하는 방법은 무엇입니까?

진척 상황을 고용주에게보고하는 데 문제가 있습니다. 저는 학교의 (기술이 아닌) 부서의 소프트웨어 프로젝트를 담당하는 파트 타임 프로그래머입니다.

담당자 :
1. 실제로 소프트웨어를 사용하고 기능 요청을 제기하는 직원
2. 내 상사 (비 프로그래머)는 그녀가 소프트웨어 사용자가 아닙니다.

프로젝트의 본질 :
타사에서 구매 한 기성품 소프트웨어입니다. 부서의 요구를 충족시키기 위해이 소프트웨어의 기능을 수정하거나 추가해야합니다. 학기 내내 사용해야하는 소프트웨어입니다. 처음에 모든 기능을 사용해야하는 것은 아닙니다.

따라서 우리는 민첩한 모델을 사용합니다. 직원이 특정 기능을 필요로 할 때 요청을 제기하고 변경합니다. 학기 말까지 필요한 모든 기능이 향상되고 구현 될 것으로 생각합니다.

문제 :
상사가 나에게 진행 상황을 물었을 때마다 대답하는 방법을 모르기 때문에 대답 할 수 없습니다. 필요한 모든 기능의 전체 목록이 없습니다. 지난 주에 제기 된 기능을 완료했지만 새 기능도 제공되고 있으며 그 정도를 알지 못하므로 상사에게 "완료"했다고 말할 수 없습니다. "완료율이 몇 개인 지"또는 "xxx로 완료 할 것"이라고 말할 수 없습니다. 때때로 3 개의 요청 중 2 개를 완료 할 수 있습니다. 2 번을 완료했지만 아직 완료되지 않은 기능이 하나 있습니다. 오랜 시간이 지난 후, 나는 "항상 끝나지 않은 무언가가 너무 길다"고 들린다.

진행 상황을보고 할 수 없으면 정말 나빠 보입니다. 내가 한 일이 아니라 사람들에게 알리는 방법에 관한 것입니다. 내가 관리자이고 직원이 몇 달 동안 진행 상황을보고하지 않으면이 사람도 능력이 없다고 느낄 것입니다.

"소프트웨어 수정의 상태 / 진행 상황"과 같이 간단하게보고하거나 질문에 대답하는 방법을 알고 있습니까?

업데이트 내 상사는 개발 작업에 직접 관여하지 않으므로 내가하는 일이나 프로그램 작동 방식에 대한 실마리가 없습니다. 그녀는 바쁘기 때문에 정기적으로 만나지 않으며 주 사용자가 아니기 때문에 시간 낭비라고 생각합니다. 그녀는 프로그램의 세부 사항을 모릅니다.

소프트웨어를 사용하고 더 잘 알고있는 직원을 정기적으로 만나고 있습니다.

나는 상사에게 진행 상황을 설명하기가 어렵다고 느낀다.

이것은 독립적으로 일하는 프로그래머이고 기술이 아닌 사람에게보고 할 때 흔히 발생하는 문제입니다.

그런 사장들은 대부분 몇 가지를 알아낼 수 있기를 원합니다.

• 사용자는 얼마나 행복합니까?
• 사용자가 원하는 일이 있습니까?
• 당신이하고있는 돈의 가치가 있습니까?

아시다시피, 상사는 정말 바빠서 배울 시간이없고 어쨌든 관심이 없습니다.

제가 당신이라면, 일주일에 한 번 보고서를 이메일로 보내드립니다 :

• 시작시 "실행 요약": "이번 주에 3 개의 기능을 완료하고 2 개의 새로운 기능 요청을 받았습니다. 이번 주 초에 11 개의 완료되지 않은 기능 요청이 있었고 마지막에 10이있었습니다."
• 각각 짧은 문장으로 된 기능 상태 목록은 세 그룹으로 나뉩니다.
  1. 주중에 한 기능
  2. 주중에 온 기능 요청
  3. "백 로그"의 다른 기능
• 비 기술적 언어를 사용하는 것이 복잡하거나 특이한 사항에 대한 간단한 설명.

내가 당신의 상사 였는데 아무런보고도받지 못했다면 매주 그 사실을 알게되어 매우 기쁩니다. 그리고 다른 것을 원하면 부탁드립니다.

당신이 완성되었는지 또는 얼마나 멀리 가야하는지 알 수있는 방법이없는 것 같습니다. 괜찮아.

요청 된 기능 목록, 수행 된 기능, 진행 중 또는 시작되지 않은 기능을 유지하십시오. 각 범주의 총계를 주 단위로 차트로 추적하십시오. 그러면 종료일까지 추정 할 수있는 일련의 포인트가 제공됩니다. 즉 ( "완료된"기능 수만보고)

• 1-2 주 완료
• 2 주차-5 주차 (1 주차 2 주, 2 주차 3 ​​주차)
• 3 주차-8 주차
• 넷째 주-12

16 주가있는 경우 약 48 개의 기능을 완료 할 수 있습니다 (일부 기능은 다른 기능보다 크거나 작은 것에 대해 너무 걱정하지 마십시오. 4-5 주 후에는 평균을냅니다). 그런 다음 X 개의 기능 만 처리 할 수 ​​있다고 모든 사람에게보고 할 수 있습니다. 프로젝트가 끝날 무렵, 가장 중요한 것은 필요한 기능을 제공했으며 지난 2 주 동안 자신을 죽이지 않았다는 것입니다. 이러한 방식으로보고하면 주요 요구 사항을 최대한 빨리 해결할 수 있습니다.

보고하고 싶은 다른 것은 용량이 얼마나되는지입니다. "2 개의 기능 요청 만 받았지만 3 개를 처리 할 수있었습니다. 직원에게 더 많은 기능을 더 빨리 올리도록 요청할 수 있습니까?"

내가 귀하의 질문에 완전히 답변했는지 확실하지 않으므로, 후속 질문을 자유롭게 요청하십시오 ...

세 단어는 ... 차트를 태워.

민첩한 중독자이든 개발자를 담당하는 사람이든 고용주는 번 다운 차트에 감사합니다 .

모든 사람은 프로젝트가 언제 완료되는지 이해하고 어제 날씨 를 활용 하면 프로젝트의 완료를 예측하는 가장 정확하고 현실적인 방법을 제공 할 것입니다.

나는 적어도 일주일에 한 번 일대일로 일하고 그 시점에서 관리자와 우선 순위를 논의 할 수 있다고 가정합니다. 그의 관점에서 중요한 점은 다른 사람 등)-따라서 관리자가보기 좋게 보이게하는 작업과 수행해야 할 작업의 총량을보고 할 수 있습니다.

귀하의 관리자는 아마도 1 분 단위의 고장을 찾고 있지 않을 것입니다. 그는 작업이 완료되고 있는지, 중요한 것들이 더 많은 관심을 끌고 있는지, 진행이 차단되어 짐이나 유휴 상태에서 익사하지 않는지 확인하려고합니다.

진정한 민첩한 프로세스에서는 항상 물건이 들어오지 만, 관리자와 관리자는 가장 중요하고 가장 필요한 것이 무엇이고 현재 작업 기간에 어느 정도의 양이 될지에 동의합니다 (1 주일이든, 두 주, 한 달에 ...), 필요한 경우 작업을 작은 조각으로 나누면 조각이 기간에 맞게됩니다.

몇 주가 걸리는 주요 데이터베이스 점검은 백업 설정, 백업 확인, 새 데이터베이스 레이아웃 설계, 변환 소프트웨어 작성 및 테스트, 롤백 설정 및 테스트, 변환 시도와 같은 방식으로 분류 될 수 있습니다. 동일한 위치에서 롤백을 시도한 다음 마지막으로 변환을 수행합니다. 이들 각각은 아마도 1 주 (또는 그 이하) 청크로 나눌 수 있습니다. 2 ~ 3 주가 소요될 수있는 경우 다음 회의에 어느 정도 진행되었는지 (2 주 동안 50 %, 3 주 동안 33 % 등)보고합니다.

이상적으로, 당신은 당신이해야 할 일과 지금 할 일이있는 차트를 가지고 있고, 당신이 진행하면서 "지금"항목을 체크합니다. 이를 통해 관리자는 걸어서 목록에있는 것과 비교 한 것의 수를 확인할 수 있습니다.

매주 한 번 (애자일 프로세스의 반복 / 스프린트 길이가 예제를 위해 일주일이라고 가정합니다) 다음을 수행하십시오 .

• 새로운 작업을 직원에게 시연하여 요청이 완료되었는지 확인
• 일주일 동안 완료 한 요청 수를 상사에게보고하고 해당 요청을 식별 / 설명하십시오. 짧은 요약을
• 주 동안 백 로그 / 큐에 추가 된 새로운 요청 수와 총 요청 수를 상사에게보고
• 다음주에 어떤 일을 할 계획인지 상사에게 말하십시오. 즉, 현재 우선 순위. 그녀가 그들을 확인하거나 바꿀 수있는 기회가 있습니다.
• 그 후 1-2 주 동안 계획이 무엇인지 상사에게 알리십시오.

나는 상사가 속도 , 제품 소유자 또는 번 다운 차트 와 같은 민첩한 용어 를 관리하거나 이해하기에 충분히 기술적이지 않다고 생각합니다 . 위의 템플릿은 이러한 전문 용어를 피하고 "백 로그"및 "대기열"과 같은 간단한 단어를 상식적으로 사용하므로 상사와 쉽게 대화 할 수 있어야합니다.

나는 나의 속도를 그 / 그녀의 주요 통계로 사용할 것이다. 특정 주 (또는 다른 기간) 동안 "합의한"작업 / 기능 수와 완료 한 작업 수를 보여줍니다. 이것에서 나는 더 중요한 기능 구현과 이것이 과거 반복에서 변경된 이유에 대해 언급 할 것입니다. 당신은 또한 당신이 직면하고 능가한 장애물과 그것이 당신의 속도에 어떤 영향을 미쳤는지 언급 할 수 있습니다.

상사가 알고 싶어하는 다른 통계에는 발생 된 새로운 버그 보고서 수, 버그 보고서 종결 및 제출 된 새로운 기능 요청이 포함될 수 있습니다. 어떤 것이 가장 중요한지 결정하기 위해 직접 요청하거나 최선의 판단을해야합니다. 결국, 나는 진보의 기본 개요를 제시하고 그가 알고 싶은 다른 것이 있는지 묻습니다. 모든 보스는 당신이 발전하고 있으며 최선을 다하기 위해 필요한 것이 있다는 것을 알고 싶어합니다.

주간 보고서 커밋 제안 : 요청 된 기능을 나열합니다. 변경된 기능을 기록하십시오. 당신이 한 일을보고하십시오.

관리자가 이해하는 방식으로 결론을 내리려고합니다.

Total Recieved Feature Requests:
Requests Completed:
Requests since last Update:
Estimated Time to required to complete remaining Requests:

관리자가 프로그래머가 아니기 때문에 정확한 완료 날짜를 알고 있다고 생각하지는 않습니다. 가지고있는 번호를 제시하십시오. 관리자가 수신 및 완료된 요청 수를 확인한 후 관리자는 진행 상태를 확인합니다. 요청 번호가 소진되면 관리자는 오버로드되기 전에 우선 순위를 지정하여 개입하여 도움을 줄 수 있습니다. 그리고 당신이 할 일이 부족하면 그들은 당신에게 작은 측면 프로젝트를 찾을 수 있습니다. 결국 시야가 끝나지 않는 것처럼 보일 때 프로젝트에서 약간의 휴식을 취하는 것이 항상 좋으며 작업 일이 더 빠르며 바쁠 때 더 보람이 있습니다.