Scrum Boot Camp 横浜に参加してきた - Diary of absj31
(本編終了間際、『ふりかえり』でのKPT作成資料。※なぜ『レッドブル』が置いてあるのかは後述。) 6月18日 Scrum Boot Camp 横浜(神奈川県) Scrum(スクラム)は竹内弘高氏、野中郁二郎氏が1986年にハーバードビジネスレビュー誌にて発表した 「New New ProductDevelopment Game」を元にしてジェフ・サザーランド氏らが考案したアジャイル開発手法の１つで、 近年アジャイルな開発の手法として日本国内においても急速に採用事例が増えています。 一方でコーチや経験者の指導のないままに表面的なプラクティスを導入し、結果としてあまりうまくいかないと いうケースも良く聞くようになりました。 そこで今回はこれからScrumを導入して開発を行うことを検討されている方もしくはトレーニングを受けない (受けさせて貰えない)ままにScrumチームに参加されている方を対象
- アジャツール - Agileなツール紹介
本連載では、「アジャツール - Agileなツール紹介」と題して、筆者やその回りの人々が使っている「Agileなツール(略してアジャツール)」を独断と偏見で紹介していきます。といっても、奇をてらったツールばかりでなく、普段皆さんの机の片隅にあるようなものにも着目していきます。
スクラムにおけるイベントと出席者
みなさんこんにちは。@ryuzeeです。 スクラムにおけるイベントはスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブの4つがあります（スプリント自体もイベントですが他のイベントの入れ物なので除外しました）。 また責任としてはプロダクトオーナー、スクラムマスター、開発者、そしてそれ以外のステークホルダーに分けられます。 誰がどのイベントに出席するべきなのかについて、マトリクス化された資料が存在しなかったので、作成してみました。なお、イベントではありませんが、プロダクトバックログリファインメントを参考までに入れました 以下補足です。 プロダクトオーナーのデイリースクラムへの出席出席しません。 デイリースクラムでやるべきことは開発者がスプリントゴールを達成できそうか確認し、必要なら再計画のきっかけにすることです。 開発者がスプリントゴールの達成にリスクが
Fearless Change 第一章の非公式翻訳 - kawaguti’s diary
Agile Japan 2011 の基調講演のため、Linda Rising さんが来日予定です。基調講演は日本中のサテライト会場にも中継される予定です。 Linda さんは、企業組織の柔軟な変化について、コンサルティングやコーチングを行っています。その方法は、パターンランゲージを用いて、誰にでも実行可能な方法を記述していく、というアプローチです。コンピュータサイエンスのバックグラウンドを持ち、通信系の大企業で勤務した経歴をもっているせいか、その一人称の語り口、安易に切り捨てない包容力に驚かされます。 InfoQでのインタビュー (2008年) http://www.infoq.com/interviews/Linda-Rising-Fearless-Change "Fearless Change" という本は、彼女と、ビジネスマネジメント系のバックグラウンドを持つMary Lynn Ma
Big Joltがやってくる - Fly me to the Luna
いよいよ来週がAgile Japan 2011が開催されますね。僕はスタッフとか、実行委員とか、そういう立場の人間ではありません。ただ、今回基調講演されるお二方の一人、リンダ・ライジングさんと、その講演「Fearless Change - 不安を乗り越えて組織改革を推進するには」が楽しみでブログを書いています。 この「Fearless Change」とは、リンダ・ライジングさんとマリリン・マンスさんのお二人で書かれた書籍のタイトルでもあります。書籍では人々の集まっている場所に新しいアイディアを広めるための48のパターンと、その戦略が270ページ足らずにまとまっています。 Fearless Change: Patterns for Introducing New Ideas 作者: Mary Lynn Rising, Linda Manns出版社/メーカー: Addison-Wesley P
[Agile]Scrumで開発する際に最初にやるべきこと | Ryuzee.com
スクラムを利用してプロジェクトを進める際に、最初にやっておくべきことをまとめておく。 もちろん全プロジェクトでこれを全部やらなきゃいけないわけではない。そのあたりはコンテキスト依存ということで。 プロダクトゴールや価値の明確化 これから作るもののビジネス価値や製品ビジョンを明確にする プロダクトバックログの作成 もちろん全部が揃っている必要はないが、優先度が高いストーリーは明確に存在するはず。 バックログ項目の優先順位付け バックログ項目の見積もり バックログ項目の詳細化 個々のスプリントの開始前には優先順位の付け直しや見積もりの変更が行われるので、全てを詳細まで行ってはいけない。あくまで初期の1〜2スプリントが実施できる程度にとどめること。アップフロントでの計画を増やしすぎない。要求は必ず変化する。 おおよそのリリースプランニング ロールの明確化 プロダクトオーナーは誰？、スクラムマスタ
![[Agile]Scrumで開発する際に最初にやるべきこと | Ryuzee.com](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)
チームサイズ・スプリント期間・プロダクトバックログアイテム数について
みなさんこんにちは。@ryuzeeです。 Peter Stevens氏が行ったオンライン調査（調査母数は85）をもとにしてチームのサイズとスプリント期間とプロダクトバックログアイテムの数におけるスプリントの成功への関連について以下で述べているので、それを元に考察してみましょう。 Success Factors in a Scrum Sprint なお、ここで言っているスプリントの成功とは以下のように定義されています。 「良いチームはオーバーコミットもアンダーコミットも(あまり)しないという考えのもとに、 成功＝チームがコミットしたプロダクトバックログアイテムを全てデリバリできた、ということを指すこととする」 チームのサイズとスプリント期間2週間スプリントを採用しているチームが規模に関わらずもっとも多く、半数以上を占めています。 4週間以上という回答もあるようですが、これはスクラムとしてはい
こくちーずプロ - 無料で使えるイベント・セミナーの告知・集客サービス
個人から法人まで幅広い主催者の方にご活用いただいています。 イベント主催者7万人以上 チケット販売430万枚以上
Agile本読部 - "Fearless Change" 第一回 - kawaguti の日記 (id:wayaguchi)
本読回1日目 - Agile本読部 | Google グループ http://groups.google.co.jp/group/agilebooks-reading/browse_thread/thread/2bd338acbe1dea62 Fearless Change: Patterns for Introducing New Ideas 作者: Mary Lynn Rising, Linda Manns出版社/メーカー: Addison-Wesley Professional発売日: 2004/10/04メディア: ハードカバー購入: 11人 クリック: 114回この商品を含むブログ (16件) を見る参加できました。ありがとうございました。 途中の板書です。 ふりかえりの板書です。 こんぴろさんメモから抜粋 http://twitter.com/kompiro/ 今日は5号室でや
Martin Fowler's Bliki in Japanese - 5ポンドの鞄
http://martinfowler.com/bliki/FivePoundBag.html 10ポンドのクソを5ポンドの鞄に入れることはできない――実際にやってみた人 Kentと一緒に『XPエクストリーム・プログラミング実行計画』を書いたとき、計画がどんなものなのか端的に示すために、この一風変わった文章を引用をした。 ソフトウェア開発の大きな問題点は、限られた時間内にどれだけのことを成し遂げられるか、きちんと認識している人がほとんどいないという点である。 どれだけの量が入るか分からないまま、多くの機能を鞄に無理やり詰め込もうとしている。 すべての機能を入れたいのだろうが、たいていその鞄は小さすぎる。 Kentの計画手法が本当に素晴らしいのは、シンプルなメカニズムを使ってこのことにうまく対応している点だ。 その原則は極めてシンプルである。 プロジェクトを複数のイテレーションに区切る。 要
『アジャイル開発について、僕がしている事。』
令和からの働き方について -TownSoft- 元「傲慢SE日記」で、しばらく放置していました。 2020年からはこれからの働き方などについて書いて行こうかと思います。 アジャイル開発って、スキルではないのでどうすればアジャイル開発かと言うと定義が難しい。 強いて言うならば ・プロセスやツールより人と人同士の相互作用を重視する。 ・包括的なドキュメントより動作するソフトウェアを重視する。 ・契約上の交渉よりも顧客との協調を重視する。 ・計画に従うことよりも変化に対応することを重視する。 を守ってるものだろうか？ まぁ、まぁ、僕がやってるものもこれを守ってるからアジャイル開発と言っていいと思うが。。。 デブサミで聞いたり、どこかの教科書っぽい文献を読むとXPやらスクラムやらが主流で色々書かれてるけど・・・。 これって本当に実践できるのだろうか？ と思う。 なんていうか、アジャイルで決められた
組織パターン トップ10 - James Coplien - Digital Romanticism
この記事はJames Coplien氏の記事「Organizational Patterns: Building on the Agile Pattern Foundations」を、氏の許可を得て翻訳したものです（元の記事が長いため抄訳としています）。（原文最終更新日：2006年7月9日） 目的の統一性（"Unity of Purpose"） 顧客の参画 ("Engage Customers") ドメイン専門家という役割 （"Domain Expertise in Roles"） アーキテクトがプロダクトをコントロールする （"Architect controls Product"） 作業の均等な分配（"Distribute Work Evenly"） 関数の所有者とコンポーネントの所有者 （"Function Owner and Component Owner"） 雇われアナリスト （
アジャイルチームのアーキテクトのための10の助言
原文(投稿日：2010/09/14)へのリンク Microsoft AustraliaのソリューションアーキテクトであるTom Hollander氏は、TechEd Australiaでアジャイルチームにおけるアーキテクトの役割と題したプレゼンを行った。 氏はこの場でアジャイルチームを率いるアーキテクトとして氏が行っていることについて議論した。 アーキテクトの役割について話すとき、氏が指すのは“ソリューションアーキテクト’、つまりアプリケーションのアーキテクトだ。エンタープライズアーキテクトやある種の専門家(例えばメッセージングやインフラなどの専門家)を指してはいない。 氏のチームは、最後に2、3日のコード凍結を行う、安定した4週間のイテレーションプロセスで、毎日のスタンドアップミーティングや毎日のビルドと自動テストが伴う継続的統合を実践している。氏のチームでは次のような役割を採用している
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロダクトオーナーパターン
実践知とリーダーシップ― 知識創造理論がシステム開発に及ぼしたもの
アジャイルチームへ上手く移行するには
パタンランゲージからプロジェクトランゲージへ
パタン・ランゲージからプロジェクト・ランゲージへ Part1
リーンやアジャイルの契約書の書き方
アジャイル/スクラムの振り返り - ヒントと秘訣
