プログラミングと計画[終了]

最近、私のチームの主任開発者が去ったため、私はより高度な計画の割り当てを任されました。長期計画は嫌いです。私の脳は自然に配線されていないように見え、学習するのに時間を費やすほど興味がありません（図のプログラミング側に追いつくのは十分に困難です）。

ハイレベルなプランナーでなくても、優れたプログラマーになることはできますか？

上級プログラマーとして、製品全体を計画し、完成日を選ぶのが得意な人はいますか？

詳細な長期プロジェクト計画は、通常非常に不正確であることで有名です。システムの機能は発売前に必然的に変化し、人々は通常、仕様に含まれる仕様の検討に長い時間を費やし、利害関係者にせいぜい一見しただけです。

アジャイル計画についてもっと読む必要があります。アジャイル計画にもっと合うかもしれません。多くのアジャイル方法論は、詳細な長期計画から離れる方法を見つけようとします。

アジャイル方法論は、詳細な技術仕様とドキュメントを最小限に抑えて、自己文書化コードと、孤立したアトミックユーザーストーリー、そして最終的に動作するソフトウェアを優先します。効率的なアジャイルチームでは、計画に費やす時間が最小限になります。

アジャイルマニフェストを読んで、スクラムを調べてください。反復開発および動的システム開発手法を使用して、プロジェクトをガイドします。

アジャイルアプローチの主な欠点は、プロジェクトの正確な範囲がわからないことを公​​然と認めなければならないことであり、このアイデアに経営陣の賛同を得るのは非常に難しく、通常は時間がかかります。これに関するいくつかのヒントについては、この質問と回答とこの投稿を参照してください。

確かに、上級プログラマーになればなるほどコーディングは少なくなることは確かですが、アジャイルチームでは、より多くの技術仕様を書くことを意味するのではなく、管理と個別指導に多くの時間を費やすことになると思いますチームのメンバーとコードに関するアーキテクチャの決定を行います。

はい、可能です。ただし、優れたソフトウェアエンジニアまたはソフトウェアアーキテクトになりたい場合は、そこで高度な計画を立ててください。私にとって、プログラマとエンジニアの主な違いは、全体像を見ることができることです。

高レベルのプランナーではなく、優秀なプログラマーになることは可能ですか？

しばらくの間、はい。これを長時間行うことは可能ですか？番号。

現在、多くの雇用主にとって、生活費の競争力を高めることは標準的な運用手順です。あなたが自分自身を改善しないなら、より大きくて難しい問題に取り組もうとしないでください。それらの業界競争力のある昇進は、5年か10年であなたを市場から引き離します。これを維持すると、雇用主は最終的にあなたを追い払う理由を探し始め、他の場所での雇用可能性も劇的に低下します。

確かに、プログラマーの観点からすると、優れたプログラマーになることができます。経営者の観点からは、まったく別の質問です。私の経験では、計画プロセスに関与することは、1）より興味深いプログラミングの割り当てを取得し、2）必要な方法でそれらを実行するための最良の方法です。

言い換えれば、短期計画に到達すると、多くのオプションが利用できなくなります。希望するソリューションに6週間かかるが、予算が2つしかない場合は、彼らが決めたものに固執します。長期計画で既に議論されていることについて懸念がある場合、彼らはそれを再ハッシュしたくありません。

あなたがその状況に満足しているなら、あなたにもっと力を。ほとんどの人は、経験が増えるほど満足しなくなります。

汚い小さな秘密は、誰もが長期計画と推定に非常に優れているということではありません。優れたプランナーとは、自分の限界を認識している人のことなので、信じられないかもしれませんが、あなたはその先を行っています。推定の不確実性の会計処理に関するトレーニングを受けます。エビデンスに基づいたスケジューリングやスクラムなどの手法を見てください。これらの手法は、履歴データに基づいて推定の正確さを示します。あなたの作品に大きな発言権があれば、長期的には幸せになります。

高レベルのプランナーではなく、優秀なプログラマーになることは可能ですか？

短い答え：はい、可能です。

ただし、関与しているプロジェクトの種類について経験を積むほど、計画のアイデアは向上します。理想的には、プログラマーとして、問題を解決する方法がいくつかあるか、それを探します。したがって、アプローチを知っていれば、計画について考え始めることができます:)

別の可能なルートは、優れたプランナーになるプログラマーも最終的にプロジェクト管理に向かうことです。したがって、プロジェクトの管理に関心がある場合は、その方向に向けてさらに努力することができます。

はいといいえが答えです。

一方では、プロジェクト管理に向かっている。IMO、すべての優秀なプログラマーはある程度のプロジェクト管理能力を持っていますが、それらは異なるスキルセットです。長期計画を立てることにより、実際のプロジェクト管理とのコミュニケーション能力が向上します。したがって、長期計画を立てる能力がなければ、優れたプログラマーになることはできません。

そうは言っても、プロジェクト管理は、プログラミングではなく関連する側面にアピールする異なるスキルセットです。そこで、ここで「はい」の出番です。優れたプログラマーになるためにプロジェクトマネージャーである必要はありません。

特定の状況では、会社が何を必要としているか、何を楽しんでいるかについて、より客観的になるようにしてください。あなたの質問に反映されているエゴが少し多すぎるため、この状況を見る能力に偏りが生じています。楽しみながら仕事を続けながら雇用主に貢献する方法を見つけることができる場合は、それを考慮して上司と話し合う必要があります。

計画とバンジーボス

ディルバートはバンジーボスについて多くのストリップを持っています。計画に関する私たちの課題と期待は、リーダーシップの低下の原因と結果の両方である可能性があります。フォーチュン100社での私の経験では、1年でプロジェクトリーダーとしてその年を始めた人は全員退職しました。おそらく、これは計画の問題が原因でした。前のリードがこの理由で去ったかどうかはわかりませんが、あなたの役割がコミットメントを持って計画を立てる必要があるとき、それがうまくいかない場合、しばしば、締め切り関連の出口が結果になります。

計画の組織的背景

計画に不満がある場合は、解決すべき問題が文書化または理解される前に、マーケティングやその他の利害関係者に対するコミットメントに責任を負うことに不快感を感じるかもしれません。これは良い本能です。

計画は重要なツールです。無視しないでください。誤解しないでください。

計画は、コミットメント、説明責任、交渉力に完全にリンクしています。アジャイル計画には多くのメリットがあります。計画手法のテクニックと同様に、そのテクニックを知っておく必要があります。あなたの組織には独自のアプローチがあり、多くのプロジェクトの指導者として生き残った人とアドバイスや協力をすることができます。

簡単な計画の例-ソフトウェアに関するものであってはなりません...

屋根ふき会社が私の家に来て買い替えに入札した場合、低すぎると仕事でお金を失うかもしれませんが、高すぎると彼らは仕事に就けません。いずれにせよ、彼らは廃業しています。新しい役割では、少なすぎると説明責任が始まるまでプロジェクトを実行し、問題が発生します。締め切りまでに成功を保証するのに十分なパディングがあるプロジェクトを見積もると、彼らは多くの場合、他の誰かを選んでリードします。キッカーはあなたが屋根erき職人のようではないということです。彼は屋根の大きさを確認でき、その大きさの屋根にかかる時間に関する履歴データを持っています。

より良いプランナーになる

何らかのトレーニングを検討することをお勧めします。アジャイルの方法論、および最新の計画された方法論では、推定はチーム全体の活動です。したがって、チームのトレーニングも検討する必要があります。

経験から、それを延期するチームメンバーから見積もりを得るのはイライラすることがあると言えます。要件や機能の説明、または既存のコードを参照せずに、タスク名に基づいて2分以内に見積もりを出します。過去のプロジェクトで同様の問題に数週間を費やしたとしても、リストしたタスクのいくつかは1日のうちの数分の一で完了することができると主張しています。

さまざまなプロジェクトマネージャートレーニングコースと認定資格がありますが、独立して認定されたものを監視します。アジャイルチームと協力する予定がある場合（またはその逆の場合）、計画された方法論に基づいたアプローチで認証することを選択する前に、再考する価値があります。

SLIMは、1970年代にDoDプロジェクトでGEや他の会社で働いた後、パトナムによって発明された方法です。SLIMは影響力があり、彼の会社QSMは、彼らが作成したツールから流出したと思われる認証を提供しています。会社がツールを採用しているかどうかによって、価値がないか高い価値になる可能性があります。

Steve McConnell（Code Completeの著者）もソフトウェア推定に関する本を執筆し、彼の会社ConstruxはProject Management Instituteを通じて認定されたPDUクレジットの2つのクラスを教えています。私は彼の本を持っています。教室でのトレーニングを通してこのトピックについて学びたいなら、おそらくConstruxを選ぶでしょう。また、スクラムトレーニングを行い、Scrum.orgで認定されたさまざまなスクラム評価を管理します。

ソフトウェアプロジェクトの見積もりに関する優れたアカデミックトレーニングを提供できるもう1つのソースは、非常に大規模なプロジェクトを見積もるためにNASAや他の大規模な請負業者で使用されているCOCOMOおよびCOSYSMOの建設的コストモデリングに関する広範な研究に基づいたUSCのBarry Boehmのグループです。私がCOCOMOを本当に信じているかどうかはわかりませんが、規模とコストの要因がスケジュール期間に与える影響を相関させるために行った経験的な作業が好きです。

また、O'Reillyが発行した教科書から、 Watts Humphreys PROBEやKent Beckの計画ゲームなどの主要なソフトウェア推定方法について簡単に説明している章を見つけました。PROBEには、エンジニアが自分の生産性に関するメトリックを追跡し、それらを新しいプロジェクトの割り当て部分に適用するという概念が含まれています。Planning Gameは、開発者と他の利害関係者との非常に高度な共同作業です。