ソフトウェア開発には、プログラミング言語の選択から設計技術への移行、プロジェクト管理技術で終わるまで、あらゆるレベルでこのような信念が浸透しています。 成功したプロジェクトの結果の結果を解釈し、その例で何らかの方法論をテストすることを決めた場合、可能な限り懐疑的に構成されていないと、道に迷うことにもなります。 このシリーズの記事では、特定の開発方法論の有効性を分析するための出発点をいくつか紹介します。 ある程度、以下に書かれていることはすべて、 programming-motherfucker.comの主なアイデアの詳細な説明にすぎません。
おそらく、真理の探求が最も難しい分野として、プロジェクト管理から始めるでしょう。 そして、少なくとも1人がこの記事を読んだ後、その人気だけに基づいて彼のプロジェクトにファッショナブルな開発方法論を導入することを拒否した場合、このテキストを書くのにかかった時間は無駄ではなかったと推測できます。
はじめに
おそらく、次の文は不合理で非現実的に見えるかもしれませんが、そうです：ソフトウェア開発方法論の有効性を正確に測定することは不可能です。 その理由は簡単です。正確な結果を得るには、同じチームで、同じ言語で、同じマネージャーで、同時にプロジェクト開発プロセスを開始する必要があります。 しかし、開発へのアプローチは異なります。 ほぼ同じ方法で、各開発方法に精通した平均的なマネージャーがいることを条件とします。 また、開発プロセスに対する管理者のカリスマ/しつこい/やる気の影響の可能性を排除するために、すべてのコミュニケーションが純粋に公式なトーンでテキスト形式でのみ行われることを条件としました。 でたらめ？ 本質的に反論できますか？
もちろん、利益や害が明らかで、最も重要なことを証明できるものがあります。 しかし、側に一歩踏み出す価値があり、ボールが偶然支配される渦に突入します。そこでは、信頼性は統計誤差の範囲内にあり、主な議論は真実の階級に引き上げられた個人的な経験で誇示しています。 簡単に言えば、私たちは現実の生活に入ります。
マネージャーはまだ人です
それだけです。 真実ではありません。人間の行動を研究している基礎科学は何ですか？ そうです、それは心理学と社会学です。 両方とも、メディア、歴史、無数の実験など、膨大な量の情報を自由に利用して長い間存在していました。 それにもかかわらず、これらの科学のいずれも、もちろん些細な状況について話していない限り、人、社会集団、または国家の行動を高い確率で予測することはできません。
これは、管理の理論全体が最終的には人々の同じ科学であり、さらに若いだけで、いくつかの異なる学校を持っているという効果に言われました。 そして、あなたはそれを信じないでしょうが、これらのアプローチはすべて、しばしば互いに矛盾します...仕事です！ いずれにせよ、各学校の支持者はそう思う。 いずれにせよ、成功したプロジェクトは各学校の旗の下にあり、失敗は管理方法に関係しない千の理由に起因する可能性があります。
この事実から、管理方法の選択はプロジェクトにとって重要ではないという結論に至るはずです。 それから、方法論からそれを使用する人を見ることは論理的です。 ヒューマンファクターは、このような方法論の偶発的な操作を説明できる唯一のものです。正直に言って、予算の客観的な不足、非現実的な締め切り、プログラマーの弱いレベルなど、多くの理由があります。
謙虚なキャリアの中で、私はさまざまな管理モデルに対処しなければなりませんでした。 プログラマーが電話をかけられ、仕事をさせると脅されたとき、純粋に盗賊の選択肢がありました。 小規模チームの最も一般的なモデルは、1人のボス、最大12人のプログラマーです。そのような方法論はありません。または、あらゆる場所から借用があります。 スタートアップは、緊急、またはアジャイルとデリバティブ、または開発者の群れであり、リーダーは人よりもタスクである可能性が高いです。 大規模なチーム-ある部門/チームから別の部門/チームへの混乱と揺れ、最近同じアジャイルが修正されました。
さらに、これらすべてのプロジェクトは、大規模から小規模まで、ライブおよびライブ、そして失敗します。 異なるプロジェクトで使用される同じ方法論は、異なる結果につながる可能性があります。 結果が誰がテクニックを使用するかに依存すると仮定する（他のすべての要因を無視する）ことは論理的です。 チームを生産的な仕事に動機付けることは可能でしょうか？ 顧客との交渉はどの程度成功しますか（彼も人間です）？ 幽霊のような見込み客のために働くようにプログラマーを説得することは可能でしょうか？ プログラマー自身が競合他社に行きたくないような雰囲気を整理することは可能でしょうか？ 条件と価格はどの程度正確に計算されますか？ マネージャーは、チームが納品日まで作業明細書の矛盾を解決しないように、クライアントの要件を策定できますか？
ほとんどの場合、これらの問題は既存の方法論の範囲外であるか、これらの問題を解決する方法の使用は決定的ではありません。 ここでの決定的なポイントは、個人の資質ですが、残念なことに聞こえるかもしれません。プロジェクトの不十分な方法論に反して、成功につながる可能性がある、または最も高度なプロジェクト管理にもかかわらずプロジェクトが失敗する可能性があるということです。
したがって、次の開発方法論を評価する前に、あなたが知っているすべてのマネージャーの記憶を整理し、自分自身に正直な答えを与えますが、彼らはタスクと部下に対処しますか？
プログラマーも人です
プロジェクトの結果がどの程度それらに依存しているのかを言う必要がありますか？ 必要です。 あなたの分野でのプロ意識の明らかなレベルに加えて、次の要因が重要であることを理解する必要があります。
- チームの資格レベルのばらつき-1人のチームリーダーが5人のジュニアを抜くことはありません。 いいえ、それはそうです-私のコンピューターサイエンスの先生は15人もの人を引き寄せることができましたが、商業開発には十分ではありませんでした
- チーム内のコミュニケーションはどうですか？ 最も熟練したプログラマーの中で、数時間かかるソリューションに関する1時間ごとの会議や会議を見たときに意欲を失う人の割合が高い。 大部分のプログラマーの中で、数行にわたるソリューションに関する1時間ごとの会議や会議がない場合、仕事の目的に対する理解を失う人の割合が高くなっています。
- プロジェクトがパフォーマーにとってどれほど魅力的か。 地球の特定の地域にある特定の衛星の可視性マップを発行して衛星を追跡するためのスタートアップは、「そのような機能を備えたサイトのクローンのクローン」のような単純なプロジェクトよりも、ほとんどすべてのプログラマーに熱意を引き起こします。 プログラマーからよくお金を払ってそのようなクローンを一生リベットする準備ができていると聞いたことがありますが、実際にはそのようなユニットを扱うことができ、それらは高級プログラマーだとは思いません。 ある点から、利益の点で無意味なプロジェクト（しかし商業的な観点からは無意味ではない）が働きたいという欲求を殺し始め、先延ばしに徐々に没頭します。
- プログラマーが既存の開発方法論に忠実である方法。 誰もが毎日の集会を好むわけではありません。 プログラマーが開発方法の1つに専念し、別の方法がプロジェクトに選ばれることもありますが、心配する必要はありません。
より多くの金が必要
お金がなければ解決できない問題の数はもちろん、多くの問題はお金で解決できます。 プログラマーが明るい未来への信仰よりも強い飢えを感じたという事実のために、スタートアップがその創立から数か月後にバラバラになるとき、我々は明白な例を考慮しません。 プロのプログラマーを雇う度合いは、プロジェクトの予算に依存することは明らかです。 また、開発に拍車をかける開発者のイニシアチブに支払うプレミアムシステムを導入できるかどうかにも依存します。
他の微妙な点もお金に依存します。重要な瞬間にコンサルタントを雇うことができ、既製のコンポーネントを購入することで時間を節約できます。 独立したビジネスプロジェクトまたはスタートアップの場合、予算により、何百もの競合他社の間で広告とプロモーションに費やすことができる金額が決まります。 歴史は、貧弱なコードと管理を備えたプロジェクトが有能なマーケティング会社で成功することを教えてくれます。
そして最も重要なことは、プロジェクトのリソースが多くなればなるほど、最終的な成功に影響を与えないようにミスを犯す余裕が増えることです。
有効値としてのランダム性
通常、方法論の有効性はプロジェクトの結果に従って評価されます。 そして、ここで私たちはすぐに2つのtrapに陥ることができます-偶然の影響と結果の主観的な解釈。 後者は、選択した方法論を使用したときに失敗したプロジェクトの数を人々が無視するという事実に要約されます（そして、それがどのような違いを生むか、十分な他の理由があることがわかりました）。 まあつまり ほとんどの人はこれを無視します。 つまり あなたがしなければならないことは、一連のプラクティスを作成し、それらを最後にもたらされるいくつかの有名なプロジェクトに適用し、このプラクティスのセットを管理テクニックに組み合わせて、ビッグネームと呼ぶことです。
おめでとうございます、あなたはプロジェクト管理方法論を作成しました。 あなたのテクニックがどれほど効果的であるかをチェックする人はいません（彼らの意見はまだ聞かれません）、誰もがあなたのプロジェクトの成功のみを見ます。 とにかく、プロジェクトの成功に影響を与える他の多くの要因が存在するために方法論が非常に悪い場合でも、特定の数のプロジェクトで結果を生む可能性が高いと思います。 そして、その使用が失敗につながる場合、まれなマネージャーは彼が悪いテクニックを選んだと言うでしょう、彼はむしろ貧しいプログラマー、小さな予算、弱点、非常識な顧客について不平を言います、そしてあなたは他に何も知りません。
上記の人間の性質を考慮すると、新しいプロジェクト管理方法と古いプロジェクト管理方法の自然選択の有効性はかなり低いように思われ、ソフトウェア開発で使用される方法が本当に効果的であるという主張に疑問を投げかけます。 実際、生き残り、配布を得るためには、技術は開発プロセスを圧倒するほど干渉しないように、1つの要件をすべて満たす必要があります。
主観の5分間
ソフトウェアの体系的な開発は少なくとも30年にわたって行われており、その間、業界で無条件に受け入れられるプロジェクト管理の方法論は提示されていませんでした。 生産されるソフトウェアの開発効率と品質に根本的な変更を加えることなく、定期的な方法の変更があります。
方法論の適用からの顕著な結果は、チームに平凡なマネージャーがいる状況に還元でき、どんな明らかな改善であっても、改善につながる可能性があります。 平均的なマネージャーレベル以上の場合、一般的に方法論の有効性は証明可能性を超えています。
通常、開発方法論を導入/変更する決定は、開発が不十分であることが明らかになった時点で行われます。 このアイデアはマネージャーやプログラマーに伝えられますが、より生産的に作業する必要があるというヒントがあり、方法論はシンボルとしてのみ機能します。 簡単に言えば、開発者への圧力から主な結果が得られます。
開発方法論の影響は、他の要因の影響の中で低下しているため、原則として、その利点を評価することはできません。
実際の条件では、管理手法の有効性を検証することはできないという事実により、実際にランダムに使用される多くのアプローチがあります。 これはすべて、マネージャーの銀河の出現につながり、不確実性と困難な証明可能性の原則を混同し（管理ルールの複雑なシステムは単純に間違ってはならないと仮定）、方法論を選択してそれを信頼することにしました。 外から見ると、サーカスのように見えます。一部は、ファッショナブルなテクニックを使用して、フォーマルなアプローチを管理する経験の不足を隠そうとします。管理する才能を持っているが、批判的思考を持たない人は、方法論の成功に成功し、管理プロセスに変更を加える会社のマネージャーが際立っていますアクティビティをシミュレートするプロジェクト。 これはすべて何らかの形で存在し、機能します。明確な評価基準がない場合は、何でも証明できるため、おそらく長い間存在するでしょう。
おわりに
プロジェクト管理にファッショナブルな方法論を使用する必要性に直面した場合、または何か新しいことを試してみたい場合は、その有効性に関する保証を真剣に受け取らないでください。 原則として、有効性の認識は1つまたは2つの当局にかかっており、それからinertia性になります。そして、これらの当局のリーダーシップキャリアが実際に成功した理由は決してわかりません。 ただし、少なくとも2つの理由で、利用可能なテクニックを知っておく必要があります。仕事を見つけたい場合、および一般的な問題の典型的な解決策を頭の中に持ちたい場合です。 また、目的に合ったパターンを選択する機能は、経験が必要です。