スプリントの期間を長くしたいと思ったら...
みなさんこんにちは。@ryuzeeです。 元記事はLichard Lawrence氏のWhy Longer Sprints Probably Won’t Helpです。 良記事でしたので抜粋・意訳にてご紹介します。 本文に入る前に若干前提事項を補足しておきます。 以下で言っている「スプリント期間を伸ばす」というのは、あるスプリントだけの期間を伸ばすのではなく、スプリントのサイズ自体を変えることです（例：2週間スプリント→4週間スプリント）タイムボックスであることに意味があるので、ご存知の通り「あと1日あれば終わる」とか言ってスプリント期間を延長することは許されませんそしてスプリントの期間は原則固定なので、今回は2週間、次回は4週間、その次は1週間、というのも無しです。ただし変化への対応はもちろん大事。今回はその点に関するお話です コーチとしてよく、「スプリント期間が短すぎるので、XからYに
ストーリーベースのアジャイル開発に。Railsのプロジェクト管理·Fulcrum MOONGIFT
Fulcrumはストーリーベースのアジャイル開発にマッチしたプロジェクト管理システム。 FulcrumはRuby on Rails製のオープンソース・ソフトウェア。アジャイル開発において用いられるユーザストーリー。利点としては機能をユーザ視点で捉えることで、実装されるべき機能が明確になりイテレーションが終わった段階できちんとできているか確認がしやすいことだ。 4つの枠が特徴 そのため通常のタスク管理に比べると大ざっぱに見えてしまい、逆に細かな進捗が見づらくなってしまう場合もあるようだ。そんな状態を解決するには、最適なプロジェクト管理を導入することにあるだろう。今回紹介するのはFulcrumだ。 Fulcrumはストーリーベースのタスク管理を実現する、アジャイル開発向けのプロジェクト管理だ。完了したストーリー、作業上、バックログ、Chilly Bin（終わらなかったタスクを放り込んでおく場所
アジャイル開発でツールを導入する5つのステップ
みなさんこんにちは。@ryuzeeです。 アジャイルな開発で利用できるツールはたくさんありますが、その導入の仕方について賛同できる記事があったので意訳にてご紹介します。 なおターゲットのチームはco-locateしたチームです。 元記事はMarc Löffler氏の5 Steps to Introduce an Agile Toolになります。 世の中にはかなりたくさんのアジャイル開発用のツールが出回っている。マイク・コーン氏のWebサイトにそれらのツールの長〜いリストがあるので見てみると良いだろう。しかし、こういうツールを自分のチームや会社に導入するには、どういう方法を取れば良いのだろうか？以下にまとめてみた。 1. 最初はツールなしで始めるツールを持ったバカはやっぱりバカだｗ。とても洗練されているアジャイル用のツールを導入する前に、まずScrumやXPやKanbanやその他のメソッドが
アジャイル動物園 - 豚と鶏と他の動物たち
みなさんこんにちは。@ryuzeeです。 アジャイルなプロジェクトに関係する人を比喩する方法としては、豚と鶏の話が有名ですが、拡張バージョンとして、さらに多数の動物が出てくるアジャイル動物園の話をご紹介します。 原文はAgile Animal Farm - Pigs, Chickens, and moreです。 昔むかし、鶏と豚が田舎道を歩いていました。鶏は豚の方に振り返ってこう言いました。 「すごいアイディアがあるんだ！Ham-n-Eggsっていう朝食のレストランを始めようよ！」 豚はしばし考えて言いました。 「いや、やめとくよ。君は単に卵を提供するだけで、僕のベーコンを焼いている間に、その気になればどこかに行ってしまうことができちゃうじゃん」 このアジャイル界隈でいまだ使われている例示はアジャイルチームに本当にコミットしている人なのかどうかの区別をつけることについての理解を助けてくれる
アジャイルサムライ読書会(湯島道場) 第四回 風の巻に参加してきた #agilesamurai #湯島道場 - Diary of absj31
アジャイルサムライ読書会（湯島道場） 第四回 風の巻 #agilesamurai : ATND (写真：上野公園 西郷隆盛像。まぁ風貌・雰囲気的に『サムライ』と当たらずともという感じで…) 前回第3回から夏休み期間を挟んで2週間ぶりに開催された第4回。会場はこれまで同様株式会社アルティネット様会議室。今回は私自身夏休み期間中だったこともあり、昼間辺りから湯島・上野辺りを徘徊しつつの夜に湯島道場参戦！という形でした。 アジャイルサムライ−達人開発者への道− 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未出版社/メーカー: オーム社発売日: 2011/07/16メディア: 単行本（ソフトカバー）購入: 42人 クリック: 1,991回この商品を含むブログ (257件) を見るThe Agile Samurai: How Agile Masters Del
10年たった今見えてきたアジャイルに関する8つの問題提起
Agile 2011 Conferenceに行ってきました。 たくさんのセッションに参加してきたのですが、その中でもカンファレンス二日目に参加した、Chet Hendrickson氏とRon Jeffries氏の「What We Have Learned So Far: what we got right & what we got wrong」が面白かったので、ここでまとめたいと思います。 内容はタイトルにあるように、「この10年で何を学び何を得たのか？そして何が正しくて、何が間違っていたのか？」というもの。アジャイルに関するたくさんのプラクティスやアイデアを共有してきた、Chet氏とRon氏が提起するアジャイルの注意点を確認してみましょう。 アジャイルはしばしば独断主義としてとらえられてしまいます。常に改善を求められる雰囲気や、現実的なマネジメントの影響で「隠し事」が難しくなり、恐怖を
アジャイルアーキテクチャの相互作用
図 1. アジャイルのアーキテクチャに関する作業のハイブリッドなフレームワーク。プロジェクトにアーキテクトを巻き込むことは、プロジェクトの目的を達成する手助けとなります。テーブル1では、さらに相互作用ポイント(緑)、重要な技術(金)、アーキテクチャ機能(紫)というフレームワークの要素を説明しています。 テーブル 1 は、図1の要素を簡単に説明しています。このリストは網羅的ではありませんが、アーキテクチャ機能は、アーキテクトが通常プロジェクトで実行するものです。 テーブル 2は、交差している点においてアーキテクトの主な関心や相互作用点とアーキテクチャ機能がどのように交わるのかを示します。まとめて言うと、3つのカテゴリと4つの項目によって、他の優先順位や選択肢に基づいてカテゴリや項目を追加することで、アジャイルアーキテクチャを拡張できることを理解し、指導するのに役立つフレームワークが作り出され
アジャイルの人たちは自分の優秀さに気づいていない - 設計者の発言
アジャイル手法を実践できるプロジェクトは恵まれている。それは、「理解ある管理者」がアジャイル手法を了承してくれたからではない。管理者がそう判断できるほどに参加メンバーが優秀だからだ。 アジャイルの特徴のひとつが「少数精鋭」である。いっぽう、アジャイルの対立手法として理解されているウォーターフォール型手法では「人海戦術」で進められる点が対照的だ。じつは「少数精鋭」というのはアジャイルの特徴であるだけでなく、あまり触れられたくない弱点でもある。なにしろ「精鋭」しか関われない。 しかしアジャイル手法の推進者は、自分が優秀であることをそれほど意識していない。それどころか彼らは「いえいえ精鋭である必要はありません。じっさい私はアジャイルが大好きですが、凡庸な技術者ですよ」と自嘲的に語るだろう。そしてそれは本心でもあるだろう。なぜなら、彼らは「超」がつくほど優秀な技術者たちがいることをアジャイルコミュ
アジャイル開発とは：「アジャイル開発」をエグゼクティブサマリにまとめてみた | Social Change!
アジャイル開発を開発者以外にも２ページ程度のサマリで説明するというのに挑戦してみました。なるべくアジャイル開発の文脈で使われる言葉（適応型とか）を使わないようにしてみたのと、従事する人でなく決定権を持つ人向けに中身よりも得られる価値などを中心に記述しました。（記事の最後でPDFを皆さんの会社でも使えるようクリエイティブコモンズで公開してます。） アジャイル開発に関するサマリ アジャイル開発（アジャイルソフトウェア開発）とは、ソフトウェア開発における開発手法の総称です。その特徴は、日々変化するビジネスや市場環境に応じて、作るべきソフトウェアも変化させていくことが出来る点です。 アジャイル開発におけるゴールと狙いは、IT投資に対するソフトウェアから得られる価値を最大化することです。コストパフォーマンスの最大化であり、ただソフトウェアを作ることだけが目的ではありません。 １．誕生の経緯と求められ
パブリックなメモ : 『アジャイルサムライ』を読んだ
2011年08月14日06:25 カテゴリ 『アジャイルサムライ』を読んだ アジャイル開発について書かれた『アジャイルサムライ』って本を読んだ。 アジャイル開発？何それおいしいの？なエンジニアが読んでなんとなくわかった感じになるすばらしい本だ。 はい、自分のことです。 ということでどんな風にわかった感じになったか少し書く。 この本を読んだ感想を一言で言うと 「顧客に無理と言うための信頼を積み上げる方法」 でした。 いわゆる、ウォーターフォール的なこれまでの開発手法を同じような言葉にすると 「顧客がやれと言ったことをやる方法」 だと思います。 ウォーターフォールだと最初にやることを全て決めて、後は全力でそれを実現する。 しかし、最初にやると決めたことは大抵、無理がある。ってみんな言ってる。 原因はやりたいことが多すぎて実現出来ることが乖離している、とか、下請けは出来ないことを出来ると言わない
アジャイル宣言の葛藤
アジャイル宣言の話の続きです。「アジャイル宣言の背後にある原則」の何が自分の心の中で消化できていない部分を書きます。 以下、ソフトウェア開発者を一般化したように書きますが、言うまでもなく世の中には多様な開発者がいます。簡単に一般化できるものではないことは理解しています。ただ、ある一定の傾向があると思っているだけです。いちいち例外もあります、とは断りませんが、例外があるのは当然です。 さて、ある種の人たちには、開発者は顧客視点が欠けている、という題目が信じられています。 これは必ずしも真実とは異なります。 ソフトウェア開発の過程で技術的好奇心が顧客視点を上回る場面があるのは否定しません。使う人の気持ちより作る楽しさに目を奪われることがあるのも否定しません。しかし純粋に技術的好奇心だけで開発が終始するプロジェクトは、ソフトウェア開発としては稀です。利用者がいる前提で作るソフトウェアで、使う人の
Martin Fowler's Bliki in Japanese - フィーチャーブランチ
@@ -1,25 +1,29 @@ http://martinfowler.com/bliki/FeatureBranch.html -gitやMercurialの様な分散バージョン管理システム(DVCS)の台頭と共に私はブランチとマージ、どの様に継続的インテグレーション(CI)に適合に向けての戦略に関して、より多くの会話を見てきた。ここ、特にフューチャーブランチのプラクティスとどの様にCIに適合させるかに関して、少し戸惑いがある。 +gitやMercurialの様な分散バージョン管理システム(DVCS)の台頭と共に私はブランチとマージ、どの様に継続的インテグレーション(CI)に適合に向けての戦略に関して、より多くの会話を見てきた。ここ、特にフィーチャーブランチのプラクティスとどの様にCIに適合させるかに関して、少し戸惑いがある。 -シンプルな(分離した)フューチャーブランチ +
XP | astah publish - Beta
Delete Confirmation Are you sure want to delete this account? Deleting this account will remove all of the account's assignments.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
インドアジャイル西遊記 | オブジェクトの広場
失敗を学びに変えるアジャイルなマインドセットとは？～Agile 2011 Conference
Readingagilesamuraicalendar
恐怖の中でのアジャイルの導入
Y.M | 株式会社ラグザイア
2000人のアジャイル実践者が集うカンファレンス～Agile 2011 Conference
Ken Schwaber氏とJeff Sutherland氏、スクラムガイド改訂版をリリース
