アジャイルコーチはなぜ1週間スプリントを勧めるのか
みなさんこんにちは。@ryuzeeです。 職業柄スクラムを始めたばかりのチームを支援することがよくあります。 そのような状況で、ロールの明確化や初期のプロダクトバックログの準備とあわせて話題にのぼることが多いのが、スプリントの期間をどうするかです。 そして、多くの場合、1週間スプリントを提案しています。 今回はなぜ1週間スプリントが良いのか見ていきましょう。 1週間スプリントがよい理由1週間スプリントがよい理由を列挙すると以下のようなものがあります。 レトロスペクティブ（ふりかえり）が頻繁にあるので改善が進む計画の精度が高くなる例え失敗しても一週間で済むので実験しやすいベロシティの数字がすぐ出るのでやる気になる中だるみする余裕がない・リズムがよい一週間で収まるサイズのプロダクトバックログアイテムにするので明確な完成を定義しやすい。従ってプロダクトオーナーの受け入れを取りやすいスパイクが必要
スクラムがうまくいっている兆候
みなさんこんにちは。@ryuzeeです。 昨日Twitter上で@yujioramaさんから「これは成功すると思えたスクラム導入の兆しとか読んでみたいです!」という要望を頂いたので個人的な見解を書いてみたいと思います。 なお、僕は基本的に、技術力とかツールの話以前の話としてチームの態度や周りとの協調関係を重視しているので、主にそういう観点が多いことを念頭においておいてください。 プロダクトオーナープロダクトオーナーが明確なプロダクトバックログアイテムを書いている自分が書いたプロダクトバックログアイテムに責任をもっている。開発チームがプロダクトプロダクトバックログアイテムの中身についてプロダクトオーナーに確認できる開発チームが必要なときにはいつでもプロダクトオーナーにコンタクトできるプロダクトオーナーが開発チームのそばにいるプロダクトオーナーと開発チームが敵対関係でなく会話しているプロダクト
アジャイル開発やスクラムのトレーニングでよく聞かれる質問とその答え (1)
みなさんこんにちは。@ryuzeeです。 弊社ではアジャイル開発、スクラムのトレーニングを提供しているのですが、トレーニング中には多くの質問をいただきます。 今日はよくある質問とその答えについていくつかご紹介したいと思います。 好評そうだったら続編も書く予定です。 ■アジャイル開発において、ドキュメント作成の一般的な指針を教えてくださいどのようなドキュメントがいつ、どの粒度で必要なのかはプロダクトやプロジェクトに依存します。 プロダクトやプロジェクトにはそれぞれ固有の品質基準があり、それはアジャイルやウォーターフォールといった方法論の違いによって変わるものでもありません。 したがってプロジェクト冒頭でプロダクトオーナーやステークホルダー（品質管理部門や顧客など）と「なんのために」「どのようなドキュメントが」「どのような記述レベルで」「いつまでに必要なのか」を決定してください。 誰も使う予定
スクラムで依存関係を取り扱う方法
みなさんこんにちは。@ryuzeeです。 コーチングをしていてよく聞かれる質問の1つに、チーム間をまたがる依存関係の管理をどうするか、というものがあります。 これの回答となる素晴らしい記事がTHE QUIET AGILISTというサイトで公開されていました。 著者のRick Cusolitoさんに記事の翻訳と公開を快諾いただきましたので、以下で紹介いたします。 元記事はこちらです。http://www.quietagilist.com/blog/2014/10/16/handling-external-dependencies-in-scrum スクラムの依存関係を扱う3つの実績のある方法 開発チームは機能横断的(クロスファンクショナル)である。インクリメントを作成するスキルをチームとしてすべて備えている。- K. Schwaber and J. Sutherland、スクラムガイド、
【我流】プレゼンテーション資料の作り方
全国100万人のブリよりワラサ好きのみなさんこんにちは。先日強いチームの作り方を公開したのですが、何人かの知り合いからこういうスライドの作り方教えてほしい、というリクエストを受けたので以下にダンプしておきます。 参考書籍以下にあげる本は一度読んでおいて損はないです。プレゼンテーションZenは、ピアソンが技術書の取り扱いやめてしまい絶版かと思ったけど第二版が出て何より。 ガー・レイノルズ シンプルプレゼンプレゼンテーションZEN 第2版プレゼンテーションZENデザインこれらの本の中でも出てきますが、「プレゼンテーション」と「ドキュメント」は明確に分けた方がいい。 よく会社で経営方針とか数字とかをパワーポイントで作って配りますが、単にデータや説明を見せるならそれこそワードでやった方が読みやすいしコンパクトです。 トヨタがA3用紙1枚でまとめる(最近そうでもないらしいですが)と聞きますが、それと
【資料公開】DevOpsの基本
こんにちは。@ryuzeeです。 営業でDevOpsの基本の話をしてきましたので資料を公開しておきます。中身自体は昨年11月に楽天テクノロジーカンファレンスで話した内容を日本語化したものです。 DevOpsに関してはいまだに実体がなんなのかという議論がなされていますが、僕自身の現時点での解釈は、ビジネス上の意思決定から実際に顧客に届ける全体の流れの話であると考えています。すなわちいかにリードタイムを短くするかとスループットを大きくするか、ということです。(それってリーンじゃん、と言われればその通り) デプロイの回数が測定基準である、という記述も見かけますが、デプロイの回数は、あくまでバリューストリームの末端の「個別プロセス」の話でしかないので、物理的に一日に10回デプロイボタンが押せても、意思決定から価値化までの時間は長い、ということがありえます。 Build・Measure・Learnの
オープンソースのTrelloクローン Libreboard | Ryuzee.com
Trelloは、https://www.trello.com で提供されているオンラインのタスク管理サービスで、利用している人も多いと思います。僕自身も以前書いたSCRUM BOOT CAMP THE BOOKの執筆の進捗管理や、Regional Scrum Gathering Tokyoのタスク管理などで使っていました。 このTrelloのオープンソース版のクローンが登場したので紹介します。 LibreboardLibreboardは、こちらで開発が進められているオープンソースソフトウェアでMITライセンスで提供されています。2014年の頭に開発が始まり、最初の開発ペースは早くありませんでしたが、昨年末くらいから急激に開発速度が上がってきているようです。 技術的には、NodejsのフレームワークであるMeteor(メテオ)を利用しています。 Meteorの詳細については以下を参照すると良
WEB+DB PRESS Vol.83に「強いチームの作り方」という話を書いた
先週金曜日発売なので今更な告知でアレなのですが、現在発売中のWEB+DB PRESS Vol.83で、原田騎郎(@haradakiro)さんと一緒に、「強いチームの作り方」という話を書きましたので是非読んでくださいませ。 内容は以下のような感じです。 なんで強いチームが必要なのか？チームで働く理由は何なのか？強いチームの特徴とはどんなものなのか？ 強いチームの構造とはどういうものなのか？多様性とはなにか？多様性をはぐくむにはどうするか？チームの責任とは？チームの育成はどうやるか？メンバーの入れ替えはどうするのか？ファシリテーターがいるとどうなるか？ 強いチームのコミュニケーションスタイルとはどういうものか？会議やメールやチャットなどをどう使い分けるのか？組織構造とコミュニケーションは関係あるのか？ 強いチームの評価とフィードバックの仕方？どうやって対立を避けるのか？感情をどう扱うか？人にど
書評 入門Chef Solo - Infrastructure as Code
伊藤直也さんがChef Soloの本を書かれたということで早速購入してみました。最近流行りのAmazon Kindle ダイレクト・パブリッシング（KDP）を使って出版されてます。 Chefは結構巨大な仕掛けになっており、はじめて取り組む人はどこから手をつけて良いのか分かりにくかったりします。日本語のリソースは今まではSoftware Designで並河さんらが書いた特集くらいだったと思いますし、色々やろうとするとopscodeのサイトの膨大なリファレンスを読まないといけない状況でした。 この本では、Chefの基本を、Chef Soloを使ったやり方を通じて、平易な日本語で説明しており、とっかかりとして非常に良い本です。簡潔にまとまっているのでとりあえず通読するなら1時間くらいでしょう。書いてある内容は、VagrantやAWSを使えば簡単に試すことが出来ます（オンプレじゃこうはいかない）。
vagrant-lxcで軽量仮想環境を手に入れる
Vagrantは標準ではVirtualBoxを仮想環境として利用しますが、とにかく遅いのが難点です。 Test-Kitchenを使ってChefのCookbookのテストをしたり、これらを継続的インテグレーションしようとしたときにこの遅さはたまりません。いくつか手段はあってお金持ちの皆様であれば、大富豪アプローチということで、仮想マシンを動かす母艦にXeon E5-2697 v2を積んだ高性能マシンを使ったりもできるのですが、普通に考えれば、VirtualBoxよりも軽量な仮想環境を使うのが有力なアプローチです。 今回はLXCを使って軽量な仮想環境を手に入れる方法を紹介します。 LXCのインストールLXC自体の説明はこの辺とかこの辺を参照ください。 インストール対象の母艦はUbuntu 12.04 LTSです。 sudo apt-get install lxc sudoの設定変更sudoのバ
継続的インテグレーションアンチパターン
みなさんこんにちは。@ryuzeeです。 なんとなく書きためておいた継続的インテグレーションのアンチパターンをいくつか紹介します（結構ラフなメモ書き）。 頻繁にSCMにコミットしないテストコードを書かないテストコードと製品コードを同時にコミットしない定時ビルドのみでコミットビルドがない・夜間ビルドしかない帰り際にコミットしてそのままCIの結果を見ずに帰るCIでテストを通すために手作業の準備が必要メインラインのみで大きなブランチをCI対象にしていない様々な種類のテストをまとめて行っているビルドの失敗に気付かないビルドに失敗しても放置しているビルドの失敗に気づいても、修正コード以外のコードをコミットする何も変更していないのにビルドが落ちたり落ちなかったりする頻繁にビルドが失敗しているので、失敗するのが普通だと思うCIからの通知メッセージが大量すぎるCIが落ちても何も通知しないCIサーバのリソー
カンバンを導入する正しい理由5個
みなさんこんにちは。@ryuzeeです。 前回の投稿の続きです。 今度はMichael Dubakov氏が5 Right Reasons to Apply Kanbanということで、正しい導入理由5個について説明していますので、抜粋・意訳にてご紹介します。 カンバンを導入する正しい理由5個 1. いつでもリリースできるようにするスクラムやXPではイテレーションの途中でリリースすることはできない。 カンバンであればいつでもリリースできるかもしれない。 ユーザーストーリーの準備ができたたら、それをリリースする。 このような開発プロセスを作ることは挑戦的だろう。 このような開発プロセスでは、フィーチャー単位でソースコードレポジトリのブランチを管理し、頻繁にマージや結合やテストを行う必要がある。 ただこうすることで頻繁にリリースすることができるようになるのだ。 これはやってみる価値がある。 プロダ
技術的負債にどのように取り組むか
みなさんこんにちは。@ryuzeeです。 定期的にSlideshareをウロウロして良い資料がないかを探しているのですが、技術的負債に関する分かりやすい資料があったのでご紹介します。 技術的負債とは、現在の進捗のために、将来のキャパシティ(ソフトウェアの開発能力)を犠牲にすることであるもうちょっと具体的に言えば、技術的負債とは、ソフトウェアの内部的な問題（見つかっているか見つかっていないかは関係はない）、要求の明確化の欠如、ダメな設計、ビジネスの要求に適していない設計、自動化できるはずの箇所の手動処理などを指す**利子の支払いは時間のムダである。**例えば欠陥を直すのに時間を取られる、要求が明確になった後に再度作りなおす、複雑なコードを理解するために余計な時間を取られる、などなど技術的負債の悲惨なサイクルがあるテストを書く時間がない、リファクタリングする時間がない、設計レビューする時間がな
資料公開 Agile/Scrum基礎
2012年も沢山の組織や会社さんにお声がけをいただき、AgileやScrumについて基礎を習得していただくための研修を実施させていただきました。 研修用の資料は随時加筆修正しているのですが、来年からは新しいコンテンツを使う予定ですので、今年主に使っていた研修用のスライドを公開します。200ページ程ある巨大な資料で、研修では一日かけて説明している内容です（ワークショップを研修時間の半分ちかくおこなっています）。個人や組織内での学習のためにご利用ください（お約束ですが営利目的では使わないでくださいね！）。 今年研修で主にやったワークショップは、紙飛行機ゲーム、マシュマロチャレンジ、自己組織化ゲーム、マネージャー・ワーカーゲーム、ピンポン玉ゲーム、プロダクトバックログ作成、プランニングポーカー、ボールゲーム、マルチタスク適性診断あたりだったのですが、来年用には新しいネタをいくつか仕込んでいますの
【書評】手動デプロイからの卒業指南書「継続的デリバリー」
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化著者／訳者：David Farley、Jez Humble、和智 右桂、高木 正弘出版社：KADOKAWA/アスキー・メディアワークス発売日：2012-03-14大型本：544ページISBN-13：9784048707879ASIN：4048707876 レビューに参加させていただいた縁でアスキー・メディアワークス社様より献本いただきました。和智さん、高木さんの黄金コンビによる翻訳です。 デプロイ自動化に関する話を網羅的に扱った本はこれがはじめてでしょう。 上級技術者向けと書かれているように内容は結構ハイレベルで、構成管理、CI、テスト戦略についての前提知識が求められるように思いますが、アジャイルなプロジェクトの中で日々改善を繰り返している人たちにとっては理解しやすいのではないかと思います。 デプ
プレゼン用の写真をFlickrでいい感じに探す方法
みなさんこんにちは。@ryuzeeです。 僕のプレゼンでは写真を一杯使います。写真が一杯あると、記憶に残りやすく伝わりやすいというメリットがあります。 また隠れメリットとして、写真を多めにして文字を少なくすると、時間に応じて聞いている人に悟られることなく内容を調節することも可能です（僕がいつも時間通りに終えられる理由です）。 写真はFlickrで無料のものを探すのと、iStockPhotoで有料の画像を購入するのとを組み合わせていますが、今回はFlickrでいい感じに探す方法を紹介します。 なお、FlickrのWebサイトはあまり軽くない感じなので、専用のツールを使います。 何個かツールを仕込んでおくと移動中の空き時間に画像を探しておいてあとで一括でダウンロードすることも可能です。 iPadで探すFlickStackrというツールを使います。無料版もありますが、機能制限が多いので有償版を使
BehatとSeleniumを組み合わせ受け入れテストを自動化する
みなさんこんにちは。@ryuzeeです。 Behatは良さそうなので引き続き検証しています。 今回は、BehatとSeleniumを組み合わせて、受け入れテスト型のテストを自動化してみたので、その方法について説明しましょう。 なお、前回の記事を読まれていない場合はまずそちらを参照してください。 PHPでBDD(Behavior Driven Development)する方法 Seleniumの課題僕が関わっている案件では受入テストを自動化しているケースももちろんあって、その際はPHPUnitとSeleniumを組み合わせています。 このテストには以下のような課題があります。 画面の操作をするphpコードが大量にあって、ソースを見ただけでは何をしているのか分かりにくいSeleniumは操作に画面の要素名利用するため、例えばサイトのデザインを大幅に変えたりすると、テストの中身も大幅に書き換えな
テスト自動化について5分で分かるまとめ
みなさんこんにちは。@ryuzeeです。 テスト自動化について簡単に教えてほしいと言われることが多いので、以下にまとめました。 テスト自動化/テスト駆動開発についてXPのプラクティスの中で、最も単体で導入しやすいプラクティスの１つであるこのプラクティスのみで１冊の本が書けるくらい奥が深い基本的な方法失敗するテストを書くできる限り早く、テストがパスするような最小限のコード本体を書くリファクタリングをする適用範囲通常では、独立性の高いクラスやファンクションへの適用が良いGUIや分散オブジェクト、自動生成されたコード、DBのスキーマに関するテストは導入が難しい既存システムにおいて、テストが準備されていない場合に、部分的に導入するのは難易度が高い。したがって新規プロジェクトの初期から導入することが望ましい問題点開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、誤解の検知は保
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】カンバンのキホン
WEB+DB PRESS Vol.93に「実践見積り」という話を書いた