agile methodology beginner s guide agile method
アジャイル手法の完全ガイド：（20以上の詳細なアジャイルスクラム手法のチュートリアル）
これは、ソフトウェア開発者とテスターが非常に有名なものを理解して作業を開始するためのガイドです。 ソフトウェア開発とテストのためのアジャイルスクラム手法 。完全なプロセスの実際の例とともに、アジャイルスクラムプロセスで使用される基本的で重要な用語を学びます。
便宜上、このシリーズのすべてのアジャイルチュートリアルをリストしました。彼らがあなたに計り知れない助けになることを願っています。
取り上げるトピック： アジャイルとは、スクラムとは、ソフトウェア開発とテストにおけるアジャイル手法、アジャイルテスト、アジャイルスクラムプロセス、スクラムチームとスクラムマスターによるスクラム手法。
学習内容：
アジャイル手法のチュートリアルリスト
チュートリアル＃1： アジャイルスクラム方法論 （このチュートリアル）
チュートリアル＃2： アジャイルマニフェスト
チュートリアル＃3： スクラムチームとその役割と責任
チュートリアル＃4： スクラムアーティファクト
チュートリアル＃5： スクラムイベント
チュートリアル＃6： スクラムでの欠陥トリアージ
チュートリアル＃7： 自給自足のスクラムチーム
チュートリアル＃8： 3つのアミーゴの原則
チュートリアル＃9： SAFe –スケーリングされたアジャイルフレームワーク
チュートリアル＃10： アジャイルスクラムクイズ
より推奨されるアジャイルスクラムチュートリアル：
チュートリアル＃11： トップアジャイル推定手法
チュートリアル＃12： アジャイルウォーターフォールハイブリッドモデル
チュートリアル＃13： かんばんvsスクラムvsアジャイル
チュートリアル＃14： JIRAアジャイルチュートリアル
チュートリアル＃15： アジャイル回顧会議
チュートリアル＃16： SCRUMにおけるビジネスアナリストの役割
チュートリアル＃17： スクラムにおけるQAの役割
ツールと面接の質問：
チュートリアル＃18： アジャイルテストツール
チュートリアル＃19： 最高のアジャイルプロジェクト管理ツール
チュートリアル＃20： アジャイル面接の上位の質問
チュートリアル＃21： トップスクラムインタビューの質問
シリーズの最初のチュートリアルであるアジャイルスクラムの紹介から始めましょう。
アジャイル開発入門
ソフトウェア開発におけるアジャイル：
アジャイルは、世界で最も広く使用され、認められているソフトウェア開発フレームワークの1つです。
ほとんどの組織は何らかの形でそれを採用していますが、採用プログラムの成熟にはまだ長い道のりがあります。この一連のチュートリアルの唯一の目的は、テクノロジーと非テクノロジーの専門家をアジャイルの世界に参加させることです。
アジャイルの使用の背後にある哲学、その利点、およびその実践方法を理解するまで、アジャイルの旅を段階的に説明します。このシリーズは、読者がアジャイルとスクラムの学習を自分の仕事に適用できるようにすることを目的としています。
この特定のチュートリアルは、なぜアジャイルが必要だったのか、そしてそれがどのように作成されたのかを説明することに専念しています。ここでの基本は、ソフトウェア開発業界におけるアジャイル採用の概念を理解してもらうことです。
アジャイルの歴史
アジャイルは、ある晴れた日に、さまざまな開発方法論のバックグラウンドを持つ17人が集まって、開発時間を短縮し、ドキュメントの負荷を軽減できるソフトウェア開発の代替ソリューションがあるかどうかをブレインストーミングするときに生まれました。
当時、ソフトウェア開発は非常に長い間行われていたため、プロジェクトを提供する準備が整うまでに、ビジネスは前進し、要件は変化していました。したがって、プロジェクトは、定義された目的を達成できたとしても、ビジネスニーズを満たすことができませんでした。
したがって、さまざまなソフトウェアエンジニアリング手法のこれらのチャンピオンが集まり、会議の最終結果は、このシリーズの次のチュートリアルで詳細に説明する「アジャイルマニフェスト」と呼ばれるものでした。
しかし、その日に生まれたアジャイルは、今日の組織で見られるものではありません。それらの専門家が同意した方法論は、「軽量」で高速であると説明されました。しかし、この会議の主な成果は、製品の迅速な提供と絶え間ないフィードバックがソフトウェア開発の成功の鍵であるという考えでした。
既存のウォーターフォール技術は煩雑であり、最終製品を納品する準備ができるまでフィードバックの準備がありませんでした。つまり、コース修正の余地はなく、製品全体の準備が整うまで、顧客は進捗状況を確認できませんでした。そして、それはこれらの専門家が避けたかったことでした。
彼らは、後の段階でのやり直しのコストを回避するために、絶え間ないフィードバックの余地があるソリューションを望んでいました。
アジャイルチャレンジ
当時の既存のウォーターフォール技術は煩雑であり、最終製品が納品されるまでフィードバックの準備がありませんでした。チームが最初に1つのステップを完全に終了し、その後になって初めて次のステップに進んだため、これは開発のウォーターフォールモデルと呼ばれていました。
つまり、コース修正の余地はなく、製品全体の準備が整うまで、顧客は進捗状況を確認できませんでした。そして、それはこれらの専門家が避けたかったことでした。彼らは、後の段階でのやり直しのコストを回避するために、絶え間ないフィードバックの余地があるソリューションを望んでいました。
そのため、アジャイルは、一定のフィードバックと配信速度だけでなく、適応性と継続的な改善にも関わっています。
アジャイルプロミスとは何ですか？
アジャイルは、ソフトウェアの開発に設定されたプラクティスを適用することだけではありません。また、チームの考え方に変化をもたらし、より優れたソフトウェアを構築し、協力して、最終的には幸せな顧客を獲得するように促します。
アジャイルの価値観と原則により、チームは焦点を移し、より優れたソフトウェアを構築するという思考プロセスを変えることができます。
アジャイルとは正確には何ですか？
アジャイルは一連のルールではありません。アジャイルは一連のガイドラインではありません。アジャイルは方法論でさえありません。むしろ、アジャイルは、計画やプロセスよりも柔軟性、適応性、コミュニケーション、および機能するソフトウェアを促進する一連の原則です。それは、いわゆるアジャイルマニフェストに非常に簡潔に捉えられています。
アジャイルソフトウェア開発により、チームは複雑なプロジェクトの開発においてより効率的かつ効果的に協力することができます。これは、簡単に採用でき、優れた結果を示す反復型および増分型の手法を実行するプラクティスで構成されています。
アジャイルを行動に移すには、さまざまなアジャイルベースの方法と方法論があります。これらの方法と方法論は、ソフトウェアの設計とアーキテクチャ、開発とテストからプロジェクト管理と配信に至るまで、ソフトウェア開発業界のすべてのニーズに応えます。
それだけでなく、アジャイルの方法と方法論は、各デリバリーの不可欠な部分としてプロセス改善の余地も開きます。
アジャイルはソフトウェア開発アプローチであり、自給自足のクロスファンクショナルチームが反復を通じて継続的な配信を行い、エンドユーザーからのフィードバックを収集することでプロセス全体を進化させます。
アジャイルを実践する方法は？
さまざまな多様な業界で実践されているさまざまなアジャイル手法があります。
ただし、それらすべての中で最も一般的な方法論は次のとおりです。
- スクラム
- Kanban
- エクストリームプログラミング
これらの方法論はすべて、リーンソフトウェア開発に焦点を当てており、より優れたソフトウェアを効果的かつ効率的に構築するのに役立ちます。
アジャイルイントロダクションは以上です。このパートは、チームがアジャイルモードと考え方で作業するために採用されるコアバリューと原則を理解するのに役立つように構成されています。
アジャイル 方法論
アジャイルモデルの概要：
oraclesqlは回答pdfで例を照会します
ご存知のとおり、アジャイルはソフトウェア開発方法論です。
また、アジャイルの創設者がアジャイルマニフェストで言及した価値観と原則についても学びました。最初の議論では、アジャイルモデルと従来のウォーターフォールモデルの違いについても説明しました。
このチュートリアルでは、アジャイル手法の長所と短所について説明します。
スクラムとは何ですか？そしてそれはアジャイルとどう違うのですか。次に、さまざまな組織で使用されているさまざまなアジャイル手法と、それらを使用してアジャイルを実装する方法を理解します。
また、これらの方法論の違いと長所/短所を理解することができます。
アジャイル手法の利点
アジャイル手法のさまざまな利点を以下に示します。
- 顧客は、各反復/スプリントの終了時にプロジェクトの進捗状況を継続的に確認できます。
- 各スプリントは、顧客が提供する完了の定義に従って、顧客の期待に応える実用的なソフトウェアを顧客に提供します。
- 開発チームは、変化する要件に非常に敏感であり、開発の高度な段階でも変化に対応できます。
- 顧客の関与を維持する双方向のコミュニケーションが常に存在するため、ビジネスと技術のすべての利害関係者は、プロジェクトの進捗状況を明確に把握できます。
- 製品の設計は効率的であり、ビジネス要件を満たしています。
アジャイル手法のデメリット
アジャイル手法にはいくつかの利点がありますが、それにはいくつかの欠点もあります。
彼らです：
＃1） 包括的なドキュメントは好ましくないため、アジャイルチームはこれをアジャイルはドキュメントを必要としないと誤って解釈する可能性があります。そのため、ドキュメントの厳密さは失われます。これは、続行するのに十分な情報であるかどうかを継続的に自問することによって回避する必要があります。
＃二） プロジェクトの開始時に、要件が明確でない場合があります。チームは先に進み、顧客のビジョンが再調整されたことに気付く可能性があります。そのような状況では、チームは多くの変更を組み込む必要があり、最終結果も測定することは困難です。
アジャイル手法の種類
世界中で実際にいくつかのアジャイル手法があります。最も人気のある4つについて詳しく学習します。
＃1）スクラム
スクラムは、最も人気のあるアジャイルフレームワークと簡単に見なすことができます。 「スクラム」という用語は、ほとんどの実務家によって「アジャイル」と同義と見なされています。しかし、それは誤解です。スクラムは、アジャイルを実装できるフレームワークの1つにすぎません。
スクラムという言葉はスポーツラグビーに由来します。プレイヤーが連動した位置で集まり、対戦相手を押します。各プレイヤーはそれぞれのポジションで定義された役割を持ち、状況の要求に応じて攻撃と防御の両方を行うことができます。
同様に、ITのスクラムは、3つの特定の明確に定義された役割を持つ権限を与えられた自己管理開発チームを信じています。これらの役割には以下が含まれます– プロダクトオーナー（PO）、スクラムマスター（SM）、およびプログラマーとテスターで構成される開発チーム 。それらは、スプリントと呼ばれる反復的なタイムボックス化された期間で連携します。
最初のステップは、POによる製品バックログの作成です。これは、スクラムチームが行うべきことのやることリストです。次に、スクラムチームは最優先のアイテムを選択し、スプリントと呼ばれるタイムボックス内でそれらを完了しようとします。
これらすべてを覚える簡単な方法は、3-3-5フレームワークを覚えることです。これは、スクラムプロジェクトには、3つの役割、3つのアーティファクト、および5つのイベントがあることを意味します。
これらは -
役割： PO、スクラムマスター、および開発チーム。
アーティファクト： 製品バックログ、スプリントバックログそして製品の増分。
イベント： スプリント、スプリント計画、デイリースクラム、スプリントレビュー、スプリント回顧展。
これらのそれぞれについては、以降のチュートリアルで詳しく説明します。
#2) Kanban
かんばんは、カードを意味する日本語の用語です。これらのカードには、ソフトウェアで実行する作業の詳細が含まれています。目的は視覚化です。すべてのチームメンバーは、これらの視覚補助を通じて行われるべき作業を認識しています。
チームはこれらのかんばんカードを使用して継続的デリバリーを行います。スクラムと同様に、かんばんもチームが効果的に機能するのを支援し、自己管理型のコラボレーションチームを促進するためのものです。
ただし、これら2つの違いもあります。たとえば、スクラムスプリント中のように、チームが作業しているアイテムは固定されており、スプリントにアイテムを追加することはできませんが、かんばんでは、空き容量がある場合はアイテムを追加できます。これは、要件が頻繁に変更される場合に特に役立ちます。
同様に、もう1つの違いは、スクラムにはPO、スクラムマスター、および開発チームの役割が定義されていますが、かんばんにはそのような事前定義された役割がないことです。
もう1つの違いは、スクラムは製品バックログの優先順位付けを示唆していますが、かんばんにはそのような要件がなく、完全にオプションであるということです。したがって、かんばんは必要な組織が少なく、付加価値のないアクティビティを回避し、変更への対応が必要なプロセスに適しています。
＃3）リーン
リーンは廃棄物の削減に焦点を当てた哲学です。 それはどのようにそれをしますか？
リーンでは、プロセスを付加価値のある活動、付加価値のない活動、および本質的な付加価値のない活動に分割します。付加価値のない活動として分類できる活動はすべて無駄であり、無駄をなくすためにプロセスでその無駄を取り除くように努める必要があります。
よりスリムなプロセスとは、チームの目標を達成するのに役立たないタスクで、より迅速な配信と無駄な労力の削減を意味します。これは、ソフトウェア開発サイクルのすべてのステップを最適化するのに役立ちます。そのため、リーン原則はリーン生産方式からソフトウェア開発に採用されました。
リーンソフトウェア開発は、以下に示す7つのリーン原則を適用することにより、あらゆるITプロジェクトで使用できます。
それらの名前が示すように、これらは非常に自明です。無駄をなくすことは最初で最も重要なリーン原則であり、その方法を見てきました。私たちは活動を付加価値と非付加価値として分類するだけです。
付加価値のないアクティビティは、コードの任意の部分である可能性があり、コードの堅牢性が低下し、関連する労力が増加し、正当なビジネス価値を付加せずに多くの時間がかかる可能性があります。また、漠然としたユーザーストーリー、不十分なテスト、または全体像に必要のない機能の追加である可能性もあります。
チームは急速に変化する環境で製品を提供するためにさまざまなスキルを必要とし、新しいテクノロジーが短期間で出現するため、学習を増幅する2番目の原則も簡単に理解できます。
変更が予想される場合など、やり直しが減り、ビジネスニーズの変化に応じてチームが作業をやり直す必要がないように、遅れて決定することは、やりがいのあることです。
ただし、チームはこれと、より高速に配信するという4番目の原則とのバランスを取る必要があるため、ここでは常にトレードオフがあります。決定の遅れは、全体的な配信に影響を与えてはならず、作業のペースを低下させてはなりません。片方の目は常に全体像を見る必要があります。
チームに権限を与えることも最近では非常に一般的であり、これはアジャイルでさえ示唆していることです。権限を与えられたチームはより責任があり、より迅速に意思決定を行うことができます。権限を与えられたチームの所有権の感覚は、より良い結果につながります。チームに権限を与えるには、チームが自分自身を編成し、自分で決定を下すことが許可されている必要があります。
したがって、リーンとアジャイルには多くの共通点があり、1つの大きな違いがあります。リーンチームは製品の改良に役立ちますが、アジャイルチームは実際に製品を構築するチームです。
＃4）エクストリームプログラミング（XP）
エクストリームプログラミングは、もう1つの最も人気のあるアジャイル手法です。 Extremeprogramming.orgによると、最初のXPプロジェクトは1996年3月6日に開始されました。また、XPは、コミュニケーション、シンプルさ、フィードバック、敬意、勇気という5つの異なる方法でソフトウェアプロジェクトの開発に影響を与えると述べています。これらはXPの値と呼ばれます。
これらのうち、それはすべてコミュニケーションから始まります。 XPチームは、ビジネスチームや他のプログラマーと定期的にコラボレーションし、最初の日からコードの作成を開始します。ここでの焦点は、他の視覚補助の助けを借りて、可能な限り対面のコミュニケーションにあります。
極端なプログラマーも簡単なコードを作成し、初日からフィードバックを受け取り始めます。焦点は、行き過ぎたり、共有されていない要件を予測したりしないことにあります。これにより、設計がシンプルに保たれ、要件を満たす最小限の製品が製造されます。
フィードバックは、チームがより良い仕事の質を向上させ、生み出すのに役立ちます。これは、お互いから学び、意見を共有する方法を学ぶときに、お互いを尊重するのに役立ちます。
これはまた、彼らがみんなの最高のアイデアを集め、他の人からのフィードバックで良い製品を生み出したことを知っているので、彼らに勇気を与えます。したがって、変更を含めたり、作業に関するフィードバックをさらに受け取ったりすることも恐れません。
これは、要件が頻繁に変更されるプロジェクトで特に役立ちます。絶え間ないフィードバックは、チームが勇気を持ってこれらの変更を含めるのに役立ちます。
したがって、スクラム、XP、かんばん、リーンなどのさまざまなアジャイル手法と、それぞれの長所と短所を見てきました。
今では、それらを簡単に区別でき、それらの間の微妙な違いも理解できます。また、これらの各方法論の基礎を学び、必要に応じてプロジェクトに適用する方法を確認しました。
次のパートでは、スクラムについてすべてを理解しましょう。
スクラム方法論
SCRUMは、反復モデルと増分モデルを組み合わせたアジャイル手法のプロセスです。
伝統的なの主要なハンディキャップの1つ ウォーターフォールモデル つまり、最初のフェーズが完了するまで、アプリケーションは他のフェーズに移動しません。また、偶然にも、サイクルの後の段階で変更があった場合、前のフェーズに戻って変更をやり直す必要があるため、それらの変更を実装することは非常に困難になります。
SCRUMの主な特徴は次のとおりです。
- 自己組織化された集中チーム。
- 巨大な要件文書はなく、非常に正確で要領を得たストーリーがあります。
- 部門の枠を超えたチームは、1つのユニットとして連携します。
- 機能を理解するために、ユーザー担当者と緊密に連絡してください。
- 最大1か月の明確なタイムラインがあります。
- 一度に「すべて」を実行する代わりに、スクラムは指定された間隔ですべてのほとんどを実行します。
- 何かをコミットする前に、リソースの機能と可用性が考慮されます。
この方法論をよく理解するには、SCRUMの主要な用語を理解することが重要です。
また読む => アジャイルスクラムプロセスを使用して、高価値のソフトウェア機能を短期間で提供する方法
重要なスクラム用語
1）スクラムチーム
スクラムチームは、7人と+または–2人のメンバーで構成されるチームです。これらのメンバーはコンピテンシーが混在しており、開発者、テスター、データベース担当者、サポート担当者などと、製品の所有者およびスクラムマスターで構成されています。
これらのメンバーはすべて、再帰的かつ明確な間隔で緊密に協力して、前述の機能を開発および実装します。スクラムチームの座席配置は、彼らの相互作用において非常に重要な役割を果たします。彼らはキュービクルやキャビンに座ることはなく、巨大なテーブルに座ります。
2）スプリント
スプリントは、事前定義された間隔または時間枠であり、作業を完了して、レビューまたは本番展開の準備を整える必要があります。このタイムボックスは通常2週間から1ヶ月の間にあります。
認証が必要なユーザー名とパスワードルーター
私たちが1か月のスプリントサイクルに従うと言う私たちの日常生活では、それは単に私たちがタスクに1か月間取り組み、その月の終わりまでにレビューの準備をすることを意味します。
3）プロダクトオーナー
製品の所有者は、開発されるアプリケーションの主要な利害関係者またはリードユーザーです。製品の所有者は、顧客側を代表する人です。彼/彼女は最終的な権限を持っており、チームが常に利用できる必要があります。
誰かが明確にする必要がある疑問があるとき、彼/彼女は到達可能でなければなりません。製品の所有者は、スプリントの途中またはスプリントがすでに開始されているときに、新しい要件を理解し、割り当てないことが重要です。
4）スクラムマスター
スクラムマスターは、スクラムチームのファシリテーターです。彼/彼女はスクラムチームが生産的で進歩的であることを確認します。障害が発生した場合は、スクラムマスターがフォローアップし、チームのために解決します。スクラムマスターは、POとチームの間の仲介者です。
彼/彼女はスプリントの進捗状況についてPOに通知し続けます。チームに障害や懸念がある場合は、POと話し合い、解決してもらいます。チームのデイリースタンドアップと同様に、POを使用したスクラムマスターのスタンドアップは毎日行われます。
おすすめの読み物 => アジャイルテストの世界で優れたチームメンター、コーチ、真のチームディフェンダーになるには？
5）ビジネスアナリスト（BA）
ビジネスアナリストは、スクラムで非常に重要な役割を果たします。この担当者は、（ユーザーストーリーの作成に基づいて）要件ドキュメントで要件を完成させてドラフトを作成する責任があります。
ユーザーストーリー/承認基準にあいまいさが存在する場合、彼/彼女は技術（SCRUM）チームからアプローチされ、POに持ち込まれるか、可能であれば自分で解決します。大規模なプロジェクトでは、複数のBAが存在する場合がありますが、小規模なプロジェクトでは、SCRUMマスターがBAとしても機能する場合があります。
プロジェクトのキックが始まるときにBAを取得することは常に良い習慣です。
6）ユーザーストーリー
ユーザーストーリーは、実装する必要のある要件または機能に他なりません。
スクラムには、これらの巨大な要件ドキュメントはありません。むしろ、要件は1つの段落で定義され、通常は次の形式になります。
として
したい
達成するために
例えば ：
管理者として、ユーザーが不正なアクセスを制限するために3回連続して間違ったパスワードを入力した場合に備えて、パスワードをロックしたいと思います。
守らなければならないユーザーストーリーのいくつかの特徴があります。ユーザーストーリーは短く、現実的で、推定可能で、完全で、交渉可能で、テスト可能でなければなりません。スプリントの途中でユーザーストーリーが変更または変更されることはありません。
POが適切な承認基準のセットを使用してユーザーストーリーを正しくドラフトしたことを確認するのは、SCRUMマスターとBA（該当する場合）の責任です。スプリントリリースに影響を与える変更が行われる場合、そのようなストーリーはスプリントから引き出されるか、利用可能な時間に従って行われます。
すべてのユーザーストーリーには、チームが明確に定義して理解する必要がある受け入れ基準があります。
受け入れ基準は、サポートドキュメントを提供するユーザーストーリーの詳細を示します。これは、ユーザーストーリーをさらに洗練するのに役立ちます。チームの誰もが受け入れ基準を書き留めることができます。テストチームは、これらの受け入れ基準に基づいてテストケース/条件を決定します。
7）叙事詩
エピックはあいまいなユーザーストーリーであるか、これらは定義されておらず、将来のスプリントのために保持されるユーザーストーリーであると言えます。
それを人生と関連付けてみてください。休暇に行くことを想像してみてください。来週行くので、ホテルの予約、観光、トラベラーズチェックなどすべてが整っています。しかし、来年の休暇の計画はどうですか？ XYZの場所に行くかもしれないという漠然とした考えしかありませんが、詳細な計画はありません。
エピックは、来年の休暇の計画と同じです。行きたいと思うかもしれませんが、現時点では、これらすべての詳細がどこで、いつ、誰と、わからないのです。
同様に、詳細が不明な将来の実装が必要な機能もあります。ほとんどの場合、機能はEpicで始まり、実装可能なストーリーに分解されます。
8）製品バックログ
製品バックログは、すべてのユーザーストーリーが保持される一種のバケットまたはソースです。これは、プロダクトオーナーによって維持されます。製品のバックログは、ビジネスニーズに応じて優先順位を付ける製品所有者のウィッシュリストとして想像できます。
計画会議（次のセクションを参照）では、製品のバックログから1つのユーザーストーリーが取得され、チームはブレーンストーミングを行い、それを理解して改良し、製品の所有者の介入を得て、どのユーザーストーリーを使用するかをまとめて決定します。
9）スプリントバックログ
優先度に基づいて、ユーザーストーリーは製品バックログから一度に1つずつ取得されます。スクラムチームはそれについてブレインストーミングを行い、実現可能性を判断し、特定のスプリントで作業するストーリーを決定します。スクラムチームが特定のスプリントで作業するすべてのユーザーストーリーの集合リストは、スプリントバックログと呼ばれます。
10）ストーリーポイント
ストーリーポイントは、ユーザーストーリーの複雑さを定量的に示します。ストーリーポイントに基づいて、ストーリーの見積もりと取り組みが決定されます。
ストーリーポイントは相対的であり、絶対的ではありません。見積もりと取り組みが正しいことを確認するには、ユーザーストーリーが大きくないことを確認することが重要です。ユーザーストーリーが正確で小さいほど、見積もりは正確になります。
すべてのユーザーストーリーは、フィボナッチ数列（1、2、3、5、8、13＆21）に基づいてストーリーポイントに割り当てられます。数字が大きいほど、複雑な話になります。
正確には
- 1/2/3ストーリーポイントを与えると、ストーリーが小さく、複雑さが少ないことを意味します。
- ポイントを5/8とすると、中程度の複雑で
- 13と21は非常に複雑です。
ここでの複雑さは、開発とテストの両方の作業で構成されます。
ストーリーポイントを決定するために、スクラムチーム内でブレーンストーミングが行われ、チームが集合的にストーリーポイントを決定します。
開発チームが特定のストーリーに3のストーリーポイントを与える場合があります。これは、3行のコード変更である可能性があるためですが、テストチームは、このコード変更がより大きなモジュールに影響を与えると感じているため、8ストーリーポイントを与えます。テストの労力は大きくなります。あなたが与えているストーリーポイントが何であれ、あなたはそれを正当化する必要があります。
したがって、この状況では、ブレーンストーミングが発生し、チームは1つのストーリーポイントに集合的に同意します。
ストーリーのポイントを決定するときは常に、以下の要素を念頭に置いてください。
- ストーリーと他のアプリケーション/モジュールとの依存関係。
- リソースのスキルセット。
- 物語の複雑さ。
- 歴史的学習。
- ユーザーストーリーの受け入れ基準。
特定のストーリーに気付いていない場合は、サイズを変更しないでください。
ストーリーが=または> 8ポイントの場合は常に、2つ以上のストーリーに分割されます。
11）チャートを焼き尽くす
バーンダウンチャートは、スクラムタスクの推定v / s実際の作業量を示すグラフです。
これは、特定のスプリントについて、コミットされたストーリーポイントの完了に向けてストーリーが進行しているかどうかを確認するために、日々のタスクを追跡する追跡メカニズムです。
例 ：これを理解するには、次の図を確認してください。
私は仮定しました：
- 2週間スプリント（10日）
- スプリントに実際に取り組んでいる2つのリソース。
'物語' ->この列には、スプリントで使用されたユーザーストーリーが表示されます。
'仕事' ->この列には、ユーザーストーリーに関連付けられているタスクのリストが表示されます。
'努力' ->この列は努力を示しています。さて、この測定値は、タスクを完了するための総努力です。特定の個人による努力を表すものではありません。
「1日目– 10日目」 ->この列には、ストーリーを完了するために残っている時間が表示されます。時間はすでに行われた時間ではなく、まだ残っている時間であることに注意してください。
「推定作業量」 ->努力の合計です。 「開始」の場合、それは単に個々のタスク全体の合計です：SUM（C5：C15）
1日で完了する必要のある作業の総数は70/10 = 7です。したがって、1日目の終わりに、作業は70 – 7 = 63に減少するはずです。同様の方法で、すべての推定作業量が0になる10日目までの日数（行16）
「実際の努力は残っている」 ->名前が示すように、物語を完成させるために実際に残された努力です。また、実際の労力が見積りよりも増減する場合もあります。
組み込み関数とExcelのグラフを使用して、このバーンダウングラフを作成できます。
チャートのバーンダウン手順は次のようになります。
- すべてのストーリーを入力します（列A5 – A15）。
- すべてのタスクを入力します（列B5 – B15）。
- 日を入力します（1日目から10日目）。
- 最初の取り組みを入力します（タスクC5〜C15を合計します）。
- 式を適用して、各日（1日目から10日目）の「推定作業量」を計算します。 D15（C16- $ C $ 16/10）に数式を入力し、すべての日にわたってドラッグします。
- 毎日、実際の取り組みを入力してください。 D17（SUM（D5：D15））に式を入力して、実際に残っている作業量を合計し、それ以外の日はドラッグします。
- それを選択し、次のようにチャートを作成します。
12）速度
スクラムチームがスプリントにアーカイブするストーリーポイントの総数は、Velocityと呼ばれます。スクラムチームは、その速度によって判断または参照されます。そうは言っても、ここでの目的は最大のストーリーポイントを達成することではなく、スクラムチームの快適さのレベルを尊重して高品質の成果物を提供することであることに留意する必要があります。
例えば ：特定のスプリントの場合：ユーザーストーリーの総数は、以下に示すようにストーリーポイントを持つ8つです。
したがって、ここでは速度はストーリーポイントの合計= 30になります
完了の定義：
すべてのストーリーが完了し、すべての開発、調査、QAタスクが「完了」とマークされ、すべてのバグが修正された場合、スプリントは完了としてマークされます。それ以外の場合は、後で実行できるバグが閉じられます（完全に関連していない、または重要性が低いなど）。が引き出されてバックログに追加され、コードレビューと単体テストが完了し、推定時間がタスクに費やされた実際の時間に達し、最も重要なことに、成功したデモがPOと利害関係者に提供されました。
SCRUM方法論で行われた活動
＃1）計画会議
計画会議はスプリントの出発点です。これは、スクラムチーム全体が集まる会議であり、SCRUMマスターは、製品のバックログから優先度に基づいてユーザーストーリーを選択し、チームがブレインストーミングを行います。
議論に基づいて、スクラムチームはストーリーの複雑さを決定し、フィボナッチ数列に従ってサイズを決定します。チームは、ユーザーストーリーの実装を完了するために実行される作業（時間単位）とともにタスクを特定します。
多くの場合、計画会議の前に「事前計画会議」があります。これは、スクラムチームが正式な計画会議に参加する前に行う宿題のようなものです。チームは、計画会議で話し合いたい依存関係やその他の要因を書き留めようとします。
＃2）スプリントタスクの実行
名前が示すように、これらは、タスクを実行し、ユーザーストーリーを「完了」状態にするためにスクラムチームによって行われる実際の作業です。
＃3）毎日のスタンドアップ
スプリントサイクル中、スクラムチームは毎日15分以内にミーティングを行い（スタンドアップコールの場合があり、1日の始めに行うことをお勧めします）、次の3つのポイントを述べます。
- チームメンバーは昨日何をしましたか？
- チームメンバーは今日何をする予定でしたか？
- 障害（障害）はありますか？
この会議を促進するのはスクラムマスターです。チームメンバーが何らかの問題に直面している場合は、スクラムマスターがフォローアップして問題を解決します。スタンドアップでは、ボードもレビューされ、それ自体がチームの進捗状況を示します。
＃4）レビューミーティング
すべてのスプリントサイクルの終わりに、SCRUMチームは再び会合し、実装されたユーザーストーリーを製品所有者に示します。製品の所有者は、受け入れ基準に従ってストーリーを相互検証できます。この会議を主宰するのは、スクラムマスターの責任です。
また、SCRUMツールでは、スプリントが閉じられ、タスクに完了のマークが付けられます。
＃5）回顧会議
ふりかえり会議は、レビュー会議の後に行われます。
SCRUMチームは、次の点について話し合い、文書化します。
- スプリント（ベストプラクティス）中に何がうまくいったのですか？
- スプリントでうまくいかなかったものは何ですか？
- 学んだ教訓
- アクションアイテム。
スクラムチームは引き続きベストプラクティスに従い、「ベストプラクティスではない」を無視し、結果として生じるスプリントで学んだ教訓を実装する必要があります。ふりかえり会議は、スクラムプロセスの継続的な改善を実施するのに役立ちます。
プロセスはどのように行われますか？例！
SCRUMの専門用語について読んだこと。例を挙げてプロセス全体を説明してみましょう。
例：
ステップ1 ：1人の製品所有者、1人のスクラムマスター、2人のテスター、4人の開発者、1人のDBAで構成される9人のSCRUMチームを作りましょう。
ステップ2 ：スプリントは4週間のサイクルに従うことになっています。つまり、6月5日から4日までの1か月のスプリントがあります。th7月の。
ステップ3 ：プロダクトオーナーは、プロダクトバックログにユーザーストーリーの優先リストを持っています。
ステップ4： チームは4日に会うことにしましたth「事前計画」会議の6月。
- 製品の所有者は、製品のバックログから1つのストーリーを取り出し、それを説明し、チームに任せてブレインストーミングを行います。
- チーム全体が、ユーザーストーリーを明確に理解するために、製品の所有者と直接話し合い、コミュニケーションを取ります。
- 同様の方法で、他のさまざまなユーザーストーリーが取り上げられます。可能であれば、チームは先に進んでストーリーのサイズを決めることもできます。
すべての議論の後、個々のチームメンバーはワークステーションに戻り、
- 各ストーリーの個々のタスクを特定します。
- 彼らが働く正確な時間数を計算します。メンバーがこれらの時間をどのように締めくくるかを確認しましょう。
総労働時間= 9
休憩の場合はマイナス1時間、会議の場合はマイナス1時間、メール、ディスカッション、トラブルシューティングなどの場合はマイナス1時間。
したがって、実際の労働時間は6時間です。
スプリント中の総稼働日数= 21日。
利用可能な合計時間数= 21 * 6 = 126。
メンバーは2日間= 12時間休暇を取っています（これはメンバーごとに異なり、休暇を取る人もいれば、そうでない人もいます）。
実際の時間数= 126 – 12 = 114時間。
これは、メンバーが実際にこのスプリントで114時間利用できることを意味します。そのため、彼は合計114時間に達するように、個々のスプリントタスクを分解します。
ステップ5 ：5日th6月には、スクラムチーム全体が「計画会議」のために集まります。
- 製品バックログからのユーザーストーリーの最終判定が行われ、ストーリーはスプリントバックログに移動されます。
- ストーリーごとに、各チームメンバーは、特定されたタスクを宣言します。必要に応じて、それらのタスクについて話し合い、サイズやサイズを変更できます（フィボナッチ数列を思い出してください!!）。
- スクラムマスターまたはチームは、ツールに各ストーリーの時間とともに個々のタスクを入力します。
- すべてのストーリーが完了すると、スクラムマスターは最初の速度を記録し、正式にスプリントを開始します。
ステップ6 ：割り当てられたタスクに基づいてスプリントが開始されると、各チームメンバーはそれらのタスクの作業を開始します。
ステップ7 ：チームは毎日15分間ミーティングを行い、次の3つのことについて話し合います。
- 彼らは昨日何をしましたか？
- 彼らは今日何をするつもりですか？
- 障害（障害）はありますか？
ステップ8 ：スクラムマスターは、「バーンダウンチャート」を使用して、進捗状況を毎日追跡します。
ステップ9 ：障害が発生した場合、スクラムマスターがフォローアップしてそれらを解決します。
ステップ＃10 ：4日th7月、チームはレビュー会議のために再び会合します。メンバーは、実装されたユーザーストーリーを製品所有者に示します。
ステップ＃11 ：5日th7月、チームは回顧展のために再び会合し、そこで話し合います
- 何がうまくいったのですか？
- 何がうまくいかなかったのですか？
- アクションアイテム。
ステップ＃12 ：6日th7月、チームは次のスプリントの事前計画会議のために再び会合し、サイクルが続きます。
スクラムアクティビティツール
スクラムアクティビティを追跡するために広く使用できるツールがいくつかあります。
それらのいくつかが含まれます：
次のチュートリアルでは、効果的なアジャイルチームを推進する概念であるアジャイルマニフェストに光を当てます。
著者について： このシリーズは、次のSTHチームメンバーによって作成されています。ShrutiShrivastava– BFSI、EコマースおよびB2Bドメインで9年の経験を持つプロのスクラムマスター。 Shrutiは、自動化テストと主要なスクラムチームのエキスパートです。Anshul Kumar Srivastava – BFSIおよびテレコムセクターで7年の経験を持つ、結果志向の製品管理の専門家およびアジャイルプラクティショナー。