« 2011年9月 | トップページ | 2011年11月 »

2011年10月

2011/10/27

ゲーム業界のプロジェクトマネジメントの資料

スクエア・エニックスのCTOが書いたプロジェクトマネージメントの資料がとても良かったのでリンクしておく。

【元ネタ】
スクエア・エニックスのCTOが書いたプロジェクトマネージメントの資料がスゴイ! at ミネルヴァの梟は黄昏とともに飛び始める

【1】ゲーム業界のソフトウェア開発案件を元にしているが、仕様・納期・人員・品質などの要素が当初見積りよりもわずかに増えるだけで、実績工数が10倍以上に膨れ上がることを簡単な例で説明している。
更に、10倍に膨れ上がった工数は、仕様を減らし、納期を延ばし、人員を大量投入し、品質を落とし、更に開発者の労働時間を80%増やせば帳尻が合うという話から、簡単にデスマーチに陥ると説明しているのが分かりやすい。
実際は簡単なモデルでは説明できないだろうが、感覚的にはフィットする。

プロジェクトがデスマーチに陥るきっかけは、各要素の些細なギャップから生まれる。
それらが積み重なって、メンバーはおろかマネージャもプロジェクトをコントロールできなくなる。

【2】興味を惹いたのは、プロジェクト管理の手法として、WF型開発とAgile開発の良い所取りで説明していること。その説明を読むと、過去の経験に裏打ちされているのだろうと納得する点はある。

「用意周到な事前対処」はWF型開発における「前工程の品質確保」。
「積極的な事後対処」はAgile開発における短いサイクルのPDCサイクル(Plan-Do-Check)。

前者はリスク分析マトリクスを連想させる。
つまり、重要度の大きいリスク、頻繁に起きる中程度以上のリスクはあらかじめ事前に対策を立てておき、予防したり対応策を即座に取れるように準備しておく。
あるいは、影響度が低いリスクは放置したり、都度対応で逃げるようにリスクを分けておく。
PMBOKでも立上げ・計画・実行・監視・終結プロセスの中で計画プロセスを最も重視しているのは、計画を立てる段階で自分の頭でシミュレーションしながら、予想できる範囲内のリスクに対応できる準備を整えること。
駄目なマネージャは、計画プロセスの成果物の品質が悪くて、何の準備もなくいきなり海に飛び込もうかとしているかのようだ。

後者は、イテレーション単位のインクリメンタル型開発。
XPの小規模リリースがこのプロセスの本質。
つまり、イテレーション終了時には必ずアウトプットが出来上がるように、少しずつ作っていくこと。
駄目なアジャイル開発のプロジェクトは、そもそもアウトプットが作れなかったり、イテレーションという定期的なサイクルを守れず、イテレーションが長くなりがちになったりする。

アジャイル開発だからと言って、手抜きをしたり、計画を立てないのは違う。
また、せっかくイテレーションという定期的なサイクルで開発しているのに、要求や作業量やリスクをイテレーションで制約をかけることができていないのだ。

計画(双眼鏡)も設計(地図)もブラッシュアップして、不測の事態を避けたり、それに気づきやすくするようにするのが大事。

アジャイル開発の落とし穴の説明も面白い。
これは、漸進型開発(インクリメンタル)と反復型開発(イテレーティブ)の使い分けで解決できると思う。

【3】実際のプロジェクトの進め方の話はとても興味深い。
Scrumのやり方に似ているなあと思った。

但し、いくつか参考になった点はある。
一つは、1点見積りではなく2点見積りにすること。
2点見積もりは最小工数と最大工数の2つで見積もり、バッファ=最大の見積工数-最小の見積工数として、バッファの半分までで完了できるなら高評価を与える仕組み。
この見積もりを使うと、最小工数までにある程度のアウトプットを作ろうとするし、最大工数までには必ずアウトプットを出そうとするから、学生症候群やパーキンソンの法則という心理学的要素をはねのけることができると言う。

又、PMBOKなどで良く出てくる3点見積りは1点見積りと同じ心理になるので良くないと言う。
何故なら、見積りの最小工数や最大工数よりも平均工数に着目してしまい、2点見積りのような心理効果が発揮されないらしい。
確かに3点見積りは手間がかかるだけで、なかなか見積りにくいと思う。

実際の見積もり手法はプラニングポーカーをやっているようだ。
スクエアが通常のScrumと違うのは、最小工数と最大工数の2枚の見積もりカードを出す点。
それ以外は、一斉にカードを出したり、メンバー同士で食い違ったら互いに説明し合って修正していく点はScrumの見積りに似ている。

二つ目は、PDCサイクルを1日・1週間・1スプリントで意識的に使い分ける運用をしていること。
各メンバーのタスクは1日単位でタスク管理ボードというアナログのかんばんで管理する。
チームは、メンバーの週報を元にチーム定例を週1回開き、進捗確認や課題管理を行う。
そして、スプリントの始めにスプリント計画を立てて、スプリント終了時にメンバー全員でふりかえり会議を行う。
この辺りの話は、XP の開発プロセスの考え方と同じように思える。

- eXtreme Programmingの魅力を探る

更に面白いのは、スプリントふりかえり会と一緒に、成果物発表会を行っていること。
要は顧客の受入テストないしデモなのだが、チーム同士でスプリントの成果物を披露することで、モチベーションが上がるらしい。

この資料を読んで、プロジェクトマネジメントの手法は、業界に関係なく共通のコンテキストがかなりあるように思った。

| | コメント (0) | トラックバック (0)

2011/10/23

スマートフォン向けアプリ開発はアジャイルに向いている

AdobeAirでスマートフォン向けアプリ開発をやっていて、アジャイル開発に向いているなあと思った。
考えたことをメモ。

【元ネタ】
アジャイル開発のボトルネック - Social Change!

資料公開:「納品のない受託開発」にみるソフトウェア受託開発の未来~IT投資に対するソフトウェアの価値を最大化できるビジネスモデルとは - Social Change!

Twitter / @akipii: 最近のシステム営業では紙や画面だけでは客の反応がなくスマートフォンのアプリのように動く物でないと客が食い付かないと聞いた。だから苦労してるらしい。SIの外側はアジャイルを受け入れる環境があるのに変化に付いていけてない。

Twitter / @akipii: 製品発表時のインパクトは小さくとも同じプラットフォームをユーザーが長期間使い続けられるようにデザインされた製品が着実にユーザーへの浸透を果たしている。

Twitter / @akipii: iPhoneシリーズは2009年に発売されたiPhone 3GSが、今でもiOSの最新版を搭載できる。iPhoneは買い時を迷う製品だが、逆に言えば、どの年の製品を買っても長い期間使い続けられる。そうした安心感の積み重ねが、iPhone 4Sの売れ行きにつながっているのだろう

【1】最近の受託開発の営業は、不況のせいもあろうが、文字だけの提案書や画面がついたパワポだけでは顧客の食い付きが悪いらしい。
スマートフォンのアプリのように、動くアプリを見せると興味を持ってくれるそうだ。
実際に動くものを見せないと、顧客の反応が今一つらしい。
だから、客の目が肥えてきているね、という話が出ているらしい。

B2Bの業務システムならばいきなり動くアプリを作るのは難しいだろうが、B2C向けのWebシステムやクライアントアプリの場合、実際に動くものがあった方が営業もやりやすい。
しかも昨今はSNSが大流行しているので、フロント側のWebシステム開発でも、単なるHP作成だけでは顧客も目を引かない。

従来の提案や営業では、システム提案書やら要件定義書やら膨大な資料を作って顧客と打合せする開発スタイルが主流だった。
でも動かないドキュメントや仕様書は、顧客自身も興味が無くなってきている風潮があるのだろう。
SIを取り巻く環境はアジャイル開発に変わっているのに、SI自身がその変化に付いていけてない状況が今の日本のIT業界の現状なのだろう。

【2】スマートフォン向けアプリ開発をやっていると、アジャイル開発にとても向いているなあ、と実感する。
スマートフォン向けアプリ開発の前提条件は、短納期でプロトタイプ重視がとても多い。
3ヶ月や1年間も開発を待ってくれない。いきなり1ヶ月後に動く物を見せることを要求される。

だから、プロトタイプを作って頻繁にVerUpしながら機能拡張していく開発スタイルになる。
無駄なドキュメントそのものを作る余裕もないから、最低限の仕様書を残すだけ。
動かない設計書よりも動くプロトタイプを重視する顧客の姿勢は、アジャイル開発ととても相性はよい。

しかし、アジャイル開発に慣れていない開発チーム、設計書に書かれた仕様を実装する開発スタイルしか知らない開発者にとって、短納期でプロトタイプ重視の開発はとても苦痛だ。
要求や仕様がそもそも確定していないし、コロコロ変わるのが前提だから、変化を受け入れるマインドがなければとてもやってられない。

アジャイル開発ならば、イテレーション単位で変化を受け入れて制御しようとする。
その中で重要なポイントは、どんな仕様に不明点や質問があるのか、という課題管理だと思う。
そういう課題を毎日洗い出しては顧客に回答してもらい、回答をもらったら即座にアプリへ反映していく。
昨日の課題は今日の課題とはステータスも違うし、明日の課題はそもそも今日の課題とは違うかもしれない。
そういう課題の変化を逐一追跡する仕組みが必要だろうと思う。
何故なら、最小限の設計書しかないので、開発者が設計者の役割を兼ねるので、実装上の観点から分かった仕様漏れや仕様の不整合がポロポロ出てきやすいからだ。

そんな状況ではチケット駆動開発はとても役立つ。特に、タスク管理も重要だが課題管理で威力を発揮するだろう。
メンバーがアプリの開発で生じた課題が生じたら、課題のチケットを起票して、リーダーへ投げる。
リーダーは発生した課題をあらゆる手段を使って方針や回答を得て、メンバーにフィードバックする。
メンバーは、回答された課題の方針に従って、ソースへ反映し、コミットする時点でチケットもCloseする。
つまり、No Ticket, No Commitの運用ルールに従うことによって、どの課題がどのソースに反映されたのか、が分かるから、ソースの変化を追跡しやすくなる。
この課題管理の管理手法は、ITS(Issue Tracking System)の本来の使い方だろうと思う。

【3】短納期でプロトタイプ重視の開発では、XPのオンサイト顧客、Scrumのプロダクトオーナーのような役割を持つ人が開発チームにいることが重要だ。
実際の開発では、顧客が常に開発チームに常駐するとは限らないので、プロジェクトリーダーが顧客プロキシとなって、顧客の代わりにプロダクトバックログからストーリに優先順位を付ける。

オンサイト顧客が暗示したもの~プロダクトオーナーとアーキテクトの役割: プログラマの思索

DevLove道場で感じたことだが、プロダクトオーナーが開発チームにいないと開発そのものが停滞してしまう。
@kuranukiさんが言っているように、開発チームがいくらアジャイルで開発速度が早くてもじきに、プロダクトオーナーの意思決定の速度が開発のボトルネックになってしまうのだ。
特に、スマートフォン向けアプリ開発のように、旬の時期にリリースしないとそもそも使ってもらえない制約条件の場合、プロダクトオーナーの役割はより重要になってくる。

DevLove道場の感想 #agilesamurai #devlove: プログラマの思索

アジャイル開発のボトルネック - Social Change!

マネジメントのスピードが開発のスピードに直結する: プログラマの思索

だから、ユーザ企業が外部SIにシステム開発をアウトソーシングするのではなく、ユーザ企業自身が開発部隊を持ってシステム開発するスタイルが多くなっているのだろうと思う。
そうすれば、開発チーム自身が開発者であり、プロダクトオーナーでもあるから、自分たちで開発の支障や課題を取り除けていける。

最近、ソフトウェアテストやアジャイル開発のイベントでSNSやゲーム業界の事例が良く出てくるけれども、その理由は、SNSやゲーム企業の開発チーム自身が開発者でありプロダクトオーナーゆえに、アジャイル開発がとてもやりやすい環境が揃ってきていて、実際の開発で試行錯誤したアジャイル開発のノウハウや品質管理のノウハウが色々たまってきているからだろうと思う。

【4】スマートフォン向けアプリ開発のアーキテクチャもそろってきた感触もある。
スマートフォン向けアプリのプログラミングスタイルは昔のVBやC#のデスクトップアプリの開発とすごく似ている。
iPhone/iPadやAndroidで動くアプリは所詮はクライアントアプリ。
ユーザが画面に触れた時のイベントに応じて、処理を実装するだけ。

デスクトップアプリ開発のベストプラクティスであるObserverパターン、Multicastパターン、Commandパターン、Stateパターン、Starategyパターン、Singletonパターンなどがスマフォ向けのアプリのフレームワークに揃っている。

ObserverパターンとMulticastパターン: プログラマの思索

デザインパターン再考: プログラマの思索

昔のデスクトップアプリと違うのは、配布方法がiTunesのような仕組みで全クライアントへアプリを最新版へダウンロードできることと、アプリ内部でsqlite3のような軽量RDBを保持していること。
iPhone/iPadやAndroidの各端末にクライアントアプリを配布する場合、iTunesのような仕掛けでアプリを一括配布する仕組みになっている。

デスクトップアプリの開発で嫌なのはユーザへ最新版を届ける仕組みがバラバラのために、CDRで配布したり、専用回線で各クライアントへログインして手作業でアプリを配置するしかなかったこと。
つまり、デプロイという作業は昔はとても大変だったのだ。

HTML5が流行するかもと言われているのは、HTML5がsqlite3を持つクライアントアプリであり、Webサーバー上でクライアントアプリそのものを自動生成してiTunesのように配布できる仕組みが整いつつあるからだろう。
この発想は、本番リリース・本番デプロイ作業をより高速に自動化していく方向、すなわちContinuous Deliveryへ進化するだろう。

Continuous Delivery~TDDとCIの次に現れた自動化の概念: プログラマの思索

継続的インテグレーションを再考: プログラマの思索

また、内部にsqlite3という軽量RDBがあるので、マスタデータだけでなく、ちょっとしたトランザクションデータも保持できる。
だから、昔VBやAccessで作っていたアプリは全てスマフォ向けに作り直すことができるだろう。

AirのActionScriptは、C#のDelegateみたいに関数ポインタが使えるので、Javaのようにインナークラスを多用せずに書けるのが楽に感じる。
とは言え、ActionScriptはJavaっぽくてRubyほどの軽量さがなくて面倒。
Railsに慣れてしまうと、DaoやCRUD画面を手作業で逐一作るのが面倒だ。自動生成すればいいのに。
又、FlashBuilderはJavaのEclipseに比べるると、import追加・リファクタリング・デバッグ時のインスペクションが非力なので正直使いづらい。

Eclipseリファクタリング・メモ: プログラマの思索

【5】スマートフォン向けアプリ開発で思うのは、プラットフォームの重要性だ。
iPhoneシリーズは2009年に発売されたが、今でもOSやアプリをVerUpすれば普通に使える。自分用にカスタマイズされたiPhoneをずっと持ち続けられるのだ。

昨今は携帯やスマートフォンならば、ソフトウェアアップデート機能が必ず付いているので、アプリの最新化だけでなくOSそのものをVerUpすることも可能。
この意味は、コンテンツはいつも最新化できることでハードの寿命がどんどん長くなり、ハードの価値そのものがそれほど意味が無いこと。
つまり、従来の製造業の発想では、ハードを買った時点で価値の減価償却が始まり、5年で価値は殆どゼロになるのが普通だったが、iPhoneなどの場合は、買った後にコンテンツをどんどん最新化したり増やしたりしながら使い込んでいくほど価値が上がっていくスタイル。

これは、@kuranukiさんが話している「Point of SalesからPoint of Use」の話を連想させる。
スマートフォンのビジネスは、従来の製造業やソフトウェア開発に対するビジネスモデルのパラダイムシフトでもあるのだろう。

資料公開:「納品のない受託開発」にみるソフトウェア受託開発の未来~IT投資に対するソフトウェアの価値を最大化できるビジネスモデルとは - Social Change!

このプラットフォームビジネスで重要な点は、ファンや開発者を増やすこと。
iPhoneのようにファンを増やせばクチコミで購入者が広がっていく。
プラグインやアプリの開発者が増えることで、コンテンツが増えたり使い勝手が上がることによって、プラットフォームの価値が上がっていく。
この手法は多分、MicrosoftがVBやC#のような開発言語、VisualStudioの開発環境をプラットフォームとして提供して大成功させた手法だったが、今はAppleやGoogleにお株を奪われているように思える。

GTDとチケット管理が似ている: プログラマの思索

スマートフォンの開発やビジネスは従来のWebビジネスとはかなり違った新しいビジネスモデル、開発スタイルであると改めて実感している。
そこはアジャイル開発、アジャイルなビジネスを実現しやすい要素が多分かなりあると思っている。

| | コメント (0) | トラックバック (0)

2011/10/21

スケジュールを見ればマネージャのレベルが分かる

@hatsanhatさんから「スケジュールを見ればマネージャがどこまでリスクを見通しているかが分かる」という指摘を聞いて考えたことをメモ。

【元ネタ】
Twitter / @akipii: Redmineによるチケット駆動開発を成功させるには全てのタスクを1人日以下まで分割しきれるかどうかが鍵。詳細レベルまで落とし込めれば作業手順もリリースサイクルもリスクもほとんど見通せているから。スケジュールを見ればPMがどこまでリスクを見通せているかすぐに分かる。

Twitter / @akipii: @dproject21 Redmineもチケット駆動開発も銀の弾丸じゃないんですよね。プログラミングやモデリングでシステム開発をどこまで解決できるか。アジャイル開発は作業を手抜きできると思う人がいるけど結局正攻法しかないんですよね。

【1】Redmineでチケット駆動開発を運用していると、チケットの粒度はどれくらいがいいのか、という質問はよく聞く。
チケットは作業指示書であり、成果物というアウトプットを要求している。
僕が過去4年間運用して実感したことは、チケットは1人日以下のタスクまで詳細化した方がいい。

開発者の観点では、成果物が半日から1日の間で作れるレベルならば、とても作業しやすい。
開発者のリズムは、朝一番にタスク一覧から最優先のタスクを担当し、夕方までにコミットして、退社前にチケットをCloseして帰るイメージ。
1日のうちに必ず1枚のチケットが終わるリズムがあると、気分的にも楽だし、達成感がある。
何よりも、毎日の朝会で「昨日やったこと」という実績を皆に確実に報告できるのがいい。

駄目な開発者は作業の進捗が90%のまま停滞しているパターンが多い。
毎日の朝会で90%の進捗を報告するが、実際にレビューしてみると、全く動かないソースだったり、設計書の穴が多すぎるパターンがとても多い。
つまり、自分自身はほとんど出来上がっていると思っているけれども、タスクの完了基準を満たしていないのだ。

アジャイル開発の観点では、リリースできない成果物は、たとえ90%の進捗でも、実際の進捗は0%という厳しいルールがある。
その意味では、進捗率は、完了か未完了かというBooleanでいいのかもしれない。

【2】リーダーとしても、1人日以下で終わるタスクをメンバーに任せたリスクはかなり小さくなると思う。
例えば、4時間で終わると見積もったタスクをメンバーが完了報告してレビューしてみると、バグが見つかったとすれば、即座にフィードバックして修正してもらえばいい。
当初の予定工数4時間ではなく実績工数が8時間になったとしても、1日で一つの成果物を生み出した事になる。

逆に、5人日で見積もったタスクが進捗90%のまま報告され続けて、最終日にレビューしたら穴だらけだったら、5日分の工数が結局無駄になったのと同じだ。
5日かかっても完了できなかった実績を考慮すると、完成品になるまで2倍ぐらい工数がかかると思った方が良い。
リリースできない成果物、納品できない成果物はたとえ進捗90%だったとしても、完成品でないから、顧客にとって価値がない。

【3】リーダーの観点では、WBSの最下層のタスクや成果物が1人日以下のレベルまで詳細化できているならば、納品までにどのタスクをどんな順番で進めればいいか、リスクはどこにあるか、をほとんど見通せているだろう。

駄目なプロジェクトリーダーは、スケジュールという計画プロセスの成果物がとても雑だ。
ガントチャートを単に作っているだけで、そのスケジュールの実現可能性まで深く考えていないからだ。
WBSを詳細化するほど、作業や成果物の曖昧さをどんどん除去していけるし、それでも不明なものはリスクや課題として浮き上がってくる。

すると、実際のタスクはチケット一覧にあるチケットを上から順にメンバーが粛々とこなせばいいから、リーダーの仕事はそれら課題やリスクに対処するのが主な仕事になってくる。
すなわち、メンバーが解決できない課題は顧客や会社の上司、他チームへ調整したり、リスクに対して予防や是正対策などを準備したりする作業が多くなるだろう。
リーダーはメンバーの進捗管理を行う管理者ではなく、チームをどの方向へリードするか、メンバーが作業しやすい環境をいかに作るか、といったファシリテーターのような役割へ変化する。

長期の計画は将来にわたる複数のイテレーション、短期の計画は直近のイテレーションでタスクを管理すればいい。
将来のイテレーションのタスクまで詳細化できればいいが、実際はそう簡単ではない。
まずは直近のイテレーションで、1ヶ月後までのタスクを詳細化することに専念すればいい。
そうすれば、1ヶ月後には必ずアウトプットが出るし、作業した結果から、自分たちチームがどこが弱いのか、どれが強みなのか、を知ることによって、リスクや課題に対して対策を立てやすくなる。

【4】RedmineやTracはチケット集計機能が優れているので、タスクだけでなくバグも課題もリスクも全てチケット化しておけば、いくらでも好きなように抽出できる。

課題一覧はトラッカー=課題で抽出すればいいし、障害一覧はトラッカー=バグで抽出すればいい。
直近のイテレーションのタスク一覧は、該当バージョンでトラッカー=タスクで抽出すればいい。
自分のタスク一覧が欲しいならば、担当者を自分でフィルタリングすればいい。
つまり、欲しい情報のSQLを投げればいいだけのことだ。

プロジェクト内部で発生する全ての作業や課題、リスクがチケット化してDBに一元化されることによって、リーダーはチケットの最新化や棚卸しに注力すれば、作業の進捗や品質を過去から未来まで追跡できる。更には課題もバグも同様に追跡できる。
「チケットの取捨選択が本来のマネジメント」というフレーズは多分そういう意味なのだろうと理解している。

| | コメント (0) | トラックバック (0)

2011/10/11

継続的インテグレーションから継続的デプロイへ

Jenkinsコミッタの川口さんの記事を見かけたのでリンクしておく。

【元ネタ】
InfoQ: 継続的デリバリのパターン

InfoQ: Jenkinsによる継続的インテグレーションのススメ(1)

InfoQ: Jenkinsによる継続的インテグレーションのススメ(2) ~Jenkinsを使い始める~

InfoQ: Jenkinsによる継続的インテグレーションのススメ(3) ~Jenkinsで分散ビルド~

(引用開始)
元々CIはこのようにビルド・テストの実行といった狭い分野にフォーカスしていましたが、最近では、汎用の自動化プラットフォームとして、バックアップ・リリース・デプロイメントなどのスクリプト可能な作業をなんでもやらせる事も広義のCIに含んでよいと思います(Continuous Deploymentなどと呼ばれる事もあります)。今までは、こうした作業は担当者が個人の計算機上でスクリプトとして記述することが普通でしたが、ちょうど開発者がIDEとは切り離された誰にでも実行可能なビルドスクリプトの利便性に気づいたように、担当者の個人の環境を離れて誰にでも見え、修正でき、実行できるような形に書く事で、属人性と環境依存性を排除することができます。
(引用終了)

CIというアイデアは、単なるビルド管理の自動化だけではない。
継続的インテグレーション入門」に書かれているように、継続的デプロイ・継続的インスペクション・継続的フィードバックなどあらゆる作業の自動化をサポートできる。
PaaSなどのクラウドでサーバーやハードウェアと言うインフラ管理も自動化できるので、それらと組み合わせれば、本番環境構築、本番リリース作業やデータ移行などをもっと自動化出来るはず。
それによって、顧客へより早く正確に納品できるようになるはず。

継続的インテグレーションを再考: プログラマの思索

Continuous Delivery~TDDとCIの次に現れた自動化の概念: プログラマの思索

クラウドの本質はインフラ管理のIT化: プログラマの思索

更なるCIツールの使い道は、バッチ処理のサポートだろうと思う。
ソフトウェア工学におけるメトリクス収集処理は、CIツールを使うことでより簡単に、より利便性が良くなると思う。

Jenkinsの特長 - メトリクス収集サーバの視点から -: ソフトウェアさかば

Redmineを業務システム化するアイデア~メトリクス集計の本質は集計バッチ処理: プログラマの思索


| | コメント (0) | トラックバック (0)

2011/10/10

Redmineを業務システム化するアイデア~メトリクス集計の本質は集計バッチ処理

IPAの定量的プロジェクト管理ツール概要やさかばさんの記事を読みながら考えたことをメモ。
ラフなメモ書き。
間違っていたら後で直す。

【元ネタ】
Jenkinsの特長 - メトリクス収集サーバの視点から -: ソフトウェアさかば

InfoQ: 継続的デリバリのパターン

マネージャから以前、ベースライン単位にタスクの進捗や課題の状況を履歴表示できないか、という問合せを受けた。
彼の意図としては、ベースライン(プロジェクトのマイルストーン)単位に集計して、予定と実績の差を見たいということだった。
僕は、現状のRedmineでは力不足です、と答えた。

その理由は、Redmineのチケット集計機能はユーザが画面表示した時点のチケットの状態を集計表示する機能だけであり、集計結果を履歴表示する機能はないからだ。
バーンダウンチャート、チケットの登録・完了の累積数、ロードマップスなどのプラグインはあるが、マネージャが欲しい機能はもっと複雑な集計結果の履歴が欲しいのだ。
しかも、その集計結果の履歴をExcelで出力できるようにしたい、とのことだった。

Redmineによるチケット駆動開発を単なるAgile開発ではなく、ソフトウェア開発の業務システムへ拡張しようとすると、もっと複雑な集計処理が必要になる。
IPAは定量的メトリクス収集ツールをRedmineの一機能として作ろうとしているが、その背後にはそういう動機があるのだろうと思う。

だが、集計結果の履歴を保持する機能を実装するのはとても難しいのが現状だろう。
その理由は、業務システムのバッチ処理のように、日次・月次などのようなタイミング(マイルストーン)でフロントで入力されたデータをバッチ処理で集計する処理が必要だからだと思う。

Jenkinsの特長 - メトリクス収集サーバの視点から -: ソフトウェアさかばにもその理由が一部書かれている。

業務システム開発で最も難しいのは、Webフロント側よりもバッチ処理の設計と開発だ。
バッチ処理はアーキテクチャ設計がほぼ全てなので、設計がまずいといくら開発しても無意味。
しかも大量データを集計するから、処理の負荷やシステム運用も考慮しなければ、使い物にならない。

Redmineをソフトウェア開発の業務システムにするには、最終的には集計処理をバッチ化する機能が必要だろうと思う。
そのイメージは下記の通り。

チケット入力などのように集計の元ネタとなるデータは、PGがWeb画面から入力する。
その入力データを定期的(日次・月次)に集計バッチ処理が一括処理して、集計用データを作る。
その集計用データをPLがWeb画面から一覧表示して見れるようにするイメージ。

この時のポイントは、幾つかある。
バッチ処理をキックする処理はCIツールで代用した方がいいこと。
バッチ処理そのものはストアドでもいいし、Perl/Rubyなどのスクリプト言語で作ってもいいが、CIツールでキックできるようにしておけば、いろんな操作が可能だし、拡張もしやすい。

また、集計バッチ処理もJenkinsのプラグイン、そして一覧表示処理はRedmineのプラグインにしてしまった方がいい。
変にカスタマイズしたフレームワークを作るよりも、JenkinsやRedmineのプラグインにした方がインストールも簡単だし、別の開発者にも流用しやすい。
特にRedmineはRailsで作られているから、Redmine本体のテーブルはそのまま変更せず、集計バッチ用のテーブルを新規に追加する設計にすればいいだろう。
そうすれば、Redmine本体がバージョンアップしても、集計バッチとRedmineのインターフェイス部分だけ修正すればいいので保守コストは大きくないはず。

【元ネタ2】
「リポジトリ」を開くまでSubversion等のリポジトリへのコミットが「活動」に表示されません | Redmine.JP

小技(0.9): コミットと同時にリポジトリの情報を取得する | Redmine.JP Blog

Subversion Plugin - Jenkins - Jenkins Wiki

Twitter / @akipii: @haru_iida @yando @daipresentsさんが書かれているように、Redmineを大規模組織で使う場合、Redmineが業務システムになるが故にWebサーバーやSCMリポジトリなどのインフラ管理がボトルネックになってきます。TiDDの今後の課題ですね。

Twitter / @akipii: JenkinsのSubversion PluginでPost-commit hookを設定できるのか。この運用はTiDDにおけるNo Ticket No Commitをサポートしてくれるから非常に重要。

post-commit-hookはチケット駆動開発の発端となった機能だけにとても重要だが、post-commit-hook後にチケットとリビジョン連携の実装方法はいくつかある。
最も簡単な方法は、SCMコミット後に、ユーザがRedmineのリポジトリ画面をリフレッシュするタイミングで、SCM連携すること。
この方法では、開発者が逐一画面を開かないといけないので、運用が面倒な弱点がある。

もう一つの方法は、RedmineのWebサービス機能を使って、SCMコミットをトリガーとしてHTTP経由でSCM連携させること。
この方法なら、開発者がリポジトリ画面をリフレッシュする動作は不要になる。
しかし、SCMコミットの量が大きすぎたりすると、Redmine本体がダウンしてしまう可能性もある。

三つ目の方法は、JenkinsのSVNプラグインのように、CIツールでpost-commit-hookの機能を実施すること。
CIツールを使う利点は、SCM連携させるタイミング(トリガー)をイベントフックにしたり、定期的なタイミング(例えば5分おき)に変えたりできること。
また、バッチ処理化することで、大量データの処理も可能になること。

今後実現して欲しい機能は、RedmineにあるSCM関連のテーブルへデータ移行させるバッチ処理を作って、CIツールでキックするようにしたいこと。
そうすれば、例えば、プロジェクトの途中からRedmineと既存SCMリポジトリを組み合わせて運用したい場合、CIツールでSCMデータをRedmineへあらかじめデータ移行すれば、問題なく運用を開始できる。
また、もしSCMコミットの量が多い場合でも、例えば夜間にCIツールでSCMデータ移行のバッチ処理を実施すればいいだろう。

Redmineでソフトウェア開発のプロジェクト管理を運用していくと、運用対象が大規模組織になるほど、多分、集計バッチ処理のような機能が必要になってくると思う。
集計バッチ処理はとても複雑だが、我々SIが受託開発でやっているバッチ設計と所詮同じだ。
プロジェクト管理の問題をどこまでソフトウェアで解決できるのか、試してみたい。

【追記】
CIツールでSCM連携する場合、トリガーはpost-commit-hookのようなユーザのイベントだけでなく、ポーリングのようにCIツールがイベントを探して検知する方法もある。
CIツールをCron(定期的なタイマー(例:日次・月次))のように扱うだけでなく、ポーリングのように賢いツールが自動検知してくれる方が運用は楽。

ポーリングとは【polling】 - 意味/解説/説明/定義 : IT用語辞典

| | コメント (0) | トラックバック (0)

2011/10/09

補完チケット方式はチケット駆動開発の先祖返り

さかばさんの記事を読んで思ったことをメモ。

【元ネタ】
[#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011: ソフトウェアさかば

[#TiDD] チケット駆動でAdaptable Waterfall開発!: ソフトウェアさかば

いきなりBTS/ITSをベースに全ての作業をチケット化してタスク管理する完全チケット方式が難しい場合、補完チケット方式という手法がある。
補完チケット方式の具体例の一つは、テスト工程の障害管理。
又、チケット駆動開発をWF型開発に適用する場合、一番導入しやすいのはテスト工程の障害管理。

要件定義、設計、開発、単体テストと順調に進んでも、結合テスト以降のテスト工程は予期しないバグ修正や突然の仕様変更が頻発しやすい。
そこで、チケット駆動開発を導入したいなら、チケット管理システムをまさにバグ管理として導入して運用すればいい。
そうすれば、システムの修正にまつわるすべての事象、作業はBTSに集約され、ワークフロー管理でき、集計した結果から是正対策や予防対策を講じることもできる。

現代のソフトウェア開発ではITS/SCM/CIは必須ツールだと思うが、実際はBTSすら導入しておらずExcelでチマチマと課題一覧や障害一覧を保守しているプロジェクトも多い。
そんなプロジェクトには、いきなり完全チケット方式によるチケット駆動開発でAgileに開発するよりも、まずはBTSをバグ管理として運用する所から始めた方が確実だろう。

BTSで障害管理プロセスをきちんと学習できれば、バグ修正とバグ検証というコーディングパイプラインは、仕様変更にも新規開発にも運用保守にも拡張可能。
必ず二人の目を通して作業をチェックし合うというプロセスをスムーズに連携できなければ、チームで開発するのは難しいだろう。
そしてチケット駆動開発を意識すれば、BTSの機能を拡張したプラクティスを導入できて効果を発揮できるだろう。

BTSからチケット駆動開発へ進化した歴史から眺めれば、補完チケット方式は先祖返りの開発スタイル。
丁度、哺乳類が海から陸地に上がって進化した後、海に戻って活動領域を広げていったイルカやクジラに似ている。
でも普通の魚類とは違って、進化した哺乳類なのだ。

| | コメント (0) | トラックバック (0)

2011/10/08

3人以上ペアでやるとミスが多くなる

「3人以上でリリース作業するとミスが多くなる」という話を聞いたのでメモ。

【元ネタ】
開発でのメモ:リンゲルマン効果 - livedoor Blog(ブログ)

責任の分散とリーダーシップ。 - hituziのブログじゃがー

傍観者効果 - Wikipedia

XPにはペアプログラミングというプラクティスがあり、その導入は難しいと言われているが、普通のソフトウェア開発では、二人で作業する場面は結構多い。

例えば、システムのリリース作業やデータ移行、サーバー入替などの作業は2人がペアで作業する時が多い。
普通、一人が作業者でもう一人は手順書やチェックシートを見ながら作業を見守る。
あるいは、設計レビューをウォークスルーで行う場合、レビューアとレビューイの2人が行う。
あるいは、バグ修正とバグ検証は必ず別々で行ってバグを潰す。
二人でペアで作業するからこそ、二人の目による品質チェックが有効に効く。

しかし、3人以上になると、その効果が出ない場面が多くなるみたい。
リリース作業を3人以上でやると、作業者以外の2人は、もう一方が見ているから、と安心してしまって責任感が薄れるらしい。
集団になると、自分の力を全力で出さなくなったり、手抜きしてしまうらしい。
こういう現象はリンゲルマン効果と呼ばれるらしい。

2人で作業するのと3人で作業するのでは、意味合いが異なってくるというのが面白い。

| | コメント (0) | トラックバック (0)

Pivotal TrackerクローンのFulcrum をインストールしてみた

Pivotal TrackerクローンのFulcrum をインストールしてみたのでメモ。
インストールはちょっと苦労した。

【元ネタ】
wholemeal: Fulcrum

malclocke/fulcrum - GitHub

ストーリーベースのアジャイル開発に。Railsのプロジェクト管理「Fulcrum」 - MOONGIFT|オープンソース・ソフトウェア紹介を軸としたITエンジニア、Webデザイナー向けブログ

Pivotal Trackerに似ているツールFulcrum: プログラマの思索

【インストール】

まず、Ruby1.9.2が必須。Ruby1.9.1、ruby1.8.xではインストールに失敗する。
gem 1.6.2が無難。
また、Rails3.0.9が必要。gemファイルに書かれている。

pik (又はrvm)でRuby1.9.2をインストールしておく。
pik (又はrvm)なら、Rubyのバージョン単位にgemライブラリを保持してくれるので、Ruby1.8.7のRedmineの環境と共存できる。

又、sqlite.dllをRuby1.9.2のbinに入れておく。

cd C:\home\ruby\fulcrum
# Install the project dependencies
gem install bundler
bundle install

ファイルをリネームする
C:\home\ruby\fulcrum\config\database.yml

# Set up the development database
rake fulcrum:setup db:setup

uninitialized constant Rake::DSL
というエラーが出る

aptanaプロジェクトの削除方法、rails環境構築 - happy codingを参考にして、rakefileの require 'rake' の前の行に require 'rake/dsl_definition' を入れろ、とあるので入れた。

修正したファイルの内容は以下。

require File.expand_path('../config/application', __FILE__)
require 'rake/dsl_definition'
require 'rake'

rake:db に成功!

# Start the local web server
rails server

http://localhost:3000/ へアクセス後、
test@example.com
testpass
でログイン

ちなみに、gem list は下記の通り。
bundlerがGemファイルに書かれたGemライブラリを自動インストールしてくれるようだ。

*** LOCAL GEMS ***

abstract (1.0.0)
actionmailer (3.0.9)
actionpack (3.0.9)
activemodel (3.0.9)
activerecord (3.0.9)
activeresource (3.0.9)
activesupport (3.0.9)
arel (2.0.10)
bcrypt-ruby (2.1.4 x86-mingw32)
builder (2.1.2)
bundler (1.0.21)
cancan (1.6.1)
childprocess (0.1.9)
chunky_png (1.2.0)
compass (0.11.5)
devise (1.2.1)
diff-lcs (1.1.2)
erubis (2.6.6)
factory_girl (1.3.3)
factory_girl_rails (1.0.1)
ffi (1.0.9 x86-mingw32)
fssm (0.2.7)
i18n (0.5.0)
jasmine (1.0.2.1)
json_pure (1.5.2)
mail (2.2.19)
mime-types (1.16)
minitest (1.6.0)
mysql (2.8.1 x86-mingw32)
orm_adapter (0.0.5)
polyglot (0.3.2, 0.3.1)
rack (1.2.4, 1.2.3)
rack-mount (0.6.14)
rack-test (0.5.7)
rails (3.0.9)
railties (3.0.9)
rake (0.9.2, 0.8.7)
rdoc (3.9.4, 3.6.1, 2.5.8)
rspec (2.6.0)
rspec-core (2.6.4)
rspec-expectations (2.6.0)
rspec-mocks (2.6.0)
rubyzip (0.9.4)
sass (3.1.5)
selenium-webdriver (0.2.1)
sqlite3 (1.3.3 x86-mingw32)
sqlite3-ruby (1.3.3)
thor (0.14.6)
transitions (0.0.9)
treetop (1.4.10, 1.4.9)
tzinfo (0.3.30, 0.3.28)
warden (1.0.4)

【画面】
Fulcrum_taskboards_second

Fulcrum_edit_stories

Fulcrum_edit_project

【感想】
(1)使い方はよく分からない。

ストーリーカードは追加できる。
見積り時間にフィボナッチ数列で設定できる。

ステータスは下記がある。
unscheduled →リリースが未計画。Chilly Binに置かれる。
unstarted →バックログで優先順位付けされているが、タスクと認識されていない(?)
started →タスクを着手して開始。
finished →タスクが終了。
deliverd →受入環境へリリース済み。
accepted →受入環境でユーザが確認OK。本番リリースする。
rejected →受入環境でユーザがNG。タスクをstartedからやり直す。

但し、バックログやDoneにストーリーが入らない。ドラッグ&ドロップでバックログやChilly Binへストーリーを移動できない。
Velocityやバーンダウンチャートが表示されない。
バージョンが古いのかもしれない。

(2)Kanbanでは、イテレーション単位に仕掛り中タスクの上限チェックと、ユーザ単位にタスクがDoneしてから次のタスクに着手できる制約の2つが最低限ある。
しかし、今のFulcrumには、特にそのような制約はない。
誰でも複数個のタスクをアサイン可能。
バージョンが古いのかもしれない。

(3)デザインやGUIは気持ちいい。
Rails3からjQueryが使えるためなのか、インジケーターが出たり、カードを上下に移動させたり、細かな使い勝手が良い。
JavaやPHPで作られたWebアプリに比べると、RailsのWebアプリはデザインやGUIが優れていると思う。

他の人の感想も聞いてみたい。

| | コメント (0) | トラックバック (0)

2011/10/04

Bitbucket が Git に対応したらしい

Bitbucket が Git に対応したらしいのでメモ。

【元ネタ】
Bitbucket が Git に対応 - Atlassian Japanese Blog

bitbucketとTortoisehgは最強だ: プログラマの思索

BitBucketを使ってみる: プログラマの思索

TortoiseHgからBTSチケットへリンクできるようになった: プログラマの思索

TortoiseHgでExcelの差分を見る方法: プログラマの思索

TortoiseSVNの差分比較でWinMergeを使う: プログラマの思索

bitbucketの良い点は、プライベートリポジトリが使いたい放題なこと。
MercurialのWindowsクライアントTortoisehgはとても優れているので、ソースだけでなく、WordもExcelもPowerPointも全てbitbucketで構成管理した方がいい。
バックアップにもなるし、作業履歴が残るので推敲するのにとても役立つ。
WinMergeとTortoisehgを組み合わせれば、WordもExcelも差分比較してくれる。
bitbucketがGitに対応したことによって、分散バージョン管理の種類をあまり気にせずに構成管理できるインフラが整った。

構成管理の概念は最終的には、成果物やプロセスの変更管理につながる。
構成管理についてはもう一度考え直してみる。

| | コメント (0) | トラックバック (0)

« 2011年9月 | トップページ | 2011年11月 »