« 2011年1月 | トップページ | 2011年3月 »

2011年2月

2011/02/27

r-rabsのRedmine Hudson Pluginがすばらしい件

r-rabsのRedmine Hudson Pluginを運用してみて、とてもすばらしいと思ったので、良かった点を書いておく。

【元ネタ】
Redmine - Hudson Plugin 0.1.0 - Redmine

RedmineとHudsonを連携させる方法 - Faster Than Light

【1】ジョブの一覧からビルド履歴を簡単に見れる点がよい。
 下記を見れば一目瞭然。

r-labs - Redmine

大規模プロジェクトになるほど、開発チーム単位でビルドモジュールを開発するため、複数のジョブが作られる。
Redmineでタスク管理しているのだから、Redmine上でHudsonを見れるのはすごく便利。

【2】チケットにあるSVNリビジョンの履歴に、どこまでビルドしたのか(SUCCESS)、が表示される
 下記を見ると、SVNリビジョンにコミットログだけでなく、どのビルド番号にソース修正が入っているのか、を表示してくれる。
 これは非常に便利だ。

リビジョン 169
Haru Iida が2日前に追加
SUCCESS built by Wiki Extensions Plugin #214 at 2日 ago
fixes #690 Wrong smiley replacement.

Wiki Extensions - Defect #690: Smiley replacement in Wiki-Links - Redmine

SW開発では、以前のソース修正が今回のビルドモジュールに入っているかどうかを確認するために、厳格なビルド&リリース作業を行い、更には手間のかかるテストを行う。
だが、障害管理プロセスでは、修正順序とリリース順序が異なる場合もあるので、リリース漏れやデグレが発生しないように注意するのが非常に大変だ。

特に2番目の特徴は、以前のバグ修正は今回のビルドモジュールに入っているのか、をチェックする機能を、Redmine+Hudsonというツールがサポートしてくれている事実を示している。
この機能をうまく使えば、ビルド&リリース作業のチェックを補強するだけでなく、開発者やテスターも、どのバージョンにどんなソース修正が含まれているのか、を意識して作業してくれるようになるだろう。

アジャイル開発のインフラを支える三種の神器: プログラマの思索にも書いたけれど、BTS・SCM・CIの連携方法はもっと研究される余地があると思う。

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

RedmineとSCMの機能の関連表~BTSとSW構成管理の密接な関係 #itsjp #tidd

チケット管理システム比較WikiへRedmineとSCMの機能の関連表を追記した。
BTSとSCMに関する考えをラフなメモ書き。

【元ネタ】
チケット管理システム比較Wiki

構成管理とは何なのか - watawata日記

SW構成管理とはそもそも何なのか?: プログラマの思索

17-B-3 チケット駆動開発 タスクマネジメントからAgile開発へ - miyohideの日記

Agile開発とチケット駆動開発の大きな違いは、チケット集計機能だけでなく、構成管理ツールとの連携にあると思う。
「No Ticket, No Commit!」を運用して、BTSチケットに構成管理情報を紐づけると、単にチケットとSCMリビジョンが紐づくだけでなく、ビルドモジュールとBTSチケット、SCMコードラインとBTSプロジェクト、SCMタグとBTSのリリース予定バージョンが対応づけられる利点がある。

つまり、チケットとSCMリビジョンを経由して、タスク管理の大きな観点の分割単位であるBTSプロジェクトやBTSのリリース計画とSCMリポジトリを関連付けることができる。

RedmineはプロジェクトがSCMリポジトリに1対1に対応する思想で設計されているから、RedmineプロジェクトとSCMコードライン(trunk、リリースブランチなど)、更にはHudsonでビルドするモジュールを自然に1対1に対応付けることができる。
HudsonにはRedmine・Trac・Mantisなど各種BTSと連携するプラグインがあるので、Hudsonのビルドログに掲載されたSCMコミットログにBTSチケットNoが書かれていれば、HudsonからBTSへリンクすることが可能になる。
これによって、ビルドモジュールからチケットへ辿ることができるので、ビルドモジュール単位のトレーサビリティが可能になる。

RedmineとHudsonの関係付け: プログラマの思索

Redmineでは、Redmineバージョンとビルドモジュールのリリース予定バージョンに対応づけることによって、XPのイテレーションやScrumのスプリントに対応付けることができ、自然にXPの小規模リリースを実現できる。
将来のリリース予定バージョンの集合は、ロードマップで一覧でき、それらはリリース計画に相当する。

更に、リリース済みのバージョンをSCMのタグと紐づけるようにすれば、ビルドモジュールのリリース済みバージョンとSCMのタグ、Redmineの終了バージョンが対応付けられるので、それらを集めると自然に変更履歴(ChangeLog)になる。

HudsonとSubversionを使っているならば、HudsonのSubversion Tagging Pluginを使って、リリースする時にSVNタグを振ってからHudsonでビルドする運用にすればよい。
そうすれば、SVNタグとリリースモジュールの対応付けをより厳格に運用することが可能になる。

HudsonのSubversion Tagging Plugin: プログラマの思索

これらの特徴によって、トレーサビリティというチケット駆動開発で最も重要な機能が実現できる。
トレーサビリティがあるからこそ、マージ作業が簡単になるし、本番リリース後の運用保守でパッチの影響調査が楽になるし、本番ソースから仕様をリバースエンジニアリングして派生開発に役立てる、などの作業もきちんと運用できるようになる。

ソフトウェア開発はとても繊細で、変化が激しい。
だから、バグ修正という名の作業で、他のバグを埋め込んでしまうデグレが発生しやすいし、同類バグの影響調査が不十分でバグを完全に除去できないというリスクがとても多い。

僕の数少ない経験では、ソフトウェア開発チームの習熟度は、障害管理プロセスがどこまでうまく機能しているか、という観点で簡単に評価できると思う。
駄目な開発チームほど、せっかく見つけたバグをどんどん溜め込んでしまって、リリース計画に基づいてバグ修正の優先順位付けを行うことなく、バグが放置されてしまう。
優秀な開発チームは、バグ修正とバグ検証の連携作業がスムーズで、たとえバグの再検証で修正漏れが発覚したとしても、そのミスを学習して、イテレーションをこなすごとに開発速度が上がっていく。

つまり、障害管理プロセスがしっかりしている開発チームは、障害管理プロセスの基本であるコーディングパイプラインがしっかりしているので、新規開発でも派生開発でもバグ修正でも同じプロセスで対応できる。
そして、製品化の速度が速いので、開発チームも動くシステムを触りながらシステムの機能を学習できるし、顧客へいち早くシステムを納品することもできる。

SW構成管理は単なるバージョン管理だけでなく、変更管理という開発プロセスも含む。
チケット駆動開発は、Agile開発にSW構成管理と変更管理の観点を組み込んで、SW開発をもっと近代化しようとする隠れた目的があるように思う。

SW構成管理とはそもそも何なのか?: プログラマの思索にも書いたけれど、SW構成管理に関する知識が日本ではまとめられていない。
BTSという枯れたツールには、SW開発プロセスを拡張させる機能がもっと隠れているから、色んな人が色んな観点で研究して、その成果を公開して、日本のIT業界の技術力向上に役立てて欲しいと思う。

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

2011/02/26

ソフトウェアかんばんと仕掛けかんばん、引き取りかんばん

「アジャイル開発でよく言われるソフトウェアかんばんとは、仕掛けかんばんなのか? 引き取りかんばんなのか?」という質問を聞いたので、改めて調べてみた。
完全に理解できてないので、情報だけ集めておく。

【元ネタ】
InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ

カンバン - Wikipedia

教えて!Ziddyちゃん - 生産管理について2点

かんばん生産入門  第1回  

かんばん(狭義) | J I T基本用語集

仕掛けかんばん | J I T基本用語集

引き取りかんばん | J I T基本用語集

飲食店に学ぶ生産管理トップページ

InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへの記事のように、平鍋さんはソフトウェアかんばんに、トヨタ式生産方式(TPS)にある仕掛けかんばんと引き取りかんばんのアイデアを注入しようと試されているようだ。

トヨタが生み出したかんばんには、カンバン - Wikipediaの通り、納入指示用の引き取りカンバン、生産指示用の仕掛けカンバンの2種類がある。
仕掛けかんばん、引き取りかんばんはソフトウェアかんばんとはは異なり、もっと製造現場の目的、つまり必要な時だけ製造して在庫を極力減らすために使われる。
仕掛けかんばん、引き取りかんばんは、ソフトウェアかんばんよりもはるかに機能が豊富で強力な仕掛けがあるのだ。

仕掛けかんばんは、工業簿記で出てくる製造指図書を連想させる。
製造指図書は、製造するために必要な材料と製造方法、製造時期を記述した指示書だ。
製造指図書には製品に含まれる全ての材料が書かれているからこそ、原価を計算できて正しい値段で製品を売ることができる。
つまり、製造指図書は利益計画や原価差異、原価計算に強く関係する。

また、製造指図書によって、材料から製品までトレースできるので、材料に不良品が混じっている場合、どの製品が出荷できないのか、を追跡することもできる。
つまり、製造指図書はトレーサビリティの元ネタにもなる。

ソフトウェアかんばんは所詮、ステータス単位にタスクカード(PostIt)を貼り付けたタスクボード(ホワイトボード)なので、本来のかんばんに比べるとはるかに貧弱。
本当は、顧客価値に直結する機能を少しずつ作っていく仕掛けをソフトウェアかんばんに注入して、プログラミングという下流工程が要件定義や設計という上流工程の作業をPull化したいはず。

平鍋さんはどう考えているのか、聞いてみたい。
もっと調べてみる。

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

2011/02/24

「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart11 #tidd

Redmineによるタスクマネジメント実践技法」の感想を見つけたのでメモ。

【元ネタ1】
Redmineによるタスクマネジメント実践技法 - umachaの本棚 - ブクログ

(引用開始)
感想としてはhttp://forza.cocolog-nifty.com/のエントリのまとめのような本。
ブログを昔から日々読んでいる人にはあんまり新しい発見もないかも。
ぼくはRedmineは既に運用しているので、後半のTestLinkの運用について
初めて知る内容が多くて面白かった。
TracやMantis派でも読んで損はないと思う。
BTSをアジャイル開発のインフラとして使うノウハウのヒントが書かれている。
(引用終了)

Blogも読んで下さってありがとうございます。
BTSをアジャイル開発のインフラとして使う方法は、もっと研究する価値があると思っています。

Twitterで、こんな面白いつぶやきを見つけた。
本来の意味は何なのだろう?

【元ネタ2】
Twitter / @わっさ: 今日、社長に言われた名言!「お前は俺のRedmineだ!」。こうしてまた1つ名言が生まれた!

自分のタスク管理を社長に任せるのだとしたら、ちょっと違うのではないかと思ったりする(笑)

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

2011/02/20

チケット管理システム比較Wiki #itsjp #devsumi

@Sean_SFさんのご好意でチケット管理システム比較Wikiが編集できるので、Redmine・Trac・Mantisの機能比較表を書いてみました。
ご参考下さい。
もし間違いがあれば、皆で直してみてください。

【元ネタ】
Twitter / @ショーン:先ほど紹介した「チケット管理システム比較Wiki」はこちら。決戦しましょう。どんどん書きこんでね! http://confluence.atlassian.jp/x/0wCFAQ #itsjp #shibutra

チケット管理システム比較Wiki

【公開】デブサミ2011講演資料「チケット駆動開発~タスクマネジメントからAgile開発へ」 #devsumi #tidd: プログラマの思索

2011-02-18 - 崩壊現実-全てはvirtualに収束する-

17-B-3 チケット駆動開発 タスクマネジメントからAgile開発へ - miyohideの日記

チケット管理システム比較Wikiを作ろうというきっかけとなったのは下記のつぶやきが発端かも。

Twitter / @showyou: #itsjp なんか対決してなくてexcelつぶそーみたいな話になってた残念。どうせだからガチンコすればいいのにtracは複数プロジェクトが残念とか

僕はプロジェクトマネージャの意識よりもプログラマの意識が強いので、ツールの実装方法やツールの機能そのものに興味があります。
Redmine・Trac・Mantisを触ってみて、実際にチケット駆動開発を運用してみて、それぞれの特徴はだいたい分かっているつもりです。
但し、ITSの最大の利点であるチケット集計・ワークフロー管理・SCM連携の機能は3つのツールとも実現可能ですが、各ツールに癖があるので運用する時には注意が必要です。

【公開】デブサミ2011講演資料「チケット駆動開発~タスクマネジメントからAgile開発へ」 #devsumi #tidd: プログラマの思索にも書いたように、ガントチャートは進捗管理の一つのビューに過ぎない。
せっかくITSを使っているならば、日々入力されているチケットの情報がDBに一括管理できているのだから、色んな観点で集計して、プロジェクトのリスクがどこにあるのか、を探し出して、早めに手を打ちたい。
ITSをプロジェクト管理ツールとして扱う運用方法は、もっと研究される余地があると思っています。

@Sean_SFさんいわく、チケット管理システムの戦いはまだ始まったばかりだそうです。

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

2011/02/19

デブサミ2011まとめサイト #devsumi

デブサミ2011の関連資料やまとめサイトが公開されているのでメモ。

デブサミまとめまとめ:2011

上記のサイトは、講演者のSlideShareと聴衆のBlogの感想がペアになっているので、とても素晴らしい。
講演内容の評価がBlogにそのまま現れているのがいい。

なお、講演者の発表資料はSlideShareのイベントカテゴリに集められているので便利です。

SlideShare ? Event ? Developers Summit 2011

Developers Summit 2011

なお、リアルタイムに追っかけたい人は、Twitterで追いかけてみてください。

Twitter / 検索 - #devsumi

チケット管理システム大決戦の続きは、下記Twitterで見れます。

Twitter / 検索 - #itsjp

先程、もっとすごいTiwtterまとめサイトが公開されていた。

devsumeet - Devsumi 2011 topics on Twitter

さらに、発表資料とTogetterをペアでまとめたサイトも公開されている。
これはすごく便利。

デブサミ2011 資料・Togetter集

これだけデブサミ2011の情報がTwitterでリアルタイムに配信されて、会場の人達だけでなく、会場に来ていない人達にもその雰囲気が共有できるのはすごい。
そして、そういう共有の場を作り出す有志の人達もすごい。

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

2011/02/18

【公開】デブサミ2011講演資料「チケット駆動開発~タスクマネジメントからAgile開発へ」 #devsumi #tidd

デブサミ2011で講演してきました。
聞きに来てくれた方にはありがとうございました。
発表資料「チケット駆動開発~タスクマネジメントからAgile開発へ」をCC Attribution ライセンスで公開します。

【参考】
創発 未来につながるために 世界に帆を立てるために Developers Summit 2011

デブサミ2011【17-B-3】チケット駆動開発~タスクマネジメントからAgile開発へ~ 小川明彦 氏 / 阪井誠 氏 - Togetterまとめ

デブサミ2011【17-B-4】チケット管理システム大決戦 JIRA vs Redmine vs Trac ?ユーザーが語る、なぜ私はこのツールを使うのか 鈴木雄介 氏 / 小川明彦 氏 / 吉羽龍太郎 氏 / 大澤俊介 氏 - Togetterまとめ

@たのぐちだいきさんが講演内容をマインドマップで公開してくれているので、詳細はそちらを御覧下さい。

Twitter / @たのぐちだいき: #devsumi 17-B-3 チケット駆動開発をマインドマップにしてみた。 http://twitpic.com/40mmzx http://twitpic.com/40mn2w

#devsumi 17-B-3 チケット駆動開発をマインドマップにしてみた。 on Twitpic

#devsumi 17-B-3 チケット駆動開発をマインドマップにしてみた。(Part2) on Twitpic

また、Twitterに流れた感想も下記のリンクでまとめられてます。

Togetter - 「デブサミ2011【17-B-3】チケット駆動開発~タスクマネジメントからAgile開発へ~」

デブサミ2011【17-B-4】チケット管理システム大決戦 JIRA vs Redmine vs Trac 〜ユーザーが語る、なぜ私はこのツールを使うのか 鈴木雄介 氏 / 小川明彦 氏 / 吉羽龍太郎 氏 / 大澤俊介 氏 - Togetterまとめ

次のパネルディスカッション「チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか」にもRedmineユーザ代表として参加しました。
詳細は、@Sean_SFさんが資料を公開してくれているので御覧下さい。

聴衆に「チケット管理システムを使っている人はいますか?」と挙手をお願いした所、半数以上が手を上げたのは正直驚きました。
Excelによる進捗管理をしている現場が大半だと予想していたので、チケット管理システム大決戦セッションは共通の敵であるExcelの人達がいなかったのでそもそも決戦にならなかったかも(笑)

僕自身は、Redmine・Trac・Mantis・Jiraを使った経験があり、各ツールの機能や特徴はほぼ把握しているつもりです。
個人的には、チケット管理システムの最大の利点であるチケット集計機能については、Redmineが最もよく考えられていると思います。
理由は上記の資料にも書きましたが、Redmineはチケットの属性とチケット集計機能の関連性が特徴としてはっきり出ているから。

管理職の大好きなガントチャートは、所詮、進捗管理で必要なビューの一つに過ぎない。
プロジェクト管理で必要なビューは、ガントチャートだけでなく、カレンダー、かんばん、バーンダウンチャート、ロードマップ、PMBOKのEVM、バグ収束曲線などたくさんあり、それらのビューをプロジェクト管理で必要な状況に応じて使い分ければいい。
チケット集計機能から得られる数々のビューから進捗や品質の管理、リスクの追跡を行えばいい。
毎晩、ツールから自動集計された進捗報告を管理職へ提出しておけば、普通は文句は言われないだろう。

「ツールでプロセスを改善していく」発想や「高機能なBTSをアジャイル開発のプロジェクト管理に使う」発想をもっと色々試してみたいと思います。

【追記】
17-B-3 チケット駆動開発 タスクマネジメントからAgile開発へ - miyohide's blog

(引用開始)
@akipiiさんのお話の中で印象的だったのは、
ガントチャートはビューの一つ
ということ。結局、必要な情報を与えればガントチャートなどはビューの一種だから自動生成できるでしょ。ってことを強調されていました。
実際、Redmineをインストールしてみてちょっと使ってみるとガントチャートが自動生成されている。これまで俺が自社ツールで苦労してメンテしていたのはなんだったんだ・・・orz
(引用終了)

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

2011/02/13

テレビCMに出てくる会計ソフト

最近、テレビで「出納帳Netで財務諸表を作りましょう」というCMが流行しているらしい(?)
CMに出てくるキャラクターが可愛いので女性が興味を持っているらしい。
ネットで見つけたのでメモ。

【元ネタ】
テレビCM・壁紙ダウンロード・キャラクター「アイベックスボーイ」|JDL IBEX net - 会計ソフト・経理ソフト・給与ソフト

要は、SaaS形式の中小企業向け会計ソフト。
現金出納帳や預金出納帳で毎日の取引を記録していきましょう、という宣伝をしているだけ。
僕にはよく分からないが、CMに出てくるキャラクターが可愛いらしい。

商業簿記2級では、日々の仕訳のうち、現金や預金に関する仕訳を仕訳帳ではなく、現金出納帳や預金出納帳に直接転記する方法も掲載されている。

普通は、日々の仕訳は仕訳帳に記入して、そこから現金出納帳・預金出納帳・仕入先元帳・得意先元帳・総勘定元帳へ転記していく。
本来、日々の仕訳を記録する理由の一つは、現金や預金の残高をチェックして支出を減らすように節約するとか、期日の迫った売掛金を回収したり、買掛金を締め日に一括払いするために残高をチェックするのに使うからだ。

しかし、一つの仕訳を転記していく作業は昔は手作業だったので、記載ミスやコピー漏れが発生しやすかった。
又、仕訳帳は大福帳みたいなシロモノだから、それだけでは意義あるデータを拾い出せない。

だから、日々の仕訳のうち、現金・預金・仕入・売上に関する仕訳は仕訳帳に記載せず、現金出納帳・預金出納帳・仕入先元帳・得意先元帳へ直接記入する運用を取る。
すると、同じ仕訳を何度も転記する回数が減るし、一つの仕訳が一つの元帳だけに記載されるから検索しやすくなる利点がある。

だが、一つの仕訳を複数の元帳に記載する場合があり、それは2重仕訳になってしまう問題がある。
だから、二重転記を防ぐために、元帳の摘要欄に転記元の元帳名、元丁欄に元帳の口座番号(つまりページ番号)を書く運用を行う。

100円ショップで売られている現金出納帳や預金出納帳には、摘要欄や元丁欄があるが、それはそういう運用で使うみたい。
そういう元帳を見ると、昔の人は簿記を手作業で行うためにいろんな工夫をしていたんだな、と思うが、今はIT化された会計システムがあるから、そんな手間は不要。
いきなり仕訳を入力して溜め込んで一括管理しておけば、夜間バッチ処理で現金出納帳・預金出納帳・仕入先元帳・得意先元帳は毎朝出力できる。

現金出納帳に記入する仕訳の元ネタは、昔は、入金伝票・出金伝票・振替伝票の3つがあった。
今でも100円ショップで束になって売られている。
おそらく中小企業なら、今でも紙の3伝票で日々の仕訳を記録して、バインダに綴じて管理しているのではないだろうか?

しかし、今は市販の会計ソフトを使った方が集計しやすいし、仕訳帳の保管やセキュリティの観点からしても、その方が安全だ。
中小企業の会計ソフトは、むしろSaaSのような形式でもっと安価にサービスを提供されるべきものだと思う。
パッケージベンダーからしても、会計ソフトの保守やバージョンアップ、サービスサポートを考えると、SaaSでシステムを一括管理できるメリットは大きい。

グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」や「グラス片手にデータベース設計 ~会計システム編 (DBMagazine SELECTION)」は業務知識や会計知識がシステム屋の観点からまとめられていて、とても良い本。
会計知識とデータモデリング、業務知識は密接に関連する。
後日まとめる。

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

2011/02/11

障害記録票と問合せ管理簿の2重管理問題

応用情報技術者試験で、インシデント管理をExcelの障害記録票と障害管理簿で2重管理していた問題が出ていた。
この手の不手際がよくありそうなのでメモ。
以下ラフなメモ書き。

【元ネタ】
平成22年度春期試験 応用情報技術者試験(AP)午後問題

平成22年度春期試験  応用情報技術者試験(AP)午後問題解答

上記の問11にITILのサービスサポートのインシデント管理の問題がある。
問題の詳細は省略。
その事件として、まずかった点は二つある。

問合せ管理簿で、他の問合せの最新状況が反映されていなかったために、過去直近の問合せと原因は同じと判断を誤ったこと。
もう一つは、問合せ管理簿に、プログラム改修の要否や改修予定日などが書かれていなかったために、ユーザに正しい情報を即答できなかったこと。

ITの運用保守業務では、インシデント管理ではまず障害の暫定措置や早期復旧を最優先にして、根本原因の解決は問題管理フロー以降で念入りに対策をとるのが基本。
インシデント管理で迅速に正しい判断を行うには、過去に蓄積された情報を早く正しく検索して、判断を誤らないようにすることが大事。

上記では、Excelで障害記録票と問合せ管理簿の2重管理をやっていたのだろうと思われる。
だから、障害記録票から問合せ管理簿への最新情報のコンバートが手作業で面倒であり、運用がルーズになっていたと思われる。

また、Excelの問合せ管理簿からプログラム改修の要否や改修予定日などの項目が漏れていたように、インシデント管理で必要な情報が表示されていなかった。
この手の運用は、最初から正しい運用を行うのは難しく、何度も試行錯誤しながら、Excelの問合せ管理簿へ項目をどんどん追記して保守していくようになる。
だから、保守コストもバカにならない。

上記の問題を読むと、Excelによる障害管理や問合せ管理は時代遅れになっているのでは、と思ったりする。
障害管理や問合せ管理は10年以上前から既に存在しており、PCがない状況では、紙の台帳で管理していた。
PCが普及してからも、台帳をExcelに焼き直しただけで管理していた。
だから、後から検索しやすくするように、付箋をつけたり、索引を手作業で作ったり、PostItなどでノウハウを書き込んだり、独自に改良していた。
その頃のできるプロマネは、運用ルールを作るのがうまく、その運用ルールをExcelの台帳として見本を作り、管理するのが基本だった。

しかし、Excelの障害管理簿はすぐに肥大化しやすく、一度ファイルが壊れると非常に困る代物。
また更新履歴を構成管理の配下に置いていないから、どれが最新の障害管理簿なのかすぐに分かるように厳重に管理しているのが普通。
だから、運用ルールが厳しくなるほど、障害管理簿への記入が遅れて、最新化が遅れて、色んな作業のリードタイムが長くなってしまう。

Excelのプロジェクト管理は何故良くないのか: プログラマの思索にも書いたけれど、Excelによる障害管理の問題点は二つに尽きる。
一つは、Excelでは作業ステータスの最新化や集計に手間がかかること。
もう一つは、Excelの台帳であろうとも構成管理されていないために更新履歴が残っていないので、過去の修正の経緯や問合せの解決方法を追跡しづらいこと。

現代ならRedmineやTracなど優れたBTSがあり、しかもプロジェクト管理機能がとても優れているので、障害の入力も最新化も集計も簡単だし、全文検索できるから、いつでも欲しい情報をすぐに探せる。
又、SCMリポジトリにある成果物の修正履歴はチケットに紐づいているから、何故こんなパッチが施されているのか、という経緯も簡単に探すことができる。

そして、昔のプロマネのやり方が現代のプロジェクト管理に合わなくなっている気もする。
上から押し付けられた運用ルールでは実際の現場にフィットしない時もある。
Excelの台帳を見本として見せて、今からのノウハウをExcelの台帳へ貯めていく手法は古いと思う。
現代なら、Excelではなく、Wikiにまとめた方が情報共有もやりやすい。

また、現場のメンバーとふりかえりなどでフィードバックしてもらい、皆ですこしずつ改善しながら、運用ルールを現場に見合った内容へ変えていく。
Agile開発では、イテレーションと言うタイムボックスがあり、ふりかえりを行うタイミングが自然に生まれるので、そのタイミングにフィードバックプロセスを回すようにすれば、チームの一体化が図れるだけでなく、次のイテレーションに向けて少しずつ改善していく契機になる。

プロジェクト管理の手法も、10年前と比べて静かに進化しているように思う。

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

基幹系バッチ処理をHadoopで高速化

基幹系バッチ処理をHadoopで高速化する記事を見つけたのでメモ。
以下ラフなメモ書き。
間違っていたら後で直す。

【元ネタ】
プレスリリース|2011年2月9日 |ウルシステムズ、業界初、基幹バッチ用のHadoopフレームワーク「Asakusa」 を開発、オープンソース化して提供開始 | ウルシステムズ株式会社 | UL Systems, Inc.

ウルシステムズ、基幹バッチ用HadoopフレームワークをOSS化 - ニュース:ITpro

基幹バッチが超高速化する?|HATのブログ

業務システムは、日中のフロントエンドのリアルタイム処理と夜間の大量データを集計するバッチ処理の2パターンを組み合わせたアーキテクチャが多い。
フロント側はVisualBasic→CGI→Java→RailsやHTML5と次々に技術革新が起きているのに、バッチ側は昔のCobolで作った資産が残っていて、そこから脱皮できない時が多い。

基幹系の業務システムのバッチ処理では、昼間に業務データを溜め込む。
そして、夜間に業務データから自動仕訳して仕訳帳・仕入先台帳・得意先台帳を日次で作ったり、月末には請求締や支払締に関する残高処理を行ったり、損益月次計算書や貸借対照表、キャッシュフロー計算書を月次で出力する処理がメイン。
Cobolから脱皮できない理由は、日次の仕訳という大量データのトランザクション処理はCobolという枯れた技術で処理すればいいだろう、という発想から抜けきれないからだろう。

Googleが編み出したMapReduceという高速バッチ処理を夜間の業務バッチ処理に使おうという上記の記事の発想は個人的には注目に値すると思う。
そもそもバッチ処理が夜間に行われるのは、処理時間がかかるために夜間はフロント側のシステムを使わない時間帯を使うと言う理由が多いからだ。
バッチ処理がリアルタイム処理に近いならば、基幹系業務システムから集計したデータを経営分析データとして顧客に早くフィードバックできる利点がある。
製造のリードタイム削減、受注時の在庫確認、現金・預金のリアルタイムな残高確認など色んな機能がもっと使い易くなるはず。

上記の記事にある「DOAはDSLである」という発想も面白い。
UMLモデリングの本質 (日経ITプロフェッショナルBOOKS)」で紹介されているが、OOAでもクラス間の制約はOCLで表現する手法もある。
しかし、モデルがより複雑になるだけで読みにくくなり、あまり利点を感じなかった。

だが、そもそもモデルは業務ロジックと言う制約を表現するためにあるのだから、単なるデータの入れ物だけでなく、その関連性も重要なはず。
RailsではActiveRecordによって、テーブルやSQLをDSLで表現している。
DOAで表現できるリレーションシップも同様にDSLですべて表現できるはず。

DSLで表現できるという意味は、認識できるすべての事象はソフトウェアで実装できるということ。
つまり、モデルを動かすことができて、すぐに検証できることを意味する。

モデルをDSLで表現しようと言う発想は、MDA(モデル駆動開発)のように昔から実験されてきたが、どれも胡散臭い。
OOAもMDAの方向へ走って、行き詰まった感がある。
モデルからプログラムを自動生成できたとしても、実際に動かして、たくさんの労力を投入してテストして、顧客の前でデモしてフィードバックを受けなければ、使えるシステムにはならない。

モデリングと言う上流工程もAgile開発のように、モデリングしながら検証してモデルを洗練させていく設計スタイルに変えられないのだろうか?

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

2011/02/09

FV表とFL表

テスト仕様書を作る一つの方法として、直交表を用いたHAYST法がある。
HAYST法で重要な概念は、FV表とFL表の二つ。
考えたことをラフなメモ書き。
間違っていたら後で直す。

【参考】
ソフトウエアテスト分析の方法

テスト分析 テスト設計

受入テストのテストケースを作る場合、要求に対してテストケースを作る。
そのテストケースのレベルは、プログラムレベルではなく、顧客の観点になる。
だから、いきなりテストケースを作ったとしても、粒度や網羅性が不十分になりやすい。

ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方」にも書いてあるように、テスト設計で最も重要な観点は、テスト対象の因子・水準を漏らさず抽出することにある。
因子とは、テスト対象のパラメータ。
水準は、パラメータが取りうる値。

例えば、MSのOffice製品をテストする場合、OSやCPU、HDDなどは因子であり、因子OSの取りうる値であるWindows XP, Vista, 7は水準になる。

実際のテスト設計では、因子そのものを漏らしてしまう時も多く、そこから必ずテスト漏れになって、バグが出る。
更に、水準を全て抽出しきれなければ、バグの温床になる。
特に、因子同士の組合せで特別な処理が発生する場合も多いので、それら全てを網羅したテストケースを作るのは実際は非常に大変。

HAYST法では、まずFV表(機能検証表:Function Verification Table)を作る。
FV表とは、機能単位の検証内容の一覧表。
僕のイメージでは、FV表は、テストの観点であり、テストケースを作る元ネタ。
ソフトウエアテスト分析の方法にFV表の例が書かれている。
FV表がしっかり書けていれば、実際のテストケースは1日で500ケースぐらいは簡単に作れる。

次に、FL表(因子水準表:Factor Level Table)を作る。
FL表とは、テスト対象の因子と水準の一覧表。
僕のイメージでは、テスト対象のパラメータの組合せを作る元ネタ。
特にデシジョンテーブルの入力条件を洗い出す時に使っている。
ソフトウエアテスト分析の方法にFL表の例も書かれている。
FL表がしっかり書けていれば、テストに必要なデータパターンを機械的に洗い出すことができる。

ソフトウエアテスト分析の方法では、FV表とFL表から作られたテストケースをTestLinkにインポートした画面で終わっているのが印象的。

FV表とFL表という言葉は今まで知らなかったけれど、それに似たような作業はやっていたので腑に落ちる。
実際のテストケースレビューでは、テストの観点に相当するFV表を何度もレビューして、漏れが無いかチェックしていた。

FV表やFL表を作る元ネタは実際は、画面遷移図だったり、システムの状態遷移図だったりする。
つまり、要件定義や外部設計、内部設計の成果物の品質が悪ければ、FV表もFL表の質も悪くなる。
逆に言えば、FV表を作りながら設計書を作れば、自分の設計を自分で検証しながら作っているのだから、機能設計書の品質は良くなるはず。
又、FL表を意識しながら状態遷移図を作れば、システムの状態や状態遷移の漏れをチェックできるので、システムの状態遷移図の品質も良くなるはず。

ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方」によれば、FV表に出てくる機能は「名詞+肯定形の動詞」で表現でき、その否定形である故障モードは「名詞+否定形の動詞」で書けるらしい。
すなわち、その故障モードに影響度を追記した表はFMEA(意味:故障モードとその影響の解析)になるので、トラブルの予測に使える、とのこと。
確かに、FMEAがあれば、業務システムの運用保守や組込製品の故障分析で威力を発揮するように思う。

テストケース作成技法を持っていれば、テスト駆動開発と組み合わせることもできるはず。
テストケースが分かっていれば、それに基づいて実装すれば、自然にテスト駆動開発になるからだ。
つまり、Agile開発にテストケース作成技法を組み合わせれば、品質をより強化できるはず。

テストケース作成技法は日本の品質管理技法の中でかなり研究されてきた分野なので、奥も深い。
色々調べてみる。

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

2011/02/08

RedmineチケットをExcelにエクスポートするプラグインRedmine XLS Export

RedmineチケットをExcelにエクスポートするプラグインRedmine XLS Exportが公開されていたのでメモ。

【元ネタ】
Twitter / @Haru Iida: チケットをExcelにエクスポートするプラグイン Latest Redmine Plugins - Redmine XLS Export http://bit.ly/dO2dod

Redmine - Redmine XLS Export - Plugins - Redmine

このプラグインは下記のような特徴を持つらしい。
基本的にはチケットの情報全てを出力してくれるみたい。

(引用開始)
Requirements:
Plugin requires Redmine version 1.0.1 or higher.
Plugin relies on gem spreadsheet for XLS based operations. Please install this gem before running plugin.
Features:
* Export only displayed or all columns
* Export issue descriptions
* Export relations information
* Export spent time data
* List attachments information
* Export watchers
* Split information by sheets based on grouping criteria
* Correct formatting and width of worksheet cells
(引用終了)

Redmine XLS Exportプラグインを使いたい人達は、マネージャ層だろう。
Redmineに貯まったタスク情報やバグ情報をExcelで出力して、マネージャは自分が欲しいと思う情報に集計し直したり、整形し直せばいい。

Redmineでは顧客向けの進捗報告が作りにくい、とよく質問されるが、Redmineは元々、開発者視点のタスク管理で運用されているわけだから、そんな状況は当たり前だ。
Redmineに元ネタとなる進捗情報はあるのだから、マネージャは自分が欲しい情報のSQLで引っ張ればいいだけのこと。
そのために、Redmineに顧客向け進捗報告のプラグインを作るのは無駄だと思う。

業務システムでは、帳票出力の機能と同列でCSV出力の機能も付属している時が多い。
何故、帳票出力だけでなくCSV出力の機能もある理由は、出力したCSVを顧客自身が加工するためにある。
いわゆるエンドユーザコンピューティングだ。
帳票では自分の用が足りないという苦情は顧客からあがりやすいので、自分で加工できるようにCSV出力の機能を付けておくわけだ。
つまり、システムをより複雑化させるような機能をわざわざ付ける必要はない。
エンドユーザコンピューティングのように、手運用した方がコストも効率もいい時があるのだ。

Redmineには、ソフトウェア開発の生産性を上げるヒントがたくさん隠されているように思う。

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

2011/02/07

iBooksの感想

iOS4に更新したら、iBooksが使えるようになったので使い方をメモ。

【元ネタ】
apptoi: PDFファイルをiBooksに同期する方法

ウェブや青空文庫をiBooksで読む!! - ZONOSTYLE

Calibreを使うと、テキストだけでなくPDFやRSSからepubを作って、iBooksへ簡単に同期してくれる。
又、DropboxにあるPDFもワンクリックでiBooksへ同期してくれる。

DropboxならPDFをカンタンにiBooksコレクションに追加できる : ライフハッカー[日本版]

但し、iPod touchのiBooksはiPadのiBooksに比べるとそれほどの驚きが無かった。
文庫本サイズの画面レイアウトなので、文字が小さいと読みづらい。

個人的には、下記の記事のように、epubをあらかじめSigilなどでローカル上で作っておき、CalibreからiPod touchのStanzaへ同期させるやり方が一番フィットしている。
文字だけの電子書籍(epub)なので、Stanza上で読みやすいからだ。

Stanzaへの本の同期 Slash×Slash

Webの情報から電子書籍(epub)をRubyでもっと簡単に自動生成できないか、色々試行錯誤中。
Rubyがもっとうまく書けるようになりたい。

電子書籍の作り方part5: プログラマの思索

電子書籍の作り方part4: プログラマの思索

電子書籍の作り方part7: プログラマの思索

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

2011/02/06

iPadと教育

iPadで教育が変わる (マイコミ新書)」という本を立ち読みした感想をメモ。

【元ネタ】
iPadで教育が変わる - 情報考学 Passion For The Future

塾講師の方がさっそくiPadで社会と理科について、小学生向けに授業してみたらしい。
すると、下記のような面白い結果が出た、とのこと。

(引用開始)
・授業が紙の資料を使った時より早く終わってしまう
・画像や動画で子供たちの理解が進んだ
・子供たちが「紙に書かないとおぼえられない」という意見を出した
・小学校低学年には向かない
・見る、聴くに優れるiPad、書く、読むは課題
・重い紙の教科書を持ち歩かないで済む
(引用終了)

iPadを使うと、板書を書く必要がないので、無駄な時間が減る。
更に、生物の動画や日本各地の風景を簡単に見ることができるので、生徒の理解も速い。
又、授業アプリには小テストを実施する機能もあるので、テストで理解度を試すことも簡単に行える。
若い人ほど、デジタルツールにすぐに慣れるので、問題ない。
だから、あっという間に授業が終わってしまう、とのこと。

iPadを教科書代わりに使うと、教師の話術が目立つようになり、教えるという技術そのものが赤裸々に出てしまう、という感想が面白かった。
個人的には、教科書の内容を先生が板書に写す作業は無駄な時間だと思うので、授業の生産性を高める方法はもっと研究される余地があると思う。
又、Moodleのようなe-ラーニングWebシステムをどこで使うと教育で効果的なのか、もっと研究されてもいいはずだと思う。

eラーニングシステム Moodle: プログラマの思索
営業支援ツールSugarCRMとeラーニング支援ツールMoodleのリンク: プログラマの思索

逆に、子どもたちにデジタル教育について賛成・反対かどうかアンケートを取ったところ、賛成4票、反対6票だったらしい。
子どもたちのそれぞれの感想が面白い。
例えば、学校の授業は黒板がメインなので、iPadの授業はに合わないのでは、という意見。
あるいは、iPadだけでは、鉛筆で書いたり計算する作業がないので、覚えられない、と言う意見。

個人的には、大学入試や資格試験が筆記試験というスタイルを残している限り、教育のデジタル化には限界があると思っている。
iPadはあくまでも補助ツールであり、最終的には、自分で書きまくって計算したり、2000文字の論文を時間内に書き上げなければ、大学入試や資格試験で合格するゴールに直結しないからだ。

ただ、PCを使う作業はプログラマだけでなく事務員の人も多いので、ノートに鉛筆で書いたり、図でスケッチしたり、計算したりする機会がすごく減っている。
だからこそ、最近は、手帳術やノート術、マインドマップなどの思考ツールが逆に注目されているのだろうという気もする。

教育のIT化については今後も着目していく。

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

2011/02/05

【公開】XP祭り関西2011講演資料「Agile開発のスケールアップ~Agile2.0を支えるチケット駆動開発」 #xpjugkansai

XP祭り関西2011で講演した資料をCC Attributionライセンスで公開します。
最近考えたこともメモ。

【1】先日、著者の長谷川さんと橘高さんから「アーキテクチャ中心設計手法」を献本して頂いた。
ありがとうございます。
本の内容は、アーキテクチャ中心設計手法(ACDM)に関する解説で、本邦初とのこと。
似たような本として「実践ソフトウェアアーキテクチャ」もある。

今回の発表では、自分が大規模プロジェクトの一つのチームリーダーとして、プロジェクト全体の中でどのように動いたら良かったのか、そして、プロジェクト全体をどのように率いればよいのか、を色々考えてみたことを入れている。
今後は、アジャイル開発をブラッシュアップする技術として、チケット駆動開発がもたらしたワークフロー・トレーサビリティ・自動集計のような機能だけでなく、アーキテクチャ設計やテスト管理の観点も入れることを考えている。

【2】懇親会や2次会で話していて思ったことがある。
一つは、ソフトウェア開発の技術革新が過去の技術ノウハウや成功体験を陳腐化させていること。

メインフレーム+Cobolや昔の組込みシステムの開発で経験した技術ノウハウは、現代ではむしろ邪魔する時がある。
バッチ処理は昔は1日1回回すだけでも大変だったから、あれこれ工夫していたけれども、今は1日にリアルタイムのように何度もバッチ処理を走らせるのも普通。
バッチ処理もCobolよりもDBMSのストアドの方がメンテナンスも楽ではないかと思ったりする。

又、DBの性能が出ないためにテーブルの非正規化などのノウハウがあるけれど、今はDBMSも性能が良くなり、しかもサーバーそのものの性能もかなりいいので、むしろDBの非正規化によって、プログラムの保守の方が大変な時がある。
サーバーもHDDやメモリが1年おきに性能が拡張されて、値段も安くなるだけでなく、SSDのようにメモリをHDD代わりに使うことによって、I/Oの性能改善だけでなく、信頼性の向上という利点もある。
サーバー構築の手法も5年前に比べると、かなり変わってきている。

組込みプログラムも、昔は少ないメモリ上でいかにプログラムを書くかというノウハウがあったけれども、Androidプログラミングのように、今は大量のメモリがある前提で作った方が綺麗なプログラムが書ける。

そして、技術ノウハウもネット上に溢れているために、会社が技術の標準化を頑張ったとしても、その内容はネット上で探せるレベルならば価値がないし、技術革新の速度に追いつかなくて陳腐化しやすい。

つまり、10年以上前の技術の成功体験は実はあまり役立っていないどころか、綺麗なプログラムを書く邪魔をしている時すらある。
むしろ、経験者がアドバイスできるのは、プロジェクトマネジメントの経験ぐらいであり、組織運営やプロジェクト管理の方面だけに限られている。

そして、従来のプロジェクト管理の技法も、Agile開発やチケット駆動開発などで、プロジェクト管理の経験がない人達が模擬体験できる時代になりつつある。

すると、ソフトウェア業界で過去に成功した人達の存在意義があまり役立っていないような気がしている。
技術革新が過去の成功体験の価値を下げている面がある。

【3】もう一つは、日本人技術者は今までソフトウェア開発の技術に関してかなり経験を持っているのに、理論化出来ていない事。
その問題意識については下記に書いた。

忘れ去られた日本のIT技術~DOAと品質管理: プログラマの思索

忘れ去られた日本のIT技術~プロジェクト管理: プログラマの思索

日本人技術者は過去数十年のシステム開発で、品質管理・DOA・プロジェクト管理についてかなりのノウハウを持っている。
しかし、そのノウハウを体系化して、一つの理論として、書籍として公開してくれていないように思う。
だから、今の技術者は過去の人達のノウハウを流用できてない。

品質管理における信頼度成長曲線などのメトリクスに関する研究は、製造業の手法を参考にして、日本のメーカー系SIが独自に生み出してきた。
しかし、奈良さんの「ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点」ぐらいしか日本人の著作がない。

金融系などの業務システム開発の経験を踏まえて、1970年頃の早い段階でTHモデルやT字形ERなどのDOAが生み出されてきた。
しかし、今の日本の業務システム開発において、参考にされてはいるが、殆ど使われていない。
むしろ、Railsが出てきて、DOAの重要性が逆に注目されているというのに。

そして、大規模プロジェクトの経験から、プロジェクト管理のノウハウもいくつかの書籍として散らばった形としてまとめられている。
しかし、CMMIもPMBOKも過去のそれら知識を集大成して整理したたものに過ぎないのに、そちらの方がはるかに普及している。
せめて日本人技術者のプロジェクト管理のノウハウを、デザインパターンのようにプラクティス集にまとめてくれるだけでもいいのに。

但し、組み込み系プログラムの保守開発の経験から、清水吉男さんが提唱するXDDPという派生開発は独自発展している。

XDDPと言う派生開発: プログラマの思索
派生開発プロセスXDDPの講演メモ: プログラマの思索

アジャイル開発もスクラムもリーンソフトウェア開発も、本来は日本の野中先生の論文やトヨタ式生産手法がアイデアの発端にある。
アジャイル開発を日本流にアレンジしたアイデアとして、平鍋さんが提唱したプロジェクトファシリテーションというプラクティス集もある。
しかし、プロジェクトファシリテーションはこれだけ価値があると知られていて普及しているのに、代表的な著作がないのがとても残念。
平鍋さんはプロジェクトファシリテーションを書籍として出版しないのかな?

自分としては、過去の日本人が既に経験している優れたノウハウを集めて、一つの体系にして、公開できるものにできたらいいな、と思っている。

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

2011/02/04

Redmineから分岐したChiliProject

Redmineの主要コミッタであったEric Davisが、Redmineから分岐したChiliProjectを作り始めた。
リンクをメモ。

【元ネタ】
Twitter / @yusuke-kokubo: EricがRedmineをforkするらしい。経緯を考えるとすごく残念な話だ。 “@edavis10: It's official, Redmine has been forked. Long live @chiliproject http://bit.ly/f7ATi1”

ChiliProject - Why Fork - ChiliProject

RedmineはVer0.9からVer1.0まで、リーダー的コミッタであったフランス人が休んでいる間、アメリカ人のEric Davisがメンテナンスして、昨年秋にリリースにこぎつけた。
Redmineの各機能のリファクタリングも行い、チケットの親子関係を持つガントチャートへ改良した彼の功績は素晴らしい。
しかし、理由はよく分からないけれども、2人のコミッタが別れると同時にRedmineをフォークしてChiliProjectが作られたらしい。

個人的にはRedmineはとても優れたOSSのプロジェクト管理ツールだと思うので、どちらが本家なのか分かりにくくなるのは困るなあと思う。
今後の動向に注目していく。

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

2011/02/03

仕様書からシステムが動くXEAD Driver

DOAの専門家である渡辺幸三さんが、データモデルの設計から動くシステムを作り出すXEAD Driverを公開されていたのでメモ。

【元ネタ】
渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - XEAD

XEAD Driverをハッキング(2010年DOA学習のまとめ) - kurokouji39の日記

関西IT勉強宴会のブログです: DOAとXEAD Driverに関する私的な想い

特徴は、ER図とそれに付随する業務フロー、CRUD図を作ると、画面や帳票を自動生成して、動作確認できること。
画面や帳票はデータモデルに依存する特徴をうまく使って、モデリングしながら画面遷移できるのがいい。

最近のシステム開発は、Railsのような優れたWebフレームワークのおかげで、テーブル設計さえ決まればCRUD画面は簡単に作れる。
だからこそ、複雑な業務ロジックをテーブルとそのリレーションでできるだけ表現できれば、プログラムからネストしたIF文も消えるし、プログラムも読みやすくなる。

どこまで使えるのか興味はあります。

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

2011/02/02

Redmineでチケット駆動開発をAgileに運用するための4つの方法

Redmineでチケット駆動開発をAgileに運用するための方法をもう一度まとめておく。
あくまでも僕の一意見なので参考までに。

【参考】
チケット駆動開発のFAQ: プログラマの思索

【再考】TiDDのプラクティス集: プログラマの思索

Agile開発の肝はイテレーションにあり: プログラマの思索

バージョンのないRedmineプロジェクト~TiDD初心者が陥りやすい罠: プログラマの思索

TiDD初心者が陥りやすい罠part2~工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

【続】TiDD初心者が陥りやすい罠part2~工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

【Redmineでチケット駆動開発をAgileに運用するための4つの方法】
(1)RedmineチケットをXPのタスクカードのように扱う (Ticket First)
(2)Redmineチケットに構成管理情報をリンクさせる (No Ticket, No Commit!)
(3)イテレーションをビルドモジュールのリリース予定バージョンに対応付ける
(4)ビルドモジュール(コンポーネント)ごとにRedmineプロジェクトを作る

【解説】
(1)チケットは障害報告書だけでなく、仕様変更もタスクも扱う。
 チケットは作業指示書である。
 チケットは仕様書ではなく、どんな仕様を実装するかという作業内容や、どのように実装していったのか、という作業履歴が書かれている。
 チケットに作業の予定日や実施した作業日、予定工数や実績工数を毎日入力する運用にすれば、進捗報告の代わりになる。
 そして、チケット集計機能を使えば、ガントチャートやかんばんなどで、リアルタイムに進捗を確認できる。

(2)SVNコミット時に、コミットログに必ずチケットNoと修正理由を書く。
 例えば、「refs #10 リンクを直した」「fixes #11 パッチを取り込んだ」など。
 すると、チケットにSVNリビジョンの履歴が残るので、どんなコミットをしたのか、が分かるようになる。
 一度、この運用ルールに慣れてしまうと、チケットNo無しのコミットは修正理由が後で分からなくなるので怖くなる。

(3)Redmineバージョンはイテレーションに紐づけて、進捗が100%になったらリリースするように運用する。
 つまり、Redmineバージョンはビルドモジュールのリリース予定バージョンに対応付ける。
 これが小規模リリースになる。
 駄目な開発チームは、Redmineバージョンが工程や機能の単位などに分かれていて、リリースできるモジュールのバージョンに対応していないため、イテレーション管理がやりにくくなる。
 特にシステムテストや受入テストで厳格に障害修正を管理してリリースするプロセスでは、Redmineのロードマップがリリース計画に対応付けられていないため、リリース管理が運用しづらい。

(4)Redmineプロジェクトは、動くモジュール、リリース対象のコンポーネント単位に対応付ける。
 基本は、ブランチ(コードライン)単位にRedmineプロジェクトをアサインする。
 すると、ビルドモジュールに関わる修正やリリース作業などは全て、一つのRedmineプロジェクトで一括管理できる。
 駄目な大規模プロジェクトでは、工程単位にRedmineプロジェクトをアサインしているため、突発的なタスクをどこのプロジェクトにアサインしたらよいか迷うし、どのバージョンにどんな機能をリリースするのかというロードマップがあちこちに散在してしまって、Agileに開発しにくい。

Redmineを運用してみると、それぞれの機能は実はこういう目的のために作られていたのか、と改めて気づく時が多く、それがすごく楽しい。
Agile開発だけでなく、ソフトウェア開発で発生する作業をサポートする機能がとても面白い。

プロジェクトとブランチ(trunk)、バージョンとイテレーション、チケットとタスクカード/ストーリーカード、ワークフローとチケットのトラッカー、チケットのコピーと複製、関連チケット、作業分類と工数出力機能、ガントチャートとチケットの開始・終了日、チケットとSCM連携、サマリとチケットのステータス、ロードマップと変更履歴、ニュース、フォーラムのスティッキー、など数々の機能にはそれぞれ意味がある。

更に、RedmineもVer1.1に上がってもっと機能も改良され、数多のプラグインで機能拡張もできる。
色々試してみたい。

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

HTML5のオフライン機能の可能性

HTML5のオフライン機能の可能性についてメモ。

【元ネタ】
HTML5で、オフラインでも使えるiPod/iPhone超簡単アプリっぽいものを作ってみた - Publickey

Web利用はオフラインに拡大へ,企業アプリも変わる? - 最新ブラウザが描く次世代Webの輪郭:ITpro

HTML5を使うと、ネットワークに接続しない状態でもオフラインでWeb画面を見ることができる。
仕組みとしては、キャッシュとして残したり、SafariやFirefoxなどのブラウザに搭載されたSQLiteに必要な情報を保存しておく。
この仕組みによって、iPhoneでオフラインでメールを見たり、Webページを見ることができる。

HTML5のオフライン機能はそんなにすごい実装ではないだろうが、Ajaxが出現した頃を思い出させる。
AjaxもHTML5もWebアプリをデスクトップアプリのように、セッション切れや画面状態の復元の難しさなどを感じさせないように進化させようとしている。

業務アプリを使うユーザ企業やそれを作るSIは、業務アプリのWebアプリ化を嫌う傾向が強い。
メインフレームの頃の基幹系システムやクライアント・サーバーの2層アーキテクチャの業務システムでは、ユーザはマウスを使わずにFunctionキーなどを駆使して、電卓のようにデータを入力するユーザインタフェースが主流だ。
何故なら、業務で使う大量のデータを入力する必要があるために、電卓のようにキーボードを早く叩いて操作できるUIを欲しがっているからだ。

だから、Webアプリが登場して、業務アプリを侵食しつつある状況に対して、使い勝手の悪さを指摘する声は大きかった。
しかし、AjaxやHTML5のように、Webアプリをデスクトップアプリ化していく手法は今後も進んでいく。

Webアプリの利点は、全てのアプリとデータがサーバー上に一元管理されているので、リリースや運用保守がやりやすい点が一番だろう。
そしてスケールアップやセキュリティ確保もやりやすい。

HTML5がもっと進化すれば、WebアプリのMVC2モデルのうち、Viewの部分はHTML5で取って代わるだろう。
そうすれば、PCのブラウザだけでなく、iPhoneのようなスマートフォン、iPadのようなタブレットでも業務アプリを操作できるようになるだろう。
今後の進化にも注目していく。

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

« 2011年1月 | トップページ | 2011年3月 »