Ryuzee.com

自分にプレッシャーをかけるために予告してみる（ｗ

3/19にマイクロソフトさんで、Agile Day2というイベントが開催されます。前回1月にマイクロソフトさんの日本法人としては初のAgile関連セミナーであるAgile Dayが開催されましたが、今回はその第2回目のイベントになります。
僕は第１回はLTでしゃべりましたが、今回は１セッションいただいて、「Agileな開発プロセスを導入する前に考えなければならないこと」(仮)というテーマでお話する予定です。
内容は、若干バズワード化しつつある「Agile」の導入について、導入を考えている、なんとなく興味がある、という人たちに、事前に考えるべきポイントの概要をお伝えすることです。答えは現場や環境によって様々だと思うので、あくまで考える軸を提供したいなーと思っています。

このイベントでは、その他に、マイクロソフト長沢さんによるマイクロソフトでのアジャイルへの取り組み、IBMのエバンジェリスト玉川さんによる大規模アジャイルの話、すくすくスクラムの今村さんによるScrumを体験してみるワークショップが実施される予定です。申し込みはマイクロソフトさんのサイトから。

以下ちらみせ興行（作成中ですので実際には出てこないかもしれませんｗ）

よし、プレッシャーかかってきたｗ

先日のオープンソースカンファレンスなどでも紹介しているAgiloについて、現在i18n対応を実施中。もうソースの修正は終わっていて鋭意テスト中です。

もともとの経緯は、
・日本語化対応した際に、Agiloを作っているドイツのAgile42社に、日本語版作ったよー、ってメールしたら
・じゃあ国際化担当よろぴこ、って言われたｗ
・別のユーザーさんから俺スペイン語対応するから、早めに頼むわ、って言われたｗ
って感じ。

現在Shibuya.tracで公開しているバージョンは、Tracが持つtranslation機構を使いつつ、他の言語を使うことは想定しないでカスタマイズしていたので、現在は、どんな言語でも簡単に対応できるように、日本語化部分の整理や言語処理の分岐などを追加中。これが終われば現在Shibuya.tracのSourceforgeにアップしている日本語オリジナル版の役割は終了する予定。

なお、現在本家で公開されているAgiloの最新のバージョンではバックログ画面のUIが新たに１つ追加になっている。新たな画面ではAjaxを使ってサーバサイドからJSONのデータを取得して画面に描画するようになっており、将来的にはFlashを使ったUIなどを考えているのではないかと思われます。

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

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

ということでもう少々お待ちください。

78 Things I Have Learned in 6 Years of Agile Coachingの78個を適当翻訳。

「私が6年間のアジャイルコーチングで学んだこと」というテーマでアジャイルに関する経験談がまとめられている。

1. アジャイルについて説明させてくれるように頼む人の数＝アジャイルメンタルモデルの数±2　(訳注：ちょっと意味わからん)
2. 分散したチームでは各サイトごとに愛とスクラムマスターが必要だ
3. foosballテーブルはあなたの最良の機敏なツールのうちの1つかもしれない
4. 地理的分散はタイムゾーンの違い以上の問題がある。その場合はインフラのサポートが必要だ
5. ローカルのイベントやオンラインのメーリングリストやカンファレンスやカジュアルな集まり等を通じてアジャイルコミュニティに精力的に関わることには十分な価値がある。
6. プロダクトオーナーを持つことは譲れない
7. 積み荷崇拝スクラムを回避しなさい！
8. アジャイルチームには楽しさが必要だ
9. 最高のアジャイルチームと企業は奉仕するリーダー次第だ
10. 本当にアジャイルな文化を持つことは、あるチームが独力で作ることができる以上のことだ
11. アジャイルな開発は、あなたが喜んで時間と費用をそれに費やす場合のみ、費用の削減につなげることができる
12. アジャイルの醸成と拡大のための素晴らしいアプローチはリーンの「Flow Pull innovate guidance」だ
13. バーンダウンチャートはチームの完了へのコミットメントに関係しており、個人のパフォーマンスやタイムトラッキングに関係しているわけではない
14. あなたのスプリントバックログが製品価値の提供を反映していることを保証しよう
15. エスカレーションは継続的なプラクティスの改善においては、アジャイルでもリーンでも役に立たない
16. 成功のためには、あなたの上司から必要以上の小切手帳をもらってくる必要がある
17. 他のチームに拡大を試みる前に、あなたのアジャイルチームのプラクティスを醸成しなさい
18. スタンドアップミーティングの明確な終わりの印を持たないことは、問題の発生につながりやすい
19. Flowのリーンの原則は、アジャイルチームが彼らのプラクティスをしっかりさせるためのガイドをする
20. リリースのビジョンについて本当にコミットしたいなら、リリース計画ミーティングに全員同席させよう
21. コマンドコントロールのスクラムマスターはチームの知力を減らしてしまう
22. 同じ場所にいるチームは、分散しているチームに比べて、より簡単により早く、高いパフォーマンス、高い信頼を得られるようになる
23. 開発場所への訪問、IM、Skype、Facebook,Yammer、ビデオ会議、その他の技術を使った頻繁なコミュニケーションは分散チームが仲良くし、愛を感じることを助ける
24. アジャイルチームでは、チームが素晴らしくなり永続するために、健全な摩擦が起こる
25. ベロシティはチームのもので個人のものではない
26. 「かんばん」はチームが継続的に価値を流してることを測定する新しい指標となっているので、注意を払わなければならない
27. プロダクトオーナー不在もしくは多すぎるプロダクトオーナーは、アジャイル風になってしまう：優先順位や受け入れに際して定義可能な意思決定がない
28. プロダクト会議はステークホルダーを管理したり、バックログがひっかきまわされるのを最小化する効果的な方法だ
29. ストーリーポイントはチームがカレンダー時間やチームメンバー数とストーリーの複雑度、努力、疑問を分離するのを助ける
30. ストーリーはお互いに相対的なサイズを持っている。タスクだけが努力見積もりを持っている
31. うまく書かれたストーリー（小さくて、役割に対する利点について書かれている）は嘘をつかない。要求は、内容がおおざっぱであるため、嘘をつくことがある
32. プロダクトバックログは常に優先順位付けする
33. プロダクトバックログはタスクリストではない。タスクはチームによる見積もりと計画が終わって初めて登場する
34. アジャイルは、従業員のQOLを向上させる
35. 素晴らしいチームは協力的なメンバーから成り立っている
36. アジャイルは放置されてしまうメッセージは作らない
37. ペアプログラミングはチームの気づきとコードの完全性を向上させる
38. チームの完全なコミットメントを取る際は、同意をとるようにし、強制的な約束やコマンドコントロールはしない
39. 効果的なチームミーティングには仕組みと訓練が必要だ
40. アジャイルの価値と原則についてコミットしよう。あなたのプラクティスはそれに従うことになる
41. 透明性はアジャイルの長所であり、懲罰のためではない。
42. アジャイルとはコミットメントに関することであり、ツールに関することではない。ツールはチームのコミットメントとそれらの可視化をサポートする
43. 孤立状態で決定を下すプロダクトオーナーはアジャイルではない
44. アジャイルチームはストレス満載な場合でも敬意と思いやりを発揮する
45. 振り返りをしないチームはアジャイルではない
46. 振り返りは非難することではない
47. 振り返りはプロセスとワーキングアグリーメントの継続的な改善をもたらす
48. もしチームのワーキングアグリーメントがないのであれば、すぐ作ろう
49. もしワーキングアグリーメントを壁に掲示してないなら、すぐ掲示しよう
50. ベロシティを知るまでは、あなたが使うキャパシティは積極的におさえるようにしなさい
51. アジャイルな経験をブログに投稿しなさい。あなたが思うより多くの人があなたの経験を聞きたがっています
52. テスト駆動開発は単によいコードを作るだけではない。よりうまく受け入れてもらうためのより良い会話の場を作ります
53. アジャイルアーキテクトとプロダクトオーナーはプロダクトバックログの順位付けのために、一緒に作業する
54. アジャイルチームにはリリーススケジュールのリズムに組み込んだ形で「hackathon」のようなブレイクを与えよう
55. キャパシティの利用状況が高いのは悪いことだ
56. 品質はみんなの責任だ
57. 素早く小さいインクリメントをすることは我々の作業について情報を与え、より早くフィーチャーのセットを生みだす
58. リーンは私のアジャイルランゲージに大きなインパクトをもたらした
59. 「一番の人を雇用する」という言葉はアジャイルにおいては陳腐だ
60. 賢く雇用し、安く雇用しない
61. 新たなメンバーを雇用する時は、チームの同意が必須だ
62. 5段階の計画を利用しよう。ビジョン、製品ロードマップ、リリース計画、イテレーション計画、そして日次計画だ。
63. リリース計画は私のお気に入りのアクティビティのひとつだ
64. チームと利害関係者は次のイテレーションを見通すためにリリースプランニングに出席する
65. FYI、よいブレインストーミングは大量のポストイットとノートと賢い人たちが必要だ
66. ファシリテーションスキルに注意を払え。あなたは意思決定を乗っ取ってはいけないし、他人にそうさせてもいけない
67. アジャイルミーティングを集中した、目的に沿った、タイムボックス化された状態に保ちなさい
68. アジャイルミーティングにおいては電子機器はOFFにしておこう。集中したミーティングは生産的で、時間通りに終わる。
69. アジャイルにおける最大のコストカットレバーは「優先順位付け」だ。
70. 新しいプラクティスを試すことを恐れるな。あなたのベロシティと品質は新しいプラクティスを導入したあなたに感謝することになるかもしれない。
71. アジャイルはソフトウェア以外にも有効だ。組織の内外で活用しよう
72. 古いツールは新しいトリックへの対応に立ちはだかっている。MS Projectはアジャイルへ進む道ではない。
73. チームのアイデンティティは重要だ。個人のヒーロー性は危険だ
74. 振り返りにおける個人の感謝は、アジャイルチームの信頼を成長させる場を作るすばらしい方法だ
75. アジャイルへの成熟度は、CMMIのような成熟度モデルではない
76. アジャイルとウォーターフォールの論争は終わった。価値あるものを提供し続けることに注力しなさい
77. アジャイルはスピードをあげるために、スピードを落とすよう我々に要求する。
78. 私はアジャイルが大好きだ

ということで、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について書かれたスライド。耳が痛いところもあったりする。

一例をあげると

• ゴールの無い、魂のないScrum
• プラクティスのつまみ食いと、プロセスの早すぎる最適化
• プランニングの停滞
• コマンド・コントロール型のマイクロマネジメント
• 個人による誇張
• リスクマネジメントの欠如
• オーバーコミットメントの危険なサイクル
• 改善の遅延

スライドの最後の方に書かれていた言葉は素晴らしい言葉なので紹介。
「あなたがアジャイルをやっていて楽しくないのなら、それは正しいやり方でやっていないからだ！」

Retrospectives | 7 Secrets of my Retrospectivesより。

1. チームはスプリントの間ベストを尽くしたと信じよう
2. 最初にファクトデータを集めよう
3. 議論するのではなくて、ファシリテーションのテクニックを使ってファクトデータを集めよう
4. まずは良い雰囲気を作ろう
5. 振り返りの内容を承認しよう
6. この先改善するために出来ることを見つけるためのブレストのセッションを設けよう
7. 未来に焦点を当てよう。チームが改善すべき問題とスクラムマスターが改善すべき問題を分離しよう

僕が良く言うのは、スプリントの結果はチームとしての結果なのだから、特定個人の問題を追及し(すぎ)ないこと。
チームとしての問題を個人の問題に付け替えてしまうと、個人は問題の隠蔽を始めてしまうケースがある。Agileの基本理念の1つに「オープンであること」があるが、それがなくなると、チームとしての力が結集できなくなる。
また振り返りのファシリテーター役は、チームを非難しないことも大事だ。チームとしての結果はスクラムマスターが責任を持てば良く、そこでスクラムマスターがチームを非難してしまうのは、自分が問題や妨害の解決、ファシリテートが出来ていなかったということだ。

アジャイルって受託開発との相性が最悪な気がするより。釣りっぽい記事な気もするんだけど。

SIerから見たアジャイル

工程の分断が絶対許されないから、上流工程と下流工程を別会社が担当する今の日本の受託開発業との相性は最悪だね。自分たちで全部やれる人材が揃ってないといけない上に、コミュニケーションを綿密にとらないと成果物がグダグダになりそうだから、人月との相性も悪い。

要件まとめてぽーんと丸投げしたほうが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. 振り返りの形式を変えて行こう。新しい質問を追加したり、違うテイストでやってみたり。
2. オフィスの中じゃなくて、公園とか庭で振り返りしよう。
3. NLPに関する本を読んで、本に記述されている表現方法を使ってみよう。(訳注:[1])
4. 質問することを学ぼう!。
5. 振り返りの最後に、次回の振り返りをどうやって良くすることが出来るかを尋ねよう。
6. スプリントで作ったものを持ってこよう。(訳注:[2])
7. チームに事前に開催通知を送ろう。そうすればチームは振り返りにデータを準備してくることができる。
8. ストーリーワークショップを振り返りとして実施しよう。90分で、直前のスプリントに関する短いストーリーを書き、映像を作り、上映しよう。
9. 未来予測のワークショップをやってみよう － 将来の2011年について振り返りをして、どうしたら2011年をより良く出来るかを考えてみよう。
10. 会議を生産的にすすめる方法について扱う研修に行こう。そしてそこで学んだことを取り入れよう。

訳注。どっちもドイツ語なので後で調べる
[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 情報共有