Tom DeMarco：ソフトウェアエンジニアリング-時間の経過したアイデア？

私は、柔軟なソフトウェア開発方法のトピックについて頻繁に人々とコミュニケーションをとり、時々これについて記事を書きます（例えば、 ITにおけるかんばんに関するHabanに関する最近の記事）。

そして、多くの人がかんばん、スクラム、またはXPについて考えることさえも止めているこれらの方法に対して人々が与える主な議論は、これらの方法論の開発に対するおそらく低いレベルの制御であると言えます。

同時に、一部の人々は、専門性の欠如として、制御のレベルが方法論にあまり依存せず、実際、ソフトウェア開発の分野での制御は概してフィクションであるという議論を認識しています。



そのような人々のために、ソフトウェアエンジニアリングの創始者の1人であり、ソフトウェアメトリックの開発者であり、有名な本「The Human Factor：Successful Projects and Teams」の共著者であるTom Demarco による新しい記事を翻訳しました。

この記事は非常に挑発的であり、今では英語のブログで広く議論されており、ロシア語への翻訳を見たことがないのは奇妙です。 しかし、挑発にもかかわらず、開発に対するコントロールの重要性と可能性についての誰かの考えを変えることができる非常に正しい考えがいくつかあります。

一般的に、カットの下の記事の翻訳を読んでください。





トムデマルコ：ソフトウェアエンジニアリング-時間の経過したアイデアですか？



最近では、ドイツのガルミッシュで開催されたソフトウェアエンジニアリングに関するNATO会議の40周年が開催されました。 ソフトウェアのエンジニアリング分野が最初に提案されたのはそこです。

私の初期の本がこの新しい規律の一部になったので、今では位置を修正、修正する絶好の瞬間のようです。 メトリックに関する初期の本、 ソフトウェアプロジェクトの制御：管理、測定、および推定（Prentice Hall / Yourdon Press、1982）は 、著名な開発者が仕事を共有し、プロジェクトを計画するのに大きな役割を果たしました。

そして今、私はこれらのヒントが過去に正しいのか疑問に思っていますが、それらはまだ正しいのですか？開発プロジェクトを成功させるにはメトリックが必要だとまだ信じていますか？

私の答え：NO、NO、NO。



私にとってこの本は、各ページに書かれた一般的に本当のことを好奇心is盛に組み合わせたものですが、一緒になって不正確な共通メッセージを作成します。

それはまるで本の若い著者が彼が好まないメトリックに決して会わないかのようです。 この本のより深い意味は、指標が優れており、指標が多いほど良いということです。

メトリックはお金と時間を要し、慎重に節度して使用する必要があることを理解しています。

さらに、ソフトウェア開発は物理学などの科学とは本質的に異なり、そのためメトリックスの精度ははるかに低くなります。 そして、彼らは無条件ではなく、非常に懐疑的であると考えられるべきです。



支配下



私の本で最も引用されている行は、最初の文です。

「測定できないものを制御することはできません」

この文は真実ですが、この文の使用が間違っていることをますます発見しています。 この提案は、制御が重要な側面であり、おそらくソフトウェア開発プロジェクトにとって最も重要な側面であることを示唆しています。

しかし、これはそうではありません！

多くのプロジェクトはコントロールなしで開発されましたが、それでもGoogleEarthやWikipediaなどの優れた製品が結果として生まれました。

コントロールの実際の役割を理解するには、 2つのまったく異なるタイプのプロジェクトの違いを理解する必要があります 。

「プロジェクトA」は最終的に100万ドルの費用がかかり、約110万ドルの価値を生み出します。

「プロジェクトB」は最終的に約100万ドルの費用がかかり、5000万ドル以上の利益（価値）をもたらします。



プロジェクトAでは制御が本当に非常に重要であるが、プロジェクトBでは絶対に重要ではないことがすぐに明らかになります。これは、 厳密な制御は比較的役に立たないプロジェクトでは非常に重要であり、有用なプロジェクト。

これは、コントロールに集中すればするほど、最終的にほとんど利益をもたらさないプロジェクトに取り組んでいる可能性が高いことを示唆しています。

もっと重要な質問は、「利益をほとんどもたらさないほど多くのプロジェクトを行っているのは、どのような悪魔なのか」だと思います。



コントロールなしでプロジェクトを立ち上げるのは普通だと言ってもいいですか？ 実際に！

最初に、正確な制御がそれほど必要とされないプロジェクトを選択する必要があると思います。 次に、どんなに一生懸命やろうとしても、それをどれだけコントロールするかについての期待を減らす必要があります。



邪魔なアナロジー



あなたがティーンエイジャーの育成を制御しようとしていると想像してください。 あなたの子供をコントロールするというまさにその考えは、あなたにとって少し不安で不快に思えるかもしれません。 さらに、成功する可能性は高くないかもしれません。

このタスクに失敗すると、完全に失敗し、誰かの人生を破壊する可能性があります。 したがって、完全にグリップを緩めたり、ティーンエイジャーを自由に泳がせたりしないことは明らかです。

それで、あなたは剣士として、まるでそれが鳥であるかのようにあなたの剣を保持することを学んでいます。 弱すぎると彼女は飛び去ってしまいます...



ここで、「測定できないものを制御できない」というルールをティーンエイジャーに適用します。 本当に重要なもののほとんど-名誉、尊厳、規律、性格、プレッシャーの下での礼儀正しさ、価値、倫理、創意工夫、忠誠心、ユーモア、善意-それらは測定できません。

あなたはあなたの子供を導くだけでなく、あなたはどんな指標からも助けを借りずにできます。 そして、これは難しいですが、子供を育てるのは難しいです。

あなたは学校の成績の形でいくつかの「測定」を持つことになります、そしてあなたはそれに感謝しています。 しかし、あなたはまた、数学の理解が測定しやすいので、あなたの子供の数学の成績がスペインの成績よりも達成度の良い指標であることを知っています。

そして、彼の行動の評価は、子供についてよりも教師についてより多くをあなたに伝える可能性があります。



では、コントロールなしでプロジェクトをどのように管理しますか？

まあ、あなたは人をコントロールし、時間とお金をコントロールします。 たとえば、チームリーダーに伝えます。

「私は最終日を知っています、そしてあなたにそれを話すつもりさえありません。 ある日、私はあなたのところに来て、プロジェクトが一週間で終わると言います-あなたはすべての仕事を終えて完成品であなたが持っていることをする準備ができているべきです。 あなたの仕事は、段階的に作業を行い、重要度の高い順にプロジェクトにピースを追加し、統合、文書化、テストを段階的かつ継続的に行うことです。





これは柔軟なメソッドの推奨のように聞こえるかもしれませんが、実際にソフトウェアを作成するには程遠いため、メソッドレベルで推奨することはできません。 むしろ、私は管理アプローチを推奨します。これは、チームをアジャイル手法に向け、少なくともアジャイルスクールからの漸進的なアイデアに導くことができる手法です。



ここまでは、主にソフトウェアエンジニアリングの指標について説明してきました。 残りはどうですか？

少しずつ、私はソフトウェアエンジニアリングが時が過ぎ去ったアイデアであるという結論に達しました！

私は今でもそれがソフトウェア工学において非常に理にかなっていると信じています。 しかし、それはソフトウェアエンジニアリングが意味するようになったものではありません。 この用語は、特定のプロセス、専門知識と研究、要件開発、メトリック、エンジニアリング、品質管理、厳密な計画と追跡、コーディングと文書化の標準を含む特定の分野を取り囲んでいます。

これはすべて、プラクティスの一貫性と予測可能性のために必要です。 一貫性と予測可能性は依然として望ましいですが、それらが最も重要なことではありませんでした。

たとえば、過去40年にわたって、予算を超過することなくプロジェクトを期日どおりに完了できなかったことに苦しんでいます。 しかし、先ほど述べたように、はるかに重要な目標は、世界を変えるソフトウェアを作成すること、または会社やビジネスを変革するソフトウェアを作成することです。 私たちは、しばしば制御不能な場所で起こる変化にかなり成功しました。



ソフトウェア開発は常に実験的なものです。 はい、プログラムの作成は必ずしも実験的ではありませんが、プログラムの概念は常にそうです。

そして、これはまさに私たちが焦点を合わせるべき場所です。 そして、これは私たちが常に以前に集中しなければならなかった場所です。