カンバンを導入する正しい理由5個
みなさんこんにちは。@ryuzeeです。 前回の投稿の続きです。 今度はMichael Dubakov氏が5 Right Reasons to Apply Kanbanということで、正しい導入理由5個について説明していますので、抜粋・意訳にてご紹介します。 カンバンを導入する正しい理由5個 1. いつでもリリースできるようにするスクラムやXPではイテレーションの途中でリリースすることはできない。 カンバンであればいつでもリリースできるかもしれない。 ユーザーストーリーの準備ができたたら、それをリリースする。 このような開発プロセスを作ることは挑戦的だろう。 このような開発プロセスでは、フィーチャー単位でソースコードレポジトリのブランチを管理し、頻繁にマージや結合やテストを行う必要がある。 ただこうすることで頻繁にリリースすることができるようになるのだ。 これはやってみる価値がある。 プロダ
資料公開 Agile/Scrum基礎
2012年も沢山の組織や会社さんにお声がけをいただき、AgileやScrumについて基礎を習得していただくための研修を実施させていただきました。 研修用の資料は随時加筆修正しているのですが、来年からは新しいコンテンツを使う予定ですので、今年主に使っていた研修用のスライドを公開します。200ページ程ある巨大な資料で、研修では一日かけて説明している内容です（ワークショップを研修時間の半分ちかくおこなっています）。個人や組織内での学習のためにご利用ください（お約束ですが営利目的では使わないでくださいね！）。 今年研修で主にやったワークショップは、紙飛行機ゲーム、マシュマロチャレンジ、自己組織化ゲーム、マネージャー・ワーカーゲーム、ピンポン玉ゲーム、プロダクトバックログ作成、プランニングポーカー、ボールゲーム、マルチタスク適性診断あたりだったのですが、来年用には新しいネタをいくつか仕込んでいますの
【書評】手動デプロイからの卒業指南書「継続的デリバリー」
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化著者／訳者：David Farley、Jez Humble、和智 右桂、高木 正弘出版社：KADOKAWA/アスキー・メディアワークス発売日：2012-03-14大型本：544ページISBN-13：9784048707879ASIN：4048707876 レビューに参加させていただいた縁でアスキー・メディアワークス社様より献本いただきました。和智さん、高木さんの黄金コンビによる翻訳です。 デプロイ自動化に関する話を網羅的に扱った本はこれがはじめてでしょう。 上級技術者向けと書かれているように内容は結構ハイレベルで、構成管理、CI、テスト戦略についての前提知識が求められるように思いますが、アジャイルなプロジェクトの中で日々改善を繰り返している人たちにとっては理解しやすいのではないかと思います。 デプ
楽天がアジャイル開発を全社へ展開
楽天は2013年中に、ソフト開発を短期間で繰り返す「アジャイル開発手法」に基づいて楽天グループ共通のシステム開発体制を整備する（図）。同手法に基づく開発プロジェクトを担う人材育成に向け、楽天はNTTデータと“異業種タッグ”を組む。 楽天は、急な仕様変更や機能追加に対応しやすいといったアジャイル開発の利点を生かして、「楽天市場」など自社サービスのグローバル対応を一気に進める。 すでに海外グループ企業の一部がアジャイル手法を先行導入しているほか、日本でも楽天市場の開発チームが2010年ごろから段階的に導入。豪アトラシアンのプロジェクト管理ソフト「JIRA」などを使った開発環境の整備やエンジニア向けの研修を進めてきた。 アジャイル手法の全面採用で、グループ全体で3000人規模のエンジニアが開発リソースやノウハウを共有しやすくなる。「海外のノウハウを日本に取り入れたり、海外プロジェクトを日本のエン
テスト自動化について5分で分かるまとめ
みなさんこんにちは。@ryuzeeです。 テスト自動化について簡単に教えてほしいと言われることが多いので、以下にまとめました。 テスト自動化/テスト駆動開発についてXPのプラクティスの中で、最も単体で導入しやすいプラクティスの１つであるこのプラクティスのみで１冊の本が書けるくらい奥が深い基本的な方法失敗するテストを書くできる限り早く、テストがパスするような最小限のコード本体を書くリファクタリングをする適用範囲通常では、独立性の高いクラスやファンクションへの適用が良いGUIや分散オブジェクト、自動生成されたコード、DBのスキーマに関するテストは導入が難しい既存システムにおいて、テストが準備されていない場合に、部分的に導入するのは難易度が高い。したがって新規プロジェクトの初期から導入することが望ましい問題点開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、誤解の検知は保
【資料公開】Doneの定義 虎の巻
みなさんこんにちは。@ryuzeeです。 この年の瀬にスクラム道.08を開催しました。今回のテーマはDone(完了)の定義です。以下に資料を公開します。 なお、議論を誘発するために、あえて細かいことを書きすぎないようにしていたりしますのでそのあたりはご了承ください。 スクラムでは、完成の定義は必須です。これがないとどこまで作業をして良いか分からないし、完成の定義を見ることでチームの成熟度を把握することもできます。 いつもの通り感想などを。 今回はいつもの永和システムマネジメントさんではなく、KDDI Webコミュニケーションズさんに会場をお借りしましたが、綺麗で広くて良かったです。スクラム道のWebサーバについてもご提供頂いておりありがたい限りです最近Scrum Boot Campばっかりだった気がして、久々に道場だったのでやり方を忘れてた（汗完成の定義は書籍には、それを作れ、としか載って
深夜のScrum談義・その2
HiroyukiWada @libaty いろんなものやことを犠牲にして無理やりバーンダウンを落とすお仕事。たぶん次は今回の1.5倍以上落とせってなるはず。はてさてどうしたものか。 2012-07-04 22:41:37 Ryutaro YOSHIBA @ryuzee その圧力からチームを守るのがスクラムマスターの仕事ですよ RT @libaty: いろんなものやことを犠牲にして無理やりバーンダウンを落とすお仕事。たぶん次は今回の1.5倍以上落とせってなるはず。はてさてどうしたものか。 2012-07-04 22:44:41 HiroyukiWada @libaty スクラムマスターも交代になりました。今までのSMは開発チームと掛け持ちだったので、新しく１人立てて今までのSMは開発チーム専属になれそうです。なので圧力への壁は今までより高くなるやも。 QT @ryuzee: その圧力からチー
スクラムを失敗させる方法
1. ふりかえり（レトロスペクティブ）をしないか、間違ったふりかえりをするふりかえりをせずして、どうやって物事をよりうまくできるようにすることができるというのだろうか？ ふりかえりは、全てのチームメンバーがうまく行ったこと、もっとうまくできるだろうことについて議論できるという点で必要不可欠だ。 そしてもちろん言うまでもなく、失敗から学習しなければならない。もしそういったことが行われていない（形式的なふりかえり）なら、ふりかえりは役に立っていない。 2. ダメなプロダクトオーナープロダクトオーナーはいつでもプロジェクトのために時間を使えるようでなくてはならない。 プロダクトオーナーはスプリントプランニングやふりかえりに参加しなければならない。 また一方でプロダクトオーナーはスプリント中のタスクは見積りしてはならない。見積りはチームの責任なのだ。 プロダクトオーナーはビジネス上の優先順位に基づ
The GitHub poweredby Agile渋谷で発表してきました - kunitooの日記
2012/06/23にThe GitHub poweredby Agile渋谷 にいってきました。 仕事でGitHubを使っているので、まだお仕事で使っていない方の参考になればと思い「とあるプロジェクトのGitHub」というタイトルで発表してきました。 (うまくslideshareを貼れなかったのでリンクだけです) View more presentations from kunitoo 補足 以下資料の補足です。 プロジェクトで元々社内のgitリポジトリを使用してGitHubに移行しました Pull Requestをした人がレビュー完了後Merge Pull Requestを行うというルールにしています 参加した感想 大場さんのGitHub::Enterpriseの話を聞いて思ったのは社内にGitHubの世界が広がっているという感じがすごいなって思いました。何百、何千人もいる会社ではGi
全員スクラムマスター に参加してきました。 #devlove0521 - Change The Worlds
こくちーず 5月21日 全員スクラムマスター。(東京都) Togetter 2012/05/21 全員スクラムマスター。まとめ - Togetter 先月5/21(月)は株式会社エムティーアイを会場に開催された『全員スクラムマスター。』に参加してきました。 勉強会の参加者は全員自称を含めてスクラムマスターというもので、内容もスクラム道と同じ様に30分程度発表者がそれぞれ発表し、その発表のテーマに関して、ディスカッションするという形式でした。 オープニング会場を提供して頂いた株式会社エムティーアイからご挨拶です。 スクラムマスター同士で抱えてる問題・悩みについて、ディスカッションしましょうといった本会の主旨の説明がなされました。 続いて、株式会社エムティーアイのCTOである古賀氏よりご挨拶です。 今後も会場提供に協力したい旨と株式会社エムティーアイに興味がわいたら是非一緒に働きましょうといっ
アジャイル開発にハイスキルが必要という誤解について - うさぎ組
これの続きです。 →「アジャイル開発とはなにか - うさぎ組」 ある方とアジャイルについて話していてなぜその方がアジャイルは難しいと言っているのかようやく説明できるようになったのがなんとなく成長したなぁと感じました。 その方はXPやScrumといったプロセスやフレームワークをアジャイルだと見なしていて、それらを実践するのは難しいというのです。 例えば、XPには設計が極端に少なく多くのエンジニアには難しい、大きい設計をしたらXPではないというのです。そしてそれはアジャイルではない。と。 僕はアジャイルというのはもっと根源的なものであって、アジリティにソフトウェアを開発しようとする状態や手法だと思います。 前のブログからの引用になりますが、 ======================== アジャイル開発は何かに対する答えを持っているんじゃなくって、自分達の最適解を探すためのアジリティなメンタ
アジャイル動物園 - 豚と鶏と他の動物たち
みなさんこんにちは。@ryuzeeです。 アジャイルなプロジェクトに関係する人を比喩する方法としては、豚と鶏の話が有名ですが、拡張バージョンとして、さらに多数の動物が出てくるアジャイル動物園の話をご紹介します。 原文はAgile Animal Farm - Pigs, Chickens, and moreです。 昔むかし、鶏と豚が田舎道を歩いていました。鶏は豚の方に振り返ってこう言いました。 「すごいアイディアがあるんだ！Ham-n-Eggsっていう朝食のレストランを始めようよ！」 豚はしばし考えて言いました。 「いや、やめとくよ。君は単に卵を提供するだけで、僕のベーコンを焼いている間に、その気になればどこかに行ってしまうことができちゃうじゃん」 このアジャイル界隈でいまだ使われている例示はアジャイルチームに本当にコミットしている人なのかどうかの区別をつけることについての理解を助けてくれる
kanon
Kanon LABへようこそ Kanonはあなたのプロジェクトの物語を作るツールです。このチケットシステムは、Kanon自身によりセルフホスティングされています。 ※スパム対策のために認証ユーザにのみチケットの作成と更新を許可しています。アカウントを作成するには、上記のRegisterからアカウント作成を行ってください。 ソースコード 下記のリポジトリでソースコードは取得できます。 KanonProject(OpenProj clone): http://github.com/okamototk/KanonProject Kanon Conductor(Trac/Hg/SVN/Git/Jenkins installer): https://bitbucket.org/okamototk/kanonconductor Kanon Naiagara、Kanon Allegroは、Kanon
「アジャイル開発」で解決できることは何か〜アジャイルは「速い・安い」のファストフードではない | Social Change!
ここ最近の「アジャイル」という言葉の使われ方に違和感を感じています。 年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。 そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。 大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。 アジャイル検定の本格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立 近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手
リリースプランニングの10個のTips
みなさんこんにちは。@ryuzeeです。 Release planning 10 Tipsを抜粋・意訳にてご紹介します。 スクラムにおいては、プロダクトバックログの重要性が極めて高いので、それをどうやってメンテナンスしていくか、という点について参考になると思います。 以前、コーチで行ってた現場で、「プロダクトバックログを最初に抽出して固定して一括請負契約できますか？」という質問を受けたことがありますが、アジャイルにおいては要件は可変パラメータなので、プロダクトバックログの固定自体はあり得ません。 プロダクトバックログは常時変化していることを認識することプロダクトプロダクトバックログアイテムの優先順位を継続的に付け直すこと次のスプリントのためのプロダクトバックログアイテムを継続的に準備することプロダクトバックログアイテムの個数は60〜70項目までにすることプロダクトオーナーは開発チームと一緒
一瞬でなまけ癖をなくす方法。:United Flowers Diary
2012年05月03日 一瞬でなまけ癖をなくす方法。 なまけ癖をなくす方法を、研究している人たちがいます。 素晴らしいですね（笑） そんな素晴らしい人たちが、インディアナ大学のスティーブン・シャーマン教授たちです。 彼らは、ある驚くべき仮説をうちたてます。 「人がなまけるのは、やるべき作業を、抽象的に理解しているからじゃないか？」 ・・・エラい学者さんの考えることは、意味不明ですね（笑） 具体的に考えてみましょう。 たとえば「英語の勉強」という作業は、人によって抽象的にも具体的にも解釈されます。 抽象的な解釈をする人： 「家に帰ったら、英語の勉強をしよう！」 具体的な解釈をする人： 「今日は、英単語を勉強しよう。家に帰ったら、すぐに机に向かい、単語帳の見開き2ページに載っている、30個の単語を覚えよう。そうだな、制限時間は20分。がんばるぞ！」 みなさん既にご察しか
組織に継続的インテグレーションを導入していく7つの段階
みなさんこんにちは。@ryuzeeです。 継続的インテグレーションの導入に関する分かりやすい記事があったので抜粋・意訳にてご紹介します。 原文はJohn Ferguson Smart氏のブログ記事「The Seven Phases of Introducing Continuous Integration into Your Organization」です。 継続的インテグレーションは全部かゼロかといった類のものではない。事実、CIの組織への導入はいくつかの明確な段階を経て進んでいくのだ。それぞれの段階は技術的な構造もそうだが、それ以上に重要であるであろう開発チーム自体のプラクティスや文化のインクリメンタルな改善を含んでいる。 以下の章では各段階についておおよその全体像を示すことにしよう。 第1段階 ビルドサーバがない初期の段階ではチームはなんらの中央ビルドサーバも持ちあわせていない。ソフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Microsoft – 長沢智治のブログ
History of WaterFall
GitHub - agile-samurai-ja/support: 『アジャイルサムライ』のサポートページです
