あなたはプログラミングに精通していますが、エクストリーム プログラミング (略して XP) はまだ少し謎です。
名前に惑わされないでください。有益な情報を見逃す危険があります。
この記事では、エクストリーム プログラミングについて知っておく必要があるすべてのことを取り上げ、エクストリーム プログラミングを有利に利用できるようにします。
エクストリーム プログラミングは、総称してアジャイル方法論として知られているものの一部であるソフトウェア開発方法論です。 XP は、価値、原則、および実践に基づいて構築されており、その目標は、小規模および中規模のチームが高品質のソフトウェアを作成し、絶え間なく変化し進化する要件に適応できるようにすることです。
XP が他のアジャイル方法論と異なる点は、XP がソフトウェア開発の技術的側面を強調していることです。 エクストリーム プログラミングは、エンジニアリング プラクティスに従ってチームが持続可能なペースで高品質のコードを提供できるように、エンジニアがどのように作業するかについて正確です。
エクストリーム プログラミングとは、一言で言えば、極限まで行われたグッド プラクティスです。 ペアプログラミングはいいので、ずっとやりましょう。 事前にテストするのは良いことなので、製品コードを書く前にテストします。
XP は、他の方法論とは異なり、エンジニアリングの実践に関して重要かつ関連性のある価値と原則に基づいています。
価値観はチームに目的を提供します。 それらは、高いレベルで意思決定を導く「北極星」として機能します。 ただし、値は抽象的で、特定のガイダンスにはあいまいすぎます。 例：コミュニケーションを大切にしていると言うと、さまざまな結果につながる可能性があります。
実践は、ある意味、価値観の反対です。 それらは具体的で現実的なものであり、 defi何をするかを具体的に設定すること。 プラクティスは、チームが価値観に対して責任を持つのに役立ちます。 たとえば、情報ワークスペースを実践すると、透明性のあるシンプルなコミュニケーションが促進されます。
原則は、実践と価値の間のギャップを埋めるドメイン固有のガイドラインです。
XP の価値: コミュニケーション、シンプルさ、フィードバック、勇気、敬意。 それぞれについて詳しく見ていきましょう。
起草 BlogInnovazione.イメージのそれ alexsoft.com
コミュニケーション学: コミュニケーションの欠如は、チーム内での知識の流れを妨げます。 多くの場合、問題が発生した場合、誰かがすでにその修正方法を知っています。 しかし、コミュニケーションが不足していると、問題について学ぶことも、その解決に貢献することもできなくなります。 このように、問題を XNUMX 回解決することになり、ムダが発生します。
単純: シンプルさとは、常に最も簡単なことをしようと努力することです。 それはよく誤解され、最も単純なこと、ピリオドと見なされ、「それが機能する」部分を無視します。
また、シンプルさは非常に文脈に依存することを覚えておくことも重要です。 あるチームにとって単純なことは、別のチームにとっては複雑であり、各チームのスキル、経験、知識に完全に依存します。
フィードバック: より伝統的なカスケード ソフトウェア開発方法論におけるフィードバックは、多くの場合、「少なすぎる、遅すぎる」ものです。
ただし、XP は変化を受け入れ、XP チームはタイムリーで絶え間ないフィードバックを求めて努力します。 軌道修正が必要な場合、XPers はできるだけ早く知りたいと考えています。
起草 BlogInnovazione.イメージのそれ alexsoft.com
フィードバックにはさまざまな形や大きさがあります。 プログラミングを組んでいる場合、同僚からのコメントは重要なフィードバックです。 理想的にはチームのメンバーである顧客を含む、アイデアに対する他のチーム メンバーの意見も同様です。
テストは、テスト結果を超えた貴重なフィードバックのもう XNUMX つのソースです。 テストを書くのが簡単か難しいかに関わらず、フィードバックも同様です。 テストの作成に問題がある場合は、プロジェクトが複雑すぎる可能性があります。 フィードバックに耳を傾け、デザインを合理化します。
素晴らしいアイデアのように思えることでも、実際にはうまくいかないことがあります。 したがって、完成したコードは、配布された製品と同様に、フィードバックのソースでもあります。
最後に、フィードバックが多すぎることに注意してください。 チームが処理しきれないほど多くのフィードバックを生成すると、重要なフィードバックがレーダーから外れてしまう可能性があります。 そのため、速度を落として過剰なフィードバックの原因を突き止め、修正することが不可欠です。
コラッジョ: ケント・ベック defi勇気は「恐怖に直面した効果的な行動」として現れます。 ソフトウェア エンジニアとして、恐れることはたくさんあるので、勇気を示す機会はたくさんあります。
真実、特に正直な見積もりなどの不愉快なものを話すには勇気が必要です。 フィードバックの授受にも勇気が必要です。 また、サンク コストの誤謬に陥ることを避け、多額の投資を受けて失敗したソリューションを破棄するには、勇気が必要です。
尊敬: XP の基本的な前提は、誰もが自分の仕事に関心を持っているということです。 ケアと敬意がなければ、どんなに技術的に優れていてもプロジェクトを救うことはできません。
すべての人は、尊厳と尊敬に値します。もちろん、ソフトウェア開発プロジェクトに携わる人々も含まれます。 あなたとあなたのチームメンバーがお互いを尊重し、気遣うとき、クライアント、プロジェクト、そして将来のユーザー、全員が利益を得ます
原則は、価値観よりも具体的なガイダンスを提供します。 それらは、価値を明らかにし、より明確にし、あいまいさを少なくするガイドラインです。
起草 BlogInnovazione.イメージのそれ alexsoft.com
たとえば、勇気の価値だけに基づいて、すぐにスケジュールを大幅に変更することをお勧めします。 ただし、ベイビー ステップの原則は、大きな変化にはリスクがあることを示しています。 そのため、代わりに小さいものを優先してください。
人類: 人間は人間のためにソフトウェアを作成しますが、これは見落とされがちな事実です。 しかし、基本的な人間のニーズ、長所と短所を考慮に入れると、人間が使いたいと思う製品が生まれます。 そして、充実感と成長の機会、帰属意識と基本的な安心感を提供する職場環境は、他の人のニーズをより簡単に考慮できる場所です。
経済: XP では、チームは常にソフトウェア開発の経済的現実に注意を払い、経済的リスクとプロジェクトのニーズを常に評価します。
たとえば、技術的な問題ではなく、ビジネス上の価値に基づいてユーザー ストーリーを実装します。
相互利益: XP の後は、一方の当事者に利益をもたらし、他方の当事者を犠牲にするソリューションを避けます。 たとえば、拡張仕様は他の誰かがそれを理解するのに役立つかもしれませんが、実装する気が散り、ユーザーの実装が遅れます。
相互に有益な解決策は、自動化された受け入れテストを使用することです。 実装に関するフィードバックを即座に取得し、同僚はコードで正確な仕様を取得し、ユーザーは最初に機能を取得します。 さらに、リグレッションに対するセーフティ ネットが用意されます。
ベネフィット（共益）: 特定のソリューションが XNUMX つのレベルで機能する場合、それより高いレベルまたは低いレベルでも機能する可能性があります。 たとえば、XP では、程度の差こそあれ、早期かつ継続的なフィードバックを得ることが重要です。
改善: 改善の原則によると、チームは最初の実装で完璧を目指すのではなく、十分に優れた実装を目指し、実際のユーザーからのフィードバックで継続的に学習し、改善します。
多様性: あなたとあなたの同僚は、多様な視点、スキル、態度から恩恵を受けます。 そのような多様性はしばしば衝突につながりますが、それは問題ありません。
衝突や不一致は、誰もが勇気と尊敬の価値を持って行動するとき、より良いアイデアが生まれる機会です。 反対の意見を表明する勇気、礼儀正しく共感的な方法でそれらを表現することを尊重します。 そして、これらすべてが効果的なコミュニケーション演習です。
反射: 優れたチームは、自分の仕事を振り返り、改善方法を分析します。 XP は、このための多くの機会を提供します。 毎週や四半期ごとのサイクルだけでなく、すべてのプラクティスで促進されます。
論理的な分析に加えて、感情を考慮することが重要です。 あなたが何かを推論する前に、あなたの腸はあなたに知らせることができます。 そして、彼は非技術者と話すことができるので、彼らはまったく新しい可能性を開く質問をすることができます.
フロー: 従来のソフトウェア開発方法論には、個別のフェーズがあり、長期にわたって継続し、フィードバックや軌道修正の機会がほとんどありません。 その代わり、XP でのソフトウェア開発は、価値の一貫した「流れ」の中で、継続的に発生する活動の中で行われます。
機会: ソフトウェア開発において、問題は避けられません。 ただし、すべての問題は改善の機会です。 このようにそれらを見ることを学ぶと、それらの再発を防ぐのにも役立つ創造的で目標指向の解決策を思いつく可能性がはるかに高くなります.
冗長性: 冗長性の原則では、特定の問題が重大な場合、それに対抗するために多くの戦術を採用する必要があります。
欠陥を取ります。 すべての欠陥が生産から逃れるのを防ぐことができる単一の戦術はありません。
したがって、XP のソリューションは、一連の品質対策を積み重ねることです。 ペアプログラミング、テスト、継続的インテグレーション。 それぞれが単一の防御線であり、一緒になって事実上侵入できない壁です。
失敗: 失敗は知識に変換されるとき、無駄ではありません。 行動を起こし、何がうまくいかないかを素早く知ることは、多くの選択肢の中から選択する際に優柔不断になるために何もしないよりも、はるかに生産的です。
品質: 品質と速度の間にはジレンマがあるとよく考えられます。
それは逆です。品質を向上させるためにプッシュすることで、より速く進むことができます。
たとえば、リファクタリング (コードの動作を変更せずにコードの構造を変更すること) は、コードの理解と変更を容易にする方法です。 その結果、コードに欠陥が生じる可能性が低くなり、バグを修正する必要がないため、最初により多くの価値を提供できます。
小さなステップ: 大きな変化は危険です。 XP は、あらゆるレベルで小さなステップで変更を加えることで、そのリスクを軽減します。
プログラマーは、テスト駆動開発を使用して小さなステップでコードを記述します。 彼らは、数週間または数か月ごとではなく、XNUMX 日に複数回コードをメインラインに統合します。 プロジェクト自体は、長期にわたるフェーズではなく、短いサイクルで行われます。
責任を受け入れる: XP では、責任は受け入れられるべきであり、割り当てられるべきではありません。
説明責任には、自分の責任について決定を下す権限が伴う必要があります。 その逆もまた真です。 結果を受け入れる必要がないのであれば、人々に決定を下してほしくありません。
アジャイルな方法論であるエクストリーム プログラミングは、厳格な計画に従わなくても受け入れられ、採用を開始できます。 これは、大きな初期プロジェクトではなく、反復設計です。
XP は従来の方法論とは大きく異なります。つまり、長期にわたるフェーズを回避します。
XP は他のアジャイル方法論とどう違うのですか?
エクストリーム プログラミングは、その性質上、他のアジャイル方法論と多くの共通点がありますが、それらの中で独自のものでもあります。
他のほとんどの開発方法論は、仕事を成し遂げる方法について、どちらかといえば多くを語っていません。 一方、XP は、この点に関して非常にこだわりがあり、ソフトウェア エンジニアリングの実践に重点を置いています。
スクラムは、チームが適応的な方法で複雑なプロジェクトを開発するのを支援するフレームワークです。 スクラムは、開発者がどのように仕事をするかを指示しません。 前述のように、XP は優れたプログラミング手法に重点を置いています。
起草 BlogInnovazione.ja 画像 ネットソリューション
また、XP は明らかにプログラミングに関するものです。 一方、スクラムは、反復アプローチの恩恵を受けるすべてのプロジェクトに適用できます。
XP は、そのコンポーネントへの変更を受け入れます。 チームは、特定のニーズに基づいてプラクティスを変更する権限を与えられ、奨励されることさえあります。 一方、スクラムガイドは、「スクラムの一部しか実装できないが、結果はスクラムではない」と断言しています。
また、スクラムは、仕事を成し遂げるための方法論と実践で補完する必要があるフレームワークです。
これは、極端なプログラミングとスクラムで作業することが強く推奨されることを意味します。
Kent Beck によると、成熟した XP チームは厳格な役割を割り当てるべきではありません。
いくつかの重要な役割を見てみましょう。
これらは XP で採用されているプラクティスです。 彼らは、ソフトウェア エンジニアリング、職場、プロジェクト管理の XNUMX つの主要なグループに分けられます。
ペアプログラミング: XP では、マシンに座ってペアでコードを記述します。 あなたとあなたのカップルは、あなたが取り組んでいる機能を分析、実装、テストしながらお互いに話し合っています。 ペア プログラミングは、魅力的で、楽しく、疲れる一方で、バグの少ないコードを生成するのに特に優れています。
XNUMX分制限: 必須 すべての自動テストの実行を含め、プロジェクト全体を最大 10 分でビルドするのに XNUMX 分かかります。 この制限は、テストの合理化と効果を維持するためのものです。
プログラミング前のテスト: テスト ファースト アプローチを使用して機能を実装します。 テスト駆動開発 (TDD). TDD は、単純な反復手順を使用した開発で構成されます。
TDD にはいくつかの利点があります。
まず、フィードバック。 テストを書くのが難しい場合は、探している、または継承した設計が複雑すぎる可能性があり、単純化する必要があります。
第二に、TDD により、プログラマーは自分が書いたコードを信頼できるようになり、次のステップが常に明確なループのリズムが生まれます。
最後になりましたが、最初から TDD を使用すると、100% のコード カバレッジが保証されます。 テスト スイートは、将来の変更に対する真のセーフティ ネットとなり、コードのリファクタリングを促進し、品質の好循環を生み出します。
増分設計: インクリメンタル デザインを実践するということは、アプリケーションのデザインに毎日投資する必要があることを意味します。重複を取り除き、小さな改良を加えて、現在のシステムが必要としている最適なデザインを実現する機会を探します。
継続的インテグレーション: XP では、作業内容を XNUMX 日に数回、メインの共有リポジトリに統合し、システム全体の自動ビルドをトリガーします。 できるだけ早く、できるだけ頻繁に統合すると、マージや論理的な競合が発生しにくくなるため、統合のコストが大幅に削減されます。 また、環境や依存症の問題も明らかにします。
共有コード (共同所有): XP はコードの共有、つまり共同所有を促進します。各開発者はすべてのコードに責任があります。 多様性の原則を考慮すると、情報交換が促進され、チーム バス ファクターが減少し、各モジュールの全体的な品質が向上します。
単一コードベース: 単一のコードベースは、「トランクベースの開発」とも呼ばれます。 つまり、真実の情報源は XNUMX つしかないということです。 そのため、長期間単独で開発するのではなく、早い段階で頻繁に貢献を XNUMX つのストリームにマージしてください。 機能フラグは、機能が完成するまで機能の使用を制限するのに役立ちます。
毎日の配信: 少なくとも XNUMX 日 XNUMX 回の本番環境へのデプロイは、継続的インテグレーションの論理的な結果です。 実際、今日、多くのチームがさらに進んで、継続的な実装を実践しています。 つまり、誰かがメインラインに参加するたびに、アプリケーションが本番環境にデプロイされます。
コードとテスト: このプラクティスは、テストを含むソース コードがソフトウェア プロジェクトの唯一の永続的な成果物であることを意味します。 ドキュメントを含む他のタイプの成果物の生成に関与することは、顧客にとって真の価値を生み出さないため、多くの場合無駄です。
他のアーティファクトやドキュメントが必要な場合は、本番コードとテストからそれらを生成する努力をしてください。
根本原因分析: 欠陥が生産に入るたびに、欠陥を修正するだけではいけません。 そもそも何が原因なのか、なぜあなたとチームメイトが横滑りを防げなかったのかを突き止めてください。 次に、再発しないように対策を講じます。
一緒に座る: XP では、チームはオープン スペースで一緒に作業することを好みます。 この練習は、コミュニケーションとチームへの帰属意識を促進します。
チーム全員: プロジェクトの成功に必要なすべての人が XP チームの一員です。 これは非常にコンテキストに依存し (チームごとに異なります)、動的であり、チーム内で変化する可能性があります。
情報ワークスペース: 情報ワークスペースは、チームの物理的なスペースを使用して、プロジェクトの進行状況を誰でも一目で把握できる情報を表示します。 これを行う方法は、物理的なメモやグラフから、プロジェクト管理ソフトウェアのかんばんボードやダッシュボードを示すスクリーンショットまで、さまざまです。
元気な仕事：XPでは、精力的に仕事ができる範囲でしか働きません。 労働時間は、最大で週 40 時間に制限する必要があります。
Analisi- ユーザー分析と呼ばれる形式でユーザー要件を記述します。 ユーザー分析には、短い説明的な名前と、実装する必要があるものについての簡単な説明があります。
Slack : サイクルを計画するときは、必要に応じてチームが放棄できる小さなタスクを追加します。 チームの成果が多すぎる場合は、いつでもストーリーを追加できます。
サイクル (毎月および毎週): XP の開発は、週次サイクルと月次サイクルの XNUMX つの主なサイクルで行われます。
会議、サイクル、予定されたリリース: XP での開発は、週ごとのサイクルと四半期ごとのサイクルの XNUMX つの主要なサイクルで行われます。 当初、Kent Beck は XNUMX 週間のサイクルを推奨していましたが、彼の本の第 XNUMX 版でそれを変更しました。
毎週のサイクル: 毎週のサイクルは、XP プロジェクトの「パルス」です。 サイクルは、クライアントがその週に作成したいストーリーを選択する会議から始まります。 さらに、チームは先週の進捗状況を含む作業をレビューし、プロセスを改善する方法について考えます。
月周期: 毎月、チームはプロセスにおける改善の機会を反映し、特定します。 クライアントは、その月の XNUMX つまたは複数のテーマを、これらのテーマの分析とともに選択します。
エクストリームプログラミングを始めるには？
技術的なスキルと XP の習慣は習得が難しい場合があります。 一部のプラクティスは、慣れていないプログラマーにはなじみのないものに見えるかもしれません。
Ercole Palmeri
Coveware by Veeam は、サイバー恐喝インシデント対応サービスを引き続き提供します。 Coveware はフォレンジックと修復機能を提供します…
予知保全は、プラント管理に対する革新的かつ積極的なアプローチにより、石油・ガス部門に革命をもたらしています。
建物のエネルギー効率を高めるために欧州連合が制定した「グリーンハウス」法令は、立法手続きを次のように終了しました。
