Ryuzee.com

RetrospectivaはRails製のオープンソースプロジェクト管理ツール。入手はhttp://retrospectiva.org/overviewから可能だ。
で、Retrospectivaはプラグインを利用して機能拡張することができ、Agileプロジェクト用の、AgilePMというプラグインが公開されていたので試してみた。

動作させた環境

Lenovo S10e上のUbuntu9.10日本語版。
ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux]
Rails 2.3.5
sqlite3

インストール

Retrospectivaのインストールはかなり簡単。curlがインストールされていれば

として指示に従えばOK。

AgilePMのインストールは、コマンドラインで以下のようにすればOK。

以上が終わったら以下のように起動する。3000番ポートで起動される。

なお、初回ログインはadmin/passwordの組み合わせで管理者権限でログインできるので、ログイン後パスワードを変更する。

操作イメージ

• ログイン後はプロジェクトが存在しないので、管理メニューから新規プロジェクトを作成する。
• マイルストーンを作成する。
• メニューの「目標一覧」をクリックして、新しいスプリントを作成する
• スプリントの中で「新しい目標」をクリックすると、ユーザーストーリーを作成することができる
• 次にメニューの「ストーリー一覧」をクリックすると、一覧が表示される。ここで言っている「ストーリー」はScrumで言うところのタスクなので、ちょっと戸惑う。追加の際に、紐づく「目標」(＝ユーザーストーリー)と見積もり時間を入力する。
  
• タスクの追加を全部済ませたら、後は一覧画面で毎日残存時間を更新していけば良い。画面遷移なく一覧の上で直接時間編集できるので分かりやすい
• タスクの残存時間の推移を見たければ「未処理」という項目をクリックすれば良い
  またバーンダウンチャートは目標一覧の画面で見ることができる。
  

使用感と感想

操作性については分かりやすい。Ajax等を利用して比較的ストレスなく操作できる。
ただ、いくつかScrumを利用している僕個人にとっては致命的な問題があるような気がするので、以下に記しておく

• 日本語訳のせいかもしれないが、Scrumで言うストーリーが「目標」、タスクが「ストーリー」と書かれており混乱する
• 「目標」(＝ストーリー）に相対見積もりの値をつけることが出来ない
• 「目標」(＝ストーリー）に絶対的な優先順位をつけることが出来ない(必須、線形、魅力くらいはつけられる)

この問題があるが故に僕なら現場で使わないだろう。用語の混乱は現場の混乱に直結するし、相対見積もりが出来なければスプリント中に実装するストーリーを選択するのに別の管理方法を取らなければならなくなる。それであれば、基本に忠実なTeamTrickを使った方が良いと思う。

Scrum Smellsより。スクラム風の特徴をまとめてあったのでとりあえず目次だけ適当訳。
あとはMike Cohnが書いたこちらの文書も参照。http://www.mountaingoatsoftware.com/system/article/file/11/ScrumSmells.pdf

1. リズムがない
2. 「鶏」がしゃべっている
3. 「豚」不在
4. バックログを管理できていない
5. 問題の兆候がずっと続く
6. スクラムマスターが仕事を割り振る
7. デイリースクラムがスクラムマスターのためのものとなっている
8. 仕事の役割が職能で分解されている
9. テスターがチームに統合されていない
10. バックログアイテムの見積もりを嫌がる
11. それ本当にDoneなの？
12. ここじゃ何も変わらない
13. 誰も振り返りに出たがらない
14. 経営層からのプレッシャー
15. スプリントでのコミットメントがない
16. 技術的負債がある
17. チームとして行動しない
18. 技術的なプラクティスがない
19. ゴリラがいる

デイリースクラムをよりよくする10のTIPSについて書かれていたので勝手訳してみた（笑

原文は10 Tips to Improve Your Daily Scrum

1. スクラムマスターは、スクラムボード(タスクボード)の隣に立たない。スクラムボードはチームのためのツールで、チームがスクラムボードを使うべきだ。
2. プロジェクトを妨げる項目の一覧を用意しよう。何かはっきりしないこと、必要な情報、待ち状態－これらすべてが妨害事項だ。「全ての妨害・障害はスクラムマスターによって24時間以内に解決される」という24時間ルールに従おう。もし24時間以内に対応できないなら、上層部に報告しよう。そうすれば会社がこれらの妨害の解決を助けてくれる。
3. 常に時間通りに始めよう。組織のみなにデイリースクラムの開催について絶対はっきり伝えよう。部屋の外にデイリースクラムの情報を貼りだそう。そうすればみんな分かる。廊下に大きいスクラムカレンダーを貼りだそう。全てのミーティングでそれを提示しよう。そうすれば、みんなはすぐにそれを見るようになる。
4. チームカレンダーを掲示しよう。またデイリースクラムの４つの質問が書かれたシートを掲示しよう。そうすればデイリースクラム中にチームに質問する必要がなくなる。
5. ファシリテーションは十分に実施しよう。通常、あなたが思っている量は十分ではない。管理するな。やるべきことを命令するな。
6. プロダクトオーナーや管理者等がデイリースクラムに口出しすることを許してはいけない。チームメンバーのみが話すことができる。
7. チームメンバーにはあなたが解決した妨害・問題点を説明しよう!
8. デイリースクラムのために、クッキーやチョコや何かを買おう。
9. 出席できないメンバーがいる場合は、居るメンバーが代わりをしよう。代わりをするメンバーはチームに対して欠席しているメンバーの状況を伝えなければならない。
10. タイムボックスは厳密に守ろう。15分だ。

早速やってみてはどうだろうか。

1/22(金)にマイクロソフト社で実施されたAgile Dayのセミナーに行ってきました。
いつものように知った顔が多かったりします。スーツ比率は半々くらいかな。年齢層は20代前半、40代後半以降は少ない感じで、会社の現場を回している中堅～マネージャクラスが多かったのではないかと思います。
3月と6月にまたAgile Dayが開催される予定とのことで、個人的にはお勧めイベントだと思うので、興味のある方は是非。

マイクロソフト長沢さんのセッション

アジリティを向上させるためにマイクロソフトが行ったこと

主にマイクロソフトにおけるAgileへの取り組みや現場の回し方、体制等について事例を発表されました。
僕がAgileについて外部に研修するときに、Agileへの取り組みが進んでいる企業の一つとしてマイクロソフトをあげているけど、流石という感じ。

話の内容をいくつか抜粋。

• Tech Fielderの取り組みについて説明。得てしてベンダー側はカタログスペックや美辞麗句を話がちになるところがあったり、セールストークになりやすいけれど、そうではなく、現場の人の経験や意見、技術を発表してもらい、共有する、というのを目指しているとのこと。マーケティングの手法としても、利用者の成功体験や口コミは大事だしね。
• マイクロソフトでは、Scrumのプロセスを取り入れて開発を進めている。(以前Agile Conferenceでも聞いた)
• 利用しているツールはTeam Foundation Server。残念ながら僕は利用したことが無いので機会があれば触ってみたい。
• IBMのRational Team Concertと同様に、プロセステンプレートと呼ばれるものを利用して、Team Foundation ServerでScrumのようなプロセスの利用を可能にするとのこと。なお、プロセステンプレートはCodePlexで公開されているらしいので、既にTeam Foudation Serverを利用している人は評価してみると良いのではないか。是非結果とか教えてほしい。
• マイクロソフトにおけるTeam Foundation Serverの利用事例は増えており、Team Foudation Serverの開発チーム自体でも開発中のTeam Foudation Serverを利用している。eat your own dog foodの原則通り、人に提供する前に自分たちで使っている。やはり自分が利用者になると色々な点に気付くことが多いから、普通のシステム開発をしている人も、もし自分が利用者だったらどう思うのか？という点については良く考えると良いだろう。
• Visual Studioの開発の際は、新バージョンの開発に入る前に、既存の不具合・問題を4か月かけて片付けた。壊れた、もしくは品質に問題のあるコードベースへの機能の追加は将来に負債を抱える結果となるので、このアプローチは非常に重要。
• 標語でいうと、Get Clean, Stay Clean。綺麗な状態にして、それを保ち続ける
• マイクロソフトでの開発チームは、職能による物理チームに横櫛を通したバーチャルチームで構成する。チーム内での進め方は、共通のルールを守っている限りチームの自主性に任される。
• Visual Studioでは、1スプリントは6週間に設定されている。レビューとしては実施計画レビューと実施結果レビューを行う。
• 開発はチームごとにブランチを切って実施
• 品質のチェックはQuality Gateという17のチェック(静的解析、コードカバレージ等)で定点チェックされ合格しないと出荷できない

三井さんのセッション

開発現場でのムダ取り・改善活動

岐阜と東京を行ったり来たりして、Agileの普及や実際の開発現場の支援をされている三井さんのセッション。前回聞いたのは昨年後半にIBMで行われたセミナー。相変わらずパワフルな印象。50歳過ぎて現場のスクラムマスターを続けているというのは尊敬するし、その経験の蓄積が顧客からの信頼の源泉なのだと思う。セミナー開始前に食事をご一緒させていただいて、趣味もパワフルということが判明(笑)

主なところを抜粋。

• ソフトウェアにおいて全機能の65%が利用されない、またはほとんど利用されない、という調査結果があり、作りすぎのムダがある。
• 作りすぎのムダを無くすためには常に有言実行の行動が必要である。
• 頭脳労働においては一人の担当者を固定すると、思考停滞等の無駄が発生する。
• ムダを改善するスタイルとしては、二人ひと組の作業チームを組んで決められたタイムボックスの中で作業するのが良い。(XPにおけるペアプロを業務におけるコーディング以外の部分にも適用してしまうという風に理解)
• 作業チームによる作業は効率が良く、生産性は倍になるケースも。頭がフル回転して思考停止しないので、非常に疲れる。それ故にそもそも残業が少なくなる。
• 作業チームを作る場合は、中間管理職の意識改革が必要で、チームが自発的にやるようにしないといけない。
• 見積もりゲーム→ペアプロ→ローテーションで、チーム内の仕様認識を統一できる。「ソースコードがきれいなら」詳細設計書はいらない。
• 作業の見える化が必要。始める前の見積もり時間と実績時間を記録する。粒度は細かい方が良く、三井さんのチームでは0.25時間単位とのこと。自分のチームでは0.5時間単位で、10を超えるような大きいタスクは分割する習慣。当たり前のことかもしれないが、仕事の中身への理解度が高い程、タスクの粒度は細かくなる傾向にある。
• 改善活動は常にやり続ける必要がある。止めると陳腐化する。
• Agileを本だけ見てその通りにやるのはうまくいかないことが多い。
• 会議では、チームの悩みをどんな小さなことでも出せるようにすることが必要。それがリスクの見える化になる。
• 振り返りがチームの意欲を引き出す。
• Agileを経験した人はWFに戻っても効率が高い(自分はコミュニケーションパスと頻度の違いと理解)
• CMMIやiso9001とAgileが合わないという意見もあるが、そうではない。CMMI5は自立したチーム。

ebackyさんのセッション

あなたにとって、アジャイルとはなんですか？

ebackyさんらしいセッション。以前Shibuya.tracの勉強会に来た時と同じパターン。参加者に考えさせる機会を与えて、色んなキッカケにしている。

• Agileとは何？という質問を繰り返して、ちょっとずつヒントを与えながら参加者に考えさせる。
• (ちなみに僕にとってのAgileは、「お客さんに最大の価値を提供する、チームを幸せにする、勤務先の会社に利益をあげる、これらのための道具」です)
• Agileの押しつけはその時点でAgileでなくなってしまう危険がある。けれども学習の段階では時に盲目的にプラクティスに従ったほうが良いこともある。
• 我々がやるべきことは、Agileが本当に意味するところを「説得」するのではなく「説明」できるようにすることだ。
• Agileの探究は良いけれども、とにかく、「現場や開発チームから目を離さない！」ということを大事にする。
• あきらめずに「戦略的なtry & errorを繰り返す」ようにする。
• AgileはPeople Oriented。

ライトニングトーク

僕もちょっと話して来ました。アンチパターンの紹介と言って良いかな。
僕が言いたかったのは、チームの自立性を維持するためには、周りの人(特に力を持っている人)にAgileを誤解させないような努力が必要だ、ということ。日本の受託型SIやコンサル→開発の案件において、プロジェクト開始時点でチームに関係ない外的要因によって失敗の可能性が増えてしまう、というのは避けたいし、そうならないようチームが努力するべきなんだと思う。
僕がお話した内容

個々の内容については、マイクロソフトのサイトにしばらくした後掲載されると思う。

• アジャイル開発　まずは社内の誤解に立ち向かえ(←僕)
• TDD ってどんな感じ? ～ FizzBuzz を作ってみる
• アジャイルソフトウェア開発現在進行形

僕個人のまとめ

僕は自分自身が他の会社の人にAgileを教える立場なんだけど、長沢さん、三井さん、ebackyさんの話のストーリーに感服でした。
押しつけじゃなく、自分たちの経験を伝えていて、それは銀の弾丸では無いんだけれども、参加者の共感を確実に得ている。
認知→共感→実行のプロセスを経て、参加者が何かを実行できる土台になっていた。
プラクティス自体はそれはそれで素晴らしいんだけど、押しつけでなく、自分達が良い、と思って実行できる環境づくりが大事なんだと改めて認識。

その他

LTで投票結果が1位だったとのことで、色々なグッズを頂いてきました。長沢さんありがとうございます。

• Windows7のロゴ入り手帳。この間Windows7入れておいて良かった(笑)
• Visual Studioのロゴ入りプランニングポーカー！。これで上司に見積もりゲームやってても、何トランプやってるんだ？と言われなくなります(そもそも言われませんけど)
  
• Windows7のバッチ付きポーチ

moongiftで紹介されていたので早速試してみました。

概要

TeamTrickはRailsで出来ているScrumプロジェクトの管理ツールで、チーム管理、プロダクトバックログ、スプリントバックログ、バーンダウンチャートなど基本的な機能を備えている。
外部へのデータのエクスポートや外部からのインポートには対応していない模様。
日本語は問題なく使えることを確認しています。

入手

本家サイトからダウンロード可能。
Linux用とWindows用が用意されており、Windows用の場合は、バッチファイルを実行することで即起動して使える。Windows版はインストールパスにスペースが含まれていなければ問題なく起動できる（デスクトップに配置すると起動失敗）→他のマシンでは再現しないので、他の問題かも。

機能紹介

とりあえず画面の紹介。

ユーザー登録画面。

ログイン直後。プロジェクトのリストが表示されていることから分かるように複数プロジェクト対応

プロジェクトのトップページ。ダッシュボードとして、ベロシティ等の指標やバックログ、スプリント情報が見られる。

同じくバックログの画面の下部。

左ナビからプロジェクトにあるバックログ項目を表示したところ。左列の数字は優先順位。

ユーザーとロール

スプリントの一覧。ここをクリックすると個別のスプリント画面に移動できる

個別のスプリントを表示したところ。バーンダウンチャートが表示されているのがわかる

スプリントバックログとタスクを表示したところ。ストーリ自体の合算残り時間も表示される

日本語も問題なく利用可能だ。

まとめ

機能としてはシンプルだが必要なものは揃っている。まずは初めてやってみる、というチームには良いだろう。バージョン管理システムとの連携等はないが、Scrumの原則という意味でこのプロダクトには必要機能が網羅されている、と言えると思う。Ajaxの利用によってユーザビリティもそこそこ高い。

ということで、比較的お勧めです。
正直Agiloより使いやすいかも（汗。

「プロジェクトの失敗につながる九つの要因に注意」より

1. 対象プロジェクトが新規顧客からの受注であること
2. 新システムの要件が「現行どおり」とされていること
3. 新技術や経験のない処理方式を採用していること
4. IT企業と顧客との間で一括請負契約を結んでいること
5. IT企業のプロジェクト原価率が95％以上であること
6. 開発期間が6カ月以内といった短期プロジェクトであること
7. プロジェクトマネジャが過去に似たようなシステムを開発した経験がないこと
8. 受注したIT企業が下請け企業に仕事の90％以上を回していること
9. 顧客の要件定義力に問題があること

これ読んで思いついた悲惨なシナリオ。ありがち。

今期の予算は厳しいし、偶然コンペに参加することになった新規顧客の案件を取りに行こう！
複数社いるし、値段勝負な点もあったので、協力会社に丸投げして、済ませよう。
今回は既存システムのリプレースだし、要件も変わらないからまかせちゃって大丈夫だよな。
え？協力会社にPMいないの？でもリプレースだし新旧比べれば良いから何とかなるよね？

ちなみに、自分の過去の経験で上記が６個該当したプロジェクトをやったことがある。結果？聞かないでね。
以前にデスマーチ診断プログラムを作ったのを思い出した。http://www.ryuzee.com/deathmarch/

僕としては、一括請負で範囲・期間保証の契約だけはしたくない。エスパーじゃないから無理です
あとさ、期間が6か月以内だとリスクが高いっていうけど、長いほうが当初の要件との乖離とか出てくるから顧客のビジネス上のリスクは高いし、メンバーのモチベーション維持できないリスクもあるんでないの？

• Scrumには基本の３つの役割と、その他の３つの登場人物がいる
• それぞれ映像制作にたとえると、スクラムマスターは監督、プロダクトオーナーは脚本家、チームは俳優/女優になる
• その他３つの登場人物として、カスタマー＝プロデューサー、マネージャ＝スタジオの管理者、エンドユーザー＝観客、になる

※movieを映画ではなく、映像と訳しているのは、WFとAgileの比較において、以前「WFは長編映画、AgileはTV番組だ」という例えがあったからである。

http://agile.dzone.com/articles/technical-stories-are-they
より抜粋して翻訳（この記事自体も、YahooGroupのScrumメーリングリストで議論されたもの。本文中XPに関する記載はあえて除外）

疑問：プロダクトバックログに技術的なストーリーを含めるべきか

Scrumでは？

Scrum.orgのScrumガイドの説明ではこう言っている
「プロダクトバックログには、製品の開発、リリースのために必要なすべての事柄を含める。プロダクトバックログは、フィーチャー、ファンクション、技術要素、機能拡張、バグフィックス等の将来の製品出荷までに行われるすべての項目を含む」
「スプリントバックログは、チームがプロダクトバックログアイテムを完了させるのに必要なタスクから構成される。項目の多くはスプリント計画ミーティングで洗いだされる。スプリントバックログはスプリントゴールの到達に必要とチームが判断したすべての作業のことである」

じゃあ正しい答えは？

状況、コンテキスト次第。

例えばあなたのDONEの定義の中に、ユニットテスト、自動テスト等の項目が含まれているなら、あえてバックログにそのような項目を載せる必要はない。顧客と交渉の必要もないし、それで十分だ。見積もりの際には定義したDONEの内容がすべて完了する時間を見積もる必要がある。

一方、「チームメンバーとして、既存のユニットテストをCruiseControl上で動作させたい」のようなストーリーはどう扱うか？
このストーリーは良く書けているけれど、エンドユーザーにとっては最終的には直接的な価値はない。こういう時は以下のようにすればよい

「この手のストーリーはプロダクトバックログには含めないけど、スプリントバックログの中には含めてよいタスクだろう。（中略）もしスプリント計画ミーティングでタスクのブレークダウンをしてるなら、この手のストーリーや作業はスプリントバックログ内のタスクとして含め、この作業に関する時間はバーンダウンチャートでトラッキングすれば良い。（後略）」

最後に

この手の話をどう扱ったらよいかはチームで議論して、チームとして最善の方法を決めたら良い。

---
上記までがまとめの内容。んで以下私見。

私見

顧客が技術に精通している場合は、継続的インテグレーション環境を構築する、というストーリーでも分かってくれるかもしれない。
でも大多数の顧客には、この言葉は通じないので、僕の場合は、「高生産性・高品質を維持できる開発環境を構築する」というストーリーにして、そのストーリーに紐づくタスクとして、「Tracを構築する、Subversionを構築する、CruiseControlを導入する、VMwareで仮想化した開発用OSを作る、全員共通用Eclipseの設定と配布を行う」みたいなタスクにする。
以前IBMさんの無料研修に行った際に、プロダクトバックログに「開発ルームの確保」とか「マシンのセットアップ」というようなストーリーが入ってたりする例を見たけれど、僕は好みではない。
ただ、これはメーリングリストで議論されているようにチームとしてよりよい方法、やりやすい方法を考えればいいのだと思う。

マウンテン ゴート ソフトウェア社がクリエイティブ・コモンズライセンスで提供している再配布可能なScrumの説明文書(パワーポイント。原作者はアジャイルな見積もりと計画づくりの原書を書いたマイク・コーン氏)について翻訳をおこないました。

日本語訳の入手はこちら
http://www.ryuzee.com/?dl=17

原文の入手はこちら
http://www.mountaingoatsoftware.com/scrum-a-presentation

なお、訳の中には、誤字脱字、誤訳等が含まれている可能性があります。お気づきの点がありましたらコメントを記入頂くか、twitterで連絡いただければと思います。
一定時期が経過したらマウンテン・ゴート社に送付する予定です。

1/14追記
・訳の漏れとPPTのレイアウト崩れを修正しました。（かおるんさんありがとうございます）
・参考文献に、相対する日本語版の書籍名とISBNを追加しました。（かぬさんありがとうございます）

偶然見つけたんだけど、以下のサイトに、パワーポイントのプレゼンテーションが大量にリンクされている。

http://www.osun.org/Scrum-ppt.html

たとえば、An Introduction to Scrumはマウンテンゴートソフトウェア社が提供する、再配布可能なScrumの紹介パワーポイントとなっており、うまく日本語化すると社内での紹介に使えたりするのではないか。
(作者はアジャイルな見積もりと計画づくりの原書を書いたマイク・コーン氏なので、中身も折り紙つき)

このスライドの中ではScrumを100語で説明する、というスライドがあり、忙しい経営者への説明とか、話を聞かない管理職への説明にも使えそう。

ということで、順番に見ていくことにしよう。

« 前の記事 

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