ビヘイビア駆動開発はあなたのプロジェクトに適していますか?ICHI.PROビヘイビア駆動開発はあなたのプロジェクトに適していますか?チーム全体が関与し、ユーザーの行動に焦点を当てた製品/ソフトウェア開発のアプローチUnsplashのMarvinMeyerによる写真ビヘイビア駆動開発(BDD)について聞いたことがない場合は、実際にはかなり最近のものと見なされており、10年余り存在しています。大小の開発チームがこのアジャイル手法を信頼しており、他のよく知られた確立された開発戦略に取って代わっています。他のソフトウェア開発手法は製品に注意を向ける傾向がありますが、BDDはユーザーを回して、1行のコードが記述される前に、このユーザーがプロセスにどのように動作するかを示します。ソフトウェア開発方法論の簡単な歴史プロジェクトのライフサイクルを5つの主要な段階に含める、ウォーターフォール開発などの別の一般的な開発方法論を検討してください。検証、およびメンテナンス滝の流れ通常、ウォーターフォールでは、前のステップを完了したときにのみ各フェーズを開始します。そのため、理想的には、プロジェクトの見積もりの少なくとも30%〜40%を最初の2つの段階(要件と設計)に投資します。これは、この段階で機能していないものを修正する方が、よりもコストがかからないためです。後で実装または検証中に。少なくとも「純粋な滝」に対するモデルへの批判は、要件と設計がどのように計画され、堅牢であっても、各作業ユニットが独立して動作し、最後に「ジョブの完了」ボタンを押すことを前提としています。彼らの段階は、予測不可能性、ビジネス目標の変更、無視された仮定が説明されていないことを意味し、あなたが推測したように...それはプロジェクト全体を台無しにするでしょう。Application(またはSoftware)Developmentなど、他のアジャイル手法がこのモデルから進化しました。RADは開発と提供に重点を置いており、エンジニアの努力を推進するためにプロトタイプに大きく依存することがよくあります。公平を期すために、RADは速度に重点を置いているため、最も一般的にはプロジェクトのメンテナンス段階に関連付けられており、RADの修正バージョンは、製品設計のアクセントの欠如を修正しようとしています。迅速なアプリケーション開発スプリントベースの開発(別名スクラム)は、配信と速度に重点を置いた開発間のギャップを埋めると同時に、チームのすべてのメンバーの関与を活用しようとします。スプリントモデルアイデアは、チームを10人以下の小さく保ち、連続した進歩的な目標(またはスプリント)で前進することです。現在、このアプローチには、チームにその場で正しいコースへの道を与えるという利点があります。ビジネスが別の方向に進むことを決定した場合、あるスプリントから次のスプリントに目標を調整するのはかなり簡単です。残念ながら、スクラムからのペースの強さは、チームのバーンアウトに影響を与える可能性があります。私はスクラムシステムの下で働いている多くの開発者に会いました。彼らは数回のスプリントの後でのみブロックされて疲れ果てたと感じてしまいます。同様に、モデルの前提は「問題」を事前に理解できないことであるため、チームがモデルに取り組んでいるときに認識し、製品や新機能をエコシステム全体に統合することをあまり考慮しないでください。リリースされる予定です。最後に、スクラムマスターの主要人物を検討することが重要です。この人物の位置は、各反復の進行に大きな役割を果たし、製品と各チームメンバーのスキルを十分に把握する必要があります。悪いスクラムマスターは、ペースの速い多層プロジェクトにとって大きな責任となる可能性があります。ビヘイビア駆動開発についてはどうでしょうか?BDDは、ユーザーの重要性と、このユーザーと製品間の相互作用を確認します。これらの相乗効果は通常、単体テスト、エンドツーエンドテスト、ユーザビリティテストなどの開発期間中にマッピングされます。BDDの主な支持者と見なされているダンノースは、次のようにコメントしています。https://dannorth.net/introducing-bdd/、開発者がこれらのテストを作成する方法に出くわしたとき:それから、「すべき」という言葉でテストメソッド名を始めるという慣習に出くわしました。-クラスがなければならない何かを-手段は、あなただけの現在のクラスのためのテストを定義することができます。これにより、集中力を維持できます。名前がこのテンプレートに適合しないテストを作成していることに気付いた場合は、その動作が他の場所に属している可能性があることを示しています。価格計算機のように、車の価格を表示することを目的としたコンポーネントがある場合、テストは次のように開始されます。priceTDDとのやり取りで、「テスト」の代わりに「行動」という言葉を使い始めたところ、それが適切であるように見えただけでなく、コーチングの質問のカテゴリ全体が魔法のように解消されたことがわかりました。私は今、それらのTDDの質問のいくつかに対する答えを持っています。ここでのTDDは、テスト駆動開発を意味します。したがって、以前の価格計算機のテストと同様に、テストは次のようになり始めました。Evansの著書「Domain-DrivenDesign」がベストセラーになり、Northは、DDDの概念の多くをコアで活用できることに気づきました。...ビジネスドメインに基づいたユビキタス言語を使用してシステムをモデル化することで、ビジネスの語彙がコードベースに直接浸透します。「ドメイン」は、プロセスに関与するすべての人が同じ言語を共有するのに役立ちますユーザーストーリーを説明する従来の方法は、次のテンプレートに従います。共通ドメイン(言語)を使用することで、技術者以外のチームメンバーが開発フェーズに近づくことができるという利点がすでにあります。成果物自体について話すと、前述のアジャイル手法の多くでは、製品に重点が置かれています。最終製品に焦点を当てることは一般的に良いことです。ユーザーと製品の相互作用は、要件の初期段階で行われた多くの仮定を非常にうまく分解する可能性があります。ユーザーから始まるBDDモデル製品開発の20%になる可能性が非常に高い機能がある場合は、ユーザーが少なくとも20%の時間使用して利用する機能である方がよいでしょう。ユーザーがその機能を使用していない場合はどうなりますか?基本的に、実際のユーザー要件に対して精査されたことのないニーズに向けて数千ドルを推進しています。ユーザーに基づいてユーザーストーリーを設計するときは、ユーザーに適切にディスカッションを主導させ、その(実際の)ニーズを開発するためのロードマップを提供します。ビヘイビア駆動開発の例ダンノースはクレジットカードの例を提案します。従来の仕様書は次のように書くことができます。bank.考え方をシナリオに移すと、これらの仕様を改造して次のように追加できます。returned3つのアミーゴビヘイビア駆動開発を支持する主なポイントの1つは、これらのシナリオを作成するときにすべてのチームメンバーが関与することです。QA、開発、プロダクトオーナーなどの利害関係者は、開発作業を推進するマップとなるこれらのシナリオを生成するためのディスカッションに参加します。この「発見会議」、または会議は、プロダクトオーナーによって拡張されるストーリーのロードマップを提供します。プロジェクトの範囲を予算とスケジュールの範囲内で組み立てる必要があるため、この段階では優先順位付けと検証が大きな役割を果たします。https://en.wikipedia.org/wiki/Specification_by_example、これは、信頼できる唯一の情報源を維持するための共同作業です。これらの例はテストに置き換わるものではありませんが、拡張される受け入れ基準のマッピングを提供します。BDDの状態Jira、Asana、そして特にCucumberにはすべて、BDDをシステムに適応させる方法に関する少なくとも一種のプラグインまたはドキュメントがあります。お気に入りのアジャイルソフトウェアを使用したビヘイビア駆動開発を使用してプロジェクトを追跡できます。現実には、BDDモデルの下で作業するためのチームの立ち上げは、大規模でも費用もかかりません。少なくともいくつかの要素が必要になります。ドメインエキスパート(別名、対象分野のエキスパート):開発プロセスの各柱には、チーム全体で使用される言語をフラット化するのに役立つ目に見えるリードが必要です。ユーザーとユーザーのニーズを明確に理解する:基本的な牽引力の源泉は、ユーザーの行動に関する完全な知識です。これは、プロダクトオーナーだけでなく、理想的にはチームのすべてのメンバーを意味します。ユーザーストーリーとは何かを正しく認識する。ダンノースはでユーザーストーリーを定義しますhttps://dannorth.net/whats-in-a-story/。ストーリーがうまく書かれていない場合、それはプロセス全体を上向きに捨ててしまいます。いくつかの重要なルールに言及するだけです。タイトルにはアクションを説明する必要があり、ナラティブには役割を含める必要があり、イベントには機能を説明する必要があります。主張のテストがようである重要として開発。自動化を最大化します。テストの重要性を考慮すると、ほとんどのユースケースをカバーし、誤動作を早期に検出するために、テストを再構築する必要がある場合があります。コードテストで知識を拡張および活用するためのさまざまな方法を学びます。https://www.linkedin.com/in/pablo-del-valle、中、https://github.com/delvalle。リソース今週、毎日のメールリストのメンバーからメールを受け取りました。素晴らしい質問です!私のワークフローと使用している主なリソースについての洞察を共有したいと思います。年の標準を設定します。すべての開発者はターミナルを使用します。関連記事dockerでkubectlを使用したポータブルKubernetes管理Kubernetesが主流になりつつあると言うのは控えめな表現です。実際、それは最新の分散システムの設計と運用方法に影響を与えています。エントリーレベルのソフトウェアエンジニアとして学んだ5つのことそれはコーディングと技術的なスキルだけではありません。3年前、私は最初に、物事がどのように見えるかについてのたくさんの仮定と期待を持って企業の世界に足を踏み入れました。自分がどれほど間違っていることが証明されようとしているのか、私はほとんど知りませんでした。APIサーバーへの認証済みリクエストをインターセプトし、オブジェクトデータがetcdデータストアに永続化される前にそれらを処理することでゲートキーパーとして機能するプラグインです。アドミッションコントローラは、リクエストオブジェクトを変更/変更する(アドミッションコントローラを変更する)か、リクエストを許可/禁止する(アドミッションコントローラを検証する)ことができ、場合によっては両方を実行できます。DevOpsエンジニアの告白:スプリントスプリントと一般的なルーキーのミスを改善して回避する方法スプリントの日のストーリー私たちは過去2週間の成果(またはその欠如)を振り返ります。ズームにジャンプして考えを共有し、反映するまでに約20分かかります。