スクラム

ジェイソン・ガードナー（編） デイリースクラムは壊れていないが、タイミングは壊れているかもしれない リモートチームの毎日のスクラムが、特にタイムゾーンを超えて、急いでいるステータスレポートやロジスティクスの頭痛の種のように感じられるのは、あなただけではありません。分散型チームを採用する組織が増えるにつれ、集中力、説明責任、適応力を促進することを目的としたデイリースクラムは、チームメンバーが大陸やカレンダーに分散していると、その力を失う可能性があります。...

ジェイソン・ガードナー（編） チームは、顧客に真に価値を提供せずに、項目を「完了」と宣言することがよくあります。タスクにチェックを入れ、コードをマージし、ユーザーストーリーを「完了」列に移動しますが、納品された作業が使用できない、リリースできない、または期待に応えられない理由を説明するのに苦労します。 この一般的な問題は「完了」トラップとして知られており、「完了」の定義が狭すぎて、開発活動と現実世界の成果の間にギャップが生じます。透明性、一貫性、使用可能な価値を増分ごとに構築するには、チームは技術的な完了を超えて完了の定義...

ジェイソン・ガードナー（編） チームが「チームに息抜きの余地を与える」ことを望んで、スプリントを1週間から2週間に延長したらどうなるでしょうか?チームは低迷し、障害が長引くようになり、フィードバックサイクルは平坦化しました。本当の問題は、スプリントの長さが原因だったのか、それとも単なる信号だったのかということです。 スプリントの一貫性は問題ではなく、症状です スプリントの長さを一貫して維持することは、チームが健全なデリバリー リズムとフィードバック...

ジェイソン・ガードナー（編） スクラムは、顧客価値をより迅速かつ予測可能に提供するための実証済みのフレームワークを組織に提供します。スクラムがうまくいけば、高い士気と品質を維持しながら、変化に迅速に適応する、権限を与えられた自己組織化チームを構築します。 しかし、善意の組織でさえ、測定しやすいものだけに焦点を当てるという共通の罠に陥ることがあります。ストーリー ポイント、バーンダウン...

ジェイソン・ガードナー（編） 数え切れないほどのチーム ルームで、計画セッション全体で同じ混乱がこだまするのを耳にします。実用的に聞こえます。それは論理的に聞こえます。また、完全に的外れです。 組織は、見積もりと時間追跡を混同しているという理由だけで、俊敏性の取り組みを遅らせることがよくあります。ストーリーポイントは数時間ではなく、それをそのようなものと間違えると、見積もりの精度が損なわれるだけでなく、チームの信頼、速度の一貫性、長期的な俊敏性が損なわれます。 ストーリーポイントが実際に測定するもの ストーリーポイントは...

ジェイソン・ガードナー（編） スクラムを初めて使用するチームにとってよくある混乱のポイントは、製品バックログとスプリントバックログの違いです。名前は似ているように聞こえますが、どちらも作業のリストを含み、どちらもスクラムの中心です。しかし、この 2 つを混同したり、さらに悪いことに、あたかも交換可能であるかのように管理したりすると、透明性が低下し、優先順位がずれ、チームのオーナーシップが弱まります。 それを明確にしましょう。 プロダクトバックログ:長期的なゲームプラン プロダクトバックログについて考えてみてください...

ジェイソン・ガードナー（編） 正直に言うと、多くの日常的なスタンドアップはアジャイルとはほど遠いものです。 彼らは引きずります。彼らはさまよう。それらは、ステータスの更新や技術的なウサギの穴に変わります。そして何よりも悪いことに、彼らは自分たちの存在理由全体を見失います。 これにより、チームの足並みを揃え、スプリント目標に向かって前進することができます。 もしチームのスタンドアップが戦術的なツールではなく、強制的な習慣のように感じられるなら、今こそチューンナップの時です。 なぜ私たちはこの会議を開くのですか?...

ジェイソン・ガードナー 編 プロジェクト管理のダイナミックな世界では、アジャイルであることは単なる手法ではなく、必須条件です。 デイリースクラムは、スクラムの重要な要素であり、プロジェクト開発の複雑さを航海するチームのための信号となります。 この投稿は、効果的な計画と追跡によって日々の業務を最適化しようとするアジャイルチームに関わるすべての人々のために作成されています。 はじめに...

ジェイソン・ガードナー（編） ソフトウェア開発に関しては、スクラムというアジャイル手法は、プロジェクトマネジメントとチームのコラボレーションにとって非常に効果的なアプローチであることが証明されています。 ただし、チームメンバーが様々な場所や異なるタイムゾーンに分散しているチームがある場合、そのプロジェクトマネジャーやチームは、スクラムの実装を躊躇する場合があります。 実のところ、チームが分散している場合でも、スクラムは有効です。 スクラムを活用することで、成功の可能性が高まる場合があります。...

アジャイルプロジェクトマネジメントにおいて、「スクラム・オブ・スクラム」は、大規模なプロジェクトや複数のチームにわたってアジャイルプロセスをスケーリングするためには極めて重要な戦略として際立っています。 このツールは、コラボレーションと調整を促進し、さまざまなスクラムチームが共通の目標に向かって連携して作業できるようにします。 この記事では、スクラム・オブ・スクラムの本質を探り、その重要性、運用におけるダイナミクス、スクラムマスターの重要な役割に焦点を当てていきます。...

ジェイソン・ガードナー（編） 従来のソフトウェア開発では、チームは通常、バックエンド開発者とフロントエンド開発者の２つのグループに分けられてきました。 どちらもプロジェクトの成功に不可欠であり、それぞれに異なる責任があります。 バックエンド開発者はソフトウェアのロジックの作成、データベースの操作、コードの作成を担当し、フロントエンド開発者はソフトウェアのユーザーインターフェイスと設計を担当します。 しかし、この２つのグループはスクラムチームにおいて、どのように連携するのでしょうか？ 同じユーザー ストーリーから作業するのか？...

ジェイソン・ガードナー（編） ユーザーストーリーは、アジャイルソフトウェア開発の重要な要素です。 その核となるものは、「ソフトウェアシステムのユーザーのニーズと要件を説明する方法である」という単純なものです。 しかし、開発チームは、辻褄の合わない言い回しでユーザーストーリーを書くことがよくあります。 具体的には、「システムとして...」や「開発者として...」で始まるストーリーは、ユーザーストーリーの意味をなしていません。...