개발 프로세스에서 관리를 유지하는 방법

저는 소프트웨어 개발 팀의 소프트웨어 엔지니어입니다. 지난 3 년 동안 내부 고객을 위해 신제품을 개발했습니다. 이제이 제품이 완성되었습니다. 기존 제품의 새로운 주요 기능을 다룰 것입니다. 특정 기능의 경우 제품 관리 부서에서 개발하는 데 150 시간이 소요될 것으로 예상했습니다. 우리는 프로젝트 관리자와 함께 매우 상세한 계획을 세웠으며 300 시간의 노력을 기울였습니다. 어제 우리는 이것에 대해 토론했고 그들은 우리가 지나치게 과대 평가했다고 생각합니다.

계획에서 단위 테스트 작성 시간을 예상했으며 시간을 절약하기 위해 덤프를 작성하는 것이 좋습니다. 결정은 아직 이루어지지 않았으며 필요한 경우이 계획과 단위 테스트를 방어 할 것입니다. 그러나 내가 정말로 싫어하는 것은 경영진이 우리의 개발 과정을 방해한다는 것입니다. 개발 과정에서 어떻게 제거합니까? 그리고 품질 및 장기적인 시간 절약 외에도 유닛 테스트를 유지하기 위해 어떤 인수를 사용할 수 있습니까?

부수적으로 우리 회사에는 3 개의 엔지니어링 팀이 있으며 내가 속한 팀은 적시에 소프트웨어를 제공합니다 (10 % 마진 제공). 다른 팀은 항상 계획이 과소 평가되어 늦게 배달됩니다. 그들은 코딩 만 계획하고 관리, 테스트 및 처리는하지 않습니다.

먼저, 나는 당신의 입장에 전적으로 동정한다고 말하겠습니다. 비즈니스의 다른 부분간에 이해가 부족하거나 의사 소통 장애가있는 경우 실망 스러울 수 있습니다. 그렇게 말하면서, 나는 당신이 그들을 막으려 고 노력하지 않아야한다고 생각합니다. 대신 이것이 왜 좋은 생각인지에 대한 숫자를 보여 주어야합니다. 단위 테스트를 정당화한다는 사실은 무엇입니까? 당신이 없다면, 당신은 그 수치를 수집하기 시작하거나 귀하의 주장을 뒷받침하는 연구 를 보여 주어야 합니다.

나는 비슷한 시나리오를 직접 다루어야 했고 비슷한 주제에 대해이 질문에 답했다 . 또한 여기에서 어떻게 처리했는지 블로그에 올렸습니다.

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

링크 추적이 마음에 들지 않으면 관련 질문에서 요약을 반복합니다.

요약하자면, 예상 시간을 프로젝트의 실제 시간과 비교 한 다음 결함 비율을 다른 팀의 결함 비율과 비교했습니다. 우리의 경우이 숫자는 호의적으로 비교되었고 더 이상 걱정하지 않았습니다.

이 경험에 근거한 나의 결론은 다음과 같다.

... 어떤 일을하는 당신의 접근이 실용적이고 실용적이라는 것을 다른 사람에게 설득하는 가장 좋은 방법은 그것을하고 다른 접근에 대비하여 그것을 측정하는 것입니다. 사람들은 교리에 관심이 없거나 왜 무언가가 최선의 방법이라고 생각하는지에 관심이 없습니다. 사람들에게 숫자를 보여주고 접근의 효과를 측정하는 것만으로도 당신의 관행이 효과적이라는 것을 진정으로 보여줄 수 있습니다.

경영진이 단위 테스트에 150 시간을 추가로 투자하는 것에 동의하지 않는 경우 제품의 작은 영역에 투자하도록 설득하거나 데이터를 제공하기 위해 시간을 단축하는 데 동의 할 수 있습니다. ). 제품의 한 영역에서 단위 테스트를 수행 한 다음 제품의 다른 영역의 결함 비율과 비교하여 제품의 해당 영역의 결함 비율 및 결함을 찾아 수정하는 비용에 대한 데이터를 수집하십시오. 바라건대 당신은 당신의 사건을 뒷받침하기 위해 약간의 데이터를 모을 것이고 이것은 다음 프로젝트에서 문제가되지 않을 것입니다.

사용하는 방법에 관계없이 따르는 가장 중요한 규칙은

1. 개발자는 자신의 작업을 추정 할 권리가 있어야합니다.
2. 이해 관계자는 해당 작업 중 우선 순위를 정할 권리가 있어야합니다.

추정과 우선 순위는 두 당사자가 각자의 책임을 수락하면 매우 잘 작동하는 두 가지 힘입니다. 따라서 논쟁에 시간을 낭비하지 말고 이에 동의하고 양 당사자가 최선을 다해 자신의 작업을 수행 할 것임을 존중하십시오.

단위 테스트로 시간을 절약 할 수 있다는 점을 지적 할 수 있습니다. 따라서 테스트를 중단하면 예상 시간이 500 시간이됩니다.

기술 부채 및 단위 테스트의 가치에 대해 알려주십시오

기술 부채에 대한 좋은 아이디어 에서이 게시물 을 보십시오 . 그 게시물을 통해 다음 pdf를 얻을 수 있습니다.

나는 단위 테스트의 가치에 대해이 게시물 을 좋아 합니다 (아마도 더 많이 찾을 것입니다)

희망은 개발 프로세스에서 벗어나지 않고 올바른 방식으로 참여하고 헌신하는 것입니다.

IMHO는 원래 계획을 작성하고 기술 부채와 단위 테스트의 가치를 설명하는 1 장과 2 장 (부록 아님)을 추가해야합니다. 그들에게 대안을 제공하십시오 :

• 모든 개발 (개발 단계 및 유지 보수 중)에 걸리는 평균 시간이 줄어드는 시간 (전체 150 개가 아니라 터무니없는 소리) :
  • 작은 4 시간
  • 중간 16 시간
  • 큰 40 시간
• 모든 변경 (개발 단계 및 유지 관리 기간)에 소요되는 예상 시간 :
  • 작은 2 시간
  • 중간 8 시간
  • 큰 20 시간

(시간은 단지 표시 일뿐입니다. 적절한 견적을 제공 할 수있는 방법이 더 좋습니다.)

정시에 예산을 초과 한 배송에 대한 귀하의 실적을 포함하는 것을 잊지 마십시오.

적어두고 이것들과 토론하십시오. 현재 실제로 필요하지 않은 기능이나 정시에 제공하기 위해 기꺼이 취해야 할 기술적 측면에서 가치있는 부분이있을 수 있습니다. 이것들이 의식적인 선택인지 확인하십시오.

이것이 도움이되고 행운이 있기를 바랍니다.

우선, "쓰기 단위 테스트"를 별도의 작업으로 분리하여 추정, 예약 및 잠재적으로 차단하지 마십시오. 예상치는 기능 레벨 "XYZ 구현-18 시간"이어야합니다. 이 18 시간에는 "쓰기 단위 테스트"를 포함하여 해당 기능을 "완료"로 가져 오는 데 필요한 모든 프로세스가 포함되어야합니다.

이것이 "개발 과정에서"기술 이외의 개발을 수행하는 좋은 방법입니다. 작업 목록이나 프로젝트 일정에 개발 프로세스를 포함시키지 마십시오!

둘째, 팀에서 이미 좋은 제품을 제 시간에 제공하고 있지만 다른 팀은 그렇지 않은 것 같습니다. 이 관리 그룹은 해당 팀을 미세 관리하는 데 익숙 할 것입니다. 당신의 강점을 활용하십시오-작동하는 기능으로 매주 또는 격주 업데이트를 보여 주면 "개발 프로세스"에 대해 다시 알려줄 것입니다.

나는 한때 내가 아주 좋은 상태에서 코드 기반으로 작업하고있는 상황에 있었다. 매우 짧은 시간 안에 도전적인 새로운 기능이 필요했으며, 매우 짧은 시간 안에 기능을 제공 할 수있었습니다. 그 시점에서 코드베이스는 훨씬 더 나쁜 상태였습니다. 이 기능이 제공되었지만 내 작업은 완료되지 않았습니다. 모든 것을 동일한 상태로 되돌려 야했습니다.

관리자에게 다음과 같이 2 단계까지 설명했습니다. 집에서 페인트 작업을하는 것과 같습니다. 모든 도구가 해당 위치에 있고 양호한 상태 인 경우 모든 브러쉬가 청소 된 등 매우 빠르게 페인트 작업을 수행 할 수 있습니다. 그러나 모든 도구를 정리하려면 시간을 투자해야합니다. 그렇게하지 않으면 다음 페인트 작업이 훨씬 오래 걸립니다. 실제로 도구의 위치를 ​​기억하지 못하고 페인트 브러시를 더 이상 회수 할 수 없으며 정리 작업을 즉시 마치 마치 훨씬 더 많은 시간과 비용이 소요됩니다.

프로그래밍 작업에서도 마찬가지입니다. 정리하면 코드베이스를 다음에 필요할 때 다시 매우 빠르게 전달할 수있는 상태가됩니다. 그렇지 않으면 다음에 시간이 더 오래 걸립니다.

당신이 임금을 지불하고 그들이 당신의 제품을 사용할 것입니다.

과대 평가 시간에 대한 개발자를 비난하는 관리자는 내 경험에서 매우 일반적인 시나리오이며,이를 처리하지 않으면 보스가 반으로 줄 것이므로 다음 추정치가 두 배로 증가하는 벙어리 무기 경쟁으로 이어질 수 있습니다. 그것들은 그것들을 4 분의 1로 나누므로, 당신은 그들 등을 4 배로합니다. 가능하다면이 악순환을 피해야합니다.

마감 기한이 "드롭 데드 (drop dead)"이유가 없다고 가정하면 2 가지를 제안합니다.

1. 현재 고품질 작업에 대한 접근 방식을 유지하면서 150 시간 내에 할 수있는 일에 대한 자세한 계획을 제공하십시오. 이 시간대에 정확히 무엇을 전달할 수 있는지 열거하십시오. KeesDijk 의 답변 에는 세밀한 계획을 세우는 데 매우 유용한 링크가 있습니다.
2. 모든 기능을 다루고 300 시간이 걸리는 방법 (또는 숫자가 나오는 모든 것)을 보여주기 위해 동일한 스타일의 세부 계획을 계속 수행하십시오.

그런 다음 작업을 진행하고 정기적으로 진행 상황을보고하고 가능한 경우 정기적으로 일부 결과물을 확보하십시오. 이를 통해 경영진은 예측 기술과 능력을 확신 할 수 있습니다.

견적의 근거를 물어보십시오. 불일치에 대해 논의하는 것은 공정합니다. 단위 테스트 덤프는 잘못된 경제이므로 나중에 디버거에서 더 이상 단위 테스트에 사용할 단위 테스트를 작성하지 않아도됩니다. 기본적으로 완료 한 작업을 테스트 할 계획이라는 사실을 문서화했습니다. 그들은 시험하지 말라고 말하고있다 전혀 . 프로젝트를 개발할 때 단위 테스트 또는 임시 테스트를 사용하여 테스트하든 해당 시간을 여전히 고려해야합니다. 단위 테스트에 할당 된 시간을 제거하면 임시 테스트에 할당 된 시간도 제거됩니다.

결론 : 예상대로 총을 고수하십시오. 귀하의 실적은 귀하가 무엇을 말하는지 알고 있으며 추정치 (가정, 기대치, 과거 실적 등)에 대한 합리적인 답변을 제공 할 수 있습니다. 최고 경영진이 합리적인 견적을 내리는 데 필요한 가시성을 가지고 있지 않은 것 같습니다. 회의 중단없이 8 시간을 가정하고 있습니까? 추정치에서 시스템 테스트를위한 예산을 책정하고 있습니까? 귀하의 실적을 고려할 때 귀하의 절반 인 숫자는 어떻게 나타 났습니까?

나는 그것이 300 시간이 걸릴 것으로 예상하고 그들이 150 예산을 그들에게 옵션을 제공하면 그것은 버그가 급한 일이거나 배달 늦을 것입니다. 프로젝트가 완료되고 예측 한대로 요청한 내용 만 알릴 수 있습니다.

월리는 무엇을 할까?

경영진이 귀하에게 요구하는 바를 해석하는 여러 가지 방법이 있습니다.

터무니없는 것 같아? 예,하지만 당신이 과대 평가하지 않았다는 것을 어떻게 알 수 있습니까? 마감일을 지키지 마십시오 (필요한 경우 느슨 함). 미끄러 져 실수로 제 시간에 무언가를 배달 해야하는 경우 공원에서 산책했다는 인상을주지 않도록 정말로 피곤해 보이도록하십시오 .

당신은 피클에 있습니다. 총을 고수하고 단위 테스트를 계속하고 300 시간을 청구하려면 적을 만들 것입니다.

150 시간으로 줄이고 척 유닛 테스트를 수행하면 버그가 많은 제품을 더 빨리 제공 할 수 있지만 유지 보수 비용이 높아 도로를 더 슬프게 만들 수 있습니다.

어느 쪽이든, 당신은 잃습니다.

또는 그렇게 보인다.

당신은 대학에서 과학 실험실을 운영하고 있지 않습니다. 회사 에코 시스템의 고객에게 서비스를 제공하는 회사의 비즈니스 단위에 비즈니스 서비스를 제공하고 있습니다. 고객에게 더 빠르고 더 나은 서비스를 제공하기 위해 귀사의 제품이 필요할 수 있으므로 필요한 수익을 올리십시오.

당신은 ROI 분석이 필요하다는 것을 알 수 있으며, 그 분석에 필요한 모든 데이터가 없습니다. 일부 비용 부분 만 있고 (모두의 급여 번호를 모르는 경우) 수익 부분이 없으며, 특히 수익 예측이 없습니다.

경영진은 믿거 나 말거나 ROI 예측 (비즈니스 스쿨에서 가르치는 것)에 능숙하며 여러 ROI 예측을 수행하고 "지금 행동하면 훨씬 더 많은 돈을 벌 수있을 것입니다. "IT의 bozos가 불평하는 소프트웨어 유지 보수에 3 배의 비용을 지불했습니다."

따라서 조인트를 운영하려면 회사를 시작하십시오. 알다시피 쉽지는 않습니다.

다른 말로하면 : 당신이 말하는 것을하십시오. 경영진이 수행중인 작업을 알고 있다면 앞서 나갈 것입니다. 그렇지 않은 경우, 당신은 직장에서, 단위 테스트 여부입니다.

ROI 란 무엇입니까? 투자 수익. 그래도 나쁜 이름입니다. 타이밍은 투자의 모든 것이므로 ROTI (Return On Timely Investment) 여야합니다.