アジャイルに関する神話はどこですか



ソフトウェア開発への柔軟なアプローチについて多くの話があります。 また、実装のために状態を導入しようとしています。 契約。 一方、多くの企業はこれらのアプローチにつまずきます。 そして、企業は必要なことを行い、スクラムマスターも含めていますが、ソフトウェア製品は何らかの理由で開発を停止し、欠陥を修正する多くのタスクがあります。 これが起こる理由を見てみましょう。





どうしてそんな人生に来たのですか?



ソフトウェア開発への柔軟なアプローチは、ケントベックの書籍Extreme Programming(XP)のリリース後、2002年からロシアで適用され始めました。 しかし、スクラムは、スクラムアライアンスとスクラムマスターの認定によって導かれ、真の人気をもたらしました。 誰もが、使いやすさ、計画のゲーム、回顧のゲーミフィケーション、そして以前は工場や設計局で使用されていた明らかな毎日の計画会議が好きでした。 そして、誰もがより少ないドキュメントを書いて、より多くのコミュニケーションをとることが可能であり、コード自体は高品質であると信じていました。



その結果、興味深いことが起こりました。 良い宣伝のおかげで(スクラムマスターの認定には多くの費用はかかりません)、彼らはスクラムをアジャイルソフトウェア開発プロセスとして理解し始めました。 しかし、多くの場合、スクラムを実装するとき、およびコミュニケーションを改善するプラクティスでは、高品質のソフトウェア開発を保証するエンジニアリング手法を忘れていました。



その結果、アジャイルは彼らが信じるカーゴカルトに変わりました。 また、ソフトウェア製品は、適切に開発されていなかったため、開発されていません。



振り返る



ソフトウェア開発に関連するアジリティ運動の歴史を詳しく見てみましょう。



解決された主な競合は次のとおりです。







顧客が満足するためには、 高品質で便利なソフトウェアを作成する必要があります。 高品質の製品を作成するために、ソフトウェア開発プロセスの要件を変更する必要ありません 。 同時に、有用な製品を作成するには、製品の要件調整し、ニーズに適応する必要があります。 要件を同時に変更して、要件を変更することは不可能です。



しかし、その後はどうなりますか? できないが、本当にそれが欲しいとき、できます。 XPの作成者は、要件を変更(調整)し、製品が高品質であることを確認する方法を考えました。



ソフトウェア要件の変更による望ましくない主な影響は、ソフトウェアパッケージが非常に複雑であり、ある場所を変更すると、他の場所で予期しない動作が発生する可能性があることです。 単体テスト、継続的なリファクタリング、および継続的な統合を使用して、この効果の影響を軽減する必要があります。



したがって、すべてのXPエンジニアリング手法は単一のシステムにリンクされていました。



一方、顧客のことを忘れてはなりません。その間に、彼が何を計画しているかを知り、彼を知っておく必要があります。 また、チーム全体と連絡を取り合います。



その結果、実践システム全体から少なくとも1つのブリックを削除すると、システムが崩壊して製品が埋もれてしまいます。 しかし、それは結局のところ。



何がありますか



すべての基礎となる技術の不完全な適用の結果として、 Hayim Makabeeによる記事で説明された神話が現れました。 アジャイルの終::プリミティビズムからの死。 //システム設計の実践。-2015。





しかし、これらの神話はゼロから生じたものではないと思います。 これらの神話の根本原因は、アジャイルアプローチの基礎である本格的なXPプロセスを使用する代わりに、誰もがソフトウェア開発のすべてのニーズをカバーしていないスクラムコミュニケーションフレームワークを使用していることです。



まとめ



ファッショナブルであるという理由だけで、練習を考えずに適用することはできません。 いつも! あなたは常に先を考える必要があります。



ユニットテスト(TDD)を使用すると、必要なソフトウェアインターフェイスをすぐにテストして作成できます。 しかし、彼らは間違ったアーキテクチャから保護しません。 テストの作成時点では、戦略的ではなく戦術的に考えています。 これは、将来の変化に対する準備ではなく、不適切な判断の実装につながります。



優れた手法「ペアプログラミング」は、戦略的にその場で思考を提供します。 ペアプログラミングでは、1つは常に「ナビゲーター」-ストラテジスト(キーボードなし)、およびキーボードの後ろの2番目の「パイロット」になります。 これにより、一般的にすべてのコードをすぐにカバーし、ローカルで決定を下すことができます。



XP方法論では、「ドキュメントを書かないでください」と書かれています。 コミュニケーションはドキュメントよりも重要ですが、ドキュメントがコミュニケーションの手段である場合、Wikiシステムはこのドキュメントが必要な範囲で正確に作成されるようにします。 これにより、ペアの同期(パイロットナビゲーター)が向上し、アーキテクチャの調査と議論を通じて高品質のコードが作成されます。



また、エクストリームプログラミングのプラクティスでは、「技術的な義務を果たし、顧客を満足させる」という記述は一切ありません。「継続的なリファクタリングを行うと、テストがあなたを守ります。 フォースがあなたと共に来ますように。」 これは、すべてのタスクの完了時に、技術的な負債がないことを意味します。 絶対に。



XP方法論は、「システム全体を事前に設計しないでください」とも言っていません。 「変更に備えてください」とは、アーキテクチャを適度に柔軟にすると同時に、ある程度の作業を実行し、頻繁に結果を顧客に示すために適度に十分にすることを意味します。



おわりに



  1. カーゴカルトの崇拝とアクションの機械的な実行は、望ましい効果を与えません。 そして、それはさらに悪化する可能性があります。
  2. XPテクニックの少なくとも1つを使用しない場合、アジャイルで製品をビルドしません。 途中で崩壊します。
  3. 各チームメンバーは、この手法またはその手法が必要な理由を理解する必要があります。 ポイント1を参照してください
  4. あなたの栄冠で休むことはありません、あなたは常に何かを改善することができます。 慣性に屈しないでください。




文学



  1. 極端なプログラミング。 ケント・ベック
  2. 神話上の男-月またはソフトウェアシステムの作成方法。 フレデリックブルックス
  3. プロのソフトウェア開発。 マッコネルS
  4. 目的。 エリヤ・M・ゴールドラット、ジェフ・コックス




あとがき



Q:スクラムプロジェクトは成功していますか?

A:XPプラクティスを使用して行われた場合のみ。 または、ターンキーベースでプロジェクト全体が1か月未満で完了する場合。



All Articles