개발자가 프로젝트 관리를 수행하게하는 소프트웨어 관리자

저는 임베디드 시스템 회사에서 일하는 소프트웨어 개발자입니다. 전체 프로젝트 일정 (전기, 품질, 소프트웨어 및 제조 포함)을 관리하는 프로젝트 관리자가 있으므로 소프트웨어 일정이 매우 짧습니다.

내 상사 인 소프트웨어 관리자도 있습니다. 그는 소프트웨어 일정, 설계 문서 (고급 및 저수준 설계), SRS, 변경 관리, 검증 계획 및 보고서, 릴리스 관리, 검토 및 소프트웨어를 작성하고 유지 관리합니다.

전체 소프트웨어 팀 (10 명)을위한 테스트 엔지니어는 한 명 뿐이며, 언제든지 두 가지 프로젝트가 진행 중입니다.

이 문서를 만드는 데 80 %의 시간을 소비하고 있습니다. 상사는 프로세스 배경 출신이며 소프트웨어를 개선하기 위해 더 나은 문서가 필요하다고 생각합니다.

1. 그는 디자인이 가장 중요하다고 생각하고, 코딩은 "디자인을 작성하는 것"이고, 너무 오래 걸리지 않으며, "하드웨어가 준비되기 전에 모든 코드를 작성해야합니다"라고 생각합니다.
2. 분산 모델과의 공동 작업이 더 쉽다고 말한 후에도 Central & Distributed 버전 컨트롤의 차이점을 이해하지 못합니다.
3. 코드를 이해하지 못하고 모든 버그와 제안 된 솔루션을 이해하려고합니다.
4. 검증은 개발자가 수행하고 테스터가 검증해야한다고 생각합니다. 그러나 우리의 검증은 구현이 올바른지 확인하고 (단위 테스트를 작성하지 않고 일정에 고려되지 않습니다) 유효성 검사는 블랙 박스 테스트이므로 단위 테스트가 누락되었습니다.

정말 혼란 스러워요.

1. 이 모든 문서를 관리 할 책임이 있습니까? 본질적으로 소프트웨어 프로젝트 관리를하고있는 것처럼 느껴집니다. 기술 문서에는 문제가 없지만 개발자가 예약 / 계획을 수행해서는 안된다고 생각합니다.
2. 나는 문서를 만드는 것을 정말로 좋아하지 않으며, 문제를 해결하고 코드를 작성하고 싶다. 내 경험상 디자인 문서를 작성하는 것은 어느 정도 도움이 될뿐 결코 더 나은 코드를위한 솔루션이 아닙니다.
3. 상사는 실제로 더 나은 제품을 만드는 데 관심이 없지만 경영진의 눈에 좋은 관리자가되는 것에 만 관심이 있다고 생각합니다.

어떡해? 올해 내내 3 개월 동안 실제 코딩을 수행했으며 나머지는 문서를 작성하고 고객의 버그 보고서를 기다리는 데 소비했습니다.

당신은 소프트웨어 엔지니어처럼 들립니다.

프로젝트 관리자는 전체 프로젝트의 상태에보다 집중하고 이정표를 충족하고 적절한 시간에 리소스를 효과적으로 할당합니다. 또한 장애물을 제거하고 프로젝트 자원이 특정 직무에 집중할 수 있도록 도와줍니다.

설계 및 기술 문서 작성 및 유지 관리는 소프트웨어 엔지니어가되기위한 중요한 부분이며 사용자의 역할에 적합합니다. 좋은 점이 너무 많으면 나쁠 수 있습니다 ( 분석 문항 참조 ).

그는 디자인을 최우선으로 생각하고 코딩은 "디자인을 작성하는 것"입니다.

프로젝트 관리자가 디자인 문서가 가장 중요하다고 생각하면 프로세스에서 문서를 제공 할 수있는 것으로 기대합니다. 그가 시간의 80 %를 할당하기에 충분히 중요하다고 생각하면 시간 낭비가 아닙니다.

너무 오래 걸리지 않아야하며 "하드웨어가 준비되기 전에 모든 코드를 작성해야합니다".

이것은 소프트웨어 개발이 어떻게 작동하는지에 대한 희망적인 생각과 꽤 오래된 폭포 스타일의 견해입니다. 얼마나 많은 디자인과 준비를하더라도 항상 깨끗한 것은 아닙니다. 그러나이 노트에는 명확한 하드웨어 사양과 적절한 테스트 환경이 있어야하며 코드가 상호 작용할 수 있도록 하드웨어 시뮬레이션을 조롱해야하지만 현실 세계는 지저분합니다.

완벽한 세상에서 프로젝트 관리는 매우 쉽습니다. 그러나 실제 프로젝트 관리를 엄청나게 어렵게 만들고 싶더라도 세계는 완벽하지 않습니다. 이것이 그들이 큰 돈을 지불하는 이유입니다.

(2) 중앙 버전과 분산 버전 컨트롤의 차이점을 이해하지 못합니다.

왜 신경 써야합니까? 이정표에 어떤 영향을 미칩니 까? 그렇지 않습니다.

3) 코드를 이해하지 못하고 모든 버그와 제안 된 솔루션을 이해하려고합니다.

그의 목표는 소프트웨어를 작동시키는 것이며 당신도 마찬가지입니다. 코드를 이해할 필요는 없지만 작동하는 소프트웨어를 방해하는 문제를 이해해야합니다. 두 사람이이 기본 수준에서 눈을 마주 치면 상호 목표가보다 효과적으로 협력하는 데 도움이됩니다.

(4) 개발자가 검증을 수행하고 테스터가 검증해야한다고 생각합니다.

이 감정에 어떤 문제가 있습니까? 품질 보증 역할의 테스터는 기능 및 요구 사항을 검증하는 데 관심을 가져야합니다. 개발자는 테스트를 시작하기 전에 작업을 확인하고 테스트하기 위해 모든 노력을 기울여야합니다.

나는 문서를 만드는 것을 정말로 좋아하지 않으며, 문제를 해결하고 코드를 작성하고 싶다.

만약 당신이 단순한 프로그래머라면, 아마도 당신의 상사에게 이것에 대해 이야기하고 프로젝트에서 당신에게 더 나은 역할이 있는지 알아봐야 할 것입니다. 누군가는 기술 문서를 작성하고 유지 관리해야하므로 다른 개발자 중 한 명이 이러한 작업 중 일부를 도와 문서 작성에 80 %의 시간을 소비하지 않을 수 있습니다.

내 경험상 디자인 문서를 작성하는 것은 어느 정도 도움이 될뿐 결코 더 나은 코드를위한 솔루션이 아닙니다.

이것은 대부분 사실입니다. 그러나 열 명의 개발자가 모두 읽지 못할 기술 문서를 작성하는 데 80 %의 시간을 소비하는 경우에만 해당됩니다. 이것은 내가 전에 살았던 거대한 관리 반 패턴입니다. 팀에 대한 대부분의 문서를 작성하고 있다는 것을 알게되면 더 많은 코딩 작업을 수행 할 권리가 거부당하는 것은 거의 공정하지 않은 것 같습니다.

문제의 사실은 최고의 기술 문서가 코드 자체라는 것입니다.

상사는 실제로 더 나은 제품을 만드는 데 관심이 없지만 경영진의 눈에 좋은 관리자가되는 것에 만 관심이 있다고 생각합니다.

나는 그가 느낌 않는 제품 와드이며, 프로젝트 및 기능이 완료되지 및 클라이언트가 행복하지 않은 경우 다음 경영진이 그를 매우 걱정하지 않기 때문에주의. 문제는 필요한 품질 향상에 대한 당신의 관점이 그의 경영진과 일치하지 않으며, 고객이 느끼는 것에 대한 인식이 중요하다는 것입니다.

프로세스의 효율성을 3 배 증가시킬 수 있지만 일주일 내내이 작업을 수행하면 고객이 요구하는 또 다른 중요한 기능을 희생하기 때문에 제품에 진정으로 중요한 것이 무엇인지 이해하십시오.

우리 모두는 상사의 눈에 잘 보이기를 원합니다. 아무 문제가 없습니다. 자기 봉사하는 것은 인간의 본성입니다. 이것은 인생의 사실입니다.

어느 정도까지는 프로젝트 관리자에게 동의합니다. 소프트웨어 개발은 ​​코딩 기능 그 이상입니다. :-)

당신의 상황을 감안할 때, 나는 그에게 가서 그의 요청이 80 %의 시간을 소비하고 있다고 설명하고, 당신이 개발하는 대신 문서를 유지 관리하는 데 시간을 소비하는 것이 왜 중요한지 이해하려고 노력합니다.

소프트웨어 회사 인 Atlassion 은 한 명의 QA 담당자에 대해 13 명의 개발자를 보유하고 있으며 대부분의 테스트 (계획 및 실행)는 개발자가 수행합니다. Agile 2012에서 발표 한 프레젠테이션 중 하나와 현재이 방법을 모방하려고하는 팀에서 배웠습니다.

그러나 팀 전체를 발전시키는 데 도움이되는 방법론으로 Scrum을 시험해 볼 수 있다면 프로젝트 관리자와상의 할 것입니다. 귀하의 설명에 따르면, 나는 당신이 스크럼을 사용하고 있다고 생각하지 않습니다.

당신과 마찬가지로, 나는 끊임없이 변화하는 계획을 유지하는 것에 극도로 좌절했으며 스크럼 경량 접근법은이 좌절을 극복하는 데 도움이되었습니다.

내 경험에서 가장 성능이 뛰어난 팀은 업무 수행에 필요한 최소한의 프로세스에 직면 한 팀이었습니다. 특정 시점에서 추가 프로세스가 제품에서 품질을 가져 오기 시작합니다. QA가 서류 작업을 방해하는 데 더 관심이있어 버그를 놓치기 시작하고 DEV가 문서를 작성하기 때문에 기능을 코딩하거나 버그를 수정하지 않으면 문제가있는 것입니다. 그러나 이것이 실제로 회사의 경우인지 파악하는 것은 팀의 사람들 만 대답 할 수있는 매우 지역화 된 질문입니다.

상사가 매우 잘못한 점이 하나 있는데, 이는 QA가 적고 단위 테스트가 없다는 사실입니다. 개발자가 만든 버그는 정의상 감독에 대한 감독입니다. 개발자가 항상 자신의 기능을 테스트하고이를 제외하고는 거의 테스트하지 않는 것이 프로세스 문제입니다. QA는 도메인에 따라 자동화 된 테스트로 어느 정도까지 대체 될 수 있지만 둘 중 하나라도없는 경우 버그가 발생할 수 있습니다 (그리고 일반적으로 버그를 조기에 찾는 것보다 비용이 많이 듭니다).

또한 엄격한 비즈니스 관점에서 QA를 고용하는 것이 개발자를 고용하는 것보다 저렴합니다. 팀의 QA / DEV 비율이 좋은 경우 지출 한 비용을 더 많이 충당 할 수 있습니다.

내가 보거나 직접 들었던 CMMI 구현은 모두 프로세스와 문서가 무거웠습니다. 상사는 사소한 구현을 위해 문서가 충분히 상세해야한다고 자신의 기대가 비슷하다는 것을 강력하게 암시합니다.

문서 작성 / 유지 보수에 대한 비율이 불균형 인 경우보다 고르게 배포하도록 요청하는 것이 합리적입니다. 다른 개발자가 코딩 비율과 유사한 문서를 가지고 있고 코드를 작성하는 데 대부분의 시간을 보내고 싶다면; 새로운 고용주를 찾는 것이 좋습니다.

의료 시스템에 대해 이야기하고 있습니다. 안전이 가장 중요하므로 문서 (특히 추적 성)가 필수적입니다.

한 명의 테스터는 약간 가벼운 것처럼 보이지만 그 외에는 문서가 제대로 갖추어져 있는지 확인해야합니다.

의료계에 대한 나의 경험은 제한적이지만 항공 우주 / 방위 계에는 Do-178B (현재 C)가 있습니다.이 문서에는 필요한 문서 및 검사 수준을 지정하는 수명주기 모델을 규정하고 있습니다 (더 구체적으로, 소프트웨어의 설계 보증 수준]), 자동차 분야에서도 ISO26262가 적용됩니다.

문서가 없으면 제품이 인증되지 않습니다.

그러나 중요한 것은 제품을 개선하기 위해 필요한 문서를 사용하여 작업하는 것입니다. 문서는 실제 용도가 아니기 때문에 나중에 생각하지 말고 리버스 엔지니어링하지 마십시오.