アジャイル、スクラム、成果をもたらすソフトウェアを書くための派手な言葉
どのような観点から見ても、一般的にビジネス アプリケーション ソフトウェア開発者は評判が悪いです。システムはほぼ必然的に納品が遅れたり、まったく納品されなかったりすることがあります。平均的な企業の平均的なユーザーは、耐え忍ばなければならないコンピュータ システムについて文句を言いながら毎週文字通り何時間も費やすことになります。 「なぜそうなったの？」、「それはどういう意味ですか？」などは私が毎日耳にすることのいくつかです。
私はビジネス システムの作成に何年も費やしましたが、ほとんどの場合、ユーザーは自分たちが取得して使用しているものについて肯定的でした。システムは初期仕様に従って作成され、徹底的にテストされ、必要に応じて合意されたコストで必要に応じて適応されます。クライアントの継続的なサポートとソフトウェア会社の継続的な収入は、最高の組み合わせでした。詳細な要件分析に基づく最初の仕様は常に機能の概要であり、コードの詳細は含まれていません。(ゲームを書いていたときに) 疑似コードを一度使用したと思います。 「これが私たちに必要なことです」という言葉だけで私にとっては十分でした。それ以外には、いくつかのユーザー インターフェイスのモックアップと多くのデータベース設計があり、作業は終わりました。開発ライフサイクルのテストと「調整」フェーズはすべて重要でした。システムは通常、予定どおりに納品され、稼働しました。
最近では (こんなことを言うとは思ってもいませんでしたが)、システム関連のすべては計画、さらなる計画、そして再利用性が重要です。私にとって非常に異質に見えるのは、この計画の大部分が機能要件を満たすことではなく、むしろ、書くときに何を書くのか、そしてなぜそれを書くのかを詳しく説明することであるということです。それが理にかなっているといいのですが? 2 年後に再利用する必要が「あるかもしれない」場合に備えて、1000 年以内に実行できる内容を、なぜ 10 行で書くのでしょうか?個人的なレベルで言えば、2年後にこれ以上に書き直せなかったものを書いたことはありません。私は常に学習し改善していますが、12 か月経ったコードでも振り返るとうんざりすることがよくあります。求人広告を見ていると、どのような方法論やスキルが求められているのか迷ってしまいがちです。一人の人間がそこまで多くのことを知ることは人間に可能でしょうか?私はよく自問します。もう一つの質問は、彼らが製品を生産したことがあるのかということです。これだけ計画を立て、コードの再利用について心配しているのに、何かが成し遂げられるでしょうか?学術開発者を雇った会社を知っていますが、彼らは設計に集中するのに忙しすぎて、製品が完成に近づく前に会社が倒産してしまいました。人々はどれだけの遅延を許容できるでしょうか。テスト段階は決して問題ではありませんでした。製品の代金を私たちに支払っている企業が、自分たちのためにではなく、後のプロジェクトで何度も使用されるコードの代金を支払うことを期待されるのはなぜでしょうか?
誤解しないでください。計画が悪いと言っているわけではありません。計画はシステム開発の不可欠な部分ですが、それだけではありません。私は古い考えかもしれませんが、実際にシステムを書いてそれを動作させることが楽しいのです。システムが常に大きくなり、より複雑になっていることは承知しています。大規模な開発者チームが存在するのが一般的です。ただ、どれだけ計画を立て、視覚化し、ブレインストーミングを行っても、必ず何かが見逃されることはあると思います。私たちは不可能な完璧なシステムを目指して努力していますが、最悪の場合、実際にはシステムを提供できないこともあります。信じられない？マイクロソフトを見てください。アプリケーションの計画にかかる工数を想像してみてください。新しいバグや脆弱性はどのくらいの頻度で発見されますか?なぜこれらを設計段階で廃止しなかったのでしょうか?開発チームは「脆弱性 X」が発生する可能性すら考えもしませんでした。簡単に言うと、最も基本的なシステム以外では、どんなに論理的であっても、すべての不測の事態に備えて計画を立てることはほぼ不可能です。なぜテスト中に見つからないのでしょうか？ここでの解決策は、昔ながらの開発、計画 (話す) の時間を減らし、執筆とテストの時間を増やすことでしょうか?コードの再利用について心配する時間が減り、クライアントと顧客に実用的な製品を提供する時間が増えますか?計画に費やす時間を減らしてテストに多くの時間を費やした場合、Microsoft は良くなるでしょうか、それとも悪くなるでしょうか? Microsoft の弁護では、彼らはパッチ適用が非常に上手なので、私たちをテスターとして利用していると見られるかもしれません。彼らが適切なテストにもっと時間を費やしていれば、私たちが彼らのためにテストする必要はなくなるのではないだろうか？
私がまだ出会ったことのない過剰計画の最悪の例は、私が日常的に使用している金融システムです。このシステムの導入には数百万ドルの費用がかかり、計画には何年もかかり、コンサルタントの数は誰にもわかりません。これは、ソフトウェア業界の最大手の 1 つによって書かれ、専門のソフトウェア コンサルタント会社によって調整されています。この結果、システムは事実上使用不可能になり、既製の製品に置き換えられるのもそう遠くない状態になります。最低レベルでは非常にひどいので、マウスのクリック位置を間違えただけでもアプリケーションがハングしてしまいます。このシステムが引き渡し前にテストされたことが信じられません。そのまま納品が大幅に遅れたのですが、その理由は「企画サイクル」が予想以上に長かったためです。それが行うことはそれほど複雑ではありません。ただ、明らかに計画されており、考えた結果急いで実装されることになります。この計画のすべては、ユーザーの基本的な機能要件を満たすシステムにさえなりませんでしたが、まあ、彼らは将来どこかでそのコードを再利用することになるでしょう。
とにかく、私は、複数の異なる計画戦略を使用することがなぜそれほど重要なのかを理解するために、卒業証書を取得し始めたところです。 1 か月かけて「きちんと」やればできることを、なぜ 1 日で書くのでしょうか?数年後にこれを読み返して、何を考えていたか疑問に思うことはわかっています。それをするか、「ああ、私が書いていたものを実際に書き終えたのはその時だった」と自分に言い聞かせるかのどちらかです。でも真剣に言うと、この作業を終える頃には、自分がどこで間違っているかに気づくと確信しています。それまでは、RAD スタイル (名前が付いているのは嬉しいですね!) を使用してアプリケーションを書き続けるつもりです。誰の好みにも合いませんが、私にとっては問題なく機能します。
注：私の開発アプローチには名前があり、アジャイル手法として分類されているとは誰が想像したでしょうか。これを説明する素晴らしい記事があります アジャイルな方法論 ある程度詳しく。