プロダクトバックログとスプリントバックログの見積もり
みなさんこんにちは。@ryuzeeです。 以前お客様先でスクラムのトレーニングを実施した際に、プロダクトバックログアイテムとタスクの見積りについて質問をいただきました。 見積りについてはもっとも質問をいただく項目の1つでもあるので、ここでスクラムにおける見積りについて書いておくことにします。 プロダクトバックログアイテムの見積りまずはプロダクトバックログアイテムの見積りについて考えてみましょう。 なぜプロダクトバックログアイテムを見積もるのか？なぜプロダクトバックログを見積もるかといえば以下の理由です。 そのプロダクトの全体を把握する。全体のサイズが分からないと現在の進捗が把握できません。もちろん全てのプロダクトバックログアイテムを絶対に作るかといえばそうではなく、途中でプロダクトバックログアイテムが追加されたり削除されたりしますが、それでも全体の概要を把握しようとすることには意味がありま
Packer & Chef-SoloでAmazon EC2のAMIを簡単に作る方法
全国1000万人のPackerユーザーのみなさんこんにちはこんにちは。 Packerは、Mitchell Hashimotoさんによって開発が進められている様々な環境の仮想マシンのテンプレートを簡単に作れるツールです。例えばVagrantを使っている場合はいままではPatrick Deboisさんが作っていたVeeweeを使うのが定番でしたが、このPackerの登場で主流が移りつつあります。 またPackerでは、Amazon EC2用のAMI (Amazon Machine Image)を作成することもできます（某ドラクエ好きな著名エンジニアのIさんが「PackerはAMI作成ツールだ！」と言っていたのを聞いたような気がw） 今までは、Packerでミドルウェアやパッケージをインストールしたり、細かい設定をする場合にはShellのProvisionerを使っていたのですが、先日登場したバ
なぜWIPの制限が重要なのか
みなさんこんにちは。@ryuzeeです。 WIPの制限についてExplaining why Limiting WIP is so importantにて良い説明があったのでご紹介します。 ※図は上記サイトより引用 1. WIP(仕掛り中)の同時許容個数を減らす個人的には1開発者が同時に着手するタスク数は1〜2個であるべきと思っています。 したがって、WIPが「2 * チーム人数」より多いのは実質的に制限がなされていないことになってしまい効果が出ないかもしれません。 現実的に何個にするのかは仕事の内容やチームの人数に依存するので、運用しながら順次見直していけば良いでしょう。 ただし安易に数値を増やすことは慎むべきです。 2. タスクの切り替えが減る一節によればタスクの切り替えは20%程度のムダが発生するとも言われています。 ちなみにタスクの切り替えはトヨタ生産方式における7つのムダのうち運搬
スクラム概要とストーリーの書き方 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 SlideShareを徘徊していたら良いスライドを見つけたのでご紹介します。 著者のPeter Saddington氏はアジャイルコーチで、AgileScoutというブログやScrum Pocket Guideという本を書いたりしています。 このスライドでは前半でスクラムの説明（ロール、アプローチ、鶏と豚、会議体、作るもの等）をして、途中一旦の締めとして、アジャイルやスクラムにおける大事なこととして以下を説いています。 アジャイルの核はチームにあること優先度が最高のもっとも価値のあることから集中して取り組むことコミュニケーションの重要性ドキュメントはプロセスの中で書いて、前払いはしないことレビューを繰り返し繰り返し繰り返し行うこと完成を定義すること後半ではユーザーストーリーについてのより良い方法についてです。 ここでは、ユーザーストーリーは会話であ
【資料公開】バーンダウンチャート虎の巻
みなさんこんにちは。@ryuzeeです。 2010/12/22に永和システムマネジメントさんで実施したスクラム道.02でバーンダウンチャートについてお話させていただきました。 その際の資料を公開します。 スクラムではバーンダウンチャートを使うことが定義されていますが、バーンダウンチャートもツールなので、それをどう使うか、というのを考える事は非常に大事だよ、ということ、改善に使うべきであるということ、形状等を見ればチームの自己組織化レベルまで推察することができるよ、指標を追加するとさらに色々なことが分かるよ、といった話をしてます。 日本ではバーンダウンチャートについてこの話をしている人はまだほとんどいないはずです。 感想を聞かせていただければ幸いです。
リーンアジャイルメソッドの概要
みなさんこんにちは。@ryuzeeです。 Alan Shalloway氏がhttp://www.agilejournal.com/articles/columns/column-articles/3222-an-overview-of-lean-agile-methodsで書かれていた記事が良記事なので、抜粋・意訳にてご紹介します。 かつては物事はシンプルでした。 90年代に、アジャイルを選択しようとすれば、XPを選択するしかありませんでした。そして、その後、スクラムがポピュラーになりました。組織がチームへのフォーカスによって、これらのアプローチの限界に突き当たるようになったのは最近の話です。それから、ソフトウェアにリーンの原則を適用することができるということが明らかになってきました。リーンソフトウェア開発および後のカンバンが一連の中に加わりました。今、もしアジャイルな開発手法を選ぼうとす
[Agile][翻訳]アジャイル関連書籍ベスト100
Top 100 Agile Booksというテーマで、Jurgen氏が書かれていたので、どのくらいの本が日本で翻訳されてるんだっけ？という興味もあり、日本語化されているものはその旨追記してみた。 なお、Jurgen氏によれば、Amazonで、「この本を買っている人は合わせてこれも買っています」みたいな情報によって本の一覧を抽出し、ランキングについては、AmazonとGoodReadsというサイトのデータを参考にして重みづけして集計したとのこと。 本が売れないから邦訳が出るのを時間をかけてまっても仕方ないという気もするので、この本翻訳まだー？みたいな人は英語で読んでしまうと良いのではないかと思う。 Agile Estimating and Planning Mike Cohn 2005 アジャイルな見積もりと計画作り アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
![[Agile][翻訳]アジャイル関連書籍ベスト100](https://cdn-ak-scissors.b.st-hatena.com/image/square/e28ac0c06090ef4280af681bdbe7af0aed6391ba/height=288;version=1;width=512/http%3A%2F%2Fwww.ryuzee.com%2Fimages%2Ffb.png)
スクラムを失敗させる方法
1. ふりかえり（レトロスペクティブ）をしないか、間違ったふりかえりをするふりかえりをせずして、どうやって物事をよりうまくできるようにすることができるというのだろうか？ ふりかえりは、全てのチームメンバーがうまく行ったこと、もっとうまくできるだろうことについて議論できるという点で必要不可欠だ。 そしてもちろん言うまでもなく、失敗から学習しなければならない。もしそういったことが行われていない（形式的なふりかえり）なら、ふりかえりは役に立っていない。 2. ダメなプロダクトオーナープロダクトオーナーはいつでもプロジェクトのために時間を使えるようでなくてはならない。 プロダクトオーナーはスプリントプランニングやふりかえりに参加しなければならない。 また一方でプロダクトオーナーはスプリント中のタスクは見積りしてはならない。見積りはチームの責任なのだ。 プロダクトオーナーはビジネス上の優先順位に基づ
私がアジャイルで嫌いな10のこと
みなさんこんにちは。@ryuzeeです。 10 Things I Hate About Agile Development!が良い記事なので、引用・意訳にてご紹介します。 アジャイルに関する誤解がよく分かると思いますので、くれぐれも真似しないようにしてください。 ただデイリースタンドアップミーティングをやっているだけで、「アジャイルをやっている」と言うこと。 別にそれは「アジャイルをやっている」わけではない。 これ以外にアジャイルを実践するためにもっと大事なことがある「アジャイル」の頭文字のAが大文字か小文字かを気にすること。 先頭を大文字で書いたらクールじゃないって言ってるのかな？ 本当の意味での違いは、「アジャイルメソッド」と「アジャイルである」という違いなのだ。 多くの人はたぶんこの微妙な違いを分かっていない。 みんながこの大文字と小文字の違いでもめるようなことは、私にはしゃくに障る
Scrum概要早わかり(資料・動画)
著作 SCRUM BOOT CAMP THE BOOK 著者／訳者：西村直人 永瀬美穂 吉羽龍太郎 出版社：翔泳社( 2013-02-13 ) 定価：￥ 2,520 スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。 CakePHPで学ぶ継続的インテグレーション 著者／訳者：渡辺 一宏 吉羽 龍太郎 岸田 健一郎 穴澤 康裕 出版社：インプレス( 2014-09-19 ) 定価：￥ 4,320 Webアプリケーション開発における継続的インテグレーションについて、CakePHPのサンプルをベースにして、その概要から使用ツール解説、導入方法、メンテナンスまでを解説
Agile Conference Tokyo 2009に行ってきた
カンファレンスの詳細は技術評論社のサイトで。 開催は品川のコクヨホールで、12時開場、13時基調講演という流れで進んだ。 先着200名に本をくれる＆さらに先着でPokenをくれる、ということなので、丁度12時くらいに行ったのだが、既に結構並んでいた。(実は同じ本を持っていたことが判明。最近このパターン多い) 参加者は300人ということだったが、ほぼ満席で、かつスーツな方が7割(僕は当然私服)ということでマネージャ層あたりまでAgileへの関心を持ち始めているんだなぁという印象。Certified Scrum Master研修とは明らかに来ている客層が違う感じだった。 個別セッションの感想を以下に。 Thought Works社のXiao Guo氏の基調講演 通訳がgdgdだったので英語で拝聴。CSM研修でのミルズさんの通訳の素晴らしさを改めて認識 「大規模システムでのベストプラクティスとそ
オフショアはコスト削減につながらない
みなさんこんにちは。@ryuzeeです。 Zen, Project Management, and Life: Proof that Agile Worksが、偉い人への説得材料用として役にたちそうですので、要約にて紹介します。 ここで言っているオフショアは、日本でいうところの下流工程の海外への丸渡しであり、分散アジャイルではありません。 この手の話は全部のプロジェクトでアジャイルやったほうがうまくいく、とかアジャイルのほうが絶対コストが安い、納期が短いんだ！とかそういうのを保証しているものではありません。 自社の状況、チームの成熟度など、色々な要因に左右されるので、自分でよく考える必要があります（考えるきっかけになればいい）。 また調査は特定規模のプロジェクトに固定しているので、それより大規模になると違う結果が出てくるかもしれないません。 要約調査結果は20年間に行われた8000のプロジ
IBMの「チーム開発の生産性を高めるプロセスを体感しよう（入門編）」に行ってきた
Shibuya-tracつながりで、IBMのAgileセミナー「チーム開発の生産性を高めるプロセスを体感しよう（入門編）」に行ってきた。 内容はScrumの基礎とRational Team Concert(RTC)の紹介。 Scrumについては、@masayang師匠から教えを受け、多数の案件をやってきているので、新たな発見というのはあまり無かったけど、改めて復習にはなった。ただセミナーの内容は純粋Scrumというよりは日本型Scrumと言った方が良いかと思う。ターゲット層がAgile初心者だったようなので「これがAgileというものなんです」と言うと誤解を招く恐れがあるのではないかな。Agileマニフェストを最初に説明しておいた方が良かったと思う。 参考になった点を列挙しておく。 Scrum概説 WFとAgileの例え。WFは長編映画。あたるかどうかは封を切ってみないと分からない。一方で
Agileでやってるけどデスマったｗ
Agileでデスマになったのでそのログです。 この後同じことを繰り返すと馬鹿なので、まだデスマ中だけど、問題点と反省点を書いておこうと思う。 こういうのは渦中にやっておかないと終わった後だと「大変だけど終わって良かったね」で終わってしまいがちなんだよね。 これを読まれている方は反面教師にしてください。 契約と総生産量の関係性 期間と費用が決まっている場合、総生産量には当然上限がある。生産量はチームのベロシティが分かっていれば、ストーリーポイントに換算できるので、開発開始時点で、総生産可能ストーリーポイントについては明示すべきだった。土日出て頑張れ！とか残業して頑張れ！とかいうのはAgileを知らない証拠。 上記に関連して、プロダクトバックログにストーリーを追加することが出来るのは、プロダクトオーナーの権利なのだけれども、優先度高としてストーリーを追加したところで、バーター可能なストーリーが
アジャイルプロジェクトの契約に関する私見
みなさんこんにちは。@ryuzeeです。 ソフトウェアを構築するときに締結する契約は、大別すると請負契約と準委任契約、そして派遣契約（今回は割愛します）があります。 請負契約は、完成させるべきものを事前に規定し、それを満たすものを納品することで代金が支払われます。 一方で準委任契約は、発注者の代わりに自身の裁量で業務を遂行する契約であり、働いた時間に応じた代金が支払われるのが一般的です。 アジャイル開発では、顧客やユーザーのフィードバックを得て作るものを変えていきます。 つまり事前に詳細なスコープは確定しません。 それにも関わらず請負型の契約を行った場合、事前に決められた「完成させるべきもの」に加えて、フィードバックへの対応が必要になってしまいます。 事前に決められた内容によって期間と費用が固定されるため、このような変化は開発側としては避けなければいけないものになります。 その理由は、単純
チームがアジャイルかどうかをセルフアセスメントする42の質問
みなさんこんにちは。@ryuzeeです。 How Agile Are You? (Take This 42 Point Test)が良い記事なので抜粋・意訳にてご紹介します。 ちなみにチームが「アジャイル」か？というより、チームが「スクラム」か？といった方が良いと思われるので、その点は留意してください。 チームに決定権限が与えられているチームは、自己組織化されていて、目標を設定して達成することを管理（者）任せにしないチームは成果物の提供に対してコミットし、責任を持つ。そしてチームがゴールに到達するために、あらゆるタスクに協力するチームはプロダクトオーナーが誰であるかを知っているそれぞれのスプリント/イテレーションには明確なゴールが設定されているテスターを含む全てのチームメンバーは、要件を抽出するワークショップに参加する要求事項の文書は十分にそろっている。そしてフィーチャーを実装できるレベル
アジャイルへの間違った理解がプロジェクトを迷走させる | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 アジャイルに関する間違った理解、よく聞く誤解について整理しました。 アジャイルだから仕様変更は自由？スプリント中で実装中のプロダクトバックログアイテムの変更とスプリント内で実装するプロダクトバックログアイテムの追加は開発チームが受け入れない限り勘弁してください。 それ以外のプロダクトバックログアイテムの追加は歓迎しますが、変更や追加を行えば行うほど費用はかかる可能性があります。 もしくは優先順位の低い他の機能と入れ替えになります。 無制限・無費用な変更はありえません。 アジャイルだから画面から決める？そうとは限りません。 何を表示したいか、何をさせたいかは決めますが、コテコテに画面遷移やUIから決める必要は必ずしもありません。 UIの層は一番変更かけやすく終わりもありません。 UIがビジネス上の大きな価値を持つので無い限り、UIの細かい調整は後回し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ApacheDS | Ryuzee.com