「こんにちは、アミーゴ！」
「こんにちは、ビラーボ！」
「今日はプログラムが通常どのように開発されるかについてお話します。」
「20 世紀、現代の IT が初期段階にあったとき、誰もがプログラミングは建設や製造のようなものだと考えていたようです。」
「物事は通常次のように進みました。」
「顧客は、必要なプログラムの種類、つまり何を行うべきか、どのように行うべきかを説明します。」
「ビジネス アナリストは彼の話を聞き、その内容に基づいてプログラム要件の完全なリストを作成します。」
「その後、プロジェクト マネージャーはこれらの要件をタスクに分割し、どのプログラマーがどのタスクをどの順序で実行するかを決定します。」
「その後、プログラマーは仕事に取り掛かります。場合によっては、数年間（！）働くこともありました。」
「完成すると、プログラムはテスターに渡されました。」
「テスターはプログラムの各要件を調べて、それらが実装されていること、およびプログラムが想定どおりに動作することを検証します。」
「何か問題が発生した場合、テスターはバグを記録し、プログラマーに送信します。」
「その後、プログラマーはバグを修正し、修正されたプログラムをテスターに送り返します。そしてこのサイクルが繰り返されます。」
「主なバグが修正された時点で、プログラムは顧客に渡されました。」
「本当にそうなったの？」
「もちろん、かなり簡略化しましたが、これは実際に行われた方法にかなり近いものです。」
「では、プロジェクトが完了するまでに本当に 1 年半から 2 年かかる可能性があるのでしょうか?」
「プロジェクトの開発が非常に長い場合には、プロジェクトを複数のリリースに分割することがありました。3 ～ 6 か月ごとに、開発者はプログラムの機能の特定の部分を作成し、テストし、すべてのバグを修正して、開発者に見せなければなりませんでした。お客様。"
「第一に、彼が自分の感想を共有できるようにするためです。そして第二に、より重要なことは、彼がプログラムの開発費を払い続けるためです。」
「支払い続けますか？」
「当時、開発には計画より 2 ～ 3 倍の時間がかかることがよくありました。また、プログラマーには時給が支払われることが多かったので、プログラムの費用が 2 ～ 3 倍高くなりました。さらに、利益も減りました。結局のところ、顧客が今望んでいることは何ですか？」 10万ドルの製品は3年後には必要なくなるかもしれない――特に価格が3倍ならなおさらだ。」
「顧客が支払いを拒否することがよくありましたか?」
「そうです。その後、彼らは契約に罰則を追加し始めましたが、状況は改善されませんでした。ソフトウェア開発は長引いてしまいました。そして、たとえ望んでも誰もそれについて何もできませんでした。」
"しかし、なぜ？"
「まず第一に、計画段階ではほとんど何もわかっていません。多くの場合、最初はプログラマーが直面するであろう問題を誰も予測できませんでした。」
「でも、経験豊富なプログラマなら、すべてを予見できたはずですよね？」
「プログラミングがユニークな職業であることがわかりますか。」
「普通の労働者は同じ仕事を何度も繰り返し行うことが多い。時計屋は時計を作り、料理人は料理をし、教師は教え、医者は治療するなど。」
「これらの専門家は、基本的に毎日同じことを行っています。その結果、彼らの仕事はどんどん良くなっていきます。」
「プログラミングでは、アプローチが異なります。プログラマーは毎日同じタスクに直面するとすぐに、それを実行する関数、モジュール、またはプログラムを作成し、二度とそのタスクには戻りません。」
「各プログラマーは通常、各タスクを一生に 1 回解決します。」
「何かを発明する科学者や設計エンジニアのようなもの。」
「ああ。それで、プロジェクトで最も重要な役割は何ですか?」
「うーん、どう答えればいいでしょうか。どれが最も重要かを言うのは簡単ですが、最も重要でないものを特定するのは難しいです。」
"テスター (品質保証 、QA )の主な仕事は 、プログラムのステータスを監視し、バグを迅速に報告することです。テスターがバグをより多く、より早く発見するほど、より多くのバグを修正できるようになります。優れたテスターは、製品の品質に大きな影響を与えます 。優れたプログラマはそうします。」
「なぜプログラマーは自分のプログラムをテストできないのでしょうか。結局のところ、彼らは何が機能し、何が機能しないのかをテスターよりもよく知っているのではありませんか?」
「優れたプログラマーは、優れたテスターになることができないだけです。プログラマーは、プログラムがどのようにうまく機能するかを知っているため、常に特定の方法でプログラムを使用します。これとは対照的に、プログラムを自分の好きなように使用する一般ユーザーとは対照的です。 」
「さらに、テスターは、まだ動作していないものをテストしません。テスターは、プログラマーがすでにほぼ完全に動作していると主張するプログラムの機能または部分をテストします。」
「そして、テスターがその機能に大量のバグを見つけ、プログラマーがそれらを修正すると、実際に製品は完璧に近づきます。」
"プログラマー (ソフトウェアデベロッパーエンジニア 、 開発者、 SDE )の主なタスクは、新しい機能を実装することです。または、より簡単に言えば、プログラマー に割り当てられたタスクを実行することです。プログラマーに新しい機能を伴うタスクが割り当てられるときバグが割り当てられたら、バグを修正します。」
「しかし、場合によっては、プログラムまたはその一部のアーキテクチャを考え出すなど、より困難なタスクが発生することもあります。提案されたアーキテクチャが優れているほど、将来の作業の実行が容易になります。」
「問題は、最初にアーキテクチャを選択する必要があることですが、適切なアーキテクチャを選択したかどうかは、開発の途中になって初めて明らかになるのです。」
「さらに、アーキテクチャが成功し、プログラムが素晴らしいものになった場合、顧客はおそらくそれをプログラムの新しいバージョンの基礎として使用したいと思うでしょう。」
「これが私が言いたいことです。」
「どのアーキテクチャを選択しても、そのアーキテクチャでは考慮されていない多数の変更、追加、新機能が常に存在します。」
「これが良い例です。」
「顧客から 5 階建ての建物を建ててほしいと頼まれ、あなたは建築を設計して家を建てます。」
「その後、顧客は別のストーリーを追加するように要求し、さらに別のストーリーを追加するというように続けます。」
「しかし、1階の壁はそれほどの重量を考慮して設計されておらず、基礎も同様でした。したがって、すべてをやり直す必要があります。」
「しかし、5 階建ての建物が完成した後、顧客がすぐに 50 階建ての建物が欲しいと決めたらどうなるでしょうか?」
「既存の建物を取り壊して、すべてを一から作り直したほうが簡単ですが…」
「しかし、建築に関して一つアドバイスがあります。」
「アプリケーションのアーキテクチャは、何よりもまず柔軟である必要があります。つまり、アプリケーションの半分をやり直すことにした場合に、最初から始める必要はありません。このタイプのアーキテクチャは、通常、フレキシブルおよびモジュール型と呼ばれます。」
「プロジェクトマネージャーの主な仕事は意思決定をすることです。プロジェクトマネージャーは全体像を見て、その観点に基づいて意思決定を下す人です。」
「開発中に、特定のタスクが計画どおりに完了しないことが明らかになったとします。その場合、プロジェクト マネージャーは次のことができます。」
「a) タスクを変更するために顧客と交渉してみます。」
「b) タスクにより多くの時間を割り当てます」
" c) 他のプロジェクトからより経験豊富なプログラマーを連れてくる。"
「他にも多くの可能性があります。」
「それぞれの選択肢では何かを犠牲にする必要があり、 マネージャーの仕事はこれらの犠牲による損失の合計を最小限に抑えることです。」
「たとえば、競合他社が主任プログラマーに 2 倍の金額を提示して盗んだとします。」
「プロジェクトマネージャーは次のことができます。」
「a) 何もしません。プログラマーは退職し、プロジェクトは遅れてペナルティを受ける可能性があります。」
「b) 彼の給料を 2 倍にします。そうすれば、チームの他の全員も昇給を望むでしょう。全員にもっとお金を与えると、プロジェクトのコストが増加し、採算が合わなくなる可能性があります。」
" c) あなたが考えた他の選択肢。"
"そうか。"
「プロジェクトマネージャーが悪いと、良いチームは通常プロジェクトを長引かせますが、常にそうとは限りません。」
「平均的なプログラマーのチームを持つ優れたマネージャーは、優秀なプログラマーのチームを持つ悪いマネージャーよりも、ほとんどの場合、より早くプロジェクトを完了します。」
"そうか。"
「それでは、少し休憩してから続けましょう。」
GO TO FULL VERSION