一度納品すると、最終的なやり直しのリスクが大きくなる

需要は頻繁に変化せず、納期も固定されません。

顧客の変化に適応し、一度だけ納品

市場を獲得するには迅速にオンライン化しますが、多くのやり直しが必要になる場合があります

別名適応型ライフサイクル

インクリメンタリティとイテレーションの利点を組み合わせる

顧客の変化する環境に適応し、小さな反復で顧客のフィードバックを収集できる

小規模な反復を開始できる

変化に素早く適応し、迅速に市場投入します

変化を受け入れる

改善し続ける

ユーザーとして、その時・場所で、何をしたいのか、何の目的・商品価値があるのか​​？

それで、どうすればいいですか/どのように操作すればよいですか

結局どうやって確認するのか

作業を開始する前に、プロジェクト全体のすべてのストーリーを作成する必要はなく、最初のリリース計画のメイン コンテンツだけを作成する必要があります。

To Do リストは常に変更および改善されており、いつでも更新、追加、削除、修正、優先順位の変更などを行うことができます。

巨大なユーザー ストーリー (エピック ストーリーとも呼ばれる) は、バックログの最後に書き込まれます。

完了したユーザー ストーリーの定義: 0/1 合法、完了または未完了

要件をどこから始めればよいかわからない場合は、インパクト マップをバックログへの効果的な入力として使用できます。

内容: 現在の製品要件リストを整理し、優先順位付けや適度な粒度のストーリー カードへの分割などを行います。

グルーミング ミーティングの時間: 2 週間のスプリントで 1 時間のタイムボックス ディスカッション

グルーミング会議とスプリント計画会議の関係: スプリント計画会議は、プロダクト バックログのグルーミング会議が完了したときにのみ開始できます。

ストーリー ポイントの推定値は、チームによって推定された複数の推定値です。

チームベロシティ: チームが単位時間当たりに完了する作業量

スプリントごとに完了した平均ストーリー ポイント

ストーリー ポイントは、ユーザー ストーリーの期間ではなく、ユーザー ストーリーのサイズと複雑さを測定する方法です。

従来のプロジェクト計画は時間、日、週単位で測定されます

現実: 不正確な見積もりや過剰な約束を避けるために、見積もりツールは最終的に期限を提示します。

見積もりの​​精度を心配する必要はありません。早く仕事に取り掛かりましょう

チームは見積もりと約束を混同しない

ポーカーの見積もり

Tシャツ見積もり

アフィニティサイズの推定

母：やらなきゃいけない

S: やるべきだ

C: できるかもしれない

女性：それはしません

基本的なニーズ: 必須 (優先開発)

パフォーマンスのニーズ: 多ければ多いほど良い (可能な限り多くのことを達成する)

快楽ニーズ：高い満足度

それぞれ 100 ポイントに分割され、これらのポイントを使用して最も必要なニーズに投票できます。

お客様の判断に基づき、製品価値を最大化する見積りを行います

ユーザーストーリーをアクティビティに分割し続ける

チームメンバーが活動の分担を決める

前回のスタンドアップの後、私は何をしましたか?

このスタンドアップミーティングの後は何をすればよいでしょうか?

仕事でどのような障害、リスク、問題に遭遇しましたか?

Srcumタスクボード

バーンダウンチャート

点火チャート

リスクバーンダウンチャート

カンバン

カンバンボードとタスクボード

チームはスプリント中に完成した機能をデモンストレーションします

チームメンバー全員が参加する必要があります

誰でも参加できるように招待できます

PO はストーリーを承認または拒否する責任があります

一般的なガイドラインは、少なくとも 2 週間に 1 回、チームの成果物を発表することです。ほとんどのチームにとって、この頻度は、チーム メンバーが間違った方向に進まないようにフィードバックを得るのに十分な頻度です。

このスプリントで何がうまくいきましたか?

このスプリントでさらに改善できることは何でしょうか?

次のスプリントではどの領域を改善できるでしょうか?

定性的 (人々の感情) および定量的 (指標) データを見つける

このデータを使用して根本原因を見つけます

対策の立案と実行計画の策定

ミーティングの目的: これは責任ではありません。レビューはチームが継続的に改善できるようにするためのものです。

焦点: チームは優先順位を一緒に話し合い、最も必要な部分に重点的に取り組みます (いくつかの改善点に焦点を当てるだけで十分です)

会議の結論は閉ループで追跡する必要があります。結論は製品バックログに入れ、各改善の測定結果を決定し、各改善が成功したかどうかを検証できます。

作業を全体に頻繁に統合する

エンドツーエンドの情報には、システムレベルのテスト、つまりシステム全体のテストが使用されます。

構成要素の単体テストを使用する: ソフトウェア内のテスト可能な最小単位を検査して検証します。

システム統合テスト: 単体テストに基づいて、すべてのモジュールが設計要件に従ってサブシステムまたはシステムに組み立てられます。

スモーク テスト: ソフトウェア開発プロセス中のソフトウェア バージョン パッケージの迅速な基本機能テストおよび検証戦略

回帰テスト: 古いコードを変更した後、再テストして、変更によって新たなエラーが発生したり、他のコードでエラーが生成されたりしていないことを確認します。

自動テスト: ソフトウェアテストの自動化

チームは作業成果物の受け入れ基準について一緒に話し合います

チームは標準要件を満たす自動テストを作成します

TDD: 関数コードを開発する前に、最初に単体テスト ケース コードを作成します。テスト コードによって、どの製品コードを作成するかが決まります。

BDD: 自然言語または自然に似た言語を使用して、ユーザー ストーリーまたはユーザー ユース ケースを作成することにより、機能ユーザーの観点からテスト ケースを説明および作成します。

システム、テクノロジー、アプリケーション分野における未知の状況を検出

学習に役立ち、チームがいくつかの重要な技術的または機能的要素を学ぶ必要がある場合に使用されます。

技術的負債は、チームが短期的なプロジェクトの利益のために故意に技術的意思決定を誤ることによって引き起こされます。

解決策はリファクタリングとアジャイル モデリングです

2 人のプログラマーがコンピューター上で協力し、1 人がコードを入力し、もう 1 人が入力したコードの各行をレビューします。コードを入力する人はドライバーと呼ばれ、コードをレビューする人はオブザーバー (またはナビゲーター) と呼ばれます。 2 人のプログラマーは役割を交代することがよくあります

すべてのチームメンバーにはコードを変更する権限があり、チーム全体の所有権と説明責任があります。

プロジェクトのサイズとプロジェクトの重要性の 2 つの側面に基づいて、さまざまなアジャイル手法のオプションが提供されます。例: C6、D6

機能リストを確立し、機能に基づいてスケールと設計を行う

最初からコスト、品質、イベントを設定し、正式な範囲の優先順位付けを活用してこれらの制約を満たす

アーキテクチャを核にデータベース設計を中心に、ユーザーとのコミュニケーションを重視

1 つの大規模なスクラム チームではなく、2 つ以上のスクラム チームで使用される手法。チームには 3 ～ 9 人のメンバーが含まれ、作業を調整します。

ポートフォリオ、プロジェクト、チームレベルでの実践、役割、活動の詳細に焦点を当てます。顧客に継続的な価値の流れを提供することに重点を置いてビジネスを組織することに重点を置く

20、100、さらには数千人で構成され、全員が特定の共有製品で協力するアジャイル チームに適用できるマルチチーム スクラム フレームワーク

個々の製品開発レイヤーではなく、より全体的な組織を通じてスクラム方法論を適用するように設計されたフレームワーク

複数のアジャイルのベストプラクティスを包括的なモデルに統合したプロセス意思決定フレームワーク

変化に影響を与える要因

アジャイルな組織文化を作る方法

アジャイルPMO

サプライヤー

迅速かつ確実な配送

すでにアジャイルな特性を備えたチーム

地理上の位置

機能構造

プロジェクト成果物の成功規模

プロジェクトの人員配置

購買を重視する組織

変化への対応力の特徴: 経営者の意欲、従業員の意識、人材の能力など。

変化に残された障害の特徴

積極的かつ明確な経営サポート

変更管理の経験を活用して推進する

プロジェクトごとにアジャイル実践を推進

段階的な導入

アジャイルの技術と実践を実証し、指導する

プロジェクトの価値提供を実現する

革新的なアイデアや視点を考え、実践することで、顧客が価値を迅速かつ効率的に実現できるよう支援します。

さまざまなプロジェクトサポートのニーズに対応するために、プロジェクト管理自体を超えた知識に精通する