チームパフォーマンスモデルとは？
みなさんこんにちは。@ryuzeeです。 人が集まっただけでは機能するチームにならない、というのはみなさんご存知のとおりです。 そしてチームの形成過程をあわらすモデルの1つとして有名なものに「タックマンモデル」があります（こちらを参照）。 今日はもう1つ別のモデルとしてDrexlerとSibbetが提唱している「チームパフォーマンスモデル」を紹介します。 タックマンモデルでは、チームの形成過程は形成期・混乱期・統一期・機能期・解散期の5段階（初期は4段階）で構成されていましたが、このチームパフォーマンスモデルでは、以下の7段階で構成されます。 オリエンテーション信頼の醸成ゴールの明確化コミットメント実行ハイパフォーマンスリニューアルこれらのステージは前半上から下に向います（形成段階）が、この段階では、徐々に制約を感じるようになっていきます。一方で後半に下から上にあがっていく（持続段階）につ
vagrant-omnibusで簡単Chef Client/Chef Soloインストール
Vagrantを使ってインスタンスを作成し、Chef Provisionerで自動でパッケージをインストールしたり設定をする、というのが定石の流れです。 しかし、インスタンスの雛形であるboxにChef ClientやChef Soloがインストールされていない場合、このインストールを自分でしないといけないのは面倒の極みです。 そもそも設定するためにインスタンスにログインして設定を追加してからプロビジョニングするのはアホくさいですし、自動化された処理を走らせるために手動で面倒くさい処理をするというのはナンセンスです。 これを解決するには２つのアプローチがあります。 Chef Client/ Chef Soloをインストールした上でインスタンスを再度box化して次回以降も使えるようにするVagrantを起動するときにChef Client/Chef Soloがインストールされていなければ自動
資料公開 Vagrant (+Amazon EC2)
著作 SCRUM BOOT CAMP THE BOOK 著者／訳者：西村直人 永瀬美穂 吉羽龍太郎 出版社：翔泳社( 2013-02-13 ) 定価：￥ 2,520 スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。 CakePHPで学ぶ継続的インテグレーション 著者／訳者：渡辺 一宏 吉羽 龍太郎 岸田 健一郎 穴澤 康裕 出版社：インプレス( 2014-09-19 ) 定価：￥ 4,320 Webアプリケーション開発における継続的インテグレーションについて、CakePHPのサンプルをベースにして、その概要から使用ツール解説、導入方法、メンテナンスまでを解説 Chef実践入門 ~コードによる
プロダクトオーナーシップに関する分かりやすい動画
みなさんこんにちは。@ryuzeeです。 面白い動画を見つけたのでご紹介します。 作者はHenrik Kniberg氏で、一昨年のScrum Gathering Tokyo 2011で日本に来ていただき、認定スクラムマスターのコースを開催したこともある人だ。塹壕よりScrumとXPの著者といった方が分かりやすいかもしれません。 15分くらいで、絵を書きながら説明をしていくスタイルで、プロダクトオーナーシップやスクラムの流れについて解説しています。 最終的な完成図は以下のようになります。(オリジナルサイズのファイルのダウンロードはこちら) 僕の研修では、スクラムの説明をした後に、受講者自身にペアプロのようにスクラムの流れを1枚の絵で書いてもらうワークショップをやっているのですが、何かを1枚にまとめるというのは理解の促進の上で分かりやすい方法だと思っています。 分かっていないと書けません。 分
Vagrantの必須プラグインSaharaをVagrant 1.1に対応させました
Saharaはコマンドラインから仮想マシンの状態をsandboxモード(変更をいつでも巻き戻せる)に変更できるプラグインです。これを使うことで、例えばchefのレシピ作成やミドルウェアのインストールの評価やリリース手順の確認や大規模な環境変更の評価などがやりやすくなります。Vagrantを使っている人であれば必携のプラグインと言えます。 そんなSaharaですが、開発が停止しているような感じもあり、先日出たVagrant 1.1になかなか対応しそうにないように見えたので、自分でVagrant 1.1に対応させてみました。 なお、かなり大量にソースを書き換えている(作り直しに結構近い気がする)のと、Rubyはあんまり知らない人なので、ご利用は自己責任でお願いしますー。レポジトリはこちらです→ https://github.com/ryuzee/sahara インストール gemにはしていない
ウォーターフォールとアジャイルにおけるマインドセット | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 Allan Shalloway氏のMindsets: Waterfall, 1st & 2nd Generation Agileがとても素晴らしい記事だったので、ご本人の承諾を得て一部日本語訳で紹介します。 なお、氏がかかれたこちらの記事(拙訳)を先に読むと理解が深まると思います。 以下の表は、ウォーターフォールとAgile（第一世代、第二世代に分けた。）におけるマインドセットを表にしたものである。誤解されないようにしてほしいのは、どのマインドセットが正しいとか正しくないとかいうことは無いということである。 我々はもっと仕事をうまくやるために、マインドセットを自由に持ち、変化していくことが必要かもしれない。 ただし自分自身を変化させることは難しいし、ましてや他人を変化させることはもっと難しい。 第1世代アジャイルと第2世代アジャイルの類似点
アジャイルコーチって何するの？
みなさんこんにちは。@ryuzeeです。 InfoQに“アジャイルコーチ” とは何か という記事があったので、アジャイルコーチとして活動している僕が普段どんなことをやっているのか説明したいと思います。 オンラインでのコミュニケーションTwitterやFacebook、そしてこのサイトからアジャイルに取り組んでいる方や、これから取り組みをはじめようとする方からよくご質問を頂きます。 コーチとしては、実践する上でどういうことに困っているかを色々と知ることができるので大変ありがたいです。 特に金銭のやりとりはありませんが、コーチとして責任をもった回答をする必要があると思っているので、文献や海外のサイトや海外の著名トレーナーの資料などを参照しつつ自分の見解も交えて回答させて頂いているつもりです。 質問は回答をうける側よりも、回答する側のトレーニングになると思っています。 質問頂いた内容は、一般化し
スプリントにおけるコミットメントとは何か
みなさんこんにちは。@ryuzeeです。 スプリントプランニングでは、スプリントの終了までに「どのプロダクトバックログアイテムを完了させるか」を計画します。 このコミットメントとは何なのか？先日のCertified Scrum Product Owner研修でジェフ・サザーランドさんに以下のどれなのかを聞いてみました。 スプリントプランニングで決定した内容をスプリント期間中に「全て終わらせる」ことをコミットするそのスプリントにおいて、チームが「全力で選択したプロダクトバックログアイテムを完了させようとする」ことをコミットする1または2のいずれになるかはコンテキストに依存する プロジェクトの初期段階の数スプリントでは、見積りの精度は低いし、自分たちのベロシティがはっきりしていないので、通常はオーバーコミットしがちです。 またそもそもスクラムの経験が豊富ではないチームでは、「プロダクトバックロ
ストーリーポイントの見積りは何故時間の見積りより良いのか
みなさんこんにちは。@ryuzeeです。 よく聞かれるネタではあるのですが、スクラムの父ジェフ・サザーランド氏がストーリーポイントの見積りがなぜ時間の見積りよりも良いかについて過去にブログに書かれたものを意訳・抜粋にて紹介します。 以下の訳文は原文にしたがって、CC BY-NC-SAとします。 原文はこちら 左図: 不確実性コーン 右図: マイクロソフトによるストーリーポイント見積りの正確性 ストーリーポイントを使うとより正確な見積りを得られ、計画の時間を劇的に減らすことができ、リリース日をより正確に予測できるようになり、チームのパフォーマンスの改善の助けになる。 時間を使った見積りは、よくない見積りとなり、システムに大量のムダを生み出し、プロダクトオーナーのリリース計画の妨げとなり、どのプロセス改善が本当に役立っているのかチームがわからなくなる。 新たな興味深い調査結果が公開された。 ス
守破離/何が偉大なスクラムマスターを作るのか
みなさんこんにちは。@ryuzeeです。 ジェフ・サザーランド博士のブログ記事、Shu Ha Ri - What Makes a Great ScrumMaster?のご紹介です。 元記事に対応して、以下の部分はCC BY-NC-SAライセンスとします。 守破離のコンセプトは日本の合気道という武術から来たものだ。 私はデンバー(センセイは破の段階だった)とケンブリッジ(センセイは離の段階だった)で合気道の道場に数年通った。 生徒はまずは「守」からはじめて、センセイの指示に正確に従わなければならない。 黒帯を取ると、彼(彼女)は「破」の段階にたどり着いたことになり、素晴らしい型の練習をしたり、よりよくするために洞察して適用することが可能になる。 「離」の段階はちょっと違う。センセイが手を動かすと相手は触られてもいないのに宙を舞ったりする。もちろん「気」の力の使い手を見たことがなければ、こんな
Robot Framework + Selenium2Libraryで簡単受け入れテスト | Ryuzee.com
Robot Frameworkは受け入れテストや受け入れテスト駆動開発(ATDD)に使えるテスティングフレームワーク。 http://code.google.com/p/robotframework/で開発が進められている。 プレインテキストやHTML形式でテストケースを記述できること、pythonまたはjavaによってテストライブラリを作って拡張できることが特徴だ。 ここではRobot FrameworkとSelenium2(WebDriver)を組み合わせて、受け入れテストを自動化する方法について説明する。 WebDriverを単独で使ってWebアプリケーションのエンドツーエンドテストを作る場合、どうしても画面ができてからしかテストケースが作れないというのが大きな問題だ。そのため例えばPHPであればBeHatと組み合わせしたりするのだが、今回の方法は更に簡単だ。 例えば、アジャイルな開
チームへの期待を明らかにする
みなさんこんにちは。@ryuzeeです。 この記事は現在発売中のアジャイル同人誌Ultimate Agile Stories2に掲載させていただいたものを転載するものです。 1.はじめにアジャイルコーチという職業柄もあって今まで多くのチームを見てきた。良いチームもあれば、「うーん、これは単なる人の集団で、チームじゃないなぁ」と嘆きたくなるようなことも中にはあった。本稿では私自身がチームに期待することを明らかにしつつ、読者のチームでもこのような整理をすることをお勧めするものである。 2.1 私がチームのメンバー個人に期待すること給料をもらえるのは、自分が会社に所属しているからではなく、その先にお金を払ってくれるお客様がいるからだ、ということを理解しよう。したがって、お客様の期待に応えられるようにふるまう責任があることを理解しよう。 こんなの当たり前じゃないか！と思うかもしれない。しかし、コマ
目標ベロシティとベロシティのインフレ | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 現実から得られるベロシティの実績値をもとに、次のスプリントでそれよりも大きい目標ベロシティを設定することはおすすめしません。 それは以下の理由からです。 そもそもチームの実績としての指標データであるベロシティが目標値として設定されることによって、チームがその目標に到達しなかった場合にチームに何か問題が発生しているようにとらえてしまうもちろん継続的な改善によってチームのベロシティは一般的には初期のスプリントから中盤にかけては向上する傾向にはありますが、それはあくまで結果としての指標データです目標ベロシティを決めて、かつ、それをコミットしてしまった場合、往々にして、数字を満たすために、テストの手抜きをしたりリファクタリングするのをやめて目先の数字を追ってしまうことが多々ありますいくつかのスプリントをこなせばチームとしての生産力は見えてくるので、数字をコ
スクラムにおけるメトリクスの扱い | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 最近よく「スクラムではどんなメトリクスをどう取ればよいですか」と聞かれるので整理しておきます。 スクラムでよく登場する数値データスクラムでよく登場する数値データとしては、プロダクトバックログアイテムのビジネス価値や見積り、スプリントバックログのタスクの理想時間があり、スプリント中に完了したプロダクトバクログ項目の見積りポイント（相対見積りの場合）の合計がベロシティ、全プロダクトバックログアイテムの未完了分の合計見積り値の推移をプロジェクトバーンダウンチャート、スプリント期間中のスプリントバックログ項目の合計残時間の値の推移をスプリントバーンダウンチャートとして表現することができます。 最新のスクラムガイドでは見積りを相対ポイントで行うべきであるとか、これらチャートを書くべきであるとかは規定されておらず、またメトリクスをいつどのように取得するのかにつ
スクラムに関する無料の日本語資料のまとめ | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムを学習するにあたって参考になる【無料】の資料を以下にあげておきます。 僕がコーチングする際は上２つの資料については事前に読んでもらった上で、トレーニングを実施したりしてます。 スクラムガイドスクラムの父であるジェフ・サザーランド氏とケン・シュエイバー氏が書いた公式のルールブック。 これを読まないでスクラムをやるのはマズイです。 http://www.scrumguides.org/日本語版は、多くの本の翻訳をされている角さんが訳されてます塹壕よりScrumとXP昨年開催したScrum Gathering Tokyoで基調講演をされたヘンリック・クニベルグ氏によるScrumとXPの実践事例。 どういう問題がおきてどう改善したかも分かる。 http://www.infoq.com/jp/minibooks/scrum-xp-from-the-t
[Agile]Agileチームのアセスメントの方法 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 アジャイルな開発を行っているチーム（やっていなくても構いませんが…）のアセスメントを行う方法について考えてみました。 あくまで一例でこれが最適とは限りませんが、コーチとしてリアルなプロジェクトの具体的なところではない原点の部分を軸にしてチームの成熟度を把握できるようになりたいなぁということで、アジャイルマニフェストの12の原則をベースにして考えてみました（今後継続的に足していったり、現場で試してみる予定です）。 1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。プロとして顧客のために行動できているか正しいことを行っているかどうかを常に意識しているか顧客のためとは顧客の言う事をすべてやることではないことを理解しているか価値は提供する側が決めるものではないことを理解しているか顧客にとって価値がなかったらどうなるか理解しているか2
![[Agile]Agileチームのアセスメントの方法 | Ryuzee.com](https://cdn-ak-scissors.b.st-hatena.com/image/square/df332fc34a3fa52667d1fd10e539a45e2f6a3550/height=288;version=1;width=512/https%3A%2F%2Fwww.ryuzee.com%2Fcontents%2Fblog%2Fimages%2F4657%2Fthumbnail.png)
アジャイルプロジェクトの可視化方法
みなさんこんにちは。@ryuzeeです。 Agile Metrics and Diagnostics Presentation にて、アジャイルなプロジェクトの可視化方法について、詳細な説明の資料が掲載されているので、いくつか抜粋してご紹介します。 図1：スプリント中におけるタスクの残存時間の推移とバーンダウンチャート(Scrumの基本) 図2：バーンダウンチャートによると、このペースでいくと200時間不足する状況であることが分かる(Scrumの基本) 図3：合計時間と残り作業時間が減っている。ここでは何が起こっているのか？ 図4：後半になるにしたがって残り時間の減少度合いが下がっている。何かボトルネックがあると思われる。 図5：ボトルネックを明らかにするために、タスクを作業内容ごとにカテゴリ分けしてみる(テストを書く、JSPを作る、HTMLのデザインをする等) 図6：カテゴリごとにバーン
Scrum Boot Camp Premium開催のお知らせ (7/11)
2012年7月11日(水)にScrum Boot Camp Premium (第2回)を開催します。 前回は2月25日に初めて有料バージョンとしてScrum Boot Camp Premiumを実施しましたが、おかげ様で大変好評をいただき、第2回目の開催となりました。今後も四半期毎を目処に定期的に実施していく予定です。 今回の研修も、前回同様有償コースということで、 研修資料のハンドアウト(約300ページの資料を印刷・製本したもの) PDU6ポイント スクラム用語集 推薦図書一覧 研修後のメールでの質問への対応 懇親会 がコース内容に含まれています。 なお、PDUもつきますので、所属される会社にご相談の上、会社の研修の一環として参加されることをオススメします。前回は土曜日開催でしたが、今回は平日開催ですので業務として参加しやすくなっていると思います。是非、受講をご検討ください。 講師は、ア
ゴールを決め過ぎてしまうことによって陥る罠
みなさんこんにちは。@ryuzeeです。 Bob Hartman氏のAgile antipattern: Target fixationが良い記事なので、抜粋・意訳にてご紹介します。 日本でよく言われるのが、「期日までに使わない（と思われる）機能も全部作れ、契約だから」。 限られた時間軸の中で変化を受け入れながら進めている中でこういうのを要求されると、品質やチームのモチベーションやコラボレーションを犠牲にしはじめてしまいます。 このような状況が続けば焼畑農業のようにチームには何も残らなくなります。 結果として顧客にとっても幸せな結果にはなりません。 期日を約束したりストーリーポイントのゴールを約束したり、その他のゴールが命取りになることがある。これらだけでは本質的に悪くは無いとしても、下記に述べるその他の項目と組み合わさると、問題となるだろうチームはゴールを達成するために品質を端折り始める
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】強いチームの作り方(デブサミ2016版)
