« 2011年10月 | トップページ | 2011年12月 »

2011年11月

2011/11/30

ITSと開発プロセスのマッピング

@yusuke_kokuboさんが分かりやすい記事を書かれていたのでメモ。

【元ネタ】
Issue Tracking Systemの利用パターン - こくぼ@Everything is the experience.

【1】RedmineやTracのようなITSは高機能でとても柔軟なため、いろんな状況で使い道がある。
チケット駆動開発の発端はTracのチケット管理であり、テスト工程のタスク管理をToDoリスト代わりに使う発想から生まれた。

チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

更に僕は、Redmineにチケット駆動開発を適用したらアジャイル開発が自然に運用できた経験をした。
そして、IT業界に限らず、営業・製造業・製薬業・情報システム部門などの色んな立場の人達がタスク管理だけでなく課題管理や要件管理へ適用しようとしている。

【2】Redmineにはプロジェクトやチケットの親子関係を作ることができ、バージョンで進捗率を表示している特徴から、要件やWBSへマッピングする考えはとても自然だ。
そのやり方は、3種類あることは下記の記事で書いた。

TiDD初心者によく聞かれる質問part2~チケットの粒度はどれくらいが妥当ですか?: プログラマの思索

つまり、@daipresentsさんのパーキングロットチャートプラグインを使うこと、@yusuke_kokubo さんが使いこなしているredmine_backlogsプラグインを使うこと、そしてAdvanced roadmapプラグインを使う3種類がある。

プロジェクト>バージョン>チケットという関係にプロセスをどのようにマッピングするか、という考えについては、@daipresentsさんも書かれている。

3年使ったRedmineの使い方について共有したい10のこと | 世界

【3】僕の経験からすると、WF型開発でMS Projectをバリバリ使っていた人はチケットの階層構造にWBSをマッピングする手法が好き。
Redmineのガントチャートはチケットの階層構造を綺麗に表示してくれるからだ。

Agile開発に特化している人はバージョンをイテレーションに見なすことを重視してチケットの階層や属性にあまり気を使わない。むしろ安定してリリースできることを重視する。

また、チケットをタスクカードとして扱いどんどん作業していくのがチケット駆動開発の発端だったが、チケットをストーリーカードとして扱う方法もある。
Pivotal TrackerやそのクローンであるFulcrumでは、チケットをストーリーカードとして扱う。
その使い方については下記で書いた。

Pivotal TrackerクローンのFulcrum をインストールしてみた: プログラマの思索

Pivotal Trackerとredmineの違い: プログラマの思索

その場合の運用ルールは、「No Ticket, No Commit」ではなく「No Ticket, No Release」(@kuranukiさん談)になる。
つまり、ストーリーカードを発行して着手しなければ、システムの一機能として反映されないのだ。

だが、ストーリーカードにも階層構造を付けたくなる場合もある。
アジャイルな見積りと計画づくり」では、ストーリーカードには「テーマ」「エピック」「ストーリー」の3種類が紹介されていて、それらはストーリーカードの階層構造を形成している。
だから、「テーマ」「エピック」「ストーリー」をRedmineチケットの階層構造へマッピングしてストーリー管理する運用方法も可能なはず。
試してみると面白いかもしれない。

ITSと開発プロセスのマッピングは、Agile開発や従来のSW開発の理論をベースに、実際の運用をイメージしながら適用してみればいい。
RedmineやTracという優れたツールのおかげで、色んなバリエーションの開発プロセスを運用できるし、状況に応じて開発プロセスを使い分ければいいのだ。

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

2011/11/27

アジャイル開発をERP構築に適用するには

InfoQにアジャイル開発をERP構築に適用する記事があったのでメモ。

【元ネタ】
Twitter / @akipii: アジャイル開発の利点は小規模リリースだけでなくプロダクトオーナーを含む体制にあると最近は強く感じる RT @bengkarita: アジャイルはERP構築失敗を防げるか http://bit.ly/sm3DEz #yam

InfoQ: アジャイルはERP構築失敗を防げるか

【1】ERPの特徴はいくつかある。
一つ目は、とても大規模で複雑なシステムであること。
ERPはその名の通り、1企業の基幹業務システムのパッケージ製品だ。
企業の業務で、製造や販売から会計までの全てをシステム化するから、大規模で複雑になりがち。
それゆえに、設計だけでなくプロジェクトの体制そのものも複雑化しやすい。

ERPに関しては、BPR、EA、SOAなどのバズワードがたくさん言われては消えていった。
新しい技術を取り入れたとしても、今動いているシステムを止めるわけにいかず、そう簡単に移行できない。
だから、SOAなどで古いシステムと新しいシステムを接続するアーキテクチャが持てはやされるが、その技術ですべての問題を解決できるわけではない。

エリック・エヴァンスのドメイン駆動設計」は、複雑なシステムをOOAの観点でモデル化して、その複雑さを見える化しようとする。
僕の個人的な考えとしては、ERPで重要なのは業務データであり、渡辺さんの本「業務システムのための上流工程入門―要件定義から分析・設計まで」や羽生さんの本「楽々ERDレッスン」に書かれているようなDOAのモデリング技法が根本的な解決策に近いだろうと思っている。

二つ目は、プロジェクトの体制も複雑になりやすいこと。
大規模な業務システムを作るには、共通フレームワークを独自に作り、その上で各業務をサブシステム化する手法が普通。
だから、共通フレームワークという基盤に熟知し、顧客と開発チームの間を取り持つアーキテクトという役割の人が必要になる。
だが、アーキテクトの能力を持つ人が各チームにいるわけではないから、開発チームがすぐに問い合わせたい時もすぐに回答が得られるとは限らなので、開発が滞りやすい。

また、顧客の側でも、たくさんの利用部門の要望を取りまとめて、経営戦略や予算や納期の観点から優先順位付けしなくてはならない。
その役割がプロダクトオーナーになる。
プロダクトオーナーがしっかりしていないと、それぞれの利用部門から開発チームへ要望が五月雨式に届くため、開発チームの作業負荷が大きくなるだけでなく、ERP全般のリリース計画を考慮していないから、デグレードや新機能の影響範囲の考慮漏れが発生しやすく、変更管理や構成管理の観点でも危険。

更に、ERPを受託するSIでも、開発チームの要員や予算を最終的に意思決定するプロジェクトオーナーという役割が必要になる。
プロジェクトオーナーは普通はプロジェクトマネージャと呼ばれる。
各チームのリーダーは、チーム自身で解決できない問題や、リソースやコストなどを増やしたい時、プロジェクトオーナーへ直訴して調整する時が結構ある。
だが、プロジェクトオーナーとチームリーダーの人間関係がうまくいかないと、体制上の問題が先送りされて、開発そのものが破綻してしまう危険もある。

三つ目は、ERP導入によって、顧客側の体制も大きく変わってしまうこと。
従来は手作業で行ってい会計3伝票による仕訳、工場の製造や納品作業の指示書を印刷して作業を指示する運用などが全てIT化されることによって、それらの作業の従事する人が不要になる。

例えば、会計業務ならば、正社員の事務女性が出張旅費などの精算していたのだろうが、その作業は派遣社員の事務女性に置き換わり、会計に関連する正社員は会計データの整合性チェックという役割に変わる。
つまり、IT化されて業務がなくなるだけでなく、業務の役割が変わることによって、高度な知識を持つホワイトカラーという役割へ変化する。
この組織上の変化に経営者だけでなく社員自身が対応出来なければ、本来の目的であるERPによる業務の全体最適化までたどりつかない。

このように、ERP構築は受託企業だけでなく顧客企業にとっても劇薬だと思う。

【2】上記の記事で興味を引いた箇所は次の二つ。

(引用1)
顧客への価値創造に費やした時間はとても少ないです。

(引用2)
最も重要なのはアジャイルの方法を身につけ、ERPを知悉しているPMがいることです。

前者は、プロダクトオーナーという役割が曖昧か、プロダクトオーナーという人が存在しないために、顧客の価値に直結する機能とは何なのか、という議論ができなかった点にあるのだろうと思う。

後者は、プロジェクトリーダーが単にアジャイル開発の運用方法を知っているだけでなく、プロジェクトオーナーやプロダクトオーナーと頻繁に調整して問題解決していく手法を持っているのが重要な点と示唆しているように思う。
また、プロダクトオーナーがアーキテクトの役割を持ってくれればいいが、いつもそうとは限らない。
だから、プロジェクトリーダーがアーキテクトの役割も兼ねて、ERPの設計思想の観点で要件を整理したり、開発の方針を決定することも大切だと思う。

そんなことを考えると、ERP構築にアジャイル開発手法を取り入れる場合、テスト駆動開発やデイリービルド、小規模リリースなどのような技術よりも、プロダクトオーナー・プロジェクトオーナー・アーキテクトと言った体制面の仕組み作りの方がもっと重要だろうと思う。

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

2011/11/23

メール駆動開発は時代遅れではないか

マネージャになるほど膨大な量のメールを処理するのが主な仕事になってくる。
また、SEの仕事の殆どは、顧客やメンバーからのメールや添付されたExcelを元に、設計書をどんどんブラッシュアップしていくことだ。
倉貫さんのつぶやきを読んで、同感すると共に、果たしてそれが本当に良いことなのかラフなメモ。

【元ネタ】
Twitter / @kuranuki: メールで5人とかに送って、ひとりtypoとかで届かなかったときの残念さったらない。もう一度5人に送り直すか、その人だけに送り直すか。前者は他の人にはウザいし、後者はこれからの返信に漏れるし。もう複数人でのメールやだ。

Twitter / @kuranuki: メールでは手紙で出来ること以上のことをやっちゃいけないんだよ。

Twitter / @kuranuki: メールのccにいつまで偉い人を入れておくのか判断が難しい。遠慮なく入れた方が良いのか、うざい筈なので早めに外すべきなのか。どの辺りまでいって外すのか。よくわからないから、とりあえず入れておくので、偉い人のメール時間は半端なく長くなる。愚かなり。

Twitter / @kuranuki: メールの対応だけであっというまに時間が過ぎる。それが仕事と言えば仕事だが、なんとかしたい。

PCの普及によって、従来の紙による伝達からメールによる伝達に変わった。
ホワイトカラーの仕事が、メールでのやり取りによって他者と調整する作業に変わった。

だが、メールの弱点は、情報が後入れ先出しになりやすいこと。
毎日100通以上メールが届く場合、最新情報から精査していくから、過去メールの理解や判断に手間取りやすい。
1週間メールを見なければ、1千通以上のメールが蓄積されてしまって、1日がメールの理解だけで終わってしまう場合もある。

POP3、SMTPと言うメールの仕組みも現代のネットワーク技術からすれば、かなり古いプロトコルだ。
FacebookやTwitterなどのSNS技術の方が、自分に関係する人達へ情報を素早く伝達することができる時代になっている。

SEは元メールにレスしながら、メールにある要件や問合せがどのように変化して結論に至ったのか、という履歴を残していく。
その変更履歴を辿りながら、本来のあるべき仕様や結論を導きだそうとする。
だから、SEの作業のかなりの割合を占めるメールの履歴を調査する作業は変更管理の一部ではないか、と思う時がある。
殆どのSEはメール駆動開発をやっているのではないか、と思えるぐらいだ。

でも、メールでやり取りする内容は、本来はITSチケットやWikiに書かれるべきものだと思う。
何故なら、議論のやり取りと成果物の修正履歴をリンクさせることができれば、より深く変更履歴を理解しやすくなる。
また、議論した結果をWikiにまとめれば、チーム全体に情報共有しやすくなるし、ITSで全文検索できるから情報が蓄積されるほど資産になる。

変更管理という作業をどこまでチケット駆動開発が吸収してカバー出来るのか、色々考えてみたい。


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

Redmine Commit Relation Editor Pluginで変更管理を強化する

@haru_iidaさんがRedmine Commit Relation Editor Pluginという有用なプラグインをリリースされたのでメモ。

【元ネタ】
Haru's blog: Redmine Commit Relation Editor Plugin 0.0.1をリリースしました。

r-labs - Commit Relation Editor - Redmine

Twitter / @kzgs: MLで以前質問していたものがまさに見つかった感じです RT @haru_iida: Haru's blog: Redmine Commit Relation Editor Plugin 0.0.1をリリースしました。 http://bit.ly/vqzxjT

(引用開始)
Redmineではリポジトリのコミットメッセージにチケット番号を入力することでコミットとチケットの関連付けを行うことができます。チケット駆動開発の合言葉「No ticket, No commit」が示すようにこの関連付けは非常に重要です。
しかしコミットメッセージに入力するチケット番号を間違えたり、番号を入れ忘れたりすると後から関連付けを修正することができず悲しい思いをします。
このプラグインを使用するとリポジトリブラウザ上から新たにチケットを関連付けたり既存の関連付けを削除したりできるようになります。
(引用終了)

チケット駆動開発の発端となった運用ルールである「No ticket, No commit」を実践する場合、コミットログに「refs #12」「fixes #23」のようにチケットNoを書くようにする。

しかし、チケットNoを誤って書いたり、#を大文字で書いたり、間違える時がある。
すると、せっかくの変更履歴が本来のチケットとリンクしなくなる弱点があった。
現状は、チケットに本来のリビジョンを「r123」のように書いてチケット画面からリンクするする手法しかフォローすることができなかった。

だが、上記のプラグインのおかげで、間違ったチケットNoでコミットログを書いても、後から修正できるようになる。
そうすれば、チケットとバージョン管理のリビジョンを本来のあるべき姿でリンクさせることができるから、トレーサビリティを強化することができる。

このトレーサビリティという概念は最終的には変更管理プロセスを補強することにつながる。
何故なら、例えば、何故こんな汚いパッチを当てたのか、何故本来の要件がこんな複雑な仕様になってしまったのか、という変更履歴をチケットと成果物の修正履歴から辿ることができるからだ。
その作業によって、例えば、今回のバグ修正では過去のパッチを安易に修正してはいけない、とか、技術上の制約から本来の要件が現在の仕様に変わったので今回の仕様変更も同様に考慮する必要がある、などと言った判断を自信を持って説明することができる。

アジャイル開発では、頻繁なリファクタリングと小刻みな機能改善を同時並行で開発しているので、ソースはどんどん成長して変化していく。
だから、Git/Mercurialで並行開発をサポートするだけでなく、RedmineやTracで変更履歴を後から調査しやすくする環境を作ることはとても重要だと思う。

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

2011/11/20

再見積もり、Velocity、そしてアジャイルな契約

見積りや生産性を突き詰めていくと、どうしてもアジャイル開発に向いている契約は何か、という話になる。
ラフなメモ書き。

【元ネタ】
InfoQ: VelocityによってAgileは死んでしまうのか?

Martin Fowler's Bliki in Japanese - 生産性は計測不能

【1】WF型開発では、見積りのタイミングは2回ある。
1回目はシステム提案、2回目は外部設計終了時点。

システム提案時は、不確実な情報の中で大まかな概算見積を行い、外部設計終了まで委任契約で作業し、内部設計や開発以降は請負契約にするのが普通だろう。
何故なら、システム提案時の見積りはあまりにも不確定であり、SIにとっても顧客にとっても合意しづらいから。
だから、外部設計終了時点で、開発対象のスコープが確定後に再見積を実施して、開発の金額を確定して、請負契約にする。

委任契約は成果物責任がないので、外部設計終了時点まではシステム営業に近い。
作業にかかった工数だけ顧客からお金をもらう。
とはいえ、顧客も無駄にお金を払いたくないから、元請けのSIで優秀なSEが少人数で設計して、あまり時間をかけずに要件を固めるのが普通だろう。
そして、要件が確定後に請負契約に切り替えて、SIへ成果物責任を課して、システムを製造してもらう流れになる。

請負契約ゆえに支払い金額の上限があるから、仕様変更が積み重なって当初の要件スコープよりも増加すればコストが増えて赤字なってしまう。
だから、再見積もりの数字はとても重要であり、ベースラインとして保持し、その後の仕様変更で再見積もりするたびにベースラインを変更管理していくことになる。

【2】アジャイル開発でも見積もりは当然行う。
アジャイル開発で再見積りのタイミングは、ストーリーの相対規模に変化があるとチームが判断した時だ。
アジャイルな見積りと計画づくり」では再見積もりのタイミングについて説明がある。

例えば、あるイテレーションで開発中に、グラフ化の処理実装が実はとても難しく、当初の見積の2倍以上かかると分かったとする。
つまり、該当ストーリーの規模が実は大きかったと判明した時、ストーリーポイントを変更する。

但し再見積りの注意点は幾つかある。
一つは、全てのストーリーの規模(ストーリーポイント)と整合性を取ること。
ストーリーポイントは相対規模の見積りなので、一つのストーリーポイントを変更すれば、他のストーリーの規模見積りにも影響がある。
例えば、3ポイントを6ポイントに変えたストーリーがあったら、他の3ポイントのストーリーは変更したストーリーと同様に2倍すべきなのか、それとも別の値にすべきか判断する必要がある。
そうしなければ、相対規模の見積りというストーリーポイントの見積りに一貫性が無くなってしまい、Velocityの計算が狂ってしまう。

もう一つは、部分完了したストーリーの扱い。
基本は、All or Nothing。
つまり、完了したらVelocityに含めるし、未完了ならば0ポイントと見なしてVelocityに含めない。
何故ならアジャイル開発における完了条件とは、顧客へ動くシステムを納品すること。
だから、仕掛り中の機能は顧客から見ればコンパイルエラーのソースと同じく、まともに動かないから価値がない。
この意味では、アジャイル開発の完了条件はWF型開発のそれよりも厳しい。

但し、イテレーション終了時点で部分完了したストーリーポイントをVelocityに含めたい場合もある。
部分完了したストーリーポイントは現在のVelocityに加算されず、次のVelocityに反映される可能性が大きい。
つまり、現在のVelocityは予想よりも少し下がり、次のVelocityは予想よりも少し高くなるだろう。
すると、Velocityがあくまでも開発の平均速度であり、特定のイテレーションのVelocityに特別な意味がないことを分かっているチームならば、特に問題はないだろう。

だが、部分完了したストーリーを次のイテレーションで継続開発しない場合、現在のVelocityに入れたくなる。
この時、部分完了したストーリーを完了部分と未着手の部分で分割する方法を「アジャイルな見積りと計画づくり」では勧めている。
つまり、分割したストーリーのうち、部分完了したストーリーポイントを現在のVelocityへ反映し、未着手のストーリーは次回以降に回す。
分割対象のストーリーは再見積もりを実施するので、前回のストーリーポイントよりも値が上回っても構わないと「アジャイルな見積りと計画づくり」と説明している。

但し、注意点は、未完了のストーリーポイントをVelocityに含めないようにするのが大前提。
更に、部分的にストーリーポイントを加算してもVelocityに大きなブレが発生しないように、ストーリーを細かい粒度で見積もりしておくのが大事。
そうすれば、Velocityの値に一喜一憂することも無い。

アジャイルな見積りと計画づくり」を今頃になって何度も読み直して、とても奥が深いと改めて感じている。
WF型開発でプロジェクトマネジメントの経験がある人でも、「アジャイルな見積りと計画づくり」はお薦めだと思う。

【3】InfoQ: VelocityによってAgileは死んでしまうのか?の記事では、Velocityを開発チームの生産性と拡大解釈した場合の短所を説明している。
この議論の結論は、Martin Fowler's Bliki in Japanese - 生産性は計測不能で既に書かれている。

僕の理解では、Velocityとは特定のチームが特定の期間で開発した時の生産性に過ぎない。
つまり、時間と場所がかなり限られた場合でしか、Velocityの数値は意味をなさない。
他チームの開発や将来のシステム開発にVelocityを適用しても、あまり有意義な結果は得られないだろう。

でも、Velocityという値を他チームにも流用したくなるのは人間の性なのだろう。
そのアンチパターン「メトリクスの罠」については下記で書いた。

メトリクスの威力: プログラマの思索

チケット駆動開発のアンチパターンpart2: プログラマの思索

この考え方は、哲学における認識論や真理の考え方と同じだと思う。
哲学者が考えぬいた真理も、所詮は特定の時代で特定の場所でしか有効でない。

ずる賢い人ならば、その概念を自分にとって都合の良い状況へ当てはめて、歪曲させるだろう。
生産性の概念は諸刃の剣だと思う。

【4】再見積もりにも関わるソフトウェア開発の契約については、色々議論がある。
現状のソフトウェア開発の契約は委任契約か請負契約しかなく、アジャイル開発に向いた契約スタイルではない。
顧客に価値があるシステムを早く定期的に納品することを信条とするアジャイル開発では、成果物責任が発生しない委任契約は無意味だし、スコープを調整できない請負契約は要件やリスクの変化を制御しにくい。

PMBOKの調達管理でも、何種類もの契約スタイルがあり、発注者と受注者のどちらが有利なのか、という観点で整理されて説明されている。

とはいえ、IPAの委員会で平鍋さんがアジャイル開発に向いた契約スタイルについて、議論するだけでなく、提案している内容はとても価値があると思う。

アジャイル開発の契約スタイルに関するIPAの報告書: プログラマの思索

・非ウォーターフォール型開発WG活動報告書(概要資料) (PDF形式)[858KB]

・非ウォーターフォール型開発WG活動報告書 (PDF形式)[5.05MB]

個人的な考えとしては、日本の製造業を真似た契約スタイルは、WF型開発と多重下請構造にとてもマッチしているのだろうが、欧米だけでなく日本でも最先端を走るソフトウェア企業がアジャイル開発へ舵を切っている現在、時代に合わなくなっているのだろうと思う。

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

2011/11/17

SOAPからRESTへ

InfoQの記事「InfoQ: SOAP から REST へ - その方法と意義」が良かったのでメモ。

【元ネタ】
InfoQ: SOAP から REST へ - その方法と意義

次世代Webフレームワークの設計思想~RESTful Webサービス: プログラマの思索

REST思想とHTTPメソッドの関係: プログラマの思索

Ruby on Rails + Curl リッチクライアントCRUDアプリを作成する(1/5):CodeZine

RedmineのRESTful APIを使う: プログラマの思索

SOA(サービス指向アーキテクチャ)はバズワードだ。
SOAこそが今後の設計の将来だ、と言われた時期があったけれど、結局使いづらかったのではないか。
SOAを支えるエンタープライズ系技術としてSOAP、WSDLなどが声高に叫ばれたが、結局廃れてしまったか、傍流の技術になってしまったように思う。

渡辺幸三さんもDOAの立場から、SOAと言うWebサービス経由のシステム設計で、業務システム設計の全てが解決できるわけではなく幻想に近い、と言われていたのを思い出す。

データをXML形式でHTTP経由でやり取りするのは、確かに設計は綺麗なのだが、プログラムはかなり泥臭いし、結構工数もかかる。

対照的に、草の根的に発展してきたRESTはRuby on Railsの歴史と重なる。
RESTの解説はRailsを生み出したDHH(デビッド・トーマス)のRuby会議の資料がとても分かりやすかった。
#但し、何故か今はリンクが切れてしまって読めなくなっている。

Rubyist Magazine - 日本 Ruby カンファレンス 2006 特別号

Rails 勉強会@東京 #7 ポジションペーパー

RESTは、HTTPもDBと同様にCRUD操作があるという前提で作られている。
Railsは、DBを操作するActiveRecordと、HTTPを操作するRESTを故意に同一視して、URLを叩けば即座にDB操作できるような仕掛けを作っているのがすごい点だと思う。

InfoQ: SOAP から REST へ - その方法と意義の記事によれば、最近のWebAPIはRESTが圧倒的らしい。
Railsを改めて振り返ると、とてもエポックメイキングなWeb技術なのだな、と思う。

【追記】
@yohshiyさんがr-labs でRedmine REST APIを翻訳して公開されていた。
Redmine REST APIの機能は未完成だけれども、その可能性はとても大きいと思う。
RESTが使い物になれば、外部システムとの連携やスマートフォンからの接続もより簡単に実装できるだろう。

r-labs - Redmine REST API - Redmine

プログラマーズ雑記帳 Redmine REST API の翻訳

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

2011/11/15

バーンダウンチャートのパターン集

バーンダウンチャートを見れば、チームの進捗だけでなく、チームの成熟度やその後の予測もある程度可能だ。
良い記事があったのでメモ。

【元ネタ】
InfoQ: バーンダウンチャートを解読する

理想ラインが加わったredmine_version_burndown_charts画面: プログラマの思索

最初に、3パターンが紹介されている。
一つ目は、スプリント終了時に残作業量がゼロにならなかったケース。
例えば、スプリント後半にバグが頻発して、計画通りに作業が進まず、重大なバグを解決できずにリリースできなかった状況があるだろう。

二つ目は、スプリント前半は残作業がかなり残って遅延していたが、スプリント中盤からいきなり急角度で残作業が減っていき、最終的にゼロになったケース。
結果オーライかもしれないが、記事では次のように解説している。
「おそらく彼らは積極的に数字を更新することをしなかったことを示す。彼らが残った作業の量を更新するのを怠ったか、スプリントの終わりに近づくにつれてたくさんのユーザストーリーが放棄されたのだ。」
つまり、バーンダウンチャートの最新化を積極的に行わなかったという事実を見ると、チーム自身が今どれだけの作業が残っていたのか、を自覚できていなかったのではないか。

三つ目は、予想線と実績線があまり離れずに最終的にゼロになったケース。
当初の予定通りにスプリントが終了した状況になるだろう。
だが、僕の経験からしても、スプリント(イテレーション)計画通りにいつも開発が進むとは限らない。
むしろ、残作業量が暴走してしまわないように、必死にコントロールしようとしているのが普通だろう。
特に、初めてのWebフレームワークを使う開発、初めてのスマートフォンアプリの開発、新規顧客の業務システム開発などの場合は、当初の計画で全てが見通せるわけがない。

更に記事では下記のパターンが紹介されている。

(引用開始)
1. フェイキーーフェイキー(Fakey-Fakey) ・・・ 完成に向かう完璧な下り坂によって特徴づけられる。ソフトウェアプロジェクトがゴールに向かってまっすぐ進む程度に複雑である。多くの場合、このグラフは命令や統制の激しく、オープンなコミュニケーションは珍しいような環境において現れる。
2. 遅い学習者(Late-Learner) ・・・ これはグラフの後ろの方にあるこぶによって特徴づけられる。効率的にコミュニケーションをとり、スクラムを学ぼうとしているチームに一般的である。
3. 中間学習者(Middle-Learner) ・・・ これは中程にあるこぶによって特徴付けられ、遅い学習者に比べると成熟していることを示す。このチームは多くの作業や複雑さをスプリントの中頃に発見する。
4. 早期学習者(Early-Learner) ・・・ 早期のこぶとその後の緩やかなバーンダウン。このチームは早期の発見の重要性を理解しており、チームのゴールを達成するために効果的に動いている。
5. 高原(Plateau) ・・・ このチームは最初はよい進捗を見せるが、その後スプリントの後半で失速する。
6. ネバーーネバー(Never-Never) ・・・ これはバーンダウンがスプリントの終わりに向かって突然上昇し始め、下りてこないようなときのことである。この遅い変化は最初に起こす必要があり、また、レトロスペクティブの一部として扱う必要がある。
7. スコープの増大(Scope-Increase) ・・・ これはスプリントの間でいきなり作業量が増加することで特徴づけられる。これは普通、チームがスプリント計画会議中にコミットした作業のスコープを完全に理解していなかったサインである。
(引用終了)

興味を惹いたのは、「遅い学習者」「中間学習者」「早期学習者」。
いずれもScrumを学習してマスターしようとしているチームなので、最終的には成功裏に終わるのだが、微妙にニュアンスが違う。
「こぶ」は進捗の遅延から発生した残作業量だから、当初の計画と実際の開発のギャップを表す。
上記のパターンでは、スプリント前半でギャップが出るほど良いと評価している。
理由は、リスクを早期発見すればすぐに対処できるだけでなく、一つのリスク対策を学習したことになり、残りの期間で学習結果を実践できるからだろう。

バーンダウンチャートが理想通りのグラフになるためには、正確性の高い見積りと緻密な計画、そして常にその計画を最新化していくのが大切なのだろう。
バーンダウンチャートの事例を集めてみると面白いのかもしれない。

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

2011/11/14

Eclipseは未だに進化し続けている

Eclipseの記事を見つけたのでメモ。

【元ネタ】
InfoQ: Eclipseの10年

Pleiades - Eclipse プラグイン日本語化プラグイン

Strutsが出現して注目され始めた2002年頃、フリーのJavaの統合環境Eclipseも注目され始めたのを覚えている。
それまでプログラマの統合環境はMSのVisualStudioしかなかったから、Eclipseがフリーで提供されたことはとても画期的だった。
僕も雑誌やらネットやらで、Eclipseを使いこなそうと調べた時があった。

Eclipseで、JUnitの使い方を覚えてテスト駆動開発の概念やそのプログラミング技法を学んだし、リファクタリングの技法も覚えた。
Webサーバー上のwar/earファイルをリモートデバッグする技術に触れて驚いた時もあった。
だからすごく懐かしい。

それから10年経つ。
Eclipseには、Javaだけでなく、C++/Ruby/Python/PHPなど他言語の統合環境も無料で提供されて、より使い易くなった。
AdobeAirの統合環境であるFlashBuilderでさえも、EclipseのGUIが基盤になっている。

こういう無料の統合環境がプログラミングの敷居を下げて、やる気さえあれば誰でもプログラミングできる時代になったのはとても良いことだと思う。
今やプログラミング言語は、英語のような外国語を学ぶのと同じレベルになったのだから。

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

@IT連載記事「かんばん!~もし女子高生がRedmineで「スクラム」開発をしたら」

@ITにRedmine+Scrumの記事が書かれていたのでリンクしておく。
タイトルは「もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら」をもじっているような気がする(笑)

【元ネタ】
かんばん!~もし女子高生がRedmineで「スクラム」開発をしたら

高校生になって初めてスクラムを始めました~「ストーリー」で何を作るかまとめよう (1/3) - @IT

Twitter / @itmedia: 【@IT】かんばん! もし女子高生がRedmineで「スクラム」開発をしたら http://bit.ly/skDkG3 本連載は女子高生の姉妹が今注目のアジャイル開発手法であるスクラムとプロジェクト管理ソフトの「Redmine」を使ってシステム開発をするというフィクションです

妹のまいん(Redmineをよく知っている?)が仕切って、姉のぷりんとScrumで開発していくストーリーみたい。
果たして、チケット駆動開発という概念の説明は出てくるのだろうか?
今後の展開が期待大。

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

2011/11/12

git-flow による構成管理とRedmineの関係

「git-flow によるブランチ管理」という記事で、分散バージョン管理ツールを使った構成管理手法をとても分かりやすく書かれていた。
以前僕が書いた記事を見直して、理解が足りなかった部分があったと感じたので、もう一度まとめてみた。

【元ネタ】
git-flow によるブランチの管理 - O'Reilly Japan Community Blog

A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind

見えないチカラ: A successful Git branching model を翻訳しました

A successful Git branching model: プログラマの思索

Mercurialで独立並行リリース管理: プログラマの思索

Mercurialによるチケット駆動開発は強力だ!: プログラマの思索

チケット単位に並行開発する事例: プログラマの思索

Subversionのブランチを有効活用してアジャイルに開発せよ: プログラマの思索

【0】git-flow によるブランチの管理 - O'Reilly Japan Community Blogによれば、目的別にブランチを作って開発&リリースしていく。

(引用開始)
git-flow では、中央と みなす リポジトリ origin を作成することで、この長所を取り入れています。
origin には master, develop という 2 つの メインブランチ を保持します。

(1)master: リリースブランチ。プロダクトとしてリリースするためのブランチ。リリースしたらタグ付けする。集中型でいう trunk、tag。
(2)develop: 開発ブランチ。コードが安定し、リリース準備ができたら master へマージする。リリース前はこのブランチが最新バージョンとなる。

各開発者は master, develop の他に、フィーチャーブランチ、リリースブランチ、ホットフィックスブランチという サポートブランチ を利用し分散開発します。このブランチは最終的には破棄されます。各ブランチの目的は

(3)フィーチャーブランチ: 機能の追加。 develop から分岐し、 develop にマージする。
(4)リリースブランチ: プロダクトリリースの準備。機能の追加やマイナーなバグフィックスとは独立させることで、リリース時に含めるコードを綺麗な状態に保つ(機能追加中で未使用のコードなどを含まないようにする)ことができる。 develop ブランチにリリース予定の機能やバグフィックスがほぼ反映した状態で develop から分岐する。リリース準備が整ったら, master にマージし、タグをつける。次に develop にマージする。
(5)ホットフィックスブランチ: リリース後のクリティカルなバグフィックスなど、現在のプロダクトのバージョンに対する変更用。 master から分岐し、 master にマージし、タグをつける。次に develop にマージする。

となります。このサポートブランチにより、マージ、コミットすべきブランチを明確化することができます。
(引用終了)

【1】構成管理パターンについて唯一解説している本「パターンによるソフトウェア構成管理」で上記の概念を翻訳してみる。
Redmineによるタスクマネジメント実践技法」の構成管理パターンとほぼ同等だ。

(1)master

パターンによるソフトウェア構成管理」では「リリースブランチ」に相当する。
つまり、本番環境で動くソースそのものであり、開発チームが裏でガンガン開発中のソースとは異なる。
普通の運用保守では、ステージング環境(UAT:受入環境)が本番環境と同等な環境として作られており、本番障害が発生した場合、その環境でバグを再現させたりする。

git-flowで特徴的なのは、リリースブランチのライフサイクルはtrunk(develope)と同じ寿命であること。
リリース時は必ず、ユーザが運用しているブランチへパッチをマージさせてタグを打ってリリースする運用になる。
この運用の利点は、品質が安定したソース(master)が存在しているので、新規開発やリファクタリングを実施するtrunkと別運用できることだろう。
アジャイル開発では、新規機能の実装やリファクタリングが頻繁に行われるため、品質重視のブランチとまだ品質が安定していないブランチを分けて開発する方がリリース作業も楽になる。

僕がSubversionでメインラインモデルを運用していた時、リリース時はtrunkから必ずリリースブランチを作り、そのリリースブランチの寿命は次Verまでと限定していたが、git-flowの運用の方が安全だろうと思う。
masterの運用が可能なのも、Gitのマージ機能がとても強力だからという理由もある。
SVNは今もマージ作業はGitほど楽でないから。

(2)develope

パターンによるソフトウェア構成管理」では「trunk」に相当する。
つまり、最新の機能が反映されていて、ほぼ常時リリース可能なブランチになる。
開発者はdevelopeを本流と見なして、どんどんコミットしていく。あるいは、developeから自分だけの開発ソースを派生させたりする。
更に、trunkは継続的インテグレーションで常に常時リリース可能なブランチにして、品質を維持しているのが重要だろう。

(3)feature

パターンによるソフトウェア構成管理」では「タスクブランチ」に相当する。
よくある例は、顧客から突然大きな仕様追加が要請されて、新規開発中のソースと並行でその仕様追加を開発しなくてはならない状況でfeature(タスクブランチ)を使う。
つまり、trunkでは従来通りの新規開発、feature(タスクブランチ)上で仕様追加の開発とブランチを分けて並行開発していく開発スタイル。
feature(タスクブランチ)を使う状況は「Redmineによるタスクマネジメント実践技法」で詳しく書いた。

変更要求に対する選択肢: プログラマの思索

新規機能の開発は全てfeature(タスクブランチ)上で行えば、他の開発に影響を与えず、複数の開発者が並列に開発できる。
SVNでもfeature(タスクブランチ)を使う状況はあるけれどその難易度は高かった。
でも、GitやMercurialでは複数ブランチで並行開発して、最後に本流(trunk)にマージする一連の作業はとても自然だ。
この運用が可能なのも、GitやMercurialではブランチ管理やマージ機能が強力だからだ。

(4)release

パターンによるソフトウェア構成管理」では「リリース準備ブランチ」に相当する。
よくある例は、ソフトウェアの開発がほぼ完了したものの、残作業としてインストーラー作成やデプロイのための作業が残っていたりする時、trunkからリリース準備ブランチを切り、リリース準備ブランチ上で残作業を仕上げてリリースしていく。
あるいは、エラーメッセージの修正や画面のデザイン修正など、あとは細かな修正で品質を上げていく作業が残っていた場合、trunkからリリース準備ブランチを切り、リリース準備ブランチ上で後追いテストを実施して、できるだけ品質を上げていく戦略を取る。

リリース準備ブランチの利点は、残作業と新規開発を分けて並行開発できることと、リリースされたらリリース準備ブランチがそのままリリースブランチになるので、新規開発と運用保守の並行開発へすぐに切り替えられること。
git-flowでは、リリース準備ブランチでリリース準備が完了したらリリースブランチ(master)へマージされて廃止される運用になる。

Redmineの開発でも、メジャーVersionのリリース前にtrunkからリリース準備ブランチが切られて、残作業はリリース準備ブランチへ反映させたり、その後のマイナーバージョンアップはリリースブランチ上で行われている。
その理由は、Redmineの開発はSVNで行われている点があるからだろう。

(5)hot fix

入門Git」では「トピックブランチ」に相当する。
よくある例は、本番障害が発生したので、緊急で障害修正を実施して本番リリースしなくてはならない状況で使う。
git-flowでは、master(リリースブランチ)から派生させたトピックブランチ上で修正し、修正が完了したら、リリースブランチとtrunkへマージする。
注意すべき点は、トピックブランチ→リリースブランチ・turnkへマージするのであり、トピックブランチ→trunk→リリースブランチのようなマージ順序ではないこと。
トピックブランチで作ったパッチ、つまりソースの差分情報が重要なのであり、そのパッチでマージするようにする。
このパッチを育てるためにわざわざトピックブランチ上で作業したのだから。

【2】チケット駆動開発の観点では、トピックブランチはチケット単位で作られることになるだろう。
本番障害は1個のバグチケットで起票されるから、1チケットでその後の修正は管理されていくからだ。
つまり、プロジェクト単位ではなく、チケット単位でブランチが作られることになるだろう。

また、チケット駆動開発の観点では、masterは保守プロジェクト、developeは開発プロジェクトでRedmineプロジェクトを分けた方がタスク管理が楽だろうと思う。
本番運用のソースに関するタスク管理と新規開発のタスク管理はそもそもタスクの観点が全く異なるからだ。
また、実際のチーム運営でも、システム規模が大きいほど、運用保守チームと新規開発チームで分けられている時も多いから、Redmineプロジェクトを別々にして各チームのタスク管理と一致させるようにした方が運用は楽だろう。

構成管理手法とRedmineの運用に密接な関係がある理由は、ブランチ上で履歴管理されているソースや成果物の変更は全てRedmineチケットに起票されて、その後の変更管理は全てRedmineで管理されるからだ。
つまり、SVNやGitリポジトリの管理下にある全ての成果物(ソースも設計書もビルドスクリプトもその他全部)の変更管理は、チケットのタスク管理という仕組みを通じて、Redmineが代用していることになる。

Redmineによるチケット駆動開発を実践してみると、構成管理手法とRedmineの運用に密接な関係があることを経験できたし、その関連性を深く考えていくのが面白い。

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

2011/11/11

プログラマにコミュニケーションが足りないと言われる時

IT業界で働く技術者は営業マンでないのに、コミュニケーション能力が必要とよく言われる。
特に、プログラマのプログラミング能力が優れていても、実力を発揮できないとき、君はコミュニケーション能力が足りない、とよく言われる。
その理由について考えたことをラフなメモ書き。

【1】営業マンにコミュニケーション能力が必要と言われるのは、初対面の顧客へモノを売りつける必要があるから。
いかに信頼して買ってもらえるか、人間関係の構築作りに力を入れる。

だが、IT技術者に必要とされるコミュニケーション能力は、営業マンのそれとは全く違うと経験的に思う。
自分よりも上位職の人へ働きかける政治力をすごく要求されるのだ。

特にプロジェクトリーダー、そしてプロジェクトマネージャのように上位の管理職になるほど、自分よりも上位職の力を借りて組織を動かす能力が必要とされる。
以下、どんな状況でそのようなコミュニケーション能力が必要とされるのか、あげてみる。

【2】課題や仕様の不明点をプロジェクトリーダーに解決してもらえない

プログラマが仕様書に従って実装すると、必ず仕様書で不明点が出てくる。
細かな仕様の部分を自分たちで勝手に決めていいのか、プロジェクトリーダーを通じて顧客へ仕様確認すべきか、判断に迷う時がある。

また、仕様書の品質が低い場合、実装してみたらあちこちに穴があり、仕様の整合性が取れておらず矛盾している点があったりする。
そんな時は、プロジェクトリーダーを通じて、本来あるべき仕様に修正してもらわなくてはならない。

すると、プログラマがプロジェクトリーダーに、課題を解決してもらうように働きかけないといけないのだが、信頼関係がなければ、プログラマの思い通りにプロジェクトリーダーは動いてくれるとは限らない。

例えば、開発チームが元請けのリーダーと下請けのプログラマのように風通しが悪かったり、開発者や設計者同士でも信頼関係がなったりする時もある。
すると、プログラマが見つけた課題を報告したのに伝わっていなかったり、課題の重要性や緊急性を認識しないまま放置してしまう時もある。

そして、課題が解決されないまま、開発の進捗が遅れたり、テスト工程の後半になって大きなリスクとなって判明するパターンに陥る。

【3】要員の動員や予算増額をプロジェクトオーナーに承認してもらえない

プロジェクトリーダーが要件定義や外部設計で要件を詰めている時、システムの経験者を早めに入れたいとか、工数見積もりしたら開発工数が大幅に増えるので人員を増やすために予算を増額したい、などの状況が出てくる。
すると、プロジェクトリーダーの上司に当たるプロジェクトオーナー(実際は部長クラス)へ働きかけて、開発チームを円滑に回すような仕組みを整備してもらいたいのだが、プロジェクトリーダーの思い通りにプロジェクトオーナーが動いてくれるとは限らない。

プロジェクトオーナーにとって、組織の人員を一プロジェクトの都合で決めるわけにはいかないし、何故人員を増やしたいのか、その理由に正当性がなければ、そもそも予算を増額してくれはしない。
プロジェクトリーダーは見積り工数の正当性をプロジェクトオーナーへ分かりやすく説明しなければならない責任があるのだが、要件定義における工数見積りは正直正確さに欠けるので説得しづらい。

結局、本来のシステム規模とアンバランスな開発チームで体制を作らざるを得ず、開発やテスト工程で火を噴くパターンに陥る。

【4】変更要求のスコープや優先順位をプロダクトオーナーに調整してもらえない

受託開発の開発チームのマネージャ(又はリーダー)が、要件定義や外部設計で要件を詰めている時、顧客の情報システム部門の窓口に当たるプロダクトオーナーへ、納期やビジネス要件の制約から、工数見積りが大きい機能の開発を後回しにしたり、故意に2段階リリースを選択して段階的に機能拡張していく戦略を提示したりする状況がある。
しかし、顧客にしてみれば、ITのプロに任せているのに何故それぐらいの機能でそんなに工数がかかるのか分からない、とか、やはりこの機能が最優先だ、と言われて、こちらの提案通りにいかない時がある。

あるいは、開発工程に入って、ユーザ部門から度重なる変更要求がやってきて変更管理の手順を守らない場合、変更要求を受け入れて開発する手順を守ってもらうように、プロダクトオーナーへユーザ部門の取りまとめや周知徹底を依頼する時がある。
しかし、肝心のプロダクトオーナーが自分の会社の数多くのユーザ部門を取りまとめる権限がなかったり、その責任を果たせない場合、仕様変更が五月雨式に落ちてきて開発チームが混乱する状況をマネージャすらも制御できなくなる時がある。

特にアジャイル開発では、顧客にプロダクトオーナーの役割を強いる。
プロダクトオーナーは本来自分の会社の業務をモデル化でき、その優先順位を付けることができるくらい業務に詳しくないといけない。
つまり、プロダクトオーナーはアーキテクトの役割も担っている。
だが、全ての顧客がアーキテクトであると自覚しているわけでもなく、受託開発であればアーキテクトの役割すらもSIへ押し付ける。
結局、顧客が本来求めているシステムとかけ離れたシステムが出来上がったり、そもそも納期に間に合わずプロジェクトが失敗したりする。

【5】いずれの3パターンともに、自分よりも上位職又は権限の及ばない人達へ働きかけて状況を変えてもらう能力を必要とする。
特に経験のあるプロジェクトマネージャは、この辺りの事情を深く知っている人が多く、組織を動かす能力に長けているように思う。
ファシリテーションがこの辺りに必要なスキルの一つ。
ザ・ファシリテーター」では、ファシリテーションとはプロセス設計の技術だ、と主張する一文があり、なるほどと思った時がある。

個人的には工数見積もりの正当性を説明できるスキルも必要と思っている。
上位の意思決定者へ説明する時、この課題をクリアしないとこれだけのコストがかかりますよ、と論理的に話せるならば、納得してくれやすい。上位の意思決定者ほどコスト意識が強いし、その権限を持っているからだ。
IT特有の技術の一つである工数見積もりを使う場面は、多分上記の状況がとても多いように思う。

【6】WF型開発では、上記のようにたくさんの役割を持つ人が多く、その分複雑な階層構造になる。
オフショア開発していれば尚更だ。
レイヤが多くなるほど、上記のような無駄なコミュニケーションを必要とする。

レイヤの多い組織は無駄に複雑なシステムを作る~Conwayの法則: プログラマの思索

プロダクトオーナーやプロジェクトオーナーが開発チームの外にいると、常にお伺いを立てる必要があり、コミュニケーションを取る時間が開発コストへ響く。
XPのオンサイト顧客の概念はその問題にメスを入れたが、Scrumはその役割をプロダクトオーナーという概念で明確化した点がとても有意義だと考える。

最近のアジャイル開発の具体例を聞く時、SNSやゲーム業界の事例が多い。
彼らの話を聞くと、開発チーム自身がプロジェクトオーナーでありプロダクトオーナーであり、全員がアーキテクトでもある。
開発チームの内部で要件の変更、タスクの優先順位、課題の解決を実施できる。
チーム内のコミュニケーションが取りやすい分、開発速度も速い。
本来のアジャイルな開発チームとは、そういう状況を指すのかもしれない。

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

2011/11/05

RedmineのTime Trackerプラグイン運用の注意点

RedmineのTime Trackerプラグインは、実績工数をタイムウォッチのように簡単に計測してくれるので便利。
しかし運用の注意点があるのでメモ。

【元ネタ】
RedmineのTimeTrackerプラグインが使いやすい: プログラマの思索

Twitter / @bageljp: RedmineのチケットにToodledoやHiTaskみたいなタイマー機能ないのかね。実績工数をいちいち手動入力って面倒すぎ。作業の開始と終わりにボタン押して時間計測してくれれば楽なのになー。

Twitter / @akipii: @bageljp Time Trackerプラグインが良いです。 - Plugins - Redmine redmine.org/plugins/redmin…

Twitter / @bageljp: @akipii ありがとうございます!!早速入れて使ってみましたが、まさにイメージ通りのプラグインでした。最後に記録までされるし便利ですね~^^

Twitter / @akipii: @bageljp Time TrackerプラグインはAjaxで非同期通信するためハードに使うとRedmineが重くなる症状も聞いています。(@tkusukawaさん、@akiko_pusuさん談) 詳細は聞いてみて下さい。

Twitter / @tkusukawa: @akipii @bageljp @akiko_pusu TimeTrackerは経過時間表示を更新するために定期的にサーバリクエストを行います。これが時間計測していなくても全ユーザのブラウザから行われるのでユーザが多いと大変なことになります。表示更新の頻度は設定で変えられます。

Twitter / @tkusukawa: @bageljp @akipii @akiko_pusu 一番の影響はアクセスログの増加かと。たしかデフォルト60秒なので60更新/h、例えば10人が1日8時間Redmineのどこかを2ページぐらいタブ表示しているとすると、10人×2ページ×480更新/日で9600ログ/日

Twitter / @akiko_pusu: @tkusukawa @bageljp @akipii 私の環境ではリバースプロキシしてたので、redmine本体サーバ以外に、プロキシがわのログが増えすぎて反応なくなったことがありました。新しめのバージョンは設定ファイルで間隔調整でぎすが、古いのはハードコードでした。

RedmineのTimeTrackerプラグインが使いやすい: プログラマの思索に書いたけれど、PSP(Personal Software Process)のように自分の作業の内容と工数を記録しながら開発する場合に役立つ。
自分で作業ログを残すようなイメージだ。
PSPなら作業ログを後で振り返りながら、自分でプロセスを改善していく手法をとる。

だが、上記のTwitterで@tkusukawaさんや@akiko_pusuさんが言われているように、Ajaxの非同期通信でRedmineへ頻繁にアクセスするために、ApacheなどのWebサーバーのログが大量に吐かれて、Webサーバーがダウンしてしまう時があるらしい。

この問題は、Redmineの運用を開発チームや開発プロジェクトの大規模化、組織全体への導入へ拡張する場合に起きる点にあると思う。
そもそもRedmineやTracを使ったチケット駆動開発は、そもそも5人ぐらいの一つのチームでアジャイルに開発するスタイルから生まれた。
だから、複数チームへの対応、数百~数千人の運用まで最初から考慮されていなかった。

Redmineによるチケット駆動開発を大規模化していく上での課題や展望については下記に書いた。

Redmineの大規模化の壁: プログラマの思索

チケット駆動開発のスケールアップ: プログラマの思索

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

Redmineを大規模化していく上での課題は二つある。
一つは、WebサーバやSCMリポジトリの負荷分散。
もう一つは、メトリクス収集のための集計バッチ処理の強化。

上記のTwitterのやり取りは前者の問題に含まれる。
前者の問題に対しては、@daipresentsさんも既に色んな運用方法で対処されているようだ。

後者の問題は、IPAが開発中のツールのような事例がある。
個人的には、Redmineプラグインの一機能として実現して、更にJenkinsからバッチ処理をキックするアーキテクチャが理想的な設計方法だろうと考えている。

そしてこの問題の背景には、Redmineによるチケット駆動開発が組織全体へ導入されることによって、RedmineがERPのようにソフトウェア開発の基幹業務システムになってしまう点にあるだろうと直感している。
Redmineが止まったら、文字通り開発業務だけでなく会社の業務そのものが止まってしまうのだ。

だが、@daipresentsさんが1千人規模でRedmineを組織全体へ導入・運用されている事例を紹介されているように、Redmineによるチケット駆動開発の大規模化は可能だ。
そして、Redmineを大規模組織で導入することで、チケット駆動開発の本来の利点を共有しやすくなる。
ツールの導入によって、ソフトウェア開発者だけでなく、経理の事務の女性も営業マンも会社の経営陣も、チケット駆動開発に慣れれば、自然にアジャイルな概念を浸透していくきっかけになるだろう。
それによって、会社全体でアジャイルな概念を共有しやすくなる場ができる可能性がある。

Redmineによるタスクマネジメント実践技法」も1年で第4刷まで増刷されて著者本人も驚いているが、一番の驚きはプログラマ以外の人達も読者層に含まれている事実だ。

Twitter / @akipii: Redmineによるタスクマネジメント実践技法が第4刷増刷決定です。一番の驚きは読者層がIT業界の開発者だけでなくマネージャ層や製薬業・製造業・情報システム部門などの人達もいることです。Agileの概念が他業界にも普及するかもしれません。

僕の著作では、チケット駆動開発でアジャイルに開発する運用方法を中心に書いたから、一部の読者はアジャイルの概念が分からない、という感想があった。
一部の読者の感想を読むと、チケット駆動開発というアイデアはソフトウェア開発のプロジェクト管理だけでなく、営業マンのタスク管理や情報システム部門・サーバー運用保守の課題管理にも使えるようだ。
製薬業・製造業の人達もRedmineを使って運用されている。

だから、アジャイルの概念に慣れているIT技術者だけでなく、会社全体、組織全体へアジャイルの概念を普及させるきっかけになる可能性を秘めている。
それについても今後色々考えてみたい。

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

2011/11/03

日本のIT業界のホラー小説「人形つかい」

一部で有名だったシステム開発の読み物(全23話)を読んでみた。
あらすじはネタバレになるので書かないが、いくつか感想をメモしておく。

【元ネタ】
Press Enter■: 人形つかい(1) 未知との遭遇

日本のIT業界で働いた経験がある人なら、リアリティがありすぎて思わず引き込まれるだろう。
他の業界の人が読んだら、何故今の日本で奴隷のように働くのだろうと不審がるだろう。

感想を二つほど書く。
一つは、日本の製造業に特徴的な多重下請構造をIT業界が真似たことで、技術者が手配師になるか一匹狼の技術者になるかどちらかしか選択肢がない状況になっていること。
この件については過去にも色々考えた。

手配師になるか技術屋で生き残るか: プログラマの思索

個人的には、松原友夫さんの指摘「しかし、品質に関して重大責任を負うに至ったソフトウエア開発ビジネスで、成果責任を負わない派遣形態がかくも横行しているのは日本だけである。 」が最も本質を突いていると考える。

人月ビジネスの特質~成長しないこと: プログラマの思索

日本のソフトウエア産業、衰退の真因 | スラッシュドット・ジャパン

日本のソフトウエア産業、衰退の真因 - 真髄を語る:ITpro

もう一つは、SIが独自に作る俺様フレームワークに技術上だけでなくマネジメント上も致命的な欠陥があること。
この件も過去にも色々考えた。

SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索

SIerの俺様フレームワークは最悪だ

SIが俺様フレームワークを作りたがる理由は、昔のCobol開発のように、上流工程の設計さえできればプログラムは自動生成すればいい、という発想があるのだろうと思う。
その考え方は多分アジャイル開発とは相容れないと思う。

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

SIerは自動化する対象が違っているのでは? - Togetter

IT勉強会カレンダーを見る限り、日本のIT技術者は向上心があるし、RubyやSeasarなどを日本人が生み出したのだから、技術的に劣っているとは思えない。
オープンソース活動やコミュニティ活動が日本の変革の鍵を握っているように直感している。

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

2011/11/01

チケット駆動開発がもたらした新しい観点part1~Redmineプロジェクトへ案件や組織構造を反映する

Redmine・Trac・Mantisによるチケット駆動開発を4年間やってきて、いつも新しい観点を発見している。
最初はRedmineプロジェクトへ組織構造をマッピングする件について考えたことをメモ。
全3回の予定。

【0】最初は小規模プロジェクトでRedmineを運用し始めて、じきに保守ブランチが必要になったり、メンバーが増えて複数チームになったり、現行ソースを他の顧客へカスタマイズして販売する派生開発になったりすると、複数プロジェクト機能を使わざるを得なくなる。
あるいは、一つの組織でいきなり全てのプロジェクトへRedmineを導入して運用しようとすると、Redmineプロジェクトの構造をどのように決めるか、考えなくてはならない。

自分が過去に運用したり、周囲を見聞きしてきて、下記の3パターンでまとめられるように思う。
それぞれについて解説してみる。

(1)派生プロジェクト
(2)保守プロジェクト
(3)CCBプロジェクト

【1】派生プロジェクト

よくある例は、安定運用しているシステムを他の顧客や他の製品へカスタマイズして開発するパターンだ。
このパターンでは、派生元システムは親プロジェクト、派生先システムは子プロジェクトになるのが普通だ。

このプロジェクト構造にする理由は幾つかある。
一つは、Redmineの複数プロジェクト機能で有効な機能があるから。
親プロジェクトのチケット一覧に子プロジェクトのチケットも表示・非表示を制御できるので、子プロジェクトのチケットも同様に検索したり出力できる。
つまり、子プロジェクトのチケットはあたかも親プロジェクトのチケットのように故意に扱うことによって、タスクを把握したり、管理しやすくなる。

又、プロジェクトの親子関係がある場合、子プロジェクトのリポジトリにチケットがリンクされる時に、親プロジェクトのリポジトリが小プロジェクトのそれを含んでいるならば、親プロジェクトのリポジトリにもチケットがリンクされる。
つまり、子プロジェクトのチケットを親プロジェクトのリポジトリにもリンクさせることによって、トレーサビリティを拡張することができる。

Redmineでは、トラッカーやカスタムフィールドをプロジェクト単位にアサインすることが可能だから、各プロジェクトに含まれるタスクのワークフローの観点で、必要なトラッカーやカスタムフィールドだけアサインすることも可能だ。
特定の派生製品のチケットだけ固有の属性を追加したい時、その派生プロジェクトだけカスタムフィールドをチェックすればいい。
また、ユーザグループでユーザを一活登録することもできるから、派生元プロジェクトは既存メンバー、派生先の新規開発プロジェクトは新規メンバー、などのように登録ユーザを使い分けることもできる。
つまり、各プロジェクトの特性に応じて、柔軟にチケットの属性やワークフロー、ユーザを自由自在に取り外しできるので、複数プロジェクト機能をうまく使いこなせば、厳格なプロジェクト管理も可能だ。

もう一つは、プロジェクトの寿命の観点で親子プロジェクトを使い分けること。
基本は、寿命の長いプロジェクトは親プロジェクト、寿命の短いプロジェクトは子プロジェクトに設定する。
何故なら、プロジェクトの親子関係は、オブジェクトの継承のように、親プロジェクトの性質を子プロジェクトも受け継ぐと言う観点からして、親プロジェクトが廃止されたら子プロジェクトも廃止されるのが自然だからだ。

すると、派生元製品の方が普通は派生先製品よりも寿命が長いから、親プロジェクトは派生元製品になる。
派生元製品には共通のフレームワークや部品があるため、それらを保守するタスクがチケットになるからだ。

この例は特にERPのようなパッケージ製品、組込製品が相当するだろう。
MSのOffice製品群、AppleのiPod・iPhone・iPadのように似たような製品だが細部は異なる製品群はまさにその例になるだろう。
すなわち、この考え方は最終的には製品系列の開発、つまりソフトウェアプロダクトラインの考え方に発展するだろうと思う。

【2】保守プロジェクト

よくある例は、新規開発したシステムをその後ほそぼそと運用保守で続けたり、2次開発で別システムを開発する場合に、新規開発プロジェクトと保守プロジェクトを別々に分けて、親子プロジェクトで関係付ける。
新規開発と保守の二つのプロジェクトに分ける理由は、それぞれのソースが新規機能重視なのか保守重視なのかという構成管理上の観点と、大規模プロジェクトで二つ以上のチームに分けて開発と保守を割り当てるという開発リソースの観点の2点が主にあるだろう。

小規模プロジェクトでは、開発も運用保守も一チームでやる時が多い。
すると、trunkは新規開発、リリースブランチは本番運用と意図的にコードラインを分けてソース管理する。
つまり、trunkは常に最新機能を持つ常時リリース可能なコードライン、リリースブランチはtrunkからリリースした時点で発生して障害修正のみ行う保守重視のコードラインになる。
構成管理のライフサイクルとしては、trunkからリリースする時にリリースブランチが生まれ、次のバージョンでリリースする時に既存のリリースブランチは廃止され、新規のバージョンに対応するリリースブランチが生まれる。
この構成管理パターンはいわゆるメインラインモデルに相当する。
オープンソースのソフトウェア開発ではごく自然に行われている開発スタイルだ。

すると、trunkは親プロジェクト、リリースブランチは子プロジェクトで関係付けるのが自然だろう。
何故なら、trunkの方がリリースブランチよりも寿命が長いので親プロジェクトするのが自然だし、trunkのチケットを保守する時に子プロジェクトにある障害修正のチケットも同時に見れた方が便利だからだ。
僕が並行開発でRedmineの複数プロジェクト機能を有効に使えた場面はこのパターンだった。

だが、大規模な業務システムの開発ではプロジェクトの親子関係の使い方が変わってくる。
複数チームによる開発の場合、よくある例は、既存メンバーは運用保守に割り当て、2次開発のように特定期間に発生した大きなプロジェクトは新規メンバーをアサインする時が多い。
複雑な業務システムほど保守が重要なので、保守にいきなり新規メンバーを大量投入するのは危険だからだ。
逆に2次開発の場合、新機能の追加になるから、既存メンバーの一部と新規メンバーでチームを構成すれば、リスクヘッジもできる。

すると、保守チームのタスク管理は親プロジェクト、新規開発のタスク管理は子プロジェクトで関係付けるパターンが多い。
つまり、保守プロジェクトの下に1次開発、2次開発、特定機能の短期開発などのような寿命の短い案件が子プロジェクトでぶらさがってプロジェクト管理される関係になる。
この構造にすれば、短期開発で行われたタスクは全て子プロジェクトのチケットに作業履歴が残っているから、その後の運用保守でもトレーサビリティを使えば有効活用できる。
子プロジェクトの新規開発時のチケットが残っているので、作業の引継ぎもその後の運用保守での調査にも役立つ。

更に、構成管理の観点では、保守プロジェクトはtrunk、新規開発プロジェクトはタスクブランチと目的を分けてブランチ管理するパターンが多い。
つまりtrunkは保守重視であり、新規開発チームはtrunkから派生したタスクブランチでどんどん機能追加して、リリースできる品質になったらtrunkへマージするパターンになる。
そのような構成管理にする理由は、trunkを品質保証されていないソースで汚したくないことや、新規追加のシステムならばtrunkへマージする作業もほとんど上書きコピーするだけで動くだろうという推測があるからだ。

この保守パターンで面白いのは、構成管理と複数プロジェクト機能が密接に関係していること。
そもそもRedmineでは1プロジェクト=1リポジトリの設計思想があり、それは1リポジトリからビルドされてリリースされる製品と対応付けられるから、一つのコードライン、すなわちリリース可能なブランチとプロジェクトが1対1に対応付けられる。
構成管理ではtrunkの方がブランチよりも寿命が長いので、trunkを持つプロジェクトが親プロジェクトになる。
その時、リリースブランチやタスクブランチの観点で、子プロジェクトの構造の意味あいが異なってくるのが面白い。

【3】CCBプロジェクト

よくある例は、大規模プロジェクトで複数チームで開発している場合、各チームのタスク管理だけでなく全チーム共通の課題管理を行う必要がある時に出てくる。
つまり、PMBOKのCCB、ITILのCAB、アジャイル開発のスクラムオブスクラムのように、各チームのリーダーが集まった会議で、複数チームにわたる課題を調整したり、プロジェクト全体の方針を決定づけるように運営する。

すると、親プロジェクトはチーム横断の課題管理、子プロジェクトは各チームのタスク管理で関係付けられる。
マネージャのように複数チームのリーダーを管理する立場の人は、各チームの細かなタスク管理はチームリーダーに任せているので見る必要はない。
むしろ、プロジェクトの進捗を阻害する課題や各チームからあがってきた課題を見つけては解決していき、プロジェクトをスムーズに運営できるように維持する役割に徹するようになる。
だから、マネージャは、課題管理プロジェクトにあがったチケットを精査することで、プロジェクト運営を制御する方向で運用するようになるだろう。

このパターンの特徴はいくつかある。
一つは、課題管理プロジェクトとタスク管理プロジェクトでは、チケットのトラッカーや属性が異なること。
各チームのタスク管理は普通のRedmineの運用でよいが、課題管理プロジェクトでは、Excelで作られた顧客向けの課題一覧を元にチケットの属性を増やしたり、ワークフローを意図的に変えたりすることで運用する場合が多い。
Redmineプロジェクトで管理されるチケットは誰が保守するのか、という役割の観点によって、チケットが大きく変わる良い例だろうと思う。
マネージャが管理したいチケットとプログラマが作業しやすいチケットは、チケットの属性もトラッカーも全く別物にした方が運用は楽だろうと思う。

もう一つは、CCBプロジェクトと保守プロジェクトを組み合わせたパターンがよく見られること。
例えば、新規顧客の大規模プロジェクトでRedmineを使った場合、1次開発ではCCBプロジェクトの構造で親プロジェクトは課題管理、子プロジェクトは各チームのタスク管理のように関係付けて運用する。
そしてリリースが終わって運用保守に入った場合、運用保守プロジェクトを親プロジェクトとして新規に作り、1次開発の課題管理プロジェクトを子プロジェクトで関連付けて、1次開発のチケットを作業履歴として参照できるように運用していく。

この運用の利点は二つある。
一つは、過去の開発のチケットを参照しやすいので保守作業に役立つこと。
もう一つは、新たに2次開発が発生したら、子プロジェクトの2次開発用の新規開発プロジェクトや課題管理プロジェクトをぶら下げればいいこと。
特に後者の場合、今後、大規模でなくとも2次・3次と開発案件が発生するなら、運用保守チームとうまく連携して開発できるような仕組みが作りやすい。

【4】以上のような3パターンを経験的にまとめたけれども、他の案件では他のパターンもあるに違いない。
是非聴かせて欲しいなあと思う。

Redmineが持つ複数プロジェクト機能は、とても大きな可能性を秘めていると思う。

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

« 2011年10月 | トップページ | 2011年12月 »