開発者にプロジェクト管理を行わせるソフトウェアマネージャー
私は組み込みシステム企業で働いているソフトウェア開発者です。プロジェクトマネージャーがおり、プロジェクトスケジュール全体（電気、品質、ソフトウェア、製造を含む）を担当しているため、ソフトウェアスケジュールは非常に短いです。
私の上司であるソフトウェアマネージャーもいます。ソフトウェアのスケジュール、設計ドキュメント（高レベルおよび低レベルの設計）、SRS、変更管理、検証計画とレポート、リリース管理、レビュー、そしてもちろんソフトウェアを書いて維持してくれます。
ソフトウェアチーム全体（10人のメンバー）のテストエンジニアは1人だけで、常にいくつかのプロジェクトが進行中です。
私はこれらのドキュメントを作成するのに私の時間の80％を費やしています。私の上司はプロセスのバックグラウンドから来ており、ソフトウェアを改善するためのより優れたドキュメントが必要だと考えています。
- 彼はデザインを最重要であると考え、コーディングは「デザインを書き留めるだけ」であり、それほど長くはかからず、「ハードウェアの準備が整う前にすべてのコードを記述する必要があります」。
- 分散型モデルとの共同作業が簡単になると言った後でも、中央バージョンと分散バージョンの違いを理解できません。
- コードを理解しておらず、すべてのバグとその解決策を理解したい。
- 検証は開発者が行い、検証はテスターが行う必要があると考えています。ただし、検証では実装が正しいかどうかのみが確認され（単体テストは記述せず、スケジュールでは考慮されません）、検証はブラックボックステストであるため、単体テストがありません。
私は本当に混乱しています。
- これらすべてのドキュメントを管理する責任がありますか？本質的には、ソフトウェアプロジェクト管理をしているように感じます。私は技術文書で大丈夫ですが、スケジューリング/計画は開発者によって行われるべきではないと思います。
- ドキュメントの作成はあまり好きではありません。問題を解決してコードを書きたいと思っています。私の経験では、設計ドキュメントを作成することはある程度役立ちますが、コードを改善または高速化するソリューションにはなりません。
- 上司は本当により良い製品を作ることを気にしていないと感じていますが、経営者の目で見て良いマネージャーであることだけについてです。
私に何ができる？今年は実際に3か月間コーディングを行いましたが、残りはドキュメントの作成とクライアントからのバグレポートの待機に費やしました。
あなたはソフトウェアエンジニアのように聞こえます。
プロジェクトマネージャーは、プロジェクト全体のステータスと、マイルストーンが適切なタイミングで満たされていることを確認するための効果的な方法でリソースを割り当てることに、より重点を置いています。また、障害物を取り除き、プロジェクトリソースが特定の職務に集中できるようにします。
設計および技術文書の作成と保守は、ソフトウェアエンジニアであることの重要な部分であり、自分の役割に適しています。しかし、良いことをたくさんしすぎると、悪いことになる可能性があります（ Analysis Paraylsis を参照）。
彼はデザインを最重要であると考え、コーディングは「デザインを書き留める」だけです
プロジェクトマネージャーが設計ドキュメントが最重要であると考える場合、彼はプロセスでの成果物としてドキュメントを期待します。彼があなたの時間の80％をそれに割り当てるのに十分重要であると彼が感じるなら、それはあなたの側の無駄な時間ではありません。
時間がかかりすぎてはならず、「ハードウェアの準備が整う前にすべてのコードを書く必要があります」。
これは希望的な考えであり、ソフトウェア開発がどのように機能するかについて、かなり時代遅れのウォーターフォールスタイルの見方です。どれだけ多くのデザインと準備を注いだとしても、それは常にそれほどクリーンではありません。ただし、その点については、コードが相互作用するための明確なハードウェア仕様と適切なテスト環境、および模擬ハードウェアシミュレーションが必要ですが、現実世界は乱雑です。
完璧な世界では、プロジェクト管理は信じられないほど簡単です。世界は完璧ではありませんが、どれだけ望んでも本当のプロジェクト管理は非常に困難です。これが、彼らが大金を支払われる理由です。
（2）中央バージョンコントロールと分散バージョンコントロールの違いを理解していません。
なぜ彼は気にする必要がありますか？それはマイルストーンにどのように影響しますか？そうではありません。
3）コードを理解しておらず、すべてのバグとその解決策を理解したい
彼の目標はソフトウェアを動作させることであり、あなたもそうでなければなりません。彼はコードを理解する必要はありませんが、動作するソフトウェアを妨げている問題を理解する必要があります。二人がこの基本的なレベルに目を向けると、あなたの相互の目標はあなたがより効果的に一緒に働くのに役立ちます。
（4）検証は開発者が行い、検証はテスターが行うべきであると考えています。
この感情の何が問題になっていますか？品質保証の役割を持つテスターは、機能と要件の検証に関与する必要があります。開発者は、テストに進む前に、自分の作業を検証およびテストするためにあらゆる努力を払う必要があります。
ドキュメントの作成はあまり好きではありません。問題を解決してコードを書きたいと思っています。
単純なプログラマになりたい場合は、上司にこのことについて話し、プロジェクトでより良い役割があるかどうかを確認する必要があります。誰かが技術文書を作成して保守する必要があるので、おそらく他の開発者の1人がこれらのタスクのいくつかを手伝ってくれるので、文書の作成に80％の時間を費やさないでください。
私の経験では、設計ドキュメントを作成することはある程度役立ちますが、コードを改善または高速化するソリューションにはなりません。
これはほとんどの場合当てはまりますが、10人の開発者全員が自分の時間の80％を、誰も読むことのない技術文書の作成に費やしている場合のみです。これは、私が以前に住んだことのある巨大な管理アンチパターンです。チームのドキュメントのほとんどを実行していることがわかった場合、より多くのコーディング作業を実行する権利を拒否されていることはほとんどありません。
問題の事実は、最良の技術文書がコード自体であるということです。
上司は本当により良い製品を作ることを気にしていないと感じていますが、経営者の目には良いマネージャーであることだけについてです
製品が彼の病棟であり、プロジェクトと機能が完了しておらず、クライアントが満足していない場合、上級管理職は気にしないので、彼は気遣う気がする彼のために。問題は、必要な品質改善についてのあなたの見解が彼や上層部の経営陣と一致しないこと、そしてクライアントが彼らが感じることの重要性についての認識です。
プロセスの効率を3倍に高めることができますが、1週間かけてこれを行うと、クライアントが要求する別の重要な機能が犠牲になるため、製品にとって本当に重要なものを理解してください。
私たちは皆、上司の目によく似合いたいと思っています。それには何の問題もありません。自己奉仕するのは人間の本性です。これは人生の事実です。
ある程度、私はあなたのプロジェクトマネージャーに同意します。ソフトウェア開発は、コーディング機能をはるかに超えています。 :-)
あなたの状況を踏まえて、私は彼のところに行き、彼のリクエストがあなたの時間の80％を費やしていることを説明し、なぜあなたがこの時間を開発よりもドキュメントの維持（コーディングを超える）に費やすことが重要であるかを理解しようと努めます。
参考までに、ソフトウェア会社である Atlassion には、1人のQA担当者に対して13人の開発者がおり、ほとんどのテスト（計画と実行）は開発者によって行われています。これは、Agile 2012でのプレゼンテーションの1つと、現在このプラクティスをエミュレートしようとしている私たちのチームの中で学びました。
ただし、チーム全体を前進させるための方法論としてスクラムを積極的に試すかどうかについても、プロジェクトマネージャーと話し合います。あなたの説明を考えると、私はあなたがスクラムを使用しているとは思いません。
あなたのように、私は絶えず変化する計画を維持することに非常に苛立っていました、そしてスクラム軽量アプローチは私がこの欲求不満を克服するのを助けました。
私の経験で最もパフォーマンスの高いチームは、作業を行うために必要な最小限のプロセスに直面したチームでした。ある時点で、追加のプロセスが製品の品質を奪います。彼らが書類を邪魔にならないようにすることにもっと関心があるためにQAがバグを見逃し始め、DEVがドキュメントを作成しているために機能のコーディングやバグの修正を行っていない場合は、問題があります。ただし、これが実際に会社に当てはまるかどうかを判断することは、非常にローカライズされた質問であり、チームのメンバーだけが回答できます（私たちではありません）。
上司が非常に間違っていることが1つあります。それは、QAがほとんどなく、単体テストがないという事実です。 a開発者が作成したバグは、定義上、彼らの見落としです。開発者が常に独自の機能をテストすることを期待し、それ以外のテストをほとんど行わないことはプロセスの問題です。 QAはドメインに応じて自動テストにある程度置き換えることができますが、どちらもない場合は、バグをすり抜けてしまう可能性があります（通常、早期に発見するよりもコストがかかります）。
また、厳密なビジネスの観点からは、QAの採用は開発者の採用よりも安価です。チームが良好なQA/DEV比率を持っている場合、費やされたお金のより多くの範囲をカバーすることができます。
私が見た、または直接聞いたCMMIの実装はすべて、プロセスとドキュメントに負荷がかかっていました。上司は、実装を簡単にするためにドキュメントが十分に詳細である必要があると信じているので、彼の期待は同様です。
ドキュメンテーションの書き込み/メンテナンスの不均衡なシェアを受け取っている場合は、より均等に配布するよう依頼するのが妥当です。他の開発者がコーディング比率と同様のドキュメントを持っている場合、ほとんどの時間をコードの記述に費やしたい場合。新しい雇用者を見つけることを検討するときかもしれません。
あなたは医療システムについて話しているので...安全性が最重要です-したがって、ドキュメント（特にトレーサビリティ）は不可欠です。
1人のテスターは少し軽いように見えますが、それ以外の場合は、はい-ドキュメントを確実に準備する責任があります。
医学の世界での私の経験は限られていますが、航空宇宙/防衛の世界では、Do-178B（現在はC）を使用しています。Do-178B（現在のC）は、必要なドキュメントとテストのレベルを指定するライフサイクルモデルを規定しています（安全上の重要性に応じて[より具体的には、ソフトウェアの設計保証レベル]、および自動車の世界では、ISO26262も同様に機能します。
ドキュメントが適切でない場合、製品は認定されません。
しかし、重要なことは、製品を改善するために必要なドキュメントを操作することです...実際の目的を果たさないため、ドキュメントを後から考えてリバースエンジニアリングしないでください。