Agile
-
スクラムにおける技術的スパイクの進め方#吉羽龍太郎 #Agile スクラム開発で行う技術的スパイクについて Blog
-
ユーザーストーリー#Agile Whoとして、Whatをしたい。なぜならWhyだからだ のように Who What Why を含む形で書かれる、ユーザーにとっての価値を説明する文 INVESTであるストーリーが良いとされる
-
Agile Testing#Agile #DevOps #Testing
-
ユーザーストーリー駆動開発で行こうAuthors: 市谷聡啓 #Agile ユーザーストーリー駆動開発で行こう。 by @papanda ユーザーストーリー INVEST ユーザーストーリーマッピング
-
アジャイルソフトウェアの12の原則#Agile アジャイルソフトウェア開発宣言に続く原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 アジャイル宣言の背後にある原則
-
スプリント#Agile 主にスクラムにおいて扱われる、タイムボックス化されたある期間のこと 1~2週間が多く、長くても1ヶ月にするにする
-
DevOps#Agile 2009年に10+ Deploys Per Day: Dev and Ops Cooperation at Flickrにて初めて登場した言葉 開発とオペレーションを一つのチーム内で両立させる 広義な用語ではあるが、共通して以下のような手法が定義されることが多い Continuous Integration Continuous Delivery Infrastructure as Code マイクロサービス
-
群れるアジャイル#石垣雅人 #Agile #Team Organization Swarming自体の説明とリモートワーク下での暗黙知の共有について 自己組織化
-
スクラム#Agile
-
デイリースクラム#スクラム #Agile 最新のスクラムガイドより抜粋 デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。デイリースクラムは、スクラムチームの開発者のための 15 分のイベントである。複雑さを低減するために、スプリント期間中は毎⽇、同じ時間・場所で開催する。プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。 全員で以下のフォーマットを共有する 昨日やったこと 今日やること 障害となっているもの
-
INVEST#Agile 作業バッチサイズを最小化させるための観点の頭文字を略称にしたもの Independent Negotiable Valuable Estimable Small Testable
-
エクストリームプログラミング#Agile
-
スプリントレビューの進め方#スプリントレビュー #吉羽龍太郎 #Agile Blog
-
アジャイル開発はWhyから始まる#市谷聡啓 #Agile Docswell ゴールデンサークル ユーザーストーリー
-
スプリントレビュー#スクラム #Agile #スプリント 最新のスクラムガイドより抜粋 スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合う。 検査、適応を行うためのイベント
-
スプリントプランニング Deep Dive#Agile #スクラム #吉羽龍太郎 スプリントプランニング スプリントゴール リファインメント ベロシティ SMART スプリントバックログ
-
組織を芯からアジャイルにする「インセプションデッキ」#市谷聡啓 #インセプションデッキ #Agile Docswell
-
インセプションデッキ#Agile
-
Whole Team#Agile #XP #Team Organization クロスファンクショナルチームの考えをベースとするエクストリームプログラミングで紹介されるプラクティス
-
DevOpsトポロジー#DevOps #Agile #Team Organization 2013年にMatthew Skeltonによって書かれたブログ、チームトポロジーの根底にある考えがまとまったような内容になっている 訳: 吉羽龍太郎 DevOpsトポロジー | Ryuzee.com
-
スクラムガイド#Agile スクラムのフレームワークを定義しているドキュメント、2020年版が最新 Jeff Sutherland, Ken Schwaber によって作成された Scrum Guide Scrum Guide(ja)
-
"Swarming" をコンセプトに掲げるアジャイルチームのベストプラクティス#Swarming #Agile #Team Organization #Continuous Integration #Continuous Delivery XP祭り2024での自身の発表 関連Scrapは以下 自己組織化 ストラングラーフィグアプリケーション トランクベース開発 モノリスからマイクロサービスへ 関数型ドメインモデリング
-
Agile Conversation#Agile Agile Covnersation では人間中心主義での2つの価値観を原則としている。 自己開示: プロセスを隠さず失敗を認める 他者理解: 相手に関心を持ち立場を理解しようとする 組織が高パフォーマンスを発揮するためにはどのような対話をするべきか、5つの対話ステップが紹介されている。 信頼を築く対話 不安を乗り越える対話 WHYを作り上げる対話 コミットメントを行う対話 説明責任を果たす対話 重要なのはこれらは段階的に踏んでいくステップでありそれぞれ独立していないこと。第1ステップの「信頼を築く対話」はその後のステップの基礎となる。 アジャイルソフトウェア開発宣言 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
-
エッセンシャル スクラム
-
ベロシティ#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 #Documentation
-
エンジニアリング組織論への招待
-
Swarming#Agile #Team Organization 重要な領域または主要な活動に焦点を置いてチームのエネルギーを集中させる。バックログに課題を積むのは最後の手段である。 障害にチームメンバー複数人で集中して対処するイメージを日々のスプリントにも適用していく。 Agile Teams Swarm to Greatness スワーミングがアジャイルチームを助ける ハイインテグリティコミットメントを実現するスクラム開発の進化
-
ゴールデンサークル#Agile TEDの優れたリーダーはどうやって行動を促すかによって初めて解説された考え 円の中心から Why What How の順に並ぶ Howが一番外側にあるが優先度が低いというわけではなく、HowによってWhatに大きな影響を与えるケースもある
-
スプリントレビュー Deep Dive#Agile #スクラム #吉羽龍太郎 #スプリントレビュー ステークホルダー
-
スクラム/適応Adaptation #スクラム #Agile 最新のスクラムガイドより抜粋 プロセスのいずれかの側⾯が許容範囲を逸脱していたり、成果となるプロダクトが受け⼊れられなかったりしたときは、適⽤しているプロセスや製造している構成要素を調整する必要がある。それ以上の逸脱を最⼩限に抑えるため、できるだけ早く調整しなければならない。関係者に権限が与えられていないときや、⾃⼰管理されていないときは、適応が難しくなる。スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。
-
スクラム/透明性Transparency #スクラム #Agile 最新のスクラムガイドより抜粋 創発的なプロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒える必要がある。スクラムにおける重要な意思決定は、3つの正式な作成物を認知する状態に基づいている。透明性の低い作成物は、価値を低下させ、リスクを⾼める意思決定につながる可能性がある。透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。
-
スクラム/検査Inspection #スクラム #Agile 最新のスクラムガイドより抜粋 スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱⼼に検査されなければならない。これは、潜在的に望ましくない変化や問題を検知するためである。スクラムでは、検査を⽀援するために、5 つのイベントでリズムを提供している。検査によって適応が可能になる。適応のない検査は意味がないとされる。スクラムのイベントは、変化を引き起こすように設計されている。
-
ユーザーストーリーマッピング#Agile #Documentation ユーザーストーリーを洗い出すためのプラクティス 優先度付けや段階的なリリースのスコープ整理を行う Blog / Agile Studio
-
DevOps capabilities/Work in process limits#Agile DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Work in process limits
-
カイゼン・ジャーニー
-
正しいものを正しくつくる
-
スプリントプランニング#スクラム #Agile #スプリント 最新のスクラムガイドより抜粋 スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計画を⽴てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチームは、アドバイスをもらうためにチーム以外の⼈をスプリントプランニングに招待してもよい。
-
組織を変える5つの対話
-
仮説検証型アジャイル開発#Agile #市谷聡啓 Blog