アジャイル,Trac,オープンソースなどの話。認定スクラムマスター。Twitterは@ryuzee
自分にプレッシャーをかけるために予告してみる(w
3/19にマイクロソフトさんで、Agile Day2というイベントが開催されます。前回1月にマイクロソフトさんの日本法人としては初のAgile関連セミナーであるAgile Dayが開催されましたが、今回はその第2回目のイベントになります。
僕は第1回はLTでしゃべりましたが、今回は1セッションいただいて、「Agileな開発プロセスを導入する前に考えなければならないこと」(仮)というテーマでお話する予定です。
内容は、若干バズワード化しつつある「Agile」の導入について、導入を考えている、なんとなく興味がある、という人たちに、事前に考えるべきポイントの概要をお伝えすることです。答えは現場や環境によって様々だと思うので、あくまで考える軸を提供したいなーと思っています。
このイベントでは、その他に、マイクロソフト長沢さんによるマイクロソフトでのアジャイルへの取り組み、IBMのエバンジェリスト玉川さんによる大規模アジャイルの話、すくすくスクラムの今村さんによるScrumを体験してみるワークショップが実施される予定です。申し込みはマイクロソフトさんのサイトから。
以下ちらみせ興行(作成中ですので実際には出てこないかもしれませんw)

よし、プレッシャーかかってきたw
先日のオープンソースカンファレンスなどでも紹介しているAgiloについて、現在i18n対応を実施中。もうソースの修正は終わっていて鋭意テスト中です。
もともとの経緯は、
・日本語化対応した際に、Agiloを作っているドイツのAgile42社に、日本語版作ったよー、ってメールしたら
・じゃあ国際化担当よろぴこ、って言われたw
・別のユーザーさんから俺スペイン語対応するから、早めに頼むわ、って言われたw
って感じ。
現在Shibuya.tracで公開しているバージョンは、Tracが持つtranslation機構を使いつつ、他の言語を使うことは想定しないでカスタマイズしていたので、現在は、どんな言語でも簡単に対応できるように、日本語化部分の整理や言語処理の分岐などを追加中。これが終われば現在Shibuya.tracのSourceforgeにアップしている日本語オリジナル版の役割は終了する予定。
なお、現在本家で公開されているAgiloの最新のバージョンではバックログ画面のUIが新たに1つ追加になっている。新たな画面ではAjaxを使ってサーバサイドからJSONのデータを取得して画面に描画するようになっており、将来的にはFlashを使ったUIなどを考えているのではないかと思われます。

また、まだ紹介していなかったけど、Agiloでは各種バックログの一覧画面から直接項目が編集できます。スプリント計画ミーティングの際の、対象ストーリーの選択や見積もり、残作業時間の更新に非常に便利。

一覧画面での一括編集は、管理画面のバックログ項目を選択して行うことができる。下記の画面で、編集可能にチェックがついているものは一覧画面で編集できるし、また一覧に表示する項目も自由に設定可能。

ということでもう少々お待ちください。
78 Things I Have Learned in 6 Years of Agile Coachingの78個を適当翻訳。
「私が6年間のアジャイルコーチングで学んだこと」というテーマでアジャイルに関する経験談がまとめられている。
ということで、2/26に明星大学で行われたオープンソースカンファレンスでTracを使ったアジャイルな開発プロジェクトの可視化について話をしてきましたので資料を公開します。
ご不明な点等ありましたらコメントいただければと思います。
また発表の際は、会場が完全に満席になるくらいお越しいただいてありがとうございました。
マイク・コーン氏のブログ記事のSeparate Estimating from Committingより適当訳。
多くの組織における根本的かつ共通の問題は、見積もりとコミットメント(約束)が同一のものとして扱われていることである。
ある開発チーム(アジャイルか否かに関係なく)は、顧客が望むもの一式を納品するのに、利用可能なリソースを踏まえて7か月かかるだろうと見積もりした。チームメンバーはこの見積もりをマネージャに提出したが、マネージャは見積もりを部長に、部長は顧客に知らせてしまった。そして、いくつかのケースにおいては、その見積もりが、チームの「伸縮可能なゴール」を奪ってしまうことになる。ここでの問題は、チームの7か月という見積もりが合っているか間違っているか、ではない。問題は見積もりがコミットメント(約束)に変化してしまったことだ。「我々は7か月かかると見積もりました」という言葉は「我々は7か月以内に終わらせます」という言葉に(誤って)変換されてしまう。見積もりもコミットメントも重要だけれども、それらは別々のアクティビティとして見られるべきなのだ。
私は今晩、娘の水泳に迎えに行く必要があった。私は娘に何時に終わる(我々は泳いで、シャワーを浴びて、家に帰る準備が出来た、というのを終わりと定義している)のか尋ねた。
彼女は言った。「たぶん5:15には準備できる」これは彼女の見積もりだ。もし私が確実に約束(決めた時間に外で待っててよ。じゃないとそのまま帰っちゃうよ、なんて場合)できる時間を尋ねていたら、彼女は練習が長引いたとかコーチの時計が5分遅れていたとか、シャワーが行列していたとかいうような問題が発生した場合の対応を含めて、たぶん5:25と答えただろう。
約束できる時間をきめるために、娘は見積もりをした。でも彼女は見積もりの時間をそのまま伝えるのではなく、約束できるデットラインに変換するべきだったのだ。見積もりをコミットメント(約束)にしてはいけない。見積もりとコミットメントの違いについて覚えておき、2つのアクティビティは分離し、必要に応じてマネージャや顧客を教育しよう。
私は「Succeeding with Agile」という私の新しい本で見積もりとコミットメントについてより詳細に説明している。
スケジュールの話だけじゃなくて、コストの話も同じだね。
上の話はアジャイルだろうがウォーターフォールだろうが関係なく気にしておく必要がある。
社内のちょっとした見積もり依頼が、気が付いたらそのままの数値で顧客に出ていた、とかは良くある話。
間違った約束や契約は、チームも顧客も会社も不幸にする。
ということで、2/26および27にオープンソースカンファレンス2010春が開催されますが、Shibuya.tracのセッションでちょっと時間をもらって、Tracを使ってAgileプロジェクト(Scrum)を実施する方法について話す予定です。
2010-02-26 (金) プロジェクト管理Webアプリ「Trac」をより便利に使う方法、教えます 14:00~14:45
以下内容のちらみせ。
Agiloの日本語化をした自分自身が、ドッグフーディングで自分が関わるプロジェクトで実際に利用していますので、そこで得られた知見も含めてお伝えしたいと思っています。

時間がある方は是非お越しください。
Scrumのアンチパターンや間違ったScrumについて書かれたスライド。耳が痛いところもあったりする。
一例をあげると
スライドの最後の方に書かれていた言葉は素晴らしい言葉なので紹介。
「あなたがアジャイルをやっていて楽しくないのなら、それは正しいやり方でやっていないからだ!」
Retrospectives | 7 Secrets of my Retrospectivesより。
僕が良く言うのは、スプリントの結果はチームとしての結果なのだから、特定個人の問題を追及し(すぎ)ないこと。
チームとしての問題を個人の問題に付け替えてしまうと、個人は問題の隠蔽を始めてしまうケースがある。Agileの基本理念の1つに「オープンであること」があるが、それがなくなると、チームとしての力が結集できなくなる。
また振り返りのファシリテーター役は、チームを非難しないことも大事だ。チームとしての結果はスクラムマスターが責任を持てば良く、そこでスクラムマスターがチームを非難してしまうのは、自分が問題や妨害の解決、ファシリテートが出来ていなかったということだ。
アジャイルって受託開発との相性が最悪な気がするより。釣りっぽい記事な気もするんだけど。
工程の分断が絶対許されないから、上流工程と下流工程を別会社が担当する今の日本の受託開発業との相性は最悪だね。自分たちで全部やれる人材が揃ってないといけない上に、コミュニケーションを綿密にとらないと成果物がグダグダになりそうだから、人月との相性も悪い。
要件まとめてぽーんと丸投げしたほうがSIerとしては美味しいわけだから、なんでこんな苦労を別にしなくちゃならないの的な話になってる所がいっぱいいそうなんだけど、どうだろう。アジャイル導入って自己否定なんじゃないのかしら。だからやりたくても出来ないんだね、これ。
今の日本のSIerのモデルは”まだ”建設業みたいな多重階層の構造であることは間違いない。
収益性については、一次受けのSIerは少ない要員で沢山のプロジェクトを外注使って回すことでレバレッジかけて、一人あたりの売上と利益を高くしている。
でも、もう気付いている会社も沢山あるんだろうけど、このビジネスモデルって、名前で仕事が取れる時にしか有効じゃないんだよね。
大手のSIerに発注した際によくあるのが、打ち合わせに一次請けの社員は1人くらいしか来なくて、残りは全部外注がやっているパターン。お客さんからすれば、マージン一杯抜かれて高い金払うくらいなら外注さんと直接契約した方が安くて良いよね。
残念ながらレバレッジかけまくってる会社からは技術力はどんどん無くなっていって、そのうち見捨てられてしまうんじゃないの?
そう考えると、分業のモデルは、工程ごとの分業ではなくて、チームの中に何人外注さんを混ぜるか?って方向が正しいのだと思う。
自社の要員で全部開発できるけれども、平均単価を下げるために外注さんを混ぜるのと、開発できないので外注さんに任せるのでは、自社の経営におけるリスク度合いが全く違うよね?
アジャイルが上述のやり方だと仮定すると、僕が顧客側にいたらこういう質問をすると思う。
* 最終的なリリース日はいつになるの?
o 意思決定を延ばすってどういうことなの?
o ウチはこの予算でいつまでにやって欲しいんだけど、それ守れるの?
* イテレーションって毎回納期もスケジュールも違うの?
o そのやり方でウチにメリットあるの?上に説明しにくいよそれ。
* ある機能の開発中、別の機能に要件漏れがあったらどうなるの?
o Aという機能を要件→テストまで回してOKだとする。
o でもBという機能の実装中にAの変更が必要なのが発覚した。
o これどうすんの?手戻りして直してくれるの?
若干アジャイルに関して誤解があるような気がする。
アジャイルだからリリース日を決めない、ってことは無い。
Scrumであればスプリント毎にレビューして、場合によっては本番にリリースするし、XPだって数イテレーションごとにリリースする。
XPなんかは最初にリリース計画もするし。
意思決定を延ばすのは、実装する機能の優先度に関わっていて、重要なものから意思決定していけば良いということ。逆にあってもなくても良い機能を今意思決定しても仕方ない。ビジネス上の価値の実現がシステム構築の目的だから、その価値の実現に大きく寄与するものについては、ギリギリまで判断を待ちたいと思うよね。
あと、イテレーションやスプリントと呼ばれる時間は、原則として一度プロジェクトを始めたら固定にするので、今回のスプリントは2週間だけど、次は1か月ということは無い。よく「でもこの機能の開発はスプリントに収まらないし?」とか聞かれることがあるが、そういう場合はストーリーの分割をすれば良い。大きすぎる項目は見積れていないのと同じだし。
手戻りについては、そもそもアジャイルって変化が起こることを想定しているので、機能や要件の漏れがあれば、重要度と照らし合わせて次のスプリントで実施するだけだ。
そのコストはどうするのよ?というのは契約次第だけど。(契約の話は以前書いたので、http://www.ryuzee.com/contents/blog/2932 を参照)
ケースバイケースなんだと思う。
顧客が、システムを「作ること」に価値を置くのか、「作ったものから得られるもの」に価値を置くのか、なんだと思う。
予算主義、丸投げ主義な顧客にはアジャイルは向いていない。あとは意思決定が苦手な組織や縦割り組織にまたがる案件とかもダメ。
こういう顧客の場合、意思決定のロジックがビジネス上の価値と関係が少なく、決めた通りにやることが評価の対象になってしまったりする。
一方で自分達で投資対効果を検討できたり、リリース時期によるビジネス機会の拡大/損失が理解できる顧客の場合は、アジャイルは向いている。
なお残念ながら、「作ること」に価値を置くタイプの顧客の案件をアジャイルでやって失敗したこともある。
5 min on Scrum | Retrospectives| 10 Ideasより。抜粋。
個人的には、振り返りは近所の緑の多い公園にいってやったり出来ると素晴らしいと思う。
訳注。どっちもドイツ語なので後で調べる
[1] http://agilesoftwaredevelopment.com/blog/peterstev/start-trust-start-retrospective
[2] Neurolinguistisches-Programmieren-Kommunikation-personliche-Entfaltung NLP,
日記 PHP オープンソース インストールマニアックス IIS Trac MySQL Perl Linux Agile・生産性向上 wordpress フリーソフト 自宅サーバ 書評 ブックマーク phpMyFaq TraM Plugin 早起き Delphi apache CakePHP Firefox Ruby eclipse セキュリティ プラグイン アジャイル mojavi Subversion Ajax/Web2.0 SQLServer Zope サーバ フレームワーク phpBB 仮想化 PostgreSQL OpenVZ scuttle CMS 文字化け 自宅 翻訳・日本語化 ApacheDS LDAP Excel 生産性向上 CodeIgniter XAMPP hacks taskfreak 修正 言語ファイル Ajax SBM ダウンロード HTML::FillInForm mod_security 情報共有