ソフトウェア開発への柔軟なアプローチについて多くの話があります。 また、実装のために状態を導入しようとしています。 契約。 一方、多くの企業はこれらのアプローチにつまずきます。 そして、企業は必要なことを行い、スクラムマスターも含めていますが、ソフトウェア製品は何らかの理由で開発を停止し、欠陥を修正する多くのタスクがあります。 これが起こる理由を見てみましょう。
どうしてそんな人生に来たのですか？
ソフトウェア開発への柔軟なアプローチは、ケントベックの書籍Extreme Programming（XP）のリリース後、2002年からロシアで適用され始めました。 しかし、スクラムは、スクラムアライアンスとスクラムマスターの認定によって導かれ、真の人気をもたらしました。 誰もが、使いやすさ、計画のゲーム、回顧のゲーミフィケーション、そして以前は工場や設計局で使用されていた明らかな毎日の計画会議が好きでした。 そして、誰もがより少ないドキュメントを書いて、より多くのコミュニケーションをとることが可能であり、コード自体は高品質であると信じていました。
その結果、興味深いことが起こりました。 良い宣伝のおかげで（スクラムマスターの認定には多くの費用はかかりません）、彼らはスクラムをアジャイルソフトウェア開発プロセスとして理解し始めました。 しかし、多くの場合、スクラムを実装するとき、およびコミュニケーションを改善するプラクティスでは、高品質のソフトウェア開発を保証するエンジニアリング手法を忘れていました。
その結果、アジャイルは彼らが信じるカーゴカルトに変わりました。 また、ソフトウェア製品は、適切に開発されていなかったため、開発されていません。
振り返る
ソフトウェア開発に関連するアジリティ運動の歴史を詳しく見てみましょう。
解決された主な競合は次のとおりです。
顧客が満足するためには、
高品質で便利なソフトウェアを作成する必要があります。 高品質の製品を作成するために、ソフトウェア開発プロセスの
要件を変更する必要
はあり
ません 。 同時に、有用な製品を作成するには、製品
の要件を
調整し、ニーズに適応する必要があります。 要件を同時に変更して、要件を変更することは不可能です。
しかし、その後はどうなりますか？ できないが、本当にそれが欲しいとき、できます。 XPの作成者は、要件を変更（調整）し、製品が高品質であることを確認する方法を考えました。
ソフトウェア要件の変更による望ましくない主な影響は、ソフトウェアパッケージが非常に複雑であり、ある場所を変更すると、他の場所で予期しない動作が発生する可能性があることです。 単体テスト、継続的なリファクタリング、および継続的な統合を使用して、この効果の影響を軽減する必要があります。
したがって、すべてのXPエンジニアリング手法は単一のシステムにリンクされていました。
- 新しい要件を実装するには、既存のコードをリファクタリングする必要があります。
- リファクタリングが何も壊さないように、単体テストが必要です。
- 単体テストが常に機能するように、一部は統合サーバーで毎日実行する必要があります。
- テストを書くことを忘れないように、コードの前にテストを書く必要があります（テスト駆動開発（TDD）テクニック）。
- そのため、テストを書くのが面倒ではありません-これを一緒に行う必要があります。
一方、顧客のことを忘れてはなりません。その間に、彼が何を計画しているかを知り、彼を知っておく必要があります。 また、チーム全体と連絡を取り合います。
- 要件の変更を時間通りに学習するには、多くの場合、結果を顧客に提供する必要があります。
- チーム全体がどこ、誰、どのリファクタリングを認識しているか-毎日コミュニケーションをとる必要があります。
- 開発アプローチを改善するには、反復の最後に結果を振り返って議論する必要があります。
その結果、実践システム全体から少なくとも1つのブリックを削除すると、システムが崩壊して製品が埋もれてしまいます。 しかし、それは結局のところ。
何がありますか
すべての基礎となる技術の不完全な適用の結果として、
Hayim Makabeeによる記事で説明された神話
が現れました。 アジャイルの終:：プリミティビズムからの死。 //システム設計の実践。-2015。- 神話1.適切な設計上の決定は、ユーザーストーリーを実装するときに発生します。
- 神話2.技術的負債は将来いつでも支払うことができます。
- 神話3.継続的なリファクタリングは、コードを作成する効率的な方法です。
- 神話4.柔軟性はアジャイルプロセスに従うことで達成できます。
しかし、これらの神話はゼロから生じたものではないと思います。 これらの神話の根本原因は、アジャイルアプローチの基礎である本格的なXPプロセスを使用する代わりに、誰もがソフトウェア開発のすべてのニーズをカバーしていないスクラムコミュニケーションフレームワークを使用していることです。
まとめ
ファッショナブルであるという理由だけで、練習を考えずに適用することはできません。 いつも！ あなたは常に先を考える必要があります。
ユニットテスト（TDD）を使用すると、必要なソフトウェアインターフェイスをすぐにテストして作成できます。 しかし、彼らは間違ったアーキテクチャから保護しません。 テストの作成時点では、戦略的ではなく戦術的に考えています。 これは、将来の変化に対する準備ではなく、不適切な判断の実装につながります。
優れた手法「ペアプログラミング」は、戦略的にその場で思考を提供します。 ペアプログラミングでは、1つは常に「ナビゲーター」-ストラテジスト（キーボードなし）、およびキーボードの後ろの2番目の「パイロット」になります。 これにより、一般的にすべてのコードをすぐにカバーし、ローカルで決定を下すことができます。
XP方法論では、「ドキュメントを書かないでください」と書かれています。 コミュニケーションはドキュメントよりも重要ですが、ドキュメントがコミュニケーションの手段である場合、Wikiシステムはこのドキュメントが必要な範囲で正確に作成されるようにします。 これにより、ペアの同期（パイロットナビゲーター）が向上し、アーキテクチャの調査と議論を通じて高品質のコードが作成されます。
また、エクストリームプログラミングのプラクティスでは、「技術的な義務を果たし、顧客を満足させる」という記述は一切ありません。「継続的なリファクタリングを行うと、テストがあなたを守ります。 フォースがあなたと共に来ますように。」 これは、すべてのタスクの完了時に、技術的な負債がないことを意味します。 絶対に。
XP方法論は、「システム全体を事前に設計しないでください」とも言っていません。 「変更に備えてください」とは、アーキテクチャを適度に柔軟にすると同時に、ある程度の作業を実行し、頻繁に結果を顧客に示すために適度に十分にすることを意味します。
おわりに
- カーゴカルトの崇拝とアクションの機械的な実行は、望ましい効果を与えません。 そして、それはさらに悪化する可能性があります。
- XPテクニックの少なくとも1つを使用しない場合、アジャイルで製品をビルドしません。 途中で崩壊します。
- 各チームメンバーは、この手法またはその手法が必要な理由を理解する必要があります。 ポイント1を参照してください
- あなたの栄冠で休むことはありません、あなたは常に何かを改善することができます。 慣性に屈しないでください。
文学
- 極端なプログラミング。 ケント・ベック
- 神話上の男-月またはソフトウェアシステムの作成方法。 フレデリックブルックス
- プロのソフトウェア開発。 マッコネルS
- 目的。 エリヤ・M・ゴールドラット、ジェフ・コックス
あとがき
Q：スクラムプロジェクトは成功していますか？
A：XPプラクティスを使用して行われた場合のみ。 または、ターンキーベースでプロジェクト全体が1か月未満で完了する場合。