プロダクトバックログにおけるよくある質問と答え | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラム道FullBoostで出ていた質問と議論で若干うずうずするところがあったので、好き勝手に答えてみます。 なお、回答はあくまでコーチとしての勝手な見解であり、全てのコンテキストに有効な絶対解では決してありません。 そもそも自分達のおかれたコンテキストを踏まえた上で、どうやったらもっとうまくいくのかを考え続け改善していけばよいのです。 「パーキンソンの法則」を「ストーリーポイント」で防ぐ事はできるのか？パーキンソンの法則とは、「ある資源に対する需要は、その資源が入手可能な量まで膨張する」という法則で、開発にあてはめれば、確保した時間は、それを使い潰すまでつ使ってしまう、ということになる。 この症状をストーリーポイントによって解消できるか、という質問に対しては、答えはNoだ。 それは以下の理由だ。 ストーリーポイントは単なるポイントであり、なんら
ウォーターフォールとアジャイルにおけるマインドセット | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 Allan Shalloway氏のMindsets: Waterfall, 1st & 2nd Generation Agileがとても素晴らしい記事だったので、ご本人の承諾を得て一部日本語訳で紹介します。 なお、氏がかかれたこちらの記事(拙訳)を先に読むと理解が深まると思います。 以下の表は、ウォーターフォールとAgile（第一世代、第二世代に分けた。）におけるマインドセットを表にしたものである。誤解されないようにしてほしいのは、どのマインドセットが正しいとか正しくないとかいうことは無いということである。 我々はもっと仕事をうまくやるために、マインドセットを自由に持ち、変化していくことが必要かもしれない。 ただし自分自身を変化させることは難しいし、ましてや他人を変化させることはもっと難しい。 第1世代アジャイルと第2世代アジャイルの類似点
スクラムがうまくいっている兆候
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 昨日Twitter上で@yujioramaさんから「これは成功すると思えたスクラム導入の兆しとか読んでみたいです!」という要望を頂いたので個人的な見解を書いてみたいと思います。 なお、僕は基本的に、技術力とかツールの話以前の話としてチームの態度や周りとの協調関係を重視しているので、主にそういう観点が多いことを念頭においておいてください。 プロダクトオーナープロダクトオーナーが明確なプロダクトバックログアイテムを書いている自分が書いたプロダクトバックログアイテムに責任をもっている。開発チームがプロダクトプロダクトバックログアイテムの中身についてプロダクトオーナーに確認できる開発チームが
どうやってプロジェクトマネージャは自組織のアジリティを向上させるか
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） チームが物理的に近い距離で一緒に働くようにする。 いつも可能とは限らないが、そうすることが好ましいレポートとかメールのような形式ばったコミュニケーションをやめて、対面のミーティングや参加者が分散している場合はビデオ会議することを推奨する個人の能力開発をする相互作用をサポートするためにツールを使う一人で働くことを好む人よりも一緒に働くことを楽しめるメンバーを選ぶ昨日やったことと今日計画していることを話すために頻繁に－毎日でも－10分から15分のチームミーティングを行うテストを開発作業に組み込むこと。 そして自動テストツールの利用を考えること。 これはビルドが終わった後にQAやテストをするプロセスとは対極にある実際の利用者を参加
コミットメントとは何か？ | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 昨年夏に同人誌として刊行された「Ultimate Agile Stories」に寄稿させていただいたのですが、昨日のJim Coplien氏の認定スクラムマスター研修でもコミットメントの話が出ていましたので、参考までに僕の考えを転載します。 なお、Ultimate Agile StoriesはIteration2として今年も刊行を計画されるそうなので、是非動向をウォッチしておいてください。昨年は平鍋さんをはじめとする日本のアジャイルコミュニティを牽引するすごい方たちがたくさん寄稿されていました。 システム開発をしていると「コミットメント」という単語をよく耳にするだろう。アジャイル、特にスクラムの文脈においては「コミットメント」は重大な意味を持っている。本稿ではシステム開発における「コミットメント」とは何なのかについて考察してみたい。 1. 辞書の定
カンバンを導入する間違った理由5個
みなさんこんにちは。@ryuzeeです。 ちょっと古い記事ですが、TargetProcessのサイトMichael Dubakov氏による5 Wrong Reasons To Apply Kanbanという良い記事があったので、抜粋・意訳にてご紹介します。 5つの間違い1.ユーザーストーリーの多様性我々のストーリーは1ポイントから40ポイントまでさまざまなので、大きいストーリーがスプリントに入らない。なのでカンバンを使う 2.スプリントがうまくいかない1スプリントの中でほとんどのストーリーが完成しない。なのでカンバンを使う 3.ふりかえりミーティングがうまくいかないふりかえりミーティングが無駄になっている。チームメンバーはプロセスの改善に協力してくれず、ミーティング自体をなくしたい。なのでカンバンを使う 4. 人的リソースの共有と機能別組織開発チームが１つで、プロジェクト間でメンバーを共有
Agile 書評 アジャイルサムライー達人開発者への道
アジャイルサムライ−達人開発者への道− 著者／訳者：Jonathan Rasmusson 出版社：オーム社( 2011-07-16 ) 定価：￥ 2,808 Amazon価格：￥ 2,808 単行本（ソフトカバー） ( 288 ページ ) ISBN-10 : 4274068560 ISBN-13 : 9784274068560 アジャイルサムライは、Jonathan Resmusson氏が昨年書いた本で、日本語監訳は永和システムマネジメントの西村さん(@nawoto)と角谷さん(@kakutani)。 僕は僭越ながら翻訳原稿のレビューに参加させて頂いたのだが、本当に素晴らしい本で、出版を心待ちにしていました。 これからアジャイルな開発に取り組もうとしている人にとっても、既にアジャイルな開発に取り組んでいる人にも役に立つ必携図書であること間違いなしです。 この本の特徴 ScrumやXPやLe
スクラムにおけるイベントと出席者
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラムにおけるイベントはスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブの4つがあります（スプリント自体もイベントですが他のイベントの入れ物なので除外しました）。 また責任としてはプロダクトオーナー、スクラムマスター、開発者、そしてそれ以外のステークホルダーに分けられます。 誰がどのイベントに出席するべきなのかについて、マトリクス化された資料が存在しなかったので、作成してみました。なお、イベントではありませんが、プロダクトバックログリファインメントを参考までに入れました 以下補足です。 プロダクトオーナーのデイリースクラムへの出席出席しませ
より良いテスト駆動開発を行うためのチートシートの紹介
みなさんこんにちは。@ryuzeeです。 planetgeek.chというサイトでUrs Enzler氏がTDDのチートシートを公開していたのでご紹介します。 Clean Code and Clean TDD Cheat Sheets (PDFファイルでダウンロード可能です) 以下で、チートシート内の一部を意訳にてご紹介しましょう。 Unit Test Smellsテストが何もテストしていない一見するとテストが有効に機能しているように見えるが、実はテスト対象をテストしていない テストに過度なテスト準備が必要とされるテストが環境をセットアップするのに長いコードを必要としている。こういうノイズがテストが本当にテストしたいのが何なのか？ということを分かりにくくする。 大きすぎるテスト有用だが大きすぎるテスト。たぶんテストが１つではなく複数の機能をチェックしているか、テストが１つ以上のことをやろう
[Agile]Scrumで開発する際に最初にやるべきこと | Ryuzee.com
スクラムを利用してプロジェクトを進める際に、最初にやっておくべきことをまとめておく。 もちろん全プロジェクトでこれを全部やらなきゃいけないわけではない。そのあたりはコンテキスト依存ということで。 プロダクトゴールや価値の明確化 これから作るもののビジネス価値や製品ビジョンを明確にする プロダクトバックログの作成 もちろん全部が揃っている必要はないが、優先度が高いストーリーは明確に存在するはず。 バックログ項目の優先順位付け バックログ項目の見積もり バックログ項目の詳細化 個々のスプリントの開始前には優先順位の付け直しや見積もりの変更が行われるので、全てを詳細まで行ってはいけない。あくまで初期の1〜2スプリントが実施できる程度にとどめること。アップフロントでの計画を増やしすぎない。要求は必ず変化する。 おおよそのリリースプランニング ロールの明確化 プロダクトオーナーは誰？、スクラムマスタ
チームサイズ・スプリント期間・プロダクトバックログアイテム数について
みなさんこんにちは。@ryuzeeです。 Peter Stevens氏が行ったオンライン調査（調査母数は85）をもとにしてチームのサイズとスプリント期間とプロダクトバックログアイテムの数におけるスプリントの成功への関連について以下で述べているので、それを元に考察してみましょう。 Success Factors in a Scrum Sprint なお、ここで言っているスプリントの成功とは以下のように定義されています。 チームのサイズとスプリント期間2週間スプリントを採用しているチームが規模に関わらずもっとも多く、半数以上を占めています。 4週間以上という回答もあるようですが、これはスクラムとしてはいただけません。 チームの規模が小さい場合や、プロダクトバックログアイテムの粒が小さい場合はさらに短い1週間スプリントは採用しやすいです。 一方で、人数が多いチームでは、必然的に開発するプロダクト
スクラムが失敗する理由を5つの観点で見てみる
みなさんこんにちは。@ryuzeeです。 Joseph Pelrine氏とJiri Lundak氏の「Why Scrum Projects Fail」が良い記事なので抜粋・意訳にてご紹介します。 アジャイルやスクラムの導入支援をしていると必然的に組織改革や人事改革にたどりつくことが多いのですが、その理由は以下の失敗の理由を見れば明らかです。 もちろん以下のどれにも該当しない現場は滅多にお目にかかれず、少なからず失敗の原因になりうる要因が存在しています。 問題はその要因を「決まってしまっている仕方のないもの」として諦めるか、「カイゼンを繰り返してより良くしていく」活動をするかにかかっています。 感情面個人の対立混乱規律がない破壊的な振る舞い無気力恐れ支配反感・嫌悪過剰な優越感無視立場を決めるぬるま湯無関心文化的側面マイクロマネジメントミニウォーターフォール責任追及詳細な報告チームの決定を覆す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
