Minimum Viable Solution #Agile #Product Management 期待する成果を達成できる最小のリリース単位 MVPがProductという語で新規プロダクトを想起させるのに対し、Solutionに置き換えることで既存プロダクトへのリリースにも適用できるよう概念を広げている

#Agile

#Agile

#Agile #Product Management プロダクトバックログ上で生まれるアイテム、要件、テストなどをまとめるハブになる

#Agile #Product Management システムの端から端まで（end-to-end）を貫く、ごく小さな実装。最終的なアーキテクチャである必要はないが、主要なコンポーネントを結合して実際に動作するものを最初に作り、そこに肉付けして少しずつ成長させる。Alistair Cockburnが提唱した。

#Agile スクラムの成果物として、動作するプロダクトのこと

Inspection #Agile スクラムを支える経験主義の柱の一つ。最新のスクラムガイドより抜粋 スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱⼼に検査されなければならない。これは、潜在的に望ましくない変化や問題を検知するためである。スクラムでは、検査を⽀援するために、5 つのイベントでリズムを提供している。検査によって適応が可能になる。適応のない検査は意味がないとされる。スクラムのイベントは、変化を引き起こすように設計されている。

#Agile スクラムの中で動くプロダクトを成果物とせず、プロダクトバックログアイテムの実現可能性を調査、検証するような取り組み https://agiledictionary.com/209/spike/

Transparency #Agile スクラムを支える経験主義の柱の一つ。最新のスクラムガイドより抜粋 創発的なプロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒える必要がある。スクラムにおける重要な意思決定は、3つの正式な作成物を認知する状態に基づいている。透明性の低い作成物は、価値を低下させ、リスクを⾼める意思決定につながる可能性がある。透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。

Adaptation #Agile スクラムを支える経験主義の柱の一つ。最新のスクラムガイドより抜粋 プロセスのいずれかの側⾯が許容範囲を逸脱していたり、成果となるプロダクトが受け⼊れられなかったりしたときは、適⽤しているプロセスや製造している構成要素を調整する必要がある。それ以上の逸脱を最⼩限に抑えるため、できるだけ早く調整しなければならない。関係者に権限が与えられていないときや、⾃⼰管理されていないときは、適応が難しくなる。スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。

#Agile #Product Management #Team Organization 10個のアジェンダをチームおよび関係者で答えていくワーク われわれはなぜここにいるのか エレベータピッチ パッケージデザイン やらないことリスト ご近所さんを探せ 技術的な解決策 夜も眠れない問題 期間を見極める トレードオフスライダー 何がどれだけ必要か 日本語のテンプレートは以下にある https://github.com/agile-samurai-ja/support

#Agile #Product Management ユーザーが目的を達成するために行う、ひとつひとつの行動。

#Agile #Product Management ユーザーストーリーマッピングの最上部に配置されるユーザーの主要なアクティビティの流れ アクティビティを時系列で左から右に並べ、プロダクト全体のユーザージャーニーを表現する 各アクティビティの下にユーザータスクをぶら下げ、さらにその下にストーリーを配置する

#Agile #Product Management ストーリーマップを左から右に読んだときに、ユーザーの行動が一連の物語として自然につながるような並びの流れ。

#Agile #Product Management 複数のユーザータスクをまとめた、ユーザーの大きな目的を表す行動のまとまり。

#Agile 仕掛り作業の件数を制限し、同時に複数の仕事に着手しないという考え

Minimum Viable Product experiment #Agile #Product Management Jeff Pattonが、エリック・リースのMVPを「実験」として捉え直して呼んだ語。何かを学ぶために作れる最小のもので、ターゲット顧客にとって本当にViableなものは何かを理解するための実験を指す。

#Agile #Product Management 作業バッチサイズを最小化させるための観点の頭文字を略称にしたもの Independent Negotiable Valuable Estimable Small Testable

#Agile Kent BeckがXPで提唱した、ソフトウェアの要求を会話のきっかけとして扱う単位。カードに短く書くのは約束ごとを思い出すための覚書であり、詳細は会話で埋めることを前提とする。

Authors 市谷 聡啓 #Agile #Product Management ユーザーストーリー INVEST ユーザーストーリーマッピング

Minimum Viable Product #Agile #Product Management 望まれる成果（アウトカム）を実現できる、最小のプロダクトのリリース。「最小」とは機能数の少なさではなく、仮説を証明・反証するための最小単位を指す。

#Agile Agile Covnersation では人間中心主義での2つの価値観を原則としている。 自己開示: プロセスを隠さず失敗を認める 他者理解: 相手に関心を持ち立場を理解しようとする 組織が高パフォーマンスを発揮するためにはどのような対話をするべきか、5つの対話ステップが紹介されている。 信頼を築く対話 不安を乗り越える対話 WHYを作り上げる対話 コミットメントを行う対話 説明責任を果たす対話 重要なのはこれらは段階的に踏んでいくステップでありそれぞれ独立していないこと。第1ステップの「信頼を築く対話」はその後のステップの基礎となる。 アジャイルソフトウェア開発宣言 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

#Agile #Product Management #Documentation Jeff Pattonが考案したユーザーストーリーを洗い出すためのプラクティス。フラットなバックログの代わりに、ストーリーを地図（マップ）の形に並べてプロダクト全体を俯瞰する。 最終的なマップは、上位からアクティビティ、ユーザータスク、ストーリーの階層で構成される。 作成はこの完成形を上からなぞるのではなく、具体から始める。まずユーザータスクを書き出し、ナラティブフローに沿って並べて網羅したうえで、それらを集約してアクティビティを抽出する。 https://jpattonassociates.com/story-mapping/ https://jpattonassociates.com/the-new-backlog/

#Agile #Product Management 市谷 聡啓によるインセプションデッキを活用して組織を芯からアジャイルにするスライド https://www.docswell.com/s/papanda/ZYR1L5-shin-agile-deck

#Agile アジャイルチームにおけるSwarmingについて述べた記事 https://www.infoq.com/jp/news/2013/03/swarming-agile-teams-deliver/

#Agile 吉羽 龍太郎によるスプリントレビューの進め方の解説 Blog ブログ

#Agile スクラムの開発者が毎日行うイベント。最新のスクラムガイドより抜粋 デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。デイリースクラムは、スクラムチームの開発者のための 15 分のイベントである。複雑さを低減するために、スプリント期間中は毎⽇、同じ時間・場所で開催する。プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。 全員で以下のフォーマットを共有する 昨日やったこと 今日やること 障害となっているもの

#Agile #Team Organization クロスファンクショナルチームの考えをベースとするエクストリームプログラミングのプラクティスで、エクストリームプログラミングで紹介される

#Agile

#Agile

#Agile #Team Organization 石垣 雅人による発表。Swarming自体の説明とリモートワーク下での暗黙知の共有について 自己組織化

Behavior-Driven Development #Testing #Agile #Product Management Dan NorthがTDDのビジネス要件との乖離の課題を解消するために名付けた考え、2006年にIntroducing BDDによって紹介された その後のコミュニティの成熟でGherkin記法の実践だけではなく、どのようにビジネスチームと一緒に製品を作り上げていくのか、に焦点が当たっている 主に以下の3つのプラクティスを行う 発見 定式化 自動化 https://cucumber.io/docs/bdd/

#Agile Ron Jeffriesが示した、ストーリーを構成する3つの要素。カード（Card）に書き、会話（Conversation）で詳細を詰め、確認（Confirmation）で完了条件を定める。カードは要求仕様書ではなく、会話を思い出すための覚書であることを示す。 https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/

#Agile 吉羽 龍太郎によるスクラムのスプリントプランニングの Deep Dive スライド スプリントプランニング スプリントゴール リファインメント ベロシティ SMART スプリントバックログ

#Agile WIP制限（Work in Process limits）。DevOps capabilitiesの1つで、Fast Flowに分類される https://dora.dev/capabilities/work-in-process-limits/

#Agile #Product Management 実際に作って試した結果から得られる、実証された学び。想定や意見ではなく、ユーザーの反応など観測された事実にもとづいて仮説の正否を判断する。 「構築・計測・学習」のサイクルを回して得られる。 構築（Build） 計測（Measure） 学習（Learn）

#Agile #Team Organization 重要な領域または主要な活動に焦点を置いてチームのエネルギーを集中させる。バックログに課題を積むのは最後の手段である。 障害にチームメンバー複数人で集中して対処するイメージを日々のスプリントにも適用していく。

#Agile 吉羽 龍太郎による、スクラム開発で行う技術的スパイクについての解説 https://www.ryuzee.com/contents/blog/7121 ブログ

#Agile 主にスクラムにおいて扱われる、タイムボックス化されたある期間のこと 1~2週間が多く、長くても1ヶ月にするにする

#Agile #Product Management 市谷 聡啓による仮説検証型アジャイル開発の資料 https://drr.red/

#Agile #Product Management Alistair Cockburnが提唱した、ゴール（目的）の大きさをレベル（高さ）で捉える考え方。高いレベルほど要約的で大きな目的を、低いレベルほど具体的な手順を表す。

#Agile アジャイルソフトウェア開発宣言に続く原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 アジャイル宣言の背後にある原則

#Agile #Testing DevOps

#Agile スクラムのフレームワークを定義しているドキュメント、2020年版が最新 Jeff Sutherland, Ken Schwaber によって作成された Scrum Guide Scrum Guide(ja)

#Agile #Team Organization #Continuous Integration #Continuous Delivery Swarmingをコンセプトに掲げたアジャイルチームのベストプラクティスについての、XP祭り2024での自身の発表 関連Scrapは以下 自己組織化 ストラングラーフィグアプリケーション トランクベース モノリスからマイクロサービスへ 関数型ドメインモデリング

かんばんとスクラム 両者のよさを最大限ひきだす #Agile カンバンとスクラムそれぞれのよさを最大限引き出す方法を解説したミニブック https://www.infoq.com/jp/minibooks/kanban-scrum-minibook/

#Agile #Product Management #Documentation プロダクトバックログアイテムが完成したと判断できる条件

#Agile スプリントの成果物が「完成している」と認識するためにチームで定める条件

#Agile Agile Manifest（ja） プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

#Agile トヨタが源流となるリーン生産方式をソフトウェア開発に適用している リーンソフトウェア開発には7つの原則がある ムダをなくす 品質を作り込む 知識を作り出す 決定を遅らせる 早く提供する 人を尊重する 全体を最適化する

#Agile スクラムのスプリントの起点となるイベント。最新のスクラムガイドより抜粋 スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計画を⽴てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチームは、アドバイスをもらうためにチーム以外の⼈をスプリントプランニングに招待してもよい。

#Agile スクラムのスプリント末に行うイベント。最新のスクラムガイドより抜粋 スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合う。 検査、適応を行うためのイベント

#Agile #Product Management 市谷 聡啓によるアジャイル開発はWhyから始まるというスライド Docswell ゴールデンサークル ユーザーストーリー

#Agile #Product Management プロダクトに必要とされるもののリスト、優先度順に並べる

#Agile 吉羽 龍太郎によるスプリントレビューの Deep Dive スライド ステークホルダー

#Agile アジャイルチームにおけるSwarmingについて述べたブログ Blog

#Agile #Product Management ストーリーを、誰のためのものかというユーザー視点を強調して捉えたもの。 Whoとして、Whatをしたい。なぜならWhyだからだ のように Who What Why を含む形で書かれる、ユーザーにとっての価値を説明する文 INVESTであるストーリーが良いとされる