Ryuzee.com

そろそろ振り返りしておく。

仕事関連

* 組織のアジャイル化とデスマーチ撲滅活動

自分がいた組織の合併に伴って結構やむを得ず転職したが、アジャイル活動は継続。
むしろアジャイルでしか開発をしないと決められたのは大きい。
デスマーチは撲滅したかったが、アジャイルでやっているにも関わらず、色々な役割を兼任しすぎ＆押さえるところを押さえきれなかった故に一時期デスマーチになってしまった。これは反省。
個人的には認定スクラムマスター研修にも行き、アジャイルに関して勉強する時間をかなり取ることが出来たのはGood。
外部の研修の講師でアジャイルを教えたりもあって、これも自分の復習には良かった。
色々分かってきたことも多いので、2010年はさらに色々勉強すべく職を変えるかも。

* 外部の勉強会とかユーザー会に一杯出る

Shibuya.tracの勉強会に出始めてから結構多くの勉強会に行ったし、そこからforkした企画会議も勉強になった。
ひきこもり体質の俺にとってはすごい進歩だよｗ
おかげで頼りになる知り合いが沢山増えた！
2010年も継続

* そうは言いつつ管理職だろうがなんだろうがソース書く

仕事でもソースを相当書いているが、プライベートでもTracプラグインのTraMの開発や、Agiloの翻訳、各プロジェクトへのパッチの作成等一杯やった。2010年も継続

仕事以外

* 家族みんなで健康に楽しく過ごす

旅行は数回か。もうちょっと一杯行けるといいな。
俺自身はほとんど風邪を引くことなく、体調不良といえばストレスによる胃痛くらい。
息子は結構風邪が長引いたりしてたな。ただ大分体力は付いてきたようなので来年はいけそう！

* ポジティブシンキングにする

嫌なことは我慢しなかった故に転職しちゃったわけだがｗ。
ストレスがたまるってことは後ろ向きなんだろうね。

* 読書120冊

全然ダメ。
言い訳すると、アジャイル関連で海外のサイトの英文をひたすら読んでいた。

* 早起き生活継続

完璧。土日も5時に起きてる。2010年ももちろん継続

* 真剣に減量＆減酒

全然ダメ。毎日飲んだうえにすぐ寝てしまう。体重増えなかったのは良かったが、年齢的にもそろそろヤバイ。

去年は2着になったアドマイヤモナークから購入して万馬券取ったんだけど、今年はどうかな。
ということで予想。

ペースはたぶん平均ペースよりやや遅め。リーチザクラウンが先手を取るだろうけど、あんまり競りかける馬はいないかな。
行ったっきりも考えたけど、リーチザクラウンは古馬のペースだとまだ対応できていないようなので割引。
直線はゴチャゴチャな感じで流れ込みそうな感じがするので、差し脚持っている奴が良いか。

◎ドリームジャーニー
○エアシェイディ
▲マイネルキッツ
△リーチザクラウン
△ネバプション
△マツリダゴッホ

買い目的には◎から買いつつ、○と▲が人気薄なのでボックスも買う。

穴が大好きなら、とりあえず、どの買い目でもいいけど、エアシェイディ、ネバプションは押さえたほうがいいんでないかい？

Hyper-V管理用のアプリケーションが、Windows Vista Home Premiumじゃ動かないということなので、Ultimateにアップグレードしてみた。

• Home PremiumにはSPが適用されていたので、アップグレード用のメディアもSP対応のものを使わないといけない。メディア1枚損した(笑)
• アップグレードは放置プレイで簡単だけどもともと入れていたアプリが結構動かなくなっていた。
  • VMwareは、ネットワーク接続情報(VMnet1とかVMnet8)が無くなるので再インストール
  • coLinuxも同様。TAPのドライバーが利用する接続が消えているので再インストール
  • DaemonToolも動作しなくなったので再インストール
  • Skypeも落ちたけど、再現しないので一旦放置
• なんで壁紙が変わってしまったんだろう？わざわざVistaデフォルトのものに戻すことないのに
• 心なしか挙動が早くなった気がするがたぶん気のせいだろう(笑)
• しばらく使ってみてWindows7にアップグレードする(はず)
• Windows Vista Home PremiumからWindows7へのアップグレードは一気にできないのが面倒だね。

ScrumMaster can not be the Product Owner | 10 reasons
より、自分の反省を踏まえて適当に意訳。
日本的Scrumだと顧客側に入ってProxy役をやるケースもあるだろうが、このProxyもスクラムマスターと兼任してはいけないような気がする。
他人間での利害の不一致は調整のしようもあるのだが、1人の個人の中での利害の相反は解決が難しいというのがその理由だ。

スクラムマスターがプロダクトオーナーになり得ない10の理由

1. スクラムマスターがチームを守れない
2. プロダクトオーナーを経営者から守れない(訳注：同じ会社の中での話を意識している？)
3. スクラムマスターは妥当な作業負荷であるべきだ
4. スクラムマスターは、プロダクトオーナーとして嫌な仕事をすると自分自身に言い聞かせることができないだろう
5. プロダクトオーナーは、スクラムマスターからの助けを受けることができないだろう
6. スクラムマスターとプロダクトオーナーの役割は相反することがあるだろう
7. スクラムマスターは成果物に深くかかわるので、もし失敗したら経営から全ての非難をうけることになるだろう(訳注：同じ会社の中での話を意識している？)
8. 誰がレビューの際の製品の妥当性を判断するのか？
9. スクラムマスターとしてのプロダクトオーナーは、彼が突然力をもったが故に、品質上の欠陥を抱えることになるだろう
10. ほとんどのスクラムマスターは製品開発は得意ではない。スキルセットが違う。

原文はこちら

1. The ScrumMaster could not protect the development team.
2. The ScrumMaster could not protect the Product Owner against Management
3. The ScrumMaster should have a reasonable workload.
4. The ScrumMaster will not be able to tell himself that he does a lousy job as a Product Owner.
5. The Product Owner would get no help from the ScrumMaster against the development team.
6. The ScrumMaster and the Product Owner role will conflict at the idea that the team shall come up with their own technical solutions.7. The ScrumMaster would now be involved in the outcome. He would get all blame from Management in case of failure.
8. Who will do the validation of the product in the Review? The ScrumMaster\Product Owner would not be independent anymore.
9. The Product Owner as ScrumMaster would accept flaws in quality, because he suddenly has the power.
10. Most ScrumMasters are not good in Product Development. Their skill set is leading them into a different role.

Yahoo Groupのスクラム開発のメーリングリストでPete Deemer氏が投稿した記事から気になるところを抜粋して適当意訳。

原文は、Manager 2.0: The Role of the Manager in Scrumを参照。12ページくらいなので気軽に読める。

• Scrumを導入すると、管理職の役割が完全に無くなってしまうのではないか、という懸念に早い段階で気付く
• Scrumには3つの役割しか規定されておらず、その他の人は、彼ら(Scrumの登場人物)をサポートするか、彼らの邪魔にならないようにしろ、くらいのことしか言及していない。
• 従来の管理職は、「コマンドコントロール」というモデルに基づいていて、部下に何をすべきかを指示し、確実に、その指示に従って部下が作業するようにしていた。
• しかしソフトウェア開発が複雑で変化の激しいものとなってきている今では管理職が全ての詳細を把握して、的確な指示を部下に出すことは難しくなってきている。
• またコマンドコントロール型のモデルだと、部下は単に指示に従うだけのモデルであり、それゆえに仕事全体に対して責任を持たないようになりがちだ。(仕事全体はうまくいかなくても、「私は自分に与えられた仕事は完了したよ」というレベルでの責任しか持たなくなってしまう)
• Scrumではその点では、「自己組織化されたチーム」というアプローチをしている。
• 自己組織化されたチームで仕事をできるようにするためには、外部からのマイクロマネジメントを止める必要がある。
• 通常チームは指示があればそれに従ってしまうものであるため、外部からの指示がなくならない限り、チームは自己組織化したチームにはならない。
• 管理職が答えを与えてしまうのは簡単だけど、そうせずに、チームに考えさせて、チームに責任を持って対応してもらうようにすべきだ。
• 管理職はScrumにおいては、チームが学習し、成長し、達成するためのメンターであり、伝道師である。これがManager1.0からManager2.0への移行である。
• この新しいマネジメントモデルを定着させるためには、組織は管理職の役割と管理職へ期待することについて再定義を行う必要がある。
• 一方で管理職をScrumMasterにする、という選択肢もあるのだが、これはあまり良くないと思われる。というのもコマンドコントロール型のモデルを壊すのは難しく、やはりチームが管理職の方を向いて仕事しがちであるからだ。従来型の指示パターンを単にScrumの中に移植した、ということになってしまうと、自己組織化されたチームから本来得られるであろうメリットはたぶん実現できない。
• 管理職の役割の再定義の方法として、一旦管理職が持っている役割を全て付箋に書きだしてみて、それを「Scrumにとって好ましいか」「Scrumと競合する/もしくはScrumでは必要ない」の2つに分けて配置してみる。その上で後者の役割を全て捨てて、残った役割を管理職の役割として、再定義すれば良い。

New to agile – Learn how to split storiesより抜粋して超意訳。

ストーリー分割のメリットのメリットは以下の10個。

1. ストーリー分割によって、元のストーリー上のいくつかの仕事はやる必要がなくなるかもしれない（リーンの警告にあるような無駄をしなくなる）
2. ストーリーを小さくした方が扱いやすく、分かりやすい
3. ストーリーを分割すると、個々のリスクが明らかになる
4. ストーリー分割によって、変更への対応が容易になる。大きいストーリーが変更されると、大きなショックを受けるけど、小さなストーリーならショックも小さい
5. 小さなストーリーの方が複数人で同時作業しやすい。ストーリーが大きくて専門知識が必要だったりすると、一人の人にそのストーリーを任せる傾向にあるが、小さく分割されていれば、専門的知識がなくてもできるところが沢山ある
6. ストーリー分割によって、本当のストーリーのサイズが明らかになる。ストーリーポイントが13のストーリーを3つに分割してみたら、個々のストーリーポイントはそれぞれ8だった、みたいなことを良く見てきた。これは不確実ということではなくて、自分たちの限界を超えるようなものは何でも”Big”と判断してしまう傾向にあるからだ。
7. ストーリー分割によって、新たな品質標準を使うことが出来るようになる。例として、あるレポートシステムは２種類の似たようなレポート機能を持っていて、１つは毎時動作し、もう一つは1年に1回しか動作しない。毎時のレポートは年次のレポートよりも高い品質が必要とされていた。あんまり良い例ではないかもしれないけど、相対する概念については分かるだろう。
8. ストーリーが正しく分割されるとテストしやすくなる。いくつかの部分はエンド・ツー・エンドでのテストが必要になるかもしれないけど、その他の部分はモックオブジェクトを使ってテストできる。
9. ストーリー分割はパフォーマンスの問題を切り離すことができる。元のストーリーの一部の機能がパフォーマンスに影響を与えるかもしれないというような場合に、パフォーマンステストの優先度を高くすることができる
10. もちろん、ストーリー分割することで、より消化しやすいチャンクにすることができ、イテレーションにぴったりはまるようになる

原文は以下の通り。

1. It may be possible to split a story so some of the work on the original story doesn’t have to be done. Ding, ding! Huge productivity improvement! Lean principle alert ? eliminate waste! This reason is good in some many ways you can’t even begin to count them. Any time work can be eliminated without affecting the overall value of the product it is a good thing. Oh, and if after splitting the story we see we don’t need to do any of it, well that’s just AWESOME!
2. Stories can be split to expose more personas. Sometimes teams see a story as large because there are many different types of personas which must be taken into account. The story becomes easier to deal with, and we gain clarity, when we see the personas split out separately.
3. Stories can be split to help expose risk. We may have user stories which have elements of risk in them. If we can split the user story to isolate the risk we may be able to avoid the risk altogether.
4. It may be possible to split a story to ease a transition. When we upgrade existing functionality we often give users a bit of a shock. Sometimes we can split stories to give a smaller shock up front and postpone other work until a later release.
5. A split story may be able to have more people work on it at once (swarming). If a story is large and requires primarily one type of expertise we tend to let a single person do all of that type of work. However, a split story may enable others to chip in because some portions of the large chunk of work can be handled by people with less expertise.
6. Splitting a story may give us more visibility into its true size. I have seen many teams split a size 13 story into 3 pieces and end up with 3 stories each of size 8! In fact it isn’t even that uncommon. When we have an upper bound on our story size we tend to use that size for anything “big.” This leads to large under-estimating for truly large stories.
7. A story split may allow us to use a different quality standard for the new stories. A simple example in a reporting system may be two of the same type of report, but one is run hourly and one is run yearly. The hourly report may need higher quality than the one run yearly. This may be a bad example, but I think it gets the concept across.
8. When a story is split correctly it can help with testing. Some portions of the story may require full end-to-end testing, while other portions may be able to be tested in a mock environment.
9. A split story may isolate performance factors. One portion of the original story may affect performance while another does not. This may affect prioritization as well as performance testing time.
10. Of course, splitting stories may just make the original story be in more digestible chunks so they fit better into iterations.

The waterfall trap for “agile” projects より抜粋して適当に意訳。

インクリメンタルでもイテレーティヴでも同じものを目指しているように見えるけど、インクリメンタルな開発は顧客が満足しないものを作ってしまうリスクが軽減されていない。大きな絵はプロジェクトの最も最後にしか見ることができない。インクリメンタル開発で細部まで作りこんでしまうと、修正が発生した場合に、多くの努力が無駄になってしまう。
イテレーティヴな開発は開始時点からの絵の変化を見ることができる機会を提供している。そして一歩ずつ全体の絵の完成に向けて進んでいくのをガイドしてくれる。

プロダクトバックログの作り方を間違えると上記のような事態になりやすいと言っても良い。
プロダクトバックログが顧客の視点で書かれていれば実現価値をスプリント中に明確にできるので良いのだが、このバックログがシステムアーキテクチャやシステム開発者の作業レベルに近い内容だと、単なるインクリメンタルに陥る可能性がある。
スプリント#1で、「共通関数を作る」みたいなストーリーが混ざっていたら要注意だ（そもそもYAGNIの原則に反している可能性も高いけど）。

原文の抜粋は以下

Although both these plans aim for the same thing, the incremental plan does not really reduce the risk of delivering something unsuitable to the client. The big picture appears only at the very end. Because increments are done in detail, a lot of effort is wasted when a piece needs rework (and the initial releases are almost certain to fall into this category). Iterative development offers a chance to see the picture from the start, and guide the development towards the full picture in steps. Not carving stuff in stone from the start allows us to change them easier later on, and we know that we’ll need to do that. Jeff gave the following rule of thumb to check quickly if your plan is iterative or incremental: “it’s not iterating if you do it only once”.

カンファレンスの詳細は技術評論社のサイトで。

開催は品川のコクヨホールで、12時開場、13時基調講演という流れで進んだ。
先着200名に本をくれる＆さらに先着でPokenをくれる、ということなので、丁度12時くらいに行ったのだが、既に結構並んでいた。(実は同じ本を持っていたことが判明。最近このパターン多い)
参加者は300人ということだったが、ほぼ満席で、かつスーツな方が7割(僕は当然私服)ということでマネージャ層あたりまでAgileへの関心を持ち始めているんだなぁという印象。Certified Scrum Master研修とは明らかに来ている客層が違う感じだった。

個別セッションの感想を以下に。

Thought Works社のXiao Guo氏の基調講演

• 通訳がgdgdだったので英語で拝聴。CSM研修でのミルズさんの通訳の素晴らしさを改めて認識
• 「大規模システムでのベストプラクティスとその適用」という副題だったので、大規模にフォーカスして話されるかと思ったが、大規模の話は後半ちょっとだけ。ちょっと内容が薄く広すぎ
• CIツールを階層化してテスト時間を短縮している
• MingleはThought Works社が出しているRuby製のScrum支援ツール。名前は知っているが未体験なので今度試す。
• ペアプロは徹底されているようだ。うちはレビューで代替しているけど、試すかなー。

MS長沢さんによるMS社のアジャイルへの取り組みとVisual Studio 2010の紹介

• プロジェクトでExcel大活躍。意外な気もするが、便利は便利だよね。間違っても仕様書の方眼紙としては使ってほしくないが、バックログ管理に使うのは十分あり。
• MSは昔からアジャイル。確かに「戦うプログラマ」でもデイリービルドしてたし、新機能の前に欠陥を直すプロセスが徹底されていた気がする。
• Visual Studioをはじめとして、MSの製品はWFで作るには規模が大きくなりすぎているんだろうと思う。目の前の一歩が正しいことを保証しないと歩けない、そういう印象。
• Visual Studioの機能は相変わらず豊富。でもこれチームの学習コストは高そうだなぁ、というのが率直なところ。Visual Studioからは大分離れている(未だにVS6.0でMFC触ってたりして)ので普通の人がどうなのかは分からないけど。
• コードベースを綺麗に保つのを重要視しているのは非常に同感。

IBM玉川さんによるIBM社のアジャイルへの取り込みとRational Team Concertのデモ

• 先日も説明を受けているので、Rational Team Concertの機能自体はまずまず分かってたが、やっぱり良い製品だと思う
• 問題は導入する組織への適合性で、いきなりScrum初心者チームが、支援なしに導入するのは無理かな。色々出来すぎるので困ってしまうかも。僕はそのうちチームで１回使いたい。
• プレゼンの準備中に、オープンソースのIceScrumを試してみたが、ダメだった。オープンソースならAgiloな方向かね。
• IBMでは案件開始前にAgileへの適合性のチェックリストが用意されていて、多くのプロジェクトがAgileというのが驚き。こういうベーシックな判断ロジックをきちんとプロセス化しているからこそ無駄にリスクを抱えないで済むのだろう
• 体制面でも社内でのAgile支援体制が整っているようで、これは他社は真似できないな。さすがIBM。僕が3月末までいた会社でははっきりした支援体制ってなくて海賊的に動かざるを得なかったし。

その他

• 日立のプレゼンのところで帰ってしまったんだけど、資料を見る限り、やはりIBMとの力量の差がありそうだな
• 個人的には単にプラクティスをいくつかつまみ食いしたスパイラルモデルのような感じかと思われる
• オフショアでやるときに、オフショア側の人たちを同じチームとして扱えるのかどうかが肝だと思う。目標の共有がなければ開発者のモラルも上がらないし、極論するとチームの目標の共有がなければAgileではないと思う。
• 休憩時間が5分ってのは難ありだなー。トイレが大行列だった（＾＾；

Comparing Open Source Agile Project Management Toolsより抜粋して適当訳。(スクリーンショットは引用元を参照のこと)

僕はAgiloで十分なんだけど、機能比較やスクリーンショットを見るとIceScrumもなかなか良さそう(今日インストールして触ってみたけど、こりゃだめだ。UIが日本人に向いてない)。有償の製品(Rational Team Concert)とかも比較したい。

ちなみに先日Certified Scrum Master研修に行ったんだけど、講師のお勧めはツールを使わないことらしい。ツールを使ってうまくいった事例を聞いたことがない、というのがその理由らしいんだけど、個人的には、だとすれば、講師が「俺だったらこう作る。それならうまくいくぜ！」みたいなのは言ってほしかった。どうやっても関係者が一堂に揃わない環境でやっているので、分散の弊害をカバーできるだけの道具が必要なんだよね。

• Agilefant
• IceScrum
• Agilo
• eXPlainPMT
• XPlanner

※評価の数字は１：貧弱/不満、２：許容範囲、３：良い、４：素晴らしい

	Agilefant	IceScrum	Agilo	eXPlainPMT	XPlanner
レビューしたバージョン	1.6.2	2#13	1.0.2 Pro	不明	0.7 beta
ライセンス	MIT	GPL	Apache License 2.0	GPL	LGPL
環境	Java 6、Tomcat 5.5、MySQL	Java 1.5、Servlet engine、HSQLDB (or other RDBMS)	Python、Trac、RDBMS (SQLite、MySQL、PostgreSQL)	Ruby、RDMBS (MySQL、PostgreSQL、SQLite)	Java 1.5、Tomcat 5.0 (5.5以外)、Servlet 2.3、MySQL (もしくは他のRDMBS)
バックログの優先順位付け	1から5の優先度	ランキング形式。ドラッグ＆ドロップで変更	ランキング形式。ドラッグ＆ドロップで変更	ランキング形式	ランキング形式
ストーリーポイント	×	○	○	○	×
タスク時間	○	○	○	×	○
タスクボードの確認	×	○	○	×	×
イテレーションバーンダウンチャート	○	○	○	×	○
バックログの階層構造	×	○	○	○	×
リリース	○	○	○	×	×
複数リリースに対応したロードマップ	○	○	○	×	×
複数プロジェクト	○	○	×	○	○
ポートフォリオ計画	○	X	X	X	X
受け入れテスト	×	○	×	○	×
問題管理	×	○	○	×	×
障害はバックログの項目の１つか	×	○	○	×	○
ストーリーテーマ	○	×	×	×	×
チームメンバー一覧	○	×	○	○	×
ユーザー権限	なし	PO, SM, メンバー, ステークホルダー, ※カスタムロール追加可能	PO,SM、メンバー	なし	管理者、特権管理者、閲覧者、編集者
レポート	1	×	3	×	3
	タイムシートのみ		カスタムレポートを保存可能		組み込みの素晴らしいレポートがある。但しカスタムレポートはなし
統合とAPI	なし	なし	SVNとの連携	なし	SOAPによる連携
開発状況	活発 Version.2がまもなく登場	活発 R3が2009年後半にリリース	活発。 2009年8月が直近リリース	微妙 最終コミットが2008年11月	停止 最終リリースは2006年5月
サポート	メールとフォーラム	メール	商用(月8ドル）	なし	フォーラム（しかしアクティブでない）
フォーラム	2	2	4	なし	1
			1日に2トピック		月に2トピック。返事はほとんどない
インストールガイド	3	1	3	なし	2
		フランス語のみ
ユーザーガイド	2	2	2	なし	1
ユーザビリティ	3	2	1	3	3
		たまに直観的でない	直観的でなく、クリック回数が多い	直観的
大規模プロジェクトへの適合性	3	1	評価なし	1	1
	プロジェクトランキングを使ったポートフォリオプランニング	1リリース、1スプリントしか実行中にできず、オーバーラップできない。大きいバックログの優先順位付けが難しい。	プロダクトバックログは1つだけ。複数プロジェクトはサポートしていない	同時に実行できるイテレーションは１つ	リリースがない
良い点	豊富な機能。タイムシート機能	豊富な機能 素晴らしいタスクボード プランニングポーカー機能	素晴らしいホワイトボード機能	直観的	直観的 豊富な組み込みのチャートとレポート
悪い点	タスクボード画面がない	あまり直観的でないことがある。大規模プロジェクトに向かない	1インスタンスに1プロダクトバックログしか作れない	サポートがない。 (開発の)ステータスが不明確 タスクの時間が入れられない スプリントバーンダウンチャートがない	開発とサポートが停止している。 大規模プロジェクトに向かない。 リリースとロードマップは直接的には機能がない

Agilo日本語版を「eat your own dog food」ということで、自分で実戦投入しました。

んで、早速プロダクトバックログをがんがん入れているんだけど、標準のプロダクトバックログ画面だと項目だけ出ていて、どのストーリーのストーリーポイントを見積ったか、どのスプリントで実装する計画を立てているかが全く分からず不便なんだよね。

でソースを読んでカスタマイズしようかと思ったのだけど、簡単に設定ファイルだけでできることが分かったのでご紹介。

プロジェクトのtrac.iniを開き、[agilo-backlogs]の項目の、product_backlog.columns =　のところに適当な値を設定すればOK。
僕の場合は、対象スプリント、オーナー、ストーリーポイントを表示している。

[agilo-backlogs]
product_backlog.columns = sprint, owner, rd_points
product_backlog.name = Product Backlog
sprint_backlog.charts = sprint_resources, sprint_tickets, burndown
sprint_backlog.columns =
sprint_backlog.name = Sprint Backlog

設定後は以下のような感じ。これで分かりやすい。

« 前の記事 

日記 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 情報共有