« 2011年4月 | トップページ | 2011年6月 »

2011年5月

2011/05/31

Redmine 1.2.0 released!

ついにRedmine 1.2.0 がリリースされたのでメモ。

【元ネタ】
Redmine - Redmine 1.2.0 released - Redmine

Twitter / @yusuke-kokubo:Redmine v1.2では日本人コミッターのまるやまさんのおかげでSCM周りが強化されてます。目立たないけど改修規模はけっこう大きい。 http://bit.ly/dXkPto

Twitter / @MAEDA, Go: Redmine 1.2.0がリリースされた。 http://t.co/4HeTm5O

Twitter / @ケイジー: おぉ。RT @naitoh: Redmine 1.2.0 ガントチャート、バージョンにくくり付けられてるチケットが全てクローズされたら、ちゃんと「ステータス:未完了」のフィルタで表示されなくなってる。結構不便だったんですよね。

Twitter / @NAITOH Jun: Redmine 1.2.0 がリリースされました。 http://www.redmine.org/news/55 大きな変更点はPDF文字化け修正、SCM回りの改良、プライベートイシュー、カスタムフィールド書式追加。あと、説明変更の差分追加、チケット一覧PDF出力の自動改行など。

Twitter / @Kato Kiwamu: Redmine の最新バージョン 1.2 がリリースされてた。 http://ow.ly/56luc プライベートチケットとか、LDAP や SCM 連携時のパスワード暗号化とか地味に嬉しい。

【過去のリリース記事】
Redmine 1.0.0 released!: プログラマの思索

Redmine Ver 0.9.4がリリース: プログラマの思索

ついにRedmine 0.9.1が出た: プログラマの思索

Redmine0.9.xの新機能: プログラマの思索

Redmine 0.8.0 release candidate!: プログラマの思索

皆さんのコメントを見ると、新バージョンに期待していた人はとても多い。
@yusuke_kokuboさんの言う通り、SCM機能の強化など地味な細かな機能改善が多いけれども、おかげでどんどん使いやすくなっている。

実際にWindwos上にRedmine 1.2.0をインストールしてみた画像を添付しておく。

以前のバージョンでは、WindowsにTortoiseHgを入れたとしても、Mercurialのhgコマンドのパスをソースにパッチあてしないといけなかったが、今回のバージョンではそのまま動作できて、リポジトリの追加も簡単だった。
しかも文字コードを選択できるようにしているし、リポジトリ設定画面でも、どのSCMコマンドが有効なのかを表示してくれるし、「バージョン管理システムのコマンドをconfig/configuration.ymlで設定できます。設定後、Redmineを再起動してください。」という親切なコメントまで表示してくれている。
とても気配りされていて、とても素晴らしい。

【プライベートチケットのチェックボックス付きのチケット新規登録】
Redmine12_newticket

【管理画面のロールと権限設定にもプライベートチケットの制御あり】
Redmine12_role_setting_2

【管理画面のリポジトリ設定】
Redmine12_repository_admin

【プロジェクト設定画面のリポジトリ設定】
Redmine12_repository_setting_2

なお、Rails2.3.11ではMongrelでは起動しない症状が報告されていたが、僕の環境では正常起動している。
但し、環境依存と思われるので注意。

Redmine - Feature #6887: Upgrade to Rails 2.3.11 - Redmine

Twitter / @akipii: Redmine1.2ではMongrelで起動できない話があるので、試してみる。@basyura rails 2.3.11+mongrel+apache 構成で動作しない場合はパッチを config/initializers に放り込むhttp://htn.to/axL4Lt.

オープンソースのプロジェクト管理ツールでRedmineほど完成形に近いツールはあまり見当たらないのではなかろうか?
Redmineの一ファンとして今後も追いかけます。

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

Redmineのガントチャート改善part2

Redmineのガントチャートを改善するパッチについてメモ書き。

【ガントチャートのPNG出力】
ガントチャートのpng出力で文字化け - Redmine Users (japanese) | Google グループ

Redmine0.9.2の設定と運用 -- qui-no Labs

RMagickをインストールしておくと、ガントチャートをPNG出力できるリンクが出てくる。
PDFとは違って、A3で1枚で印刷したいときに役立つだろう。
しかし、日本語は文字化けしてしまう。
上記のパッチを当てると、WindowsでもUnixでも日本語が文字化けしなくなる。

【開始日=終了日のチケットの色付け】
開始日と期日が同じ日の場合、ガントチャートで色が変わらない?!:ソフトウェア開発日記~北海道・東北にて~:So-netブログ

Redmine - Defect #7838: Gantt- Issues does not show up in green when start and end date are the same - Redmine

Redmineのガントチャートは何故か、チケットの開始日=終了日の場合、ステータスが進行中や終了でも、色付されない。
ガントチャートで色付されないタスクは未着手と思われてしまうので、改善して欲しいと言う要望があった。
上記のパッチを当てると、ステータスが新規以外の場合、緑色が表示されるようになる。

【ガントチャート上で開始日、期日を編集可能にする】
ガントチャート上で開始日、期日を変更したい:ソフトウェア開発日記~北海道・東北にて~:So-netブログ

ガントチャート上で開始日、期日を変更したい(その2):ソフトウェア開発日記~北海道・東北にて~:So-netブログ

Redmine - Patch #2024: gantt chart editting - Redmine

Patch #2024 gantt chart editting 使っておられる方 - Redmine Users (japanese) | Google グループ

Redmineのガントチャート上で開始日と期日を修正できるようにするパッチがアップされている。
Redmineメーリングリストでは、ガントチャート上で100件以上のチケットを表示した場合、チケットを1つずつ修正してはガントチャートを再表示させる手間がかかるために、上記のパッチが必要という内容が書かれている。

現在は、v1.1.2までのパッチが提供されている。
但し、上記のパッチを見れば分かるが、かなりたくさんのファイルにパッチを当てる必要があるため、取り込む場合は注意した方がいい。

【その他】
RedmineのガントチャートはMS ProjectのWeb版になりうるか?: プログラマの思索

Redmineに入れたプラグイン一覧part3: プログラマの思索

個人的には、ガントチャートに日付や罫線をPDF出力するパッチと文字化けせずにPNG出力するパッチがあれば十分かな。

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

2011/05/30

RedmineのTimeTrackerプラグインが使いやすい

RedmineのTimeTrackerプラグインを入れてみたら、使いやすかったのでメモ。

【元ネタ】
delaitre/redmine_time_tracker - GitHub

RedmineのTimeTracker Pluginが使いやすい - プチ技術メモ

plugin紹介 on Redmine: 100ねんごの未来予想図

Twitter / @kuribone: Redmine の Time Tracker plugin が便利だな。今まではめんどくさくてほとんど入れていなかった作業時間がある程度入れれるようになったので自分の見積と実際の作業時間がどんなものかよくわかった。結構ずれているもんだ

(引用開始)
Redmineで作業時間をストップウォッチみたいな感じで記録するプラグインがないか探していて、見つけたのがTimeTracker Pluginです。このプラグインをインストールすると、画面右上の「個人設定」の隣に現在作業中のチケットの作業時間が表示されるようになります。
使い方は非常にシンプルで、
* 作業を開始する時に対象となるチケットを表示して、画面右上の「開始」をクリック
* 作業を終了する時に画面右上の「終了」をクリック
* Redmine標準の作業時間の記録画面が表示され、初期値として開始から終了までの時間がセットされる
また、管理者権限のあるアカウントログインすると、画面左上の「管理」の隣に「作業時間」リンクが表示されます。「作業時間」リンクをクリックすると、現在作業中のチケットの一覧が表示することができます。
(引用終了)

RedmineのTimeTrackerプラグインはストップウォッチのようなプラグイン。
例えばステータスが新規→進行中に変わる時に、ストップウォッチが画面右上に現れて、ボタンを押すと秒単位で時間を記録してくれる。
実際に使ってみると、小数点2桁の時間(例えば、0.14h)で表示されるので、今まで自分たちが実績工数を入力していたのがとても安直だったことがよく分かる。

TimeTrackerプラグインが必要な状況は、実績工数をきちんと管理したい場合だ。
Redmineでタスク管理を始めると、マネージャクラスは予定・実績工数の管理をしたがる。
マネージャは最終的にはPMBOKのEVMやABC(活動基準原価計算)の元ネタとなるデータとして収集したいのだ。
そうすれば、プロジェクトの予算やコストをRedmineから集計したりシミュレーションしたりできる。

しかし、チケットをこなすたびに実績工数を入力する運用にすると、入力の手間の方がかかるために、Redmineを使うのが億劫になってしまいがち。

TimeTrackerプラグインを使う場合、今からこのチケットに専念する、と宣言してチケットに取り掛かる時に、ストップウォッチの開始ボタンを押して時間の記録を開始し、コミットが終わったら、停止ボタンを押して実績工数を入力する運用にしてもいいだろう。

【管理画面】
Redmine_timetracker__setting

【計測開始画面】
Redmine_timetracker__start

【計測した工数の更新画面】
Redmine_timetracker__update

【計測した工数の完了画面】
Redmine_timetracker__record

【計測中のチケット一覧】
Redmine_timetracker__list

あるいは、PSP(Personal Software Process)を実施する時に、自分の作業時間を記録する場合に使ってもいいだろう。
PSPでは、開発者が自分の設計書やソースの規模や工数を自分で測定しながら、自分の作業を改善していくやり方を行う。
自分で自分の作業を計測するのは結構面倒なのだが、TimeTrackerプラグインを使うならば、自分の作業をチケットに起票すれば、自然に工数を取得できる仕掛けがある。
チケットに専念すれば、バックグラウンドで実績工数をRedmineが自動で計測してくれるから、気にしなくていい。

チケット駆動開発にPSPの概念を持ち込む: プログラマの思索

とはいえ、僕はRedmineでAgileに開発したいから、実績工数の正確な入力よりも、チームのコミュニケーションが活性化して、アウトプットをどんどん出していける環境を優先したい。
色々試してみる。

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

2011/05/28

ユーザ機能駆動開発FDDを再考

アジャイル開発手法FDD―ユーザ機能駆動によるアジャイル開発」を読んで、Agile開発のスケールアップに必要な概念が揃っている感覚に陥って驚いた。
考えたことをメモ。
間違っていたら後で直す。

【元ネタ】
ユーザー機能駆動開発 - Wikipedia

トカゲの独り言: 『アジャイル開発手法FDD』読了

銀行システムの失敗から生まれた開発方法論 - 日経コンピュータ・コラム:ITpro

Twitter / @akipii: FDD(Feature Driven Development)本を読んだら、まるでデジャブみたいだった。概念モデル設計=ドメイン駆動設計(DDD)。フィーチャ=ユーザ機能リストorバックログ。フィーチャの進捗=パーキングロットチャート。

Twitter / @akipii: FDDのクラスオーナーはConwayの法則の観点からも正しい。SW組織はテクノロジラインではなく、フィーチャ単位でチームを分割して作るべき。OL・BT・サーバー・設計チームのようなテクノロジで分割された組織は統一されたアーキテクチャの無い複雑なソフトウェアを作る。

Twitter / @akipii: FDDがScrumやかんばん(リーン)に影響を与えたものは、パーキングロットチャートではないか? 要件管理の鍵はパーキングロットチャートにあるような気がする。

【FDDの特徴】
ユーザ機能駆動開発は、概念モデルからユーザ機能(Feature)のリストを抽出して、ユーザ機能をインクリメンタルに開発していく初期アジャイル開発手法の一つ。
オブジェクト指向設計と密接に絡んでいるのが特徴の一つ。
初期アジャイル開発では、XPやScrum以外の例の一つとしてFDDがよくあげられていたが殆ど普及されていないように思える。

FDDの最大の特徴は、ユーザ機能を顧客に価値あるソフトウェアの機能と定義して、ユーザ機能を中心に設計や開発をインクリメンタルに開発していくこと。
ユーザ機能の概念は顧客の観点を重視しているので、顧客に価値あるソフトウェアを届けるアジャイル精神とすごくマッチする。

【概念モデル設計=ドメイン駆動設計】
FDDで面白いと思ったものはいくつかある。

一つ目は、FDDのプロセスの最初に行われる全体モデル構築プロセスとは、まさにドメイン駆動設計(Domain Driven Development)そのものだ。
実際、「アジャイル開発手法FDD―ユーザ機能駆動によるアジャイル開発」の翻訳では、領域専門家と開発メンバーが領域分野からモデルを抽出すると書いているが、これは、業務知識(ドメイン)をよく把握している業務SEと開発者が、ドメイン駆動設計から概念モデルをオブジェクト指向分析(OOA)によって作り上げる意味だろう。
プロセスの内容を読んでみるとまさに、Eric Evansのドメイン駆動設計の本の内容をそのまま適用しているかのようだ。

FDDを提唱したピーター・コードはOOAの専門家であるから、アジャイル開発とOOAをうまく絡めているのだろうと推測する。

【ユーザ機能リスト=バックログ】
二つ目は、概念モデルからユーザ機能リストを作成する手法は、まさにバックログを作るのと同じだ。
ユーザ機能リストとは、概念モデルから顧客に価値あるユーザ機能を抽出して一覧にしたもの。

面白いのは、ユーザ機能は<アクション><結果><オブジェクト>で表現されるもので、ユーザ機能のサイズは2週間で実装できるサイズまで小さいこと。

OOAではユースケースを作ってからクラス設計していくが、「アジャイル開発手法FDD―ユーザ機能駆動によるアジャイル開発」ではユースケースを暗に批判している。
ヤコブソンいわく、10人年のプロジェクトではユースケースは大体20個レベルと言うぐらいの粒度なのに、ユースケースの粒度は実プロジェクトではバラバラになりやすい。
又、伝統的な構造化設計に慣れたドメイン専門家は、ユースケースを詳細設計書のように、ユーザインタフェースと永続化の詳細、ビジネスロジックをごちゃ混ぜに書いてしまいやすい、と。

僕の経験でもユースケースは書きづらいし、書いたとしてもあまり役立たない。
クラス図やシーケンス図を見た方がプログラム設計が分かるし、ユースケース以前の業務フロー図の方が業務を理解しやすいからだ。

FDDがユーザ機能(Feature)という概念を抽出したことは注目に値する。
XPではストーリーカードという概念があるけれども、開発者の視点が強く、顧客に価値ある機能という観点がはっきりしていないように思える。
ユーザ機能が2週間で実装できるサイズだからこそ、インクリメンタルに開発することも可能になる。

ユーザ機能はばらつきが出やすいだろうから、ユーザ機能を2週間レベルのサイズへ落とすには、オブジェクト指向分析の技術で更に分割することが必要で、ドメイン駆動設計の本が有効だろうと思う。

そして、ユーザ機能リストというバックログを作ることができれば、ビジネスの重要度や作業の優先度から、どのユーザ機能を先に開発していくか、という判断がやりやすくなる。
Scrumのバックログやリリース計画の話と非常に似通っていているので、今となってはむしろ分かりやすいように思える。

【ユーザ機能単位計画=リリース計画】
FDDでは、ユーザ機能リストというバックログを作ったら、ユーザ機能単位計画を作り、その計画に従って開発していく。
ユーザ機能単位計画はまさにリリース計画であり、Redmineのロードマップに相当するだろう。

計画作りで重要な点は、ユーザ機能に期限(完了予定日)、つまりリリース日を付けることだ。
すなわち、イテレーションの終了日と一致するから、XPのイテレーション計画又はScrumのスプリント計画を作ることと同義。
実際、ユーザ機能単位計画では、ユーザ機能を実装するためにクラスへ更に分割して開発順序を決めていくが、その作業は、フィーチャからストーリーカードへ分割し、更にタスクカードへ分割し、それらの作業順序を決めることと同じ。

FDDが他のAgile開発手法と異なる点は、ユーザ機能を実装レベルのクラスに落とす時に、クラスに開発者を担当させて、クラスの中身(ソースコードそのもの)の最終責任者を決めることだ。
つまり、OOAの責任駆動設計と開発者の実装責任をリンクさせる点に最大の特徴がある。

【ユーザ機能チームとクラスオーナー】
XPでは、ソースの共同所有というプラクティスがあるように、ソースやクラスに責任者はおらず、全員で開発していく。つまり共同担当。
FDDでは、概念モデル(領域オブジェクトモデル)からひとまとまりのクラスの担当としてクラスオーナーが割り当てられる。つまり個別担当。

共同担当の利点は、誰かがソースを修正するまで自分の修正を待つこと無しに自ら直していくことができるので、アジャイルに開発しやすい。しかし、最終責任者がいないから、メンバー数人が主導権を握ってしまい、彼らが全ての仕事を行おうとして、負担が大きくなりがち、と指摘している。

個別担当の利点は、クラスの開発者が最終責任者だから、その業務(ドメイン)やコードの概念的完全性に対する責任に一貫性があるので、クラスの品質は保持されること。
逆に、個別担当の弱点は、Fatなクラスを実装する開発者の責任が重くなりがちで、ボトルネックになりやすいことと、クラスオーナーがいなくなると、クラスに関する業務やコードの知識が抜けてしまうこと。

そこで、FDDではユーザ機能チーム結成とインスペクションで対応しようとしている。
インスペクションはレビュー技法の一種で、インスペクションを通じて、クラスの業務(ドメイン)やコードをチーム全員で共有可能にする。

ユーザ機能チームは、ユーザ機能を担当するチーフプログラマ(リーダー)が、実装に必要なクラスオーナーを集めた開発チームを作ること。
そして、ユーザ機能チーム内部で、チーフプログラマは複数のクラスオーナーの間で発生する諸問題を調整する役割を担うことで、上記の問題を解決しようとする。
特に、Fatなクラスは責任が重過ぎる症状を示しているから、そもそものクラス設計を見直す時もありうる。
FDDでは、実装対象のクラスとユーザ機能を実現するクラス(ドメイン)を故意にリンクさせているので、そういうリスクが発覚しやすい利点があり、そのリスクの解決責任をユーザ機能チーム全体に負わせているのだ。

ユーザ機能チームは特定のユーザ機能を実装するために結成されているので、それを実装する必要なソース全てを担当しているので、クラスオーナーは必ずいるし、コードの変更のために他チームへ依頼する必要もない。
だから、コードの個別担当と共同担当の両方の感覚をユーザ機能チームは持っている特徴を持つ。

アジャイル開発手法FDD―ユーザ機能駆動によるアジャイル開発」では「ユーザ機能の受付箱を持っているかのようにチームリーダーは、ユーザ機能の達成に責任があり、ユーザ機能の受付箱を持っているものとして考えることができます」というまずい翻訳があるが、多分そういう意味だろうと推測する。

【ユーザ機能チームとマトリクス型組織】
更に、ユーザ機能は2週間で実装できてしまうため、実装完了したらチームは解散して、次のユーザ機能チームを結成していく。
つまり、ユーザ機能を担当するチーフプログラマは必要なクラス担当者(クラスオーナー)を選び出し、開発が完了したら解散するというサイクルを2週間おきに何度も繰り返す事になる。
すると、ユーザ機能チームはクラス担当者の混合編成、つまり、マトリックス型組織の構造を持つ。

PMBOKのマトリックス型組織はラインとスタッフの2つの観点でメンバーは管理されるが、FDDでは、ユーザ機能とクラスという観点で開発者は組織される。
マトリックス組織は確かに柔軟な構造であるが、2つの説明責任が発生するためメンバーの負荷が高くなりがち。
FDDでは、ユーザ機能チームのチーフプログラマがマトリックス型組織で出てくる諸問題を調整する役割を担っているのがミソ。

【Conwayの法則とユーザ機能チーム】
FDDのユーザ機能チームは、Conwayの法則「システムのアーキテクチャは組織構造に従う」の観点から見て、うまく設計されているように思える。

Conwayの法則~アーキテクチャは組織にしたがう: プログラマの思索

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

オブジェクト指向分析には責任駆動設計という概念があり、Fatなクラスは責任が重すぎるため、更に分割して粒度を合わせるべきだというプラクティスが含まれている。

FDDでは、概念モデルのユーザ機能と開発担当のユーザ機能チーム、概念モデルのクラスと開発者(クラスオーナー)が対応付けられているので、システムのアーキテクチャと組織構造がそのまま直接マッピングしている特徴がある。
この特徴によって、システムのアーキテクチャはすごく見通しがよくなるだろうと推測する。

Conwayの法則に反する組織構成の例は、テクノロジラインでチームをつくることだ。
例えば、設計チーム・開発チーム・品質保証部門のように、工程別にバラバラに組織構成してしまうと、チーム間の断絶の部分で必ず認識漏れが出て、システムの構造が複雑化してしまう。

あるいは、業務システム開発でオンラインチーム・バッチチーム・サーバーチームなどのように技術別に分けてしまうと、結合テストで必ず火を噴く。
何故ならチーム内部で完結する機能は認識済みなのでテストもしているだろうが、各チームのインターフェイス部分はテストしていないので必ず認識漏れがあり、その部分にパッチを当てる度にシステムはどんどん継ぎ接ぎだらけになってしまうだろう。

システム開発の大規模化が難しいのは、Conwayの法則に逆らった組織構成にしてしまうのが最大の原因ではないかと最近思っている。

【パーキングロットチャート】
FDDが他のAgile開発にはない特徴を持つものは、パーキングロットチャートを編み出したことだろう。
パーキングロットチャートはフィーチャ(ユーザ機能)の進捗を示すための図だ。

InfoQ: かんばんボードによるプロジェクトの見える化

パーキングロットチャートには、ユーザ機能名とユーザ機能を実装するストーリーカード数、ストーリーカードの完了率、期限(リリース日、マイルストーン)が表示されている。
又、ユーザ機能の状態が色分けされており、進捗が遅れたら赤色、完了したら灰色のように表示されるので、一目で分かる。

Agile開発の進捗報告ビューでは、タスクボード(かんばん)・バーンダウンチャート・パーキングロットチャートなどがあるけれども、顧客の観点では、パーキングロットチャートが一番わかりやすいだろうと思う。
顧客にとって価値あるものはユーザ機能であり、ユーザ機能の進捗状況がパーキングロットチャートから読み取れるからだ。

タスクボードは開発者のタスクカードの進捗状況を示したものであり、粒度が細かすぎる。
バーンダウンチャートは確かに予定と実績の差が分かるけれども、進捗の遅れがどこにあるのか、その詳細は分からない。
バーンダウンチャートはあくまでも集計結果にすぎないからだ。

Redmineでは、@daipresentsさんがタスクボード・バーンダウンチャート・パーキングロットチャートのプラグインを実装してくれていて、僕も実際に使ってみた。

redmine_parking_lot_chart

redmine_version_burndown_charts

redmine_task_board

Redmineに入れたプラグイン一覧part2: プログラマの思索

タスクボードは確かに面白いのだが、リーダーも開発者もRedmineのチケット一覧の方をよく使う。
ステータス別だけでなく、期間や担当者、カテゴリなどの観点で絞りたい時が多いからだ。

また、バーンダウンチャートは、開始日・予定日はもちろん予定・実績工数をきちんと入力してくれないと綺麗なグラフにならない。
Redmineのバージョンは期限しか保持しないため、開始日が遠く離れていると変なグラフになってしまう。

でも、パーキングロットチャートは確かにすごく分かりやすい。
Redmineバージョンをイテレーションに同一視する場合、普通はイテレーションはユーザ機能を実装するために開発するわけだから、ユーザ機能に同一視しやすい。
@daipresentsさんが、パーキングロットチャートをRedmineの運用で「唯一生き残ったプラグイン」と評価した理由が何となく分かったような気がする。

Redmineでアジャイルチームのスピードやパワーを見える化する | 世界 - @daipresents

又、パーキングロットチャートプラグインを使ってみて、これらプラグインを実装された@daipresentsさんはアジャイル開発をよく研究されているなあ、という感想を持った。僕の方がまだまだ足りないと思っている。

【感想】
FDDはピーター・コードが編み出しただけに、TogetherControlのようなツールと一体化されてしまって、あまり流行していないように思える。
でも、FDDが編み出した概念は現在のAgile開発に取り入れられたものもあるし、取り入れた方が良い考え方もあるように思う。
色々考えてみる。

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

2011/05/26

MS Projectを使いこなせない理由

普通は、MS Projectをどれだけ使いこなしているか、でプロマネのスキルが分かる。
ラフなメモ書き。

【元ネタ】
MSプロジェクトは使いこなすな! - メイクミラクル ~大逆転~

タイム・コンサルタントの日誌から : Excelで工程表を書いてはいけない

MS-Projectとかイナズマ線とか | kozawa のたまに気になること

Microsoft Office : これならわかる!! Microsoft Office Project 2003

【MS Projectの代替ソフト】
プロジェクト管理の選び方と使い方&プロジェクト管理×15 at Cool Coding

Microsoft Projectの代替ソフトウェアとしてプロジェクト管理が可能でガントチャート表示もできるフリーソフト「OpenProj」 - GIGAZINE

開発マイルストーン

OpenProjを使ってみた: プログラマの思索

GanttProjectを再び使ってみる: プログラマの思索

普通のプロマネなら、MS ProjectでWBSを洗い出してスケジュールを引き、ガントチャートを見ながらスケジュール管理しているのではないだろうか?
MS Projectのウリの一つは、ガントチャートにロジカルな整合性を保証できることやリソースの平準化やEVMなどプロジェクト管理らしい機能が付いていることだろう。
だからこそ、高機能過ぎて、普通の人はMS Projectの20%しか使えてないと言われているのだろう。
僕も5年以上前はMS Projectを使いこなそうと頑張っていたが、結局使いこなせなかった。

MS Projectでスケジュール管理を始めると、mppファイルに日付を入れてリネームして、ファイルで履歴管理するようになる。
MS Project自身もWordと同様に履歴管理機能があるけれど、すぐに肥大化してしまうからだ。

又、実際のソフトウェア開発では、仕様変更や障害修正など、割り込みタスクが非常に多い。

単なる線表だけでなく、FS関係もつなげてタスクや担当者が重複しないように調整する必要がある。
うまく調整しないと、納期までに全てのタスクを終了できなかったり、特定の担当者の負荷が高くなってしまう。
だから、ガントチャートを保守するだけで、半日以上の手間がかかる。

MS Projectでガントチャートをそこまで労力をかけて保守しなければならない理由は、下記に書いた。

チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索

つまり、ガントチャートでしか、リスクや残タスク、残工数を他人に説明できる資料がないからだ。

しかし、RedmineやTracを使ってみるとよく分かるが、ガントチャートは進捗管理の一つのビューに過ぎない。
Tracならクエリを使えば、好きなだけ進捗や品質に関するビューを生成できるし、Redmineならプラグインを追加すれば、アジャイル開発のビューをすぐに使うことができる。

アジャイル開発ならば、タスクかんばん、バーンダウンチャート、パーキングロットチャート、ニコカレなど色んなビューが用意されていて、進捗やリスクを把握できる環境がある。
例えば、開発者はタスクボード、プロダクトオーナーはバックログでビューを使い分けるというScrumのような手法もある。
つまり、アジャイル開発は従来のプロジェクト管理に比べると、実は進捗管理のビューが優れている。

最近、@daipresentsさん作成のRedmineのパーキングロットチャート・プラグインを使ってみて、自分はアジャイル開発を全然理解していなかった、という気になった。
パーキングロットチャートはFDD(フィーチャ駆動開発)という別のAgile開発から生まれたビューであるが、フィーチャ(機能、ドメイン)の進捗を知るのに、一目で理解できる優れもの。

InfoQ: かんばんボードによるプロジェクトの見える化

Redmineを使ったアジャイル開発支援プラグインのご紹介 - Redmine Users (japanese) | Google グループ

もう少し色々調べてみる。

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

2011/05/25

チケットファーストからビルドファースト、Gitoriousへ

Gitoriousやゼロ機能リリース(Zero Feature Release)に関するラフなメモ書き。

【元ネタ1】
Gitを使った開発・運用フローの紹介 | FIRN.JP

Gitという優れた分散バージョン管理をソフトウェア開発の中心の配置して、チケットやビルド管理ツールを連携する方法が書かれている。

GitoriousとRedmineを使った開発 - ひかえめプロジェクト

(引用開始)
ポイントは,フィーチャーブランチ,リリースブランチ,ホットフィックスブランチをそれぞれRedmineのチケットに対応付ける点です.
これらのブランチの名前をすべて id/xx (xxはチケットナンバー)にすることで,自動的にブランチ上のコミットがRedmineのチケットに対応付けられます.
(引用終了)

ブランチはRedmineプロジェクトだけでなく、チケット単位に作ってもいい。
分散バージョン管理を使っているなら、チケット単位に自分だけのブランチを作って開発して、masterへPush又はrebaseする時にチケットがCloseされる運用になるだろう。

Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記

Redmineを使いたいと思う人の理由の一つに、SCM連携としてGitがデフォルトで対応しているから、というものがあった。
Redmineと連携する場合、MercurialよりもGitの方が使いやすいのかもしれない。
(追記:Redmineコミッタのまるやまさんから、Redmine1.2では、Redmine+Mercurialが最強です、とのコメントを頂いたので修正しました。ご指摘ありがとうございます。)

【元ネタ2】
第三回Jenkins勉強会に参加しました。あるいはZFRは次のムーブメントを起こすか - ハードコイルド・ワンダーランド

ソフトウェア開発の秘伝“Development Baseline 2007” - @IT

ゼロ機能リリースとは、一番最初のイテレーションで、ソフトウェア開発に必要な開発基盤や紙芝居(HTMLだけで、動くシステムではない)などをリリースすることらしい。
XP祭り関西2010でも、中西さんが、Trac+SVN+Hudsonという開発基盤を作るというゼロ機能リリースについて講演されていたのを思い出す。
XPのアーキテクチャスパイク、プロトタイピングに相当するように思える。

ゼロ機能リリースが必要な理由は、最初のイテレーションで、顧客へ価値あるソフトを提供する基盤を整えて、必要なフィーチャをできるだけ洗い出して、その後のイテレーティブな開発を順調に軌道に載せたいから。
牛尾さんが、この辺りのフェーズではストーリー供給力やストーリー検証力が必要、と言っていたのを思い出す。

色々考えてみる。

【追記】
かおるんさんから指摘を受けたので、修正・追記しておいた。

Twitter / @中村 薫: @akipii この話ですよね。 これなら納得です:-) http://bit.ly/kvuDNR

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

2011/05/24

RedmineのガントチャートはMS ProjectのWeb版になりうるか?

Redmineのガントチャートを改造するパッチやプラグインをメモ。

Redmineのウリの一つは、チケットに開始日・終了日・進捗率を入力しておけば、ガントチャートを自動生成してくれること。

現場リーダーがあらかじめWBSからタスク一覧を洗い出して一括インポートした後は、Redmine上でメンバーがチケットを最新化してくれれば、プロジェクトの最新状況をガントチャートで見ることができる。
又、開発チームの進捗に直接タッチしない会社の上層部もガントチャートを見れる環境にしておけば、進捗の遅れやリスク、アラームを社内全体で共有できる利点もある。

だが、Redmineのガントチャートはチケットの親子関係も反映してかなり良くなったけれども、MS Projectに比べるとまだ足りない機能がある。
色々調べてみた。

【環境】
Redmine 1.1.2

【ガントチャート改造(日付)】
Redmineに入れたプラグイン一覧part3: プログラマの思索

【Redmine 1.1.2】ガントチャートに日付を表示させる|渋谷ではたらくイタズラ者、マー君のブログ。

HTML上のガントチャートに日付を表示させるパッチ。

【ガントチャート改造(担当者)】
Redmine1.1.0でガントチャート上の担当者名表示 - Redmine Users (japanese) | Google グループ

HTML上のガントチャートに担当者を表示させるパッチ。

【ガントチャート改造(PDF出力)】
10/19時点の1.1.0に向けて開発中のredmineのガントチャートに日付を出力 その2 - 雑多な日々

10/25時点の1.1.0に向けて開発中のredmineのガントチャートをPDFに その1 - 雑多な日々

Redmine の ガントチャートの PDF 出力に縦線を出してみた - 玩具箱

ガントチャートのPDFに日付や縦線などを表示させるパッチ。
デフォルトはA4用紙だが、A3へ変更するパッチはうまくいかなかった。

ガントチャートのPDFを出力したい要望は多いが、日付を各ページのヘッダに載せたいがまだ分からない。

【ガントチャートに先行・後行の矢印を入れる】
Redmineの新たにいれたプラグインについてまとめてみた: 100ねんごの未来予想図

Redmine - Better Gantt Chart - Plugins - Redmine

kulesa/redmine_better_gantt_chart - GitHub

Twitter / @fortunan: このRedmineプラグイン面白い.ガントチャートで先行・後続をチケットの関係で表したときに矢印が出る"kulesa/redmine_better_gantt_chart - GitHub" - http://j.mp/hdURzI

redmine_better_gantt_chartプラグインを入れると、ガントチャート上に先行・後行の関係を表示してくれる有用なプラグイン。
つまり、ガントチャートのタスクの依存関係で、FSの関係があれば、その関係をMS Projectと同様に表示してくれる。

Redmine_better_gantt_chart_2

いつも「先行する」「後行する」の関係を迷うけれども、英語読みすればいいみたい。
例えば、#160のチケット上で「後続する」チケットとして#161を入力した場合、「#160が#161に後続する」関係になるようだ。

Redmine_better_gantt_chart_160_2

Redmine_better_gantt_chart_161_2

タスクのFS関係が重要な理由は、クリティカルパスを自動計算できるからだ。
クリティカルパスが分かれば、クリティカルパス上のタスクに遅延が発生しないように、リーダーは最新の注意を払えばいい。
あるいは、TOCのクリティカルチェーンに従って、クリティカルパス上の合流タスクに合流バッファをもうける手段を取ってもいいだろう。

Redmineのガントチャートがもう少し見栄えも機能も改善されれば、MS ProjectのWeb版になりうる。
逆に言えば、MS Projectの機能を全てRedmine上で実現してしまえばいい。
そうすれば、WF型開発やPMBOKが大好きな管理者に向けたアピールポイントになるだろう。

Redmineでプロジェクト管理を実施すれば、管理者には綺麗なガントチャートを見せておいて、実際の現場ではAgileな開発をやればいいのだ。

なお、RedmineのBacklogsプラグインでは色んな人たちが既に実践されているようだ。
下記の感想を読んで、僕も同感。
ツールに慣れてもらったら、実はAgile開発を自然に運用しているというやり方で広めていくのが良い気がしている。

Backlogs楽しくAgileのリズムつかめるよ!: 100ねんごの未来予想図

(引用開始)
自分の場合、チケットを仕事の中心において回していくことで様々なログをチケットに残していくようになった。また、残していくログがそれぞれのチケット間で関係を持つようになり、一種のデータベースのようになった。
Agileをやろうと決めたメンバーがRedmineをどのようにチームのやり方に合わせて使うか悩むのではなく,Redmineというツールを使って,ツールの使い方を覚えるうちにAgileな仕事の進め方を覚えていく.
通常は、目的があってそれに合うツールを探すと思うんだけど、アジャイルって何?っていうメンバーを巻き込むには、強制的にツールを使わせて言ったほうが体験を通して理解されていくのではと思った。
このやり方は割と受け入れられやすいのではと思った.やった人から広がっていく.そういう連鎖が生まれてくれれば嬉しい.
(引用終了)

【追記】
Redmine1.1.2のガントチャートを改善したパッチをアップしておく。
但し、自己責任でお願いします。

・\redmine\app\views\gantts\show.html.erb
→ガントチャート(HTML)に日付を表示する。
「show.html.erb_patch.txt」をダウンロード

・\redmine\lib\redmine\helpers\gantt.rb
→ガントチャート(PDF)に日付と罫線を表示する。
「gantt.rb_patch.txt」をダウンロード

【追記】
柴田雅之さんから、ガントチャート改造で下記のパッチを教えて頂いたので、リンクしておく。
ご指摘ありがとうございます。

Redmine - Patch #2024: gantt chart editting - Redmine

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

2011/05/23

BitnamiのRedmineが文字化けしなくなった

BitnamiのRedmineが文字化けしなくなった記事を見つけたのでメモ。

【元ネタ】
bitnami::redmine で文字化けしなくなった! - sakaikの日々雑感~(T)編

bitnami::redmine changelog.txt

以前のBitnamiのインストーラーはワンクリックでRedmineをインストールできるが、MySQLがlatin1なので、日本語が文字化けするバグがあった。
しかし、上記の記事によれば、最新版のBitnamiでは、my.cnfへUTF-8を設定するように修正してくれたらしい。
確かに、ChangeLogを読むと、そういうコメントがある。

この修正のおかげで、WindowsでもUnixでも、ワンクリックでRedmineをインストールしても日本語で文字化けすることはない。

BitnamiシリーズにあるSugarCRMやAlfrescoは、僕も実際に使っている。
LAMPStackが1個あれば、PHPアプリを配置するだけで簡単に動くので便利。
他にも色々試してみる。

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

2011/05/22

OpenProjを使ってみた

MS ProjectのOSSクローンOpenProjを使ってみたのでメモ。

【元ネタ】
Microsoft Projectの代替ソフトウェアとしてプロジェクト管理が可能でガントチャート表示もできるフリーソフト「OpenProj」 - GIGAZINE

フリーの高機能プロジェクト管理ソフト「OpenProj」を試してみました: あるSEのつぶやき

Normal is Best.: Macでプロジェクト管理「OpenProj」が悪くない

サンプルデータのダウンロード | 日経BP社 ブック&テキスト OnLine

GanttProjectを再び使ってみる: プログラマの思索

【再考】GanttProjectとFreeMindとJude: プログラマの思索

以前はGanttProjectを使っていたが、UIがしっくりこなくて使わなくなった。
OpenProjの利点は何よりもMS Projectで作ったmppファイルをそのまま読み込んで編集出来ること。
ガントチャートだけでなく、PERT図、リソース状況、WBSなどを表示してくれるので使いやすい。

但し、印刷機能はバグがあるとのことなので、2008年以降更新されていないのが若干不安だが、十分に使える。

とはいえ、一番の利用パターンは、OpenProjで大まかなWBSとスケジュールを作って、RedmineのMS Projectプラグインで一括インポートしてしまうこと。
RedmineのMS Projectプラグインを使いたいのは、WBSの階層構造をそのままチケットの階層構造へマッピングしたいから。
そうすれば、開発者はWBSの最下層のタスクだけ意識すればよく、顧客や管理者はWBSの上層の階層にあるチケットで開始日・終了日・進捗のをロールアップした集計結果だけ見ればいい。

色々試してみる。

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

2011/05/20

SEを極める50の鉄則

@hatさんのBlogで、馬場史郎さんの本「SEを極める50の鉄則」が絶賛されていたので、立ち読みした感想をメモ書き。

【参考】
SEは年齢とともに成長しなければならない・・・馬場史郎「SEを極める」 - システムエンジニアの晴耕雨読 - 楽天ブログ(Blog)

SEを極める50の鉄則, 馬場 史郎 の感想 - ブクログ


SEを極める50の鉄則 馬場 史郎 感想 - 読書メーター

SEマネジャのやるべきことの原点はこの二つ - 馬場史郎のITプロに贈る“今日の一言”1ページ目:ITpro

SEマネジャのやるべきことの原点はこの二つ - 馬場史郎のITプロに贈る“今日の一言”2ページ目:ITpro

【元ネタ】
日経コンピュータ2011.5.12|HATのブログ

(引用開始)
SEとしての私のバイブルは、馬場四郎氏の「50の鉄則」です。先にあれを実践させて「まともなSE」を増やす事が重要だと思います。
(引用終了)

馬場史郎「新版 SEを極める 50の鉄則」入門編は、SE必須の本 Dora_PaPa_san's_Pages/ウェブリブログ

(引用開始)
馬場史郎氏の「SEを極める」は、2000年4月に、出版され、SE(システムズ・エンジニア)論(?)の先駆けになった。当初、このような本は、殆ど売れないのではないかと予想されたが、あれよあれよと1年もたたない間に3万部を軽く超え、その後も人気は衰えず、この手の本(ITに関わる人材、SEもの)にしては、異例の数となったらしい。
(引用終了)

「SEを極める50の鉄則」の入門編とマネジメント編をサラリと読んでみた。
著者の略歴を想像すると、IBMのHW製品とSW製品を抱き合わせて販売ないし受託開発していたと推測されるので、そういう立場のSEに必要な技術は何か、という観点で読むと分かりやすいと思った。
著者の経験を元にSEに必要なスキルを解説してくれているので、説得力はすごくある。

心に残った箇所はいくつかある。
一つ目は、あるべきSE像、プロジェクトに強いSEに必要なスキルは3つあること。
それは、技術力(基本力とも呼んでいる)、管理能力(いわゆるPM)、そして政治的能力。
技術力は、管理能力はすぐに理解できるが、政治的能力とは、体制づくりやプロジェクト再編成のための社内調整や顧客調整を指す。
僕自身は、技術力と最近は管理能力はようやく理解してきているけど、政治的能力はまだまだ分からない。
今はファシリテーションという技術をきっかけにして、取り組んでみたいと考えている。

二つ目は、プロジェクトに強くなるには3つの観点があるということ。
それは、プロジェクト管理の基本を抑えること、提案時に技術面の課題を詰めておくこと、そして、利用部門による稼動後の運用も考慮しておくこと。

プロジェクト管理では、WBSで300~500ぐらいの詳細化は当たり前だ、と喝破されて、ううむ、計画段階でそこまで落とすのは難しいな、と率直に思った。
又、品質要件をプロジェクト立ち上げ時に明確にしておかないといけない、という指摘は、なるほど、と思った。
確かに、品質要件に含まれる非機能要件は、システム提案や要件定義で出てくるものの、実際の設計段階では漏れやすく、結合テストやシステムテストで初めてリスクが判明するアンチパターンはとても多いからだ。
更に、利用部門の運用も考慮するという点は、単に信頼性などの品質要件だけでなく、実際の業務の運用にシステムがマッチしているか、という観点も含んでいるから、ディペンダビリティという品質要件も考えよう、ということなのだろう。
例えば、異常系の業務フローを要件定義漏れでシステムに実装していないがために、本番稼動後にユーザから使いにくい、というクレームが来るのはよくある事例だろう。

三つ目は、SEは5年おきに落第の危機が現れるという点。
下記の文章を読むと、実際に自分の周囲に当てはまる30代、40代のSEはいないだろうか?

SEは年齢とともに成長しなければならない・・・馬場史郎「SEを極める」 - システムエンジニアの晴耕雨読 - 楽天ブログ(Blog)

(引用開始)
「だが、現実のSEの状況を見るとそうではないケースが散見される。
20数歳から仕事を始め、最初の5年間ぐらいは日に日に力をつけ成長していくものの、28歳前後で何%かのSEは伸びなくなる。
進級できずに落第を続けるような状態である。
 その5年後、33歳前後になると、『成長できない落第SE』はもっと増える。
こうしたSEの成長の節目は、筆者の経験で言うと、38歳、43歳、48歳と5年サイクルで来る。
 筆者はこれを『SEの5年サイクルの危機』と呼んでいる。
(中略)
○落第SEの共通点
「28歳あるいは33歳ごろ」に落第するSEのキャリアは・・
 (1) 若い時、付加価値のある仕事をあまり経験していなかった。
 (2) ビジネスマンとして厳しく指導され、鍛えられてこなかった。
 の2点である。
「38歳、43歳あるいは48歳ごろ」に落第するSEのキャリアは・・
 (3) 新しいITについて行けない
 (4) SEとしての夢が持てない
 という共通点が見られた。
(引用終了)

「付加価値のある仕事」「ビジネスマンとして鍛えられたこと」とは、いわゆるプロジェクト管理能力、政治的能力のことを指すらしい。
そういう経験を経ないと、よほどの技術力が無い限り、単なる労働者になってしまう。

又、「新しいITについて行けない」とは、業務知識が足りないとか、設計や運用の技術が足りないことを指すらしい。
B2Bのシステム開発ならば、業務知識は最終的には会計、つまり簿記の知識が必要になるだろうと直感する。
そして、10年前や20年前にCobolやJavaで腕を鳴らしたとしても、今はクラウドやスマートフォンを舞台として、単なるプログラミングだけでなくサーバー運用の技術も必要とされている。
どんどん時代が変化しているのだから、自分の技術も進化させないといけないわけだ。

以前よく言われていた「SE35歳限界説」は、多分上記のような事実を指しているのだろう。
SEだけでなく社会人になると、30代になれば成長しなくなる人が多い事実と同じ。
成長しなくなる人は、20代までの貯金で生きているにすぎない。

SEはドラッカーの言う知識労働者。
常に自分のスキルを手入れするために、アンテナを広げておかねば、と改めて痛感させられた本だった。

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

2011/05/19

ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング

@yojikさんのアドバイスを受けて、「エリック・エヴァンスのドメイン駆動設計」を読んでみたら、とてもインスピレーションが働いたので、即購入した。
@yojikさん、ありがとう。


【発端】
Twitter / @yojik: DDD本ってパターン本ですよ。。。 / ドメイン駆動設計よりもパターン本が好き: プログラマの思索 http://htn.to/8ZD5B9

Twitter / @yojik: どちらかというと @akipii さんが好きなタイプの本かもです!

【元ネタ】
「保守しやすいこと」が、良いプロセス~開発における、「設計」と「プロセス」の双対関係~:An Agile Way:ITmedia オルタナティブ・ブログ

ドメイン駆動設計よりもパターン本が好き: プログラマの思索

ドメイン駆動設計: プログラマの思索

コンウェイの法則 - Strategic Choice

Conwayの法則~アーキテクチャは組織にしたがう: プログラマの思索

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

エリック・エヴァンスのドメイン駆動設計」では、GoFのデザインパターン、ファウラーのアナリシスパターンエンタープライズ アプリケーションアーキテクチャパターンを駆使して、OOAのモデリングの過程を詳しく解説してくれているのがとても分かりやすかった。
ファウラーのアナリシスパターンや児玉公信さんの本「UMLモデリングの本質」は2000年代前半に勉強会で輪読したから、OOAがどういう手法でどんな成果物を作るのか、ということは分かっていたので、「エリック・エヴァンスのドメイン駆動設計」がやろうとしているモデリングの感触は雰囲気はつかめた。

まだ1回しか読んでいないので詳しく解読できてないけど、ソフトウェアプロダクトラインのコア資産の抽出と再利用を目指しているような感想を持った。
特に第16章の「大規模な構造」では、例えばファウラーの知識・操作レベルのパターンを用いて、従業員タイプ(管理職・平社員)を見出すモデリングがあるけれど、その目的は抽象度を上げることによって、コア資産を抽出して再利用できるようにしたいためのように思えた。
「蒸留」という概念はコアドメインの抽出ないし抽象化を意味するが、それはソフトウェアプロダクトラインのコア資産抽出と非常に似ている。

コア資産を抽出できれば、次々に似たような製品の開発、つまり派生開発がやりやすくなるだろう。
つまり、ソフトウェアプロダクトラインのような製品ファミリー開発がやりやすくなるはずだ。

MSのOffice製品、AppleのiPod/iPhone/iPad製品系列などがまさにソフトウェアプロダクトラインの良い例に当たるように思えるが、その背後にはドメイン駆動設計があるのではなかろうか?

又、第17章の「戦略をまとめあげる」でモデリングの組織構造について解説しているが、その内容は丁度、Conwayの法則(ソフトウェアの構造は開発チームの構造に似てしまう)をなぞっているように思えた。
つまり、設計者と開発者に分けるのではなく、設計と開発を行き来しながらモデルを作り上げた方が良いモデルが作れる、と。
アーキテクチャチームが設計し、開発チームがそれを指示書としてコーディングする体制にすると、ソフトウェアの構造にその体制のインターフェイスが反映されてしまって、本来のモデルからかけ離れてしまう可能性があるからだ。

面白いので又読んでみる。

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

2011/05/18

Redmineプロジェクトの構造とConwayの法則

Redmineの複数プロジェクト構造と組織構造の関係を示唆したTwitterで気付いたことがあったのでメモ。
ラフなメモ書き。

【元ネタ】
Twitter / @cointoss: Redmineがプロジェクトを頂点をする階層構造になっているおかげで情報が自然と整理される。製品開発を一つのプロジェクトとした場合、所属グループ(複数プロジェクトにまたがっていたと仮定)単位で実施していた進捗会議をプロジェクト単位に整理しようという動きが生まれてくる。

Twitter / @akipii:@cointoss1973 @sakaba37 ソフトウェアプロダクトラインやConwayの法則を連想させます。所属チーム単位ではなくフィーチャ単位で、チーム主導よりもアーキテクチャ主導でプロジェクト管理していこうという発想でうね。面白いです。#redmine

Twitter / @cointoss: Conwayの法則的には、Redmineはチームに従い、チームはRedmineに従う。といったところか。結果として チームとRedmineが整合すると良い。

鈍重な開発チームは鈍重なシステムを作る? - @IT情報マネジメント

Conwayの法則~アーキテクチャは組織にしたがう: プログラマの思索

コンウェイの法則 - Strategic Choice

「保守しやすいこと」が、良いプロセス~開発における、「設計」と「プロセス」の双対関係~:An Agile Way:ITmedia オルタナティブ・ブログ

【1】Conwayの法則は下記で紹介されている。
すなわち、ソフトウェアの構造はそれを作った組織を反映しているという法則。

Conway's Law

パターン14:Conwayの法則
別名:
アーキテクチャは組織にしたがう
(中略)
解決策:
組織を製品のアーキテクチャに当てはまるようにしなさい。このパターンランゲージにおいて、ここでは、組織がアーキテクチャに影響をおよぼすべきであるというよりも、アーキテクチャが組織に影響をおよぼすべきであるといえるだろう。
(中略)
論理的根拠:
このパターンは歴史的なものである。
Gerard Meszaros (BNR)は、人々はアーキテクチャが安定してから組織をアーキテクチャに合わせようとしたがる、といっている。もし、早すぎる時機に組織をアーキテクチャに合わせると、アーキテクチャの変化の流れは個々人の統制の範囲の間での干渉を引き起こす。

コンウェイの法則(Conway's Law) - Plan9日記

(引用開始)
要はソフトウェアの構造はそれを作った組織を反映しているという法則。3機関が協業した複雑なMulticsに対して少数精鋭の研究者がシンプルに作ったUNIX。巨大化する商用UNIXと、原点回帰したPlan9。Microsoftの発展と、MS-DOSからWindowsへの流れ。オープンソース革命とLinux。なるほど、いろいろ思いあたるところがある。
この法則、最初にどこで読んだのか忘れてたけど、Fred Brooks Jr.の「人月の神話」だったのか。
(引用終了)

【2】「Redmineのプロジェクトはどんな単位にすべきか?」という質問はよく出る。
僕は下記に書いたように、「開発チームの単位」「ブランチの単位」と考えていた。

RedmineとTracの機能比較: プログラマの思索

だが、上記のTwitterで、Redmineプロジェクトは「製品単位」に作るべきではないか、という事実に気づいた。
「製品」とは、ビルドモジュールの単位だし、ITプロジェクトの最終的な成果物であり、SCMブランチ(trunk)でもある。

製品単位にRedmineプロジェクトを作った場合、メンバーはどのRedmineプロジェクトにアサインされて、タスクはどのRedmineプロジェクトへ配置されるのか?
解答は、メンバーのアサインやタスクの配置の観点は、まさにConwayの法則通りに従えばいい。
所属チーム単位ではなく、フィーチャ(サブシステム)単位に管理する。
メンバー主導ではなくアーキテクチャ主導。
つまり、Redmineプロジェクトは、SIの組織構造にマッピングするのではなく、製品のアーキテクチャにマッピングすればいい。

組織主導よりもアーキテクチャ主導の方が良いシステムが作れる。
Redmineプロジェクトはチーム単位よりも、派生された製品単位に作る。
メンバーは複数プロジェクトに所属して、要員の流動化を図る方がよい。

下記のBlogでも似たような発言がある。

なぜRedmine導入は失敗したか?あるいは僕のがっかりメモ - ハードコイルド・ワンダーランド

(引用開始)
僕の所属していたプロジェクトはいわゆるソリューション開発というやつで、リリースするお客さんごとに
微妙にカスタマイズするのが常である。
SCMについてはメインラインモデルを利用した管理で十分だったが、ITS側でもカスタマイズごとに
プロジェクトを分けて管理した方が、視覚的にも整理されたのではないかと感じる。
TracでもTraMで複数プロジェクトが管理できるが、Redmineの「プロジェクトの親子関係」の方が
直感的で分り易く、やりたいことがすぐに実現できたのではないか。
事実、Redmineを導入したプロジェクトもソリューション開発であるが、早期からプロジェクトの親子関係を
使って顧客ごとにプロジェクトを分割したため、要件の整理に大変役立った。
(引用終了)

一つの製品(プロダクト)があり、その製品を複数の顧客へカスタマイズして開発している場合、例えば、親プロジェクトは共通の「製品」プロジェクト、子プロジェクトに顧客ごとにカスタマイズした時に発生するタスクの単位にすればいいだろう。
つまり、オリジナルの製品に対して派生された製品群は、Redmineのサブプロジェクトへ配置すればいい。
そして、メンバーは、複数プロジェクトにアサインされる。

すなわち、ソフトウェア組織は基本的にはPMBOKの言うマトリクス型組織になるだろう。
ラインとプロジェクトの2つの指揮命令系統がある組織構造にならざるを得ない。
縦割りの組織ならば、リーダー同士で調整しないと、メンバーは混乱する。

マトリクス組織 - @IT情報マネジメント用語事典

複雑な組織構造を作ると、アーキテクチャが組織構造に依存して、コミュニケーションの疎遠さがシステムをバラバラにしてしまう。
例えば、サブシステムと開発チームを密に関連付けてしまうと、チーム同士のインターフェイスがシステムのインターフェイスの溝になってしまうだろう。
大規模システムの開発案件ほど、それぞれの開発チームがタコツボのようになってしまい、チーム同士のコミュニケーションの疎遠さがそのまま開発のやりにくさに比例してしまうのは、そういう構造があるからだろう。

アジャイルな開発組織ならば、Scrumの言う自己組織化されたチームの集合体になっているだろうから、メンバーが複数のプロジェクトにアサインされていても、うまく調整出来るだろう。

Redmineプロジェクトの構造と組織構造、アーキテクチャが密接に関係するという事実、そして、特に製品ファミリー開発や派生開発でRedmineの複数プロジェクト機能が有効である事実は、ソフトウェアプロダクトラインの話を連想させる。
ソフトウェアプロダクトラインの話では、いつも組織構造の話が出てきて、何故そんな話が必要なのか、ピンとこなかったけれど、Conwayの法則の観点から考えれば、ごく自然な発想なのだろう。

この観点をもっと考えてみる。

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

2011/05/17

本来のチケット駆動開発とは何か?~アジリティと規律の絶妙なバランス #tidd

@sakaba37さんから「本来のTiDD」という言葉を聞いて分かってなかったけれど、皆さんのTwitterのおかげでようやく理解できたのでメモ。

【元ネタ】
Togetter - 「チケット駆動開発(TiDD)について思うこと」

Togetter - 「本来のチケット駆動開発(TiDD)とは何なのか?」

チケット駆動開発について思うこと - かおるんダイアリー

【1】チケット駆動開発はTracのチケット管理から生まれた。
提唱者のまちゅさんの独創性は「チケット無しのコミット不可(No Ticket, No Commit!)」にある。
つまり、成果物を更新する時は必ずチケットに変更理由を残す運用ルールを指す。

この運用ルールは、課題管理システム(ITS)と構成管理ツール(SCM)がTracではセットで提供されていることから実現した。
このルールを発展させると、成果物のトレーサビリティを実現できるので、上流工程の品質向上にも寄与することもできる。
但し、チケット駆動開発そのものはAgile開発もWF型開発も関係ない。
ITSとSCM、更にはCIツールの一体化という技術にTiDDの特徴がある。
個人的には、TiDDの本質はアジリティと規律の絶妙なバランスにあるだろうと直感している。

【2】僕は、チケット駆動開発を実践してみて、その特徴を経験できただけでなく、アジャイル開発そのものも体験することができた。
その体験では、何故アジャイル開発の運用が難しいのか、という経験も含んでいる。
僕の一意見では「並行開発」「漸進型開発(インクリメンタル)と反復型開発(イテレーティブ)」のキーワードで説明できると思っている。

更に、チケット駆動開発を運用するツールであるRedmineを通じて、今まで知られている各種のプロセスのプラクティスやアンチパターンも体で理解できた。
だから、チケット駆動開発はアジャイル開発の一つの実装形であると思っている。

【3】今の僕の興味は、チケット駆動開発を運用するツール群(ITS・SCM・CI)を使って、XP・Scrum・PF・PMBOK・ITILなどの各プロセスを実装してみて、どんな利点・弱点・課題・限界があるのか試してみたい点にある。

XP・Scrum・PF・PMBOK・ITIL・CMMI・テスト管理などの各種技法、プラクティス、アンチパターンは既に知られているにも関わらず、先人のアイデアにツールが追いついていないから、うまく運用できていない現場が多かった。
でも今は違う。
OSSの優れたツール(Redmine、Trac、Subversion、Git、Hudsonなど)、RubyやPythonのような強力な軽量言語のおかげで、プロセスの実装がやりやすくなっている。
今は、ソフトウェア開発のベストプラクティスをツールの一機能で実装してしまえばいいだけだ。

そして、TiDDのツールを通じて、ソフトウェア開発そのものの本質を理解したいと思っている。
僕の実感では、ソフトウェア開発には「一発リリースは危ない」「変化が多いので変更管理が大事なのに無駄な手続きが多い」という特徴があるように思う。
だから、WF型開発のような本番リリースが1回だけのプロセスはとても大変だし、変更管理を運用する時にアジリティと規律のバランスがとても難しいのだ。

それらツールの特徴を把握した上で、物理学者のような思考実験をしてみたいのだ。
物理学者は、複雑な自然現象をシンプルなモデルで設定するために、複雑なパラメータをどんどん削除して、本質的に必要なパラメータだけ残して、モデルから意味ある物理法則を導く。
同様に、SW開発で運用するプロセスの各種特徴はツールの一機能で実装してしまい、複雑な手続きや無駄なドキュメントを省いてしまえばいい。
そうすれば、開発プロセスというモデルはシンプルになるから、開発プロセスで本質的に必要な特徴は何なのか、が見えてくるはずだ。
すると、各プロセスのベストプラクティスやアンチパターンが見えてくるし、各プロセスの共通現象からソフトウェア開発の本質も見えてくるだろう、と思っている。

この辺りは又考えてみる。

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

高信頼化ソフトウェアのための開発手法ガイドブック

HATさんのBlogで、IPAが公開した高信頼化ソフトウェアのための開発手法ガイドブックを見つけたのでメモ。
事例が多いのですごく参考になる。

【元ネタ】
情報処理推進機構:ソフトウェアエンジニアリング

高信頼化ソフトウェアのための開発手法ガイドブック|HATのブログ

ソフトウェア開発で最も難しく、そして一番技術を必要とされる工程はテスト。
テストと一口に言っても、実践アジャイルテストにあるアジャイルテストの4象限の観点のように、単体テストだけでなく、機能テストや受入テスト、負荷テスト、セキュリティテストなどもある。
TDDは優れたプラクティスだが、それだけではソフトウェアの品質は保持できない。

ガイドブックでは、日本の大手SIの事例が掲載されていのが注目に値する。
日本のSIは自分たちの技術を公開しないので、日本のソフトウェア開発の技術力向上につながっていないから、とても良いことだと思う。

まだ詳しく読んでいないけれども、ソフトウェア品質にディペンダビリティの観点を含めている点が興味深い。
ディペンダビリティとは、単なる信頼性だけでなく、サービスや運用の可用性、信頼性も含めた包括的な概念を指す。

ディペンダビリティ - @IT情報マネジメント用語事典

別の勉強会の方から、信頼性の概念が10年前と今は異なっていると言われて、その理由を聞いた所、信頼性にディペンダビリティを含むようになったから、と聞いたことがある。
つまり、単に本番障害が少ないだけでなく、実際のシステムが滞りなく稼働して業務に支障がでないという可用性などの概念も含んでいるのだ。

セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive)では、ソフトウェア品質にディペンダビリティの概念を導入することは本来の概念を曖昧にしてしまうという観点で批判していたけれど、最近の風潮はソフトウェアとそれを取り巻く業務も含んだ品質(つまり、ディペンダビリティ)に変わってきているのだろう。

もう少し読んでみる。

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

2011/05/15

RedmineのFree Mind Plugin

RedmineのFree Mind Pluginが公開されていたのでインストールしてみた。
これは素晴らしい。

Twitter / @changeworld: Redmine Free Mind Plugin 1.0.0 をリリースしました。Free Mind で作ったマインドマップ限定ですが、マインドマップをRedmine上で表示出来ます。機能詳細については以下を参照してください。 http://bit.ly/ihlJci

changeworld / redmine_free_mind / overview -- Bitbucket

Free Mind Plugin 1.0.0 リリース - Change the worlds

Redmine_freemind

インストール方法は、プラグインを解凍して配置するだけ。
WikiにFreeMindのファイル(e.g. tidd.mm)を添付して、「{{free_mind(tidd.mm)}}」と書くだけでいい。

プロジェクトリーダーはマインドマップを使う機会がとても多い。
例えば、WBSのタスク洗い出し、今日やるべきリストの洗い出し、リスクや課題を思いつくまま書き殴って対策を考えてみる、など、ラフな思索の行為に使っている。
その時に、Wikiへある程度完成したマインドマップをそのままアップして、皆に公開すれば、情報の共有も簡単だ。

上記のプラグインが優れているのは、画面のサイズ調整やバックグラウンドの色を変えたりするのがとても簡単なこと。
デザインも色合いもとてもいい。

最近、日本人の開発者がRedmineの優れたプラグインをどんどん公開されているので、とてもありがたい。
さっそく現場で使ってみようと思う。

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

redmine-java-api

redmine-java-apiというRedmineに対するREST APIがあるらしいので、リンクしておく。
今度試してみる。

Twitter / @しまっち: redmine-java-apiってのがすでにあったんだ。 http://code.google.com/p/redmine-java-api/

redmine-java-api - Redmine & Chiliproject Java API - Google Project Hosting

Javaからアクセスできるということは、Android端末から操作することも可能なはず。
iPhoneアプリでアクセスするよりも簡単に書けるだろう。

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

2011/05/14

チケット駆動開発はまさにチケット管理ゲームだ

Redmineでチケット駆動開発をやっていると、まるでゲームをやっている感覚になってきた。
そのフィーリングをメモ。

【参考】
チケット駆動開発はステータス追跡システム: プログラマの思索

【1】ゲームというモデルには特徴がある。
一つはゴールがあること。
桃太郎電鉄やファイナルファンタジーも、資産が一番大きいこと、全てのステージをクリアすることがゴール。
つまり、成功の終了条件がある。

当然、ゴールに達せずにゲームオーバーする時もある。
完了できずに途中リタイアの時もある。

チケット駆動開発のゴールは、期日までに全てのチケットを終了ステータスにして、システムをリリースすること。
そのために、Redmineバージョン単位にタスクをグループ化して、小刻みに定期的にリリースしながら、システムの品質も機能も拡張していく。
いきなり最終ゴールを目指すのではなく、ステージを踏みながらゴールに近づいていく。
その方が確実なのだ。

とはいえ、チケット駆動開発を運用してもうまく回らず、破綻する場合もある。
チケットが乱発されたり、誰もチケットに対処せずに放置したり、一人がチケットを溜め込んだりして、期日までにリリースできなかったら、ゲームオーバーと同じ。

チケット駆動開発をやっていると、XPの言うドライブ(運転)の感覚が分かってくる。
ソフトウェア開発のプロジェクト管理は、いつもコントロール(ドライブ)しないと、すぐにハンドルで制御できなくなって、デスマーチに陥りやすい。
ゲームオーバーにならないように、チケットを取捨選択しながら、リリースに近づけるのが大事。

ゴールに近づくには、定石があるのだ。
その定石は既に色んなプラクティスが知られているので、うまく当てはめればいい。

【2】二つ目はルールがあること。
何でもかんでも可能なわけではなく、行為がルールによって限定される。
代わりにアイテムがある。
パワーアップできたり、防御できるアイテムがある。
それらアイテムを上手く使いこなすのが大事。

チケット駆動開発では、チケットを起票する時、チケットの内容だけでなく、開始日・終了日、担当者、マイルストーン(バージョン)を入力しなければならない。
又、チケットをCloseする時は、ワークフロー管理機能によって、必ずリーダーがCloseするなどのルールもあるだろう。
チケットのライフサイクルには厳格なルールがある。

Redmineによるチケット駆動開発のアイテムは、リリース計画(ロードマップ)と各種のチケット集計機能、そしてワークフロー管理、トレーサビリティの4つ。

まず、ロードマップで大まかなリリース計画を立てて、イテレーション計画で更にタスクを詳細化する。
当然、リリース計画は、イテレーション実施中も現状に合わせて柔軟に変えて、状況を見える化する。
地図が最新化されていなければ、ゴールまでの距離も分からない。

イテレーション実施中は、ガントチャート、かんばん、サマリなど各種のチケット集計機能で進捗やリスクをリアルタイムに把握する。
自分たちの能力はどれくらいなのか、今どれくらい自分たちは傷ついているのか、今後どんなトラップがありそうなのか、を早めに検知できれば、リスクに対して準備しやすい。

又、チケットの種類に応じてワークフローを変えて、ペア作業するときもあれば、顧客と質問や問合せをキャッチボールする時もある。
あるいは、チケットとソースの相互リンクによって、成果物の履歴管理だけでなく、ソース修正の変更理由を追跡できて、コミュニケーション向上に役立てたりする。

チケット駆動開発のアイテムは、特にRedmineならRubyで簡単にパワーアップできる。
足りない武器は、自分でアイテムを作ってしまえばいい。

【3】何よりもゲームは楽しい。
ゲームをやる事自体が楽しい。
夢中になって我を忘れてしまう。

チケット駆動開発をやっていると、自分たちの作業履歴がタイムラインとして残る。
タイムラインをふりかえるだけでも、結構気づきがある。
特に新人は、作業履歴やコミット履歴を振り返って、自分は半年でこれだけ仕事できたのだ、と自信がつくらしい。

チケット駆動開発はプロジェクトファシリテーション(PF)と相性が良い。
ニコニコカレンダー、かんばん、ソフトウェアあんどんなどのアイテムは全てRedmine上で実現可能だ。

朝会で毎日の自分のタスクを確認するだけでなく、プロジェクトのゴールや各人の役割を共有する。
リリース後のふりかえりで、イテレーションの作業ログを見ながら、自分たちの能力を客観的に直視して、次のイテレーションへ向けて、プロセス改善していく。

KPTによるふりかえりの結果をWikiに残して、数回ふりかえりを続けると、各人の成長、チームの成長が分かるので、モチベーションアップにつながる。
それが楽しい。

下記の記事を読んで、似たような感想を持った。

日々是精進。: 2/17: デブサミ 2011 / チケット管理システム大決戦

(引用開始)
Face To Faceのやりとりの大切さは、スピーカーの皆さんが仰っておりましたが、会話の中で出てきた本当に共有すべきことや、お互いに合意し合った証、アイディアの種は、大切にプラットフォーム上に記していきたいな、と思いました。
きっと、あとでITS上のタイムラインを眺めることで、自分たちのプロジェクトの軌跡をたどることができる、大切な『場』になってくれるんじゃないかな~、と思っています。
(引用終了)

そんなことを考えると、チケット駆動開発は単なるソフトウェア開発のタスク管理だけでなく、チケットをトランプのカードに見立てて、どれだけ早くチケットをこなしながら、リリースと言うゴールに近づけるのか、というゲームをやっている気がしてくる。
XPの「計画ゲーム」というプラクティスは、多分そういうことを意味していたのではないかと直感している。

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

2011/05/13

Redmineに入れたプラグイン一覧part3

Redmine1.1.2に更にプラグインを入れてみたのでメモ。

Redmineに入れたプラグイン一覧part2: プログラマの思索

Redmineに入れたプラグイン一覧: プログラマの思索

【1】ガントチャート改造
【Redmine 1.1.2】ガントチャートを開始日順にソートする|渋谷ではたらくイタズラ者、マー君のブログ。

【Redmine 1.1.2】ガントチャートに日付を表示させる|渋谷ではたらくイタズラ者、マー君のブログ。

Redmineのウリの一つは、チケットをきちんと入力しておけばガントチャートをいつでも出力できること。
但し、ガントチャートに日付が出てなかったり、ソート順が開始日でないので綺麗に出ない症状があり、以前から一部ユーザはカスタマイズしていた。
上記のパッチを当てると、最新版でガントチャートに日付が出てソート順が開始日になるので、MS Projectっぽくなる。
管理者や顧客向け進捗報告に使うために必要なパッチかもしれない。

【2】redmine_blogs
akiko-pusu/redmine_blogs - GitHub

r-labs - Blog Plugin - Redmine

Akikopusu_redmine_blog

上記プラグインを使えば、RedmineにBlogを入れることができる。
以前のバージョンでは動かなかったので、とてもありがたい。

WikiではなくBlogを入れる理由の一つは、Blogを進捗報告代わりにしたいこと。
Blogの方が慣れている人もいるので試してみる価値はあるかもしれない。

【3】Redmineの作成日、更新日などの相対表現表示を絶対表現になおすプラグイン
suer/redmine_absolute_dates - GitHub

Redmineでは、チケットに「何日前に更新した」というメッセージが表示されるけれど、絶対日付の方が分かりやすいものだ。
上記プラグインは日付表示を変えてくれる。
ユーザが使いやすくなるUIにしてくれるありがたいプラグイン。

Suerredmine_absolute_dates

【4】MS Porjectインポート
suer/redmine_ms_projects - GitHub

Redmine_msproject

Redmine_msproject2

Redmine_msproject3

MS Projectのガントチャートを出力したXMLをRedmineにインポートするプラグイン。
チケットの親子関係に対応しているので、MS Projectでタスクを階層化してWBSを作っておけば、インポート後、チケットの階層構造へマッピングしてくれる。
トラッカーや担当者、カテゴリ、バージョンは後で設定しないといけないが、チケット一覧で右クリックして一括編集すればいいだけなので、問題ない。

MS Projectが大好きな管理者や、最初の大まかなリリース計画はMS Projectで作る場合に有効だろうと思う。

【5】Redmineのワークフローを可視化する
suer/redmine_workflow_viz - GitHub

Redmineのワークフローを視覚化: プログラマの思索

Suerredmine_workflow_viz

トラッカーとユーザ権限単位でワークフローを可視化してくれる。
RMagickはインストール済みなのだが、Windows上のRedmineだったのでステータスが文字化けしたのかもしれない。
ワークフローを可視化することで、管理者は、どんなワークフローにすれば作業しやすいか、ということを考えるようになり、自然にプロセスについて考えるようになるだろう。

【6】終了チケットにGood Job!な画像を表示

Good Job Plugin 0.0.1 リリース - Change the worlds

changeworld / redmine_good_job / overview – Bitbucket

Redmine_good_job_2

チケットがクローズされている場合、Good Job!な画像を表示してくれる。
Facebookの「いいね!」ボタンの機能に似ている。
こういう心配りのあるプラグインがあると、メンバーも終了チケットを増やそうと言う気持ちになってくれるのではなかろうか?

僕がRedmineに最初に触れて運用したのは、Ver0.6.4の頃で、その経験を元にSQIP2009で@sakaba37さんとTiDDの論文を発表した。
そして今、Ver1.1.2に触れて、Redmine本体の機能もUIも著しく改善して、プラグインが足りない機能やUIを補強してくれて、とても使い易くなっている。

下記のつぶやきと同様、僕も今でもRedmineがとても楽しい。

Twitter / @えるきち: redmine おもしろーい

個人的には、チケット一括インポート機能やチケット集計機能がもっと改善されれば、とても使いやすくなるだろうと思う。
つまり、ExcelやMS Projectでタスクを作って一括インポートしたり、顧客向け進捗報告や課題一覧をExcel上で集計する作業をRedmineでもっとサポートして欲しいのだ。
そうすれば、Excelが大好きな管理者もRedmineを使うようになり、自然にAgileな開発スタイルに変わっていくだろうと思っている。

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

2011/05/12

アジャイルプロジェクトマネジメント再読

以前、平鍋さんが翻訳されたジム・ハイスミス著「アジャイルプロジェクトマネジメント 最高のチームづくりと革新的な製品の法則」を読み返した。
アジャイル開発を経験したからこそ、購入して5年もたってようやく理解できたのでメモ。

【参考】
アジャイルプロジェクトマネジメント 最高のチームづくりと革新的な製品の法則, ジム・ハイスミス の感想 - ブクログ

(引用開始)
アジャイルプロジェクトマネジメントのバイブル的な一冊。
タイトルにもあるように、プロジェクトマネジメント向けの内容となっており、実践を想定した具体的な記載と共に、アジャイルの原則(考え方や哲学と言っても良い)についてとても良くまとまっている。
ただし、アジャイル経験が無い状態で本書を手にとっても、そのエッセンスのほとんどは理解できないであろうと想像する。
私が本書に出会ったのは一度アジャイルプロジェクトを実践した後のこと。
経験を踏まえて本書を読むと、各ページ一言一句から得るものがある。
実践を行うにあたって、そばに置いておきたい一冊。
(引用終了)

製品開発にアジャイルなプロジェクトマネジメントの流れや概念を導入して解説してくれている。
再読してみると、PMBOKの流れや概念を連想させるものがある。

アジャイルプロジェクトマネジメントの「構想→思索→探索→適応→終結」という流れは、PMBOKの「立ち上げ→計画→実行→監視・コントロール→終結」の流れに似ている。
PMBOKもアジャイルプロジェクトマネジメントと同様、スコープ管理を重視しており、スコープ外の作業や要求された品質以上の作業を金メッキと呼んで、無駄な作業と見なしていた。
これはXPのシンプルさの重視に似ている。
「アジャイルプロジェクトマネジメントはアジャイル時代の PMBOK」という感想は確かにそうだとうなずける。

又、アジャイルプロジェクトマネジメントに出てくる数々の概念は、Scrumの用語を連想させる。
機能リストはプロダクトバックログだし、リリース計画はスプリント計画、探索はスプリント実施、適応はレトロスペクティブ(ふりかえり)にまさに置き換えられる。

顧客チーム・開発チームのインターフェイスに出てくるプロダクトマネージャとプロジェクトマネージャは、Scrumのプロダクトオーナーとスクラムマスターの関係に似ている。
お互いが対立しあうのではなく、Win-Winの関係に持っていけるように、「何を作るか(機能の優先順位の決定)」「どのように作るか(機能の実装)」の役割を分ける。

だが、アジャイルプロジェクトマネジメントがPMBOKと決定的に違うのは、計画は頻繁に変更されるのを前提としていることだろう。
計画と実績の差を管理していくのではなく、顧客へ提供する機能や価値がどれだけ反映されたのか、を見ていく。
その差を見るために状況報告の道具の一つとして、イテレーションごとのパーキングロットレポートが紹介されているが、これはパーキングロットチャートと同様だ。

Redmineでチケット駆動開発を実践してみて、どの運用がアジャイルプロジェクトマネジメントのどこに当たるのかを想起させるから、自分の中で理解できるようになったのだろうと思っている。

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

2011/05/11

Redmine BacklogsプラグインでScrumを実践する

@daipresentsさんがRedmine BacklogsプラグインでScrumを実践する方法を公開されていたのでメモ。
非常に参考になる。

【元ネタ】
Redmine Backlogsで簡単スクラム!プロダクトオーナーとして使う編 | 世界 - @daipresents

Redmine Backlogsで簡単スクラム!スクラムマスターや開発チームとして使う編 | 世界 - @daipresents

Twitter / @Dai Fujihara: よくできているRedmineプラグイン。これがあれば他いらないんじゃないかな "Redmine Backlogsで簡単スクラム!プロダクトオーナーとして使う編" http://t.co/1hbYkKy

Twitter / @yusuke-kokubo: Redmine BacklogsはRedmineのSubtaskingを上手に使った良い見本

Twitter / @yusuke-kokubo: Redmine Backlogsはv0.5.0になってた。master backlogからSprintを作れるようになっただけでバージョンアップするほどでもない気がするけど。 http://bit.ly/jrWgvL

RedmineのBacklogsプラグインを入れてみた: プログラマの思索

ストーリーカードの観点とタスクカードの観点で別々に入力して集計できれば、顧客と開発者が別々のビューで一つのDBを見ている仕組みにできるはずと思っていたから、プロダクトオーナーとスクラムマスターの観点で機能を自然に使い分けることが出来る仕組みになっている点は素晴らしい。

タスクボードにあるストーリー「スプリントの障害になるもの」は、かおるんさんが日本語訳してくれていますね。
なるほど、@daipresentsさんの言う通り、「スプリントの障害になるもの」は、メンバーが作業するのに障害となっている課題やリスクをスクラムマスターへ依頼するタスクなわけですね。
スクラムマスターはチームの防御壁であり、チームの障害を解決するファシリテーターなわけだ。

Redmine Backlogsプラグインを触ってみて最も引っかかった点は、ストーリーのタイトルを入れてEnterを押すと勝手に登録されてしまうこと。
@yusuke-kokuboさんによれば、Chromeなら問題ないらしい。

Twitter / @yusuke-kokubo: @daipresents Enterでデータが反映されてしまうのはブラウザの問題です。Chromeだと大丈夫なはず。

このプラグインは色々試してみる価値がありそう。

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

2011/05/09

チケット駆動開発は計画の変更を恐れない #tidd

チケット駆動開発でのリスケについての質問を見つけたのでメモ。
下記はあくまでも僕の一意見。
ラフなメモ書き。

【元ネタ】
チケット駆動開発でのリスケジュール方針について | OKWave

【1】チケット駆動開発をAgileに運用しているなら、チケットのDoneの条件はリリースする事。
すなわち「バージョンをCloseする=リリースした」「バージョンをCloseできない=リリースしていない」になる。
もし、遅れたチケットを無視してリリースしたなら、チケットは延期されたことを意味している。
つまり、遅れたチケットは次のバージョンへアサインされることと同義だ。

チケット駆動開発において、リスケのタイミングといつだろうか?
Agileに開発しているなら、朝会だ。
Scrumならデイリースクラム、XPならスタンドアップミーティングに相当する。
PLは課題解決マシーン。実作業はメンバーにお任せ。
課題の無いプロジェクトは、メンバーが自己解決する順調なプロジェクトなのか、PLが裸の王様なのか、どちらかだ。

タスクが1MDでも遅延したら、そのタスクは2度と元のペースに戻ることは無い。
TOCの言う通り、スケジュールは遅延が伝播するだけだ。
朝会で課題を見つけて、チーム内で調整するか、上司や顧客へ調整するか、早く判断しなくてはならない。

【2】チケットが遅延した原因を分析するのが大事。
その原因は色んなパターンがある。

例えば、割り込み作業のためにチケットのタスクに専念できない人もいる。
つまり、その人はヤミ作業している。
チケット駆動開発の根本ルールである「チケットに起票してから作業を開始する」「No Ticket, No Work」に既に違反している危険な兆候。
PLはメンバーの作業を完全にコントロールできてないわけだから、体制そのものに問題がある。

あるいは、先行のチケットが終わらないので、タスクを完了できない場合もある。
つまり、タスクに先行・後行の依存関係(PMBOKの言うFSなど)がある。
この場合、基本はクリティカルパスに専念するのが最良の解決パターンだろう。
Agile開発はタイムボックスによる開発なので、チケットの総数を少なくすることで、依存関係を見やすくする利点がある。
プロジェクト内部の作業を見える化することで、自分の作業が誰に影響を与えているか、メンバー自身に喚起させることが自然にできる。
あるいは、TOCの言うクリティカルチェーンに従って、クリティカルパス上のタスクにバッファを作っておき、遅延が伝播しないような仕掛けを入れてもいいだろう。

遅延したチケットで危険なパターンは最低3つは経験している。
一つ目は、リファクタリングしないと機能追加できないチケット。
二つ目は、仕様変更に対応したら、デグレしたチケット。
三つ目は、バグを直したら、他画面の同類バグ調査が漏れていたチケット。

一つ目は、派生開発で起きやすい症状で、当初の設計が調査不足で、見積もりが甘かったことを意味する。
3MDで終わる予定が5MD以上も起きてしまうのはざらだ。
その場合は、リファクタリングのチケットと新規追加のチケットを分ける時が多い。
開発者も、リファクタリングの帽子と新規追加の帽子をかぶり直した方が、頭を切り替えやすくなる。

二つ目と三つ目は、ソース修正の影響範囲の調査漏れ、あるいは、テスト漏れを意味している。
いずれにしても、原因は根深いので、時間をある程度確保して、抜本的な調査を行わないと、バグがモグラ叩きのように出てきて、チームが疲労してしまう。

遅延したチケットに対する抜本的な対策は、最終的にはリスク管理につながる。
チケットが遅延しないように、あらかじめ何らかの対策を用意しておくわけだ。

PMBOKの言うリスクバリュー分析図では、影響度と発生確率の4象限で、リスクに対する態度を決める。
リスクが低ければ、無視 or 却下してもいいわけだ。
つまり、リスクを受容する場合もある。

【3】上記の質問を読んで思ったことは、何故、リスケを恐れているのだろうか?
PMBOK、WF型開発では、ベースラインを設定して予定・実績比較で管理していく。
予定がコロコロ変わっては、実績と比較しても差がなくなるので、差異分析がやりにくくなるからだ。

逆に、Agile開発は計画の変更を恐れない。
むしろ積極的に計画を変更して、プロジェクトをドライブする。
完璧な計画作りよりも、プロジェクトの成功を重視するのだ。

だから、Agile開発では、ロードマップというリリース計画をあらかじめ作るけれども、あくまでも大まかに作っておき、詳細な計画はイテレーション実施前に作り、イテレーションの実施中も頻繁に変更していく。
ITSによるチケット管理の利点は、チケットですべての作業が見える化されるだけでなく、状況の変化をチケットに即座に反映しやすい点もある。
優先度や作業内容、担当者、作業の開始日や終了日が変わったら、チケットの属性を変更すればいいだけのことだ。
ロードマップやチケットを現状に合わせて、チームの現状を誰もが同一に認識出来るようにすれば、自ずから何を解決しなければ前進しないのか、見えてくる。
ファシリテーションが教えるように、問題がはっきりして解ける問題へ変換すれば、人は自然に問題を解決しようとする。

変更されたチケットの内容はリアルタイムに反映されて全員に見える化されるので、部外者の上司や顧客もITSを閲覧できるとなおいいだろう。

丁度、下記のようなTwitterを見つけた。
まさに、ロードマップを第三者が見れば、プロジェクトの状況が単なる遅延だけでなく、遅延したチケットをどのように処理しようとしているのか、というチームの意思も見えてしまうわけだ。

Twitter / @アカベコ: 結局、Redmine 1.2.0 は GW 中にリリースされなかった。残り 3 件のチケットは、スケジュールより重要ということなのか?と書きつつ、こうやって詳細な進捗を世界に公開するのは勇気あるなぁと感じる。


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

2011/05/07

在庫管理に現れる簿記の概念

簿記に出てくる商品有高帳は、在庫管理を表す。
在庫管理についてラフなメモ書き。
間違っていたら後で直す。

【元ネタ】
販売管理システムの「会計3要素」: 設計者の発言

情報システムをDOA的にチェックする|HATのブログ

【1】以前、渡辺さんから「SCM(Supply Chain Management)とは結局、在庫管理の事なんですよ」と聞いて、なるほどと思った。
以前、羽生さんの記事で読んだ「在庫は商品の集合が示す状態であり、商品のインスタンスは無関係」を連想する。

在庫は商品の集合が示す状態: プログラマの思索

小売業でも商品を仕入れて販売するとき、必ず倉庫に保管する。
製造業でも、工場で作った製品(完成品。いつでも販売可能。仕掛品とは異なる)は倉庫に保管される。
倉庫に保管する場合、電気代も人件費もかかるし、食材ならば腐るリスクもあるから専用の冷蔵庫まで必要だ。
ビジネス的には、在庫数量は少ないほどいいし、在庫回転率が高いほど、売上が伸びていることを意味する。

だから、トヨタ生産方式のようなJIT(Just In Time)、かんばんがもてはやされたわけだ。
とはいえ、今回の震災で部品の在庫がなくて製品が作れないリスクも出てきたけれど。

在庫管理では受払という言葉が頻繁に出てくるが、「受入(入庫)」「払出(出庫)」を意味している。
渡辺さんの本でも受払という言葉が出てくる。

簿記では、商品有高帳で受払を管理する。
商品有高帳は、倉庫にある商品の数量と原価を記録する。
月末締めに売上原価を計算して売上総利益を出力するためにある。

商品を仕入れたら受入、商品を売り上げた時は払出になる。
倉庫の受払いでは、仕入や売上という仕訳が必ず発生する。
業務システムならば、夜間バッチ処理で自動仕訳を発生させて、翌朝に集計結果を出力する仕組みにしているだろう。

しかし、入出庫のきっかけが仕入と売上だけではなく、仕入値引・仕入返品・売上値引・売上返品でも発生する。
この4種類はひっかけ問題としてよく出る。

商品有高帳 (1) -わかりやすい 簿記

返品・値引き | 簿記3級から勉強しよう

仕訳は、仕入や売上のマイナス金額を入力するので、仕入や売上の逆仕訳が発生する。
更に、商品有高帳にも在庫数量や在庫単価が変わるから、記載しなければならない。

仕入返品は、仕入れた商品が破損していると仕入先へ返品するから、在庫数量が減る。商品有高帳にも記載する。
仕入値引は、仕入れた商品を値引きして入庫するから、在庫単価が減る。商品有高帳にも記載する。
売上返品は、売り上げた商品が破損して得意先から戻されたので、在庫数量が増える。商品有高帳にも記載する。
売上値引は、売り上げた商品を値引きするので、在庫数量も在庫単価も変わらない。商品有高帳は記載不要。

在庫の受払が発生すれば、売掛金や買掛金にも当然連動するから、計算に注意が必要。

【2】在庫単価の計算は、簿記では先入先出法か移動平均法が主流。
業務システムならば、移動平均法であっても即座にバッチ処理で出力されるから、普通だろう。

実際の現場では、業界によって在庫管理がかなり違う。
小売業では月末に1回だけ在庫数量を数える時が多い。
多品種で大量の商品を入荷・出荷するので、毎日在庫管理するのが大変だからだろう。
だから、売価還元法や最終仕入原価法が多いと聞いている。

逆に製造業では、毎日、倉庫の部品をチェックするから、継続棚卸法が普通。
工場で製品を製造するタイミングで、下請けから部品を入庫して、製造の待ち時間を減らす。
だから、JITなわけだ。

又、実地棚卸という作業も在庫管理では重要。
実際の倉庫業務では、帳簿と実際の在庫数量や原価が違ってくるため、帳簿に実際の数値を反映させる。
普通は帳簿よりも在庫数量が減って損する場合が多いので、間接経費として仕訳を起こす時が多い。

ビジネス的には、実地棚卸で帳簿と実際の差額が小さいほど、倉庫係がきちんと仕事していることになるので、倉庫係の評価に使える指標を出力できるシステムにしておくとよい。
また、営業マンがどんどん売上となる契約を取ってきて、在庫を早めに引き当てるほど、在庫が増えてしまうため、きちんと納期回答できるシステムにしておくのが重要。
この辺りは、渡辺さんの本「業務別データベース設計のためのデータモデリング入門」が詳しく、とても参考になる。

【3】@hatsanhatさんの下記の資料はとても参考になった。

『ビジネスソフト』の選び方、作り方

(引用開始)
2-2.販売管理のポイント
在庫の履歴を追いかけられるか
マイナス在庫を許すか
支援機能が実装されているか
受注-納品データの差異(顧客満足)
発注-仕入データの差異(仕入先評価)
売掛金年齢表(得意先評価)
(引用終了)

在庫数量の入力UIは普通は正の数量だが、マイナス数値を入力したい業務があるかどうか、要件定義で確認すべき事項の一つ。
仕入値引・仕入返品・売上値引はマイナス数量やマイナス単価が発生する仕訳の一つの例だ。

上記の説明時には、入荷前に仕入れた商品を引当したい場合がある事例が紹介された。
確かに、仕入という仕訳(倉庫に商品を入庫する)が発生する前に、営業マンが在庫の引当を予約したい場合もあるだろう。
中小企業なら、この種の例外業務は口頭指示やベテランの作業員がうまくやってくれているが、いざシステム化しようとすると、その例外業務を見落としがち。
例外業務を見落とすと、せっかく作った業務システムは実際は使い物にならないリスクがある。

又、在庫の履歴管理や支援機能があるかどうかは、在庫管理の集計結果から経営上の意思決定を下すのに必要な情報だ。
在庫の数量、単価の履歴を見れば、不良在庫がどのタイミングで起きやすいか、分析しやすいし、渡辺さんの本で紹介されているように、未来在庫を見通せれば、むやみに部品在庫を増やす必要もない。
その分、キャッシュフローが安定する。

受注と納品のデータ差異が小さいほど、顧客に指定された期日に出荷できたわけだから、顧客満足が高いだろう。
逆に、受注したにもかかわらず、部品在庫が足りなくて製品が作れず、出荷が遅れれば、当然、顧客も困る。

発注と仕入のデータ差異が小さいほど、指定された期日に発注した商品が届いたわけだから、仕入先はきちんと約束を守ってくれる所、と仕入先の評価も高まるだろう。
逆に例えば、仕入先の資金繰りが悪ければ、発注してもなかなか商品や部品が届かず、こちらも製品が作れなくなるわけだから、仕入先を変えた方がいいわけだ。

売掛金年齢表という概念は始めて知ってなるほどと思った。
商品や製品を得意先へ送って売上をあげたとしても、実際は今月末請求翌月末計上という所が多いだろうから、売掛金を回収するまで、現金は入ってこない。
つまり、債権が何ヶ月残っているか、債権の繰越残は何ヶ月前のものなのか、を知るために使う。

売掛金の残高だけでなく、発生した売掛金が回収されるまでの入金の履歴を残しておけば、得意先が倒産して売掛金を回収できなくなる事態までに、何らかの手を打ちやすくなるはず。

得意先の資金繰りが悪ければ、色んな理由で売掛金の回収が伸びるし、為替手形や約束手形など現金とは違った形式で入金される場合もある。
僕は実際はよく知らないけれど、手形でもらうと銀行で手形を交換する際に手数料が発生するから、結局損している例が多いはず。

【4】業務システムでは、在庫管理が重要な業務の一つ。
在庫管理とは、自分の会社で仕掛中の資産がどれだけあるのかを管理するわけだから、自分の会社の商品が今いくつあるのかすらまともに管理できない会社が成功するわけがない。

日本の製造業の会社はJITなど優れた在庫管理の手法を編み出したからこそ、世界トップのレベルにいるわけだ。
逆に、日本のSIerは仕掛中の資産をきちんと定義できていない所が多いために、ビジネスのレベルはあまり高くないのかもしれない。

DOAと在庫管理についてはとても奥が深いので、理解できたらまとめる。

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

ビジネス特化SNS「Linkedin」から見えるもの~人脈はデータマイニングで作られる

2009年はTwitter、2010年はFacebookが流行して、ビジネスだけでなく政治まで大きな影響を与えている。
ビジネス特化SNS「Linkedin」がこれから流行するかもという記事を見つけたのでメモ。
Linkedinは使ったことが無いので、ラフなメモ書き。

【元ネタ】
[jp]ビジネスSNSのLinkedInが6月ごろに日本語化か――現在日本語の翻訳者を採用中

シリコンバレーでは常識,850万人が使うビジネス特化SNS「Linkedin」 - ニュース:ITpro

Linkedinの魅力 | Linkedinの使い方を日本語でわかりやすく解説!

「LinkedIn」は、次のFacebookになり得るか? | その他(IT) | 毎日がアップデート | あすなろBLOG

Facebookやツイッターなどのソーシャルメディアが通販サイトにお客をどれだけ流しているかを調べてみる(2010年5月版):Garbagenews.com

Web2.0の本質はデータマイニングにあり: プログラマの思索

Twitterは最速のメディア: プログラマの思索

BTSをBusiness Intelligenceとして使う: プログラマの思索

【1】理論的には、世界中のあらゆる人には、6人の人間関係を通せば必ず達すると言う理論「スモールワールド」がある。

スモール・ワールド現象 - Wikipedia

スモールワールド以外にも「弱い紐帯」という概念もある。
これは、就職する時に親密な人よりもつながりの薄い人達の情報を元に現在の職を得たという実地調査から得られた説。
これによれば、就職や転職では、薄いつながりの人達の人間関係をたくさん持っている方が有利と言うことになる。

今までは緊密な人間関係を作る方が幸せという先入観があったが、むしろ緩い人間関係をたくさん持つ方が現代社会で幸せに生きるために必要という事を示唆している。

【2】ビジネス的には、Twitter、Facebookの流れに、Linkedinもある。
Twitterの特徴は速報性の高いメディア。
フォロワーが多ければ、その人の発言が一気に広範囲に伝わる。

Facebookの特徴は実名主義による信頼関係の質が高いメディア。
Mixiよりも匿名性がないので、日本では流行しづらいと言われていたが、2011年になって一気に普及したように思える。
Facebookのおかげでネット上で本人証明がやりやすくなったのではないか?

東日本大震災で、TwitterもFacebookも安否確認にとても役立つと言う事実が公開されて、一気に広まった感がある。

SNSの強みは、友達が良いと認識した事象は確からしいという個人の人間関係から生じる信頼関係の強さ。
だから、製品マーケティングや小売マーケティングをTwitterで流す企業も多いし、Facebookに会社のファンサイトページを増やす所も多くなった。

僕のイメージでは、Linkedinは転職用SNS。
履歴書をプロフィールに書いておけば、緩い人間関係をつたって転職のお誘いが来る仕掛けなのだろうと思う。

SNSというインフラは最終的には、仕事の融通をきかせるものになっていくように思える。
緩い人脈が単なる趣味の関係だけでなく、仕事やお金にも役立つようになる。
昔から営業マンは人脈を大切にして成功していくが、今の時代は、人脈をSNSのようなWeb2.0のインフラで作っていくものなのだろう。

既存マスメディア、雑誌など出版業界、広告代理店などの業界は、Web2.0の流れに乗り遅れているように思える。

個人的には、IT技術者は他の業界にはないアドバンテージがあると思う。
IT業界ほど、無数のIT勉強会が日本中で開かれて、どんな人でも参加できるようなコミュニティを提供している業界はないみたい。
そして、IT技術者は基本はプロ野球選手と同じく、自分の技術の腕で生きているものだから、自分の技術をアピールできれば仕事しやすい。
特にオープンソースやSNSをうまく利用すれば、自分の技術力をアピールできるだろうと推測する。

【3】技術的には、SNSの背後にはデータマイニングの発展があると思っている。
GoogleのPageRank、Amazonのレコメンドエンジン、Mixiの足跡機能のように、個人の操作ログを緩やかに収集して、役立つ情報を吸い取る仕掛けが簡単に実装できるようになった。
Amazonのオススメ商品機能は、Facebookの「この人も知り合いでは?」の機能と本質的に同じ。
Linkedinの転職支援サービスも同等だろうと思う。

データマイニングの機能はBI(Buisiness Inteligence)として呼ばれていて、以前からDWH(データウェアハウス)として実装されてきた。
でも、今はおそらくHadoopなどMapReduceアルゴリズムを使って、膨大なトランザクションを集計して抽出する方向へ進化しているように思える。

データマイニングを単なるデータ集計だけでなく、マーケティングや経営上の意思決定、更には転職支援にも使うように発展している。
多分他の使い道もあるし、他のビジネスのやり方もあるだろうと思う。

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

2011/05/06

DSLもオブジェクト指向の歴史を追いかけている

平鍋さんのDSLの記事があったのでメモ。

【元ネタ】
マーチンファウラのDSL本をマインドマップにまとめてみた:An Agile Way:ITmedia オルタナティブ・ブログ

リファレンスモデルの重要性: プログラマの思索

基幹系バッチ処理をHadoopで高速化: プログラマの思索

Hadoopの本質は分散I/Oにあり~クラウド時代の非同期処理: プログラマの思索

Xead Driverの感想: プログラマの思索

マーチンファウラーがDSLの本「Domain-Specific Languages (Addison-Wesley Signature Series (Fowler))」を昨年秋に出版していたらしい。

今思うと、UMLによるモデリングでOCLで書いていたビジネスロジックは、本来DSLで表現すべきものではないかと想像する。
ドメインモデルは型として表現できるが、ドメイン同士のリレーションや複雑な制約条件はUMLでもDOAでも表現しづらい。

OOAもモデル駆動開発(MDA)を志向して袋小路に入ったけれど、DSLで概念モデルを表現してプログラミングの一種にしてしまう発想は面白い。
プログラムにしてしまえば、実際にすぐ動かせるし、編集→コンパイル→実行という開発スタイルはAgileになりやすい。

ソフトウェア設計技法の歴史を振り返ると、下流工程の技術が上流工程を覆い尽くすパターンがとても多い。
オブジェクト指向がまさにその典型例だ。
Agileもオブジェクト指向の歴史をなぞらえるように、今まさに上流工程に乗り込んでいる。
DSLもそういう歴史の流れの一部なのかもしれない。

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

2011/05/05

Agile開発がCMMI、PMBOK、BABOKまで影響を与えている

Agile開発の普及に関して良い記事があったのでメモ。

【元ネタ】
アジャイルマニフェストからの10年をふりかえる by マイク・コーン - kawaguti の日記 (id:wayaguchi)

(引用開始)
そして現在、10年が経ち、状況は180度変わった。あなたがもしアジャイルをやっていない/アジャイルになろうとする過程にないなら、自分もやった方がいいんじゃないか?と思うだろう。10年前と比べて最大の変化は、どのプロセスを利用するかを検討する議論において、アジャイルプロセス群は席が予約されている、ということだ。もし私が大企業の開発担当副社長で、他の部門の副社長たちにアジャイル開発を薦めたら、彼らはむやみに拒否することができないだろう。アジャイルは、いろんなやり方があるが、実行可能で実現可能な代替案である。すべての会社やプロジェクトにおいて適切な手法であるとは限らないが、アジャイルを提案するとき、誰一人として、それを笑いとばすことはできないだろう。
(引用終了)

オブジェクト指向は以前は一部のプログラマの技術に過ぎず、Smalltalkで育まれた。
そして、Smalltalk、C++、Java、Rubyとプログラミング言語が進化していくうちに、単なるプログラミング技術だけでなく、設計や要件定義までオブジェクト指向が席巻した。
UMLもたくさんの流派があったけれども、一つの記法に統一されてから、OOAが一気に普及した。
今や設計手法の主流は、DOAや構造化設計よりもOOAの方に移っているのではないだろうか?

同様に、Agileの発想もXPやScrumなどで90年代から試されて、今はCMMI、PMBOK、BABOKまでAgileの発想を取り込もうと取り組んでいる。
AgileもOOAと同様に、下流工程から上流工程を席巻しようとする流れになるのが興味深い。

InfoQ: 2つの世界の衝突:PMI(米国プロジェクトマネジメント協会)とアジャイル

InfoQ: PMIのAgile認証パイロットが5月に開始

Always All Ways: [IT] PMIとScrum/Agileの動向

InfoQ: SEIがCMMIとアジャイルの統合に関するレポートを発表

InfoQ: IIBAがBusiness Analysis Body of Knowledgeのアジャイル拡張を発表

CMMIはアジャイル化できるのか?: プログラマの思索

BABOKをアジャイル開発へ拡張: プログラマの思索

BABOKはアジャイル開発に使えるか: プログラマの思索

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

2011/05/04

TiDDを実践して気づいたことpart9~Scrumのベロシティ #tidd

Scrumが従来のAgile開発に比べて優れている点は、プロダクトオーナー、バックログ、ベロシティという概念を明確に定義した点にあると思う。
チケット駆動開発をいくつかのプロジェクトで実践してみて、ベロシティという概念が一番難しく、そして奥が深いという経験を少しだけした。

考えたことをラフなメモ書き。
僕はScrumを勉強中なので、間違っていたら後で直す。

【元ネタ】
Twitter / @Kakutani Shintaro: ベロシティを「安定させるもの」「だいたい予想できるようにすること」と捉えているのが素晴しい / Redmineでアジャイルチームのスピードやパワーを見える化する | 世界 - daipresents!! http://htn.to/odgTtR

Twitter / @江端 一将 (えばた かずまさ): スクラムのベロシティに似ていると思う。ベロシティを高く表現するのは簡単でしょw でも、本当の能力は、ある1つの測定項目では把握しえないみたいなww RT @kanu_ CMMIのレベルで計れないとすれば、何で計れば良いの? #aj11 #aj11cmmi

[Agile]ベロシティを他のチームと比較してはいけない | Ryuzee.com

[Agile]新規チームではベロシティの測定期間が必要だ | Ryuzee.com

[Agile]目標ベロシティとベロシティのインフレ | Ryuzee.com

fortunecodec ? 塹壕よりScrumとXP(日本語訳)

(引用開始)
Actual Velocity
実際速度
スプリントの終了時に確定する、各ストーリーの実装に実際に掛かった作業量。
Estimated Velocity
見積速度
スプリントの開始時にチームが見積もった、各ストーリーの実装に掛かるであろう作業量。
(引用終了)

Redmineでアジャイルチームのスピードやパワーを見える化する | 世界 - @daipresents

(引用開始)
アジャイルで登場するのがVelocity(速度)です。ベロシティは、チームがコミットしたイテレーション期間内のストーリーポイント合計を指します。
(引用終了)

【1】XPが「最適なペースの仕事」「週40時間労働」「適切なペース」「プロジェクト速度」という言葉で暗示している概念は、Scrumのベロシティのことだと思っている。

XPが当初注目された時に最も目立ち、賛同と批判の両方が入り交じったものが「週40時間労働」だった。
IT業界はサービス残業が当たり前で定時退社はありえない現状があるからこそ、週40時間労働が暗示している「適切なペースの仕事」というアイデアは誰も具体的に認識していなかったと思う。

駄目なプロジェクトは、前日の残業疲れがあるので、皆いろんな理由で遅刻して出勤するので朝会も開けない。
おもむろに仕事を始めて、だいたい午後4時ぐらいから開発速度が上がってくる。
そして、終電間際までバタバタ仕事をして終わる。
金曜にバグを発生させるコミットが多い: プログラマの思索でも書いたけれど、定時後の作業や休日出勤が当たり前になってくるために、18時以降や週末にコミット回数やバグ消化数が増える。
学生症候群で仕事をするのが当たり前なのだ。

何故なら、最後の1回の本番リリース直前まで本当に動くかどうか分からないので、動作確認できる期間が短く、バグ取りがリリース直前に集中してしまうからだ。
だから、本番リリース直前が最も忙しいし、リリース後も大量の問合せや障害報告という名の改善要望で溢れかえって、更に忙しくなる。
イテレーションという開発リズムがないために、開発チームが生産できるシステム規模が最後まで分からず、契約という名でメンバーに能力以上の作業負荷を強いる。

【2】XPでは、ケント・ベックがソフトウェア開発を車の運転にたとえて「ドライブ」という概念を多用する。
イテレーションの目的はストーリーの完成であり、ドライブはストーリーを実現させるマネジメントのこと。
「イテレーションを運転する」「リリースを運転する」とXPでは呼んでいる。

そのためにストーリーを完成させるまでのタスクをトラッキングする必要があり、その責任を負う人をトラッカとXPは呼んで、マネージャやメンバーと区別していた。
僕のイメージでは、XPのトラッカはScrumマスターの役割に似ている。

トラッカの仕事は、タスクの進捗具合をメンバーに確認して、見積を上回るタスクを特定して、早めに対策を打つチャンスをチームにフィードバックすること。
普通は、朝会(XPならスタンドアップミーティング、Scrumならデイリースクラム)でタスクの進捗に触れる機会があるだろう。
基本は、イテレーションを開始する前に決めたイテレーション計画の内容と実績に相違がないか、いつも追跡(トラッキング)する作業を担う。

トラッキングした結果、タスクにトラブルが発生していれば、メンバー個人の問題ではなく、チーム全体でカバーすることになる。
1人日遅れたタスクは二度と元のペースに戻ることはない、という事実は、僕自身も経験してきたし、その場合はチーム全体で計画をやり直してリソースを投入するしか解決策はないと思う。

トラッキングしてみると、開発チームが1イテレーションで実装できるストーリーの量、タスクの量は実は安定している。
XPではそれをプロジェクト速度を呼んでいた。
多分、それはScrumのベロシティに対応していると思う。

【3】XPの弱点の一つは、計画ゲームと呼ばれるプラクティスが曖昧なこと。
見積もりやマネジメントはどうやって行うのか、が明示されていないので、XPの中で最も難しいプラクティスの一つだった。
計画ゲームから出てくるプロジェクト速度の概念は、僕はずっと分からなくて、生産性のことだと漠然と思っていた。

そして、チケット駆動開発を実践したプロジェクトで、ベロシティらしき数値に気付いた時がある。
その時は、WF型開発+補間チケット方式でTracでチケット駆動開発を実践していて、チケットはWBSであらかじめ決めて、故意にイテレーションを1ヶ月に区切って開発していた。
当然、朝会はTracのチケット一覧を見ながら進捗と課題を確認し、1ヶ月終わる度にKPTでふりかえりミーティングをやった。

毎回のふりかえりで、僕はTracのレポート機能を使ってチケットを集計してメンバーに見せるのだが、毎月の終了チケットがほぼ40~50枚で安定していた。
更に興味深かったのは、最後の1ヶ月はどうしてもリソースが足りないと前持って判断していたので、メンバーを1人追加投入したにも関わらず、その月のイテレーションの終了チケット数は今までのチケット数とほぼ変わらなかったことだった。

チケットに掲載されたタスクはWBSから起こしたものが殆どだったので、チケットの粒度は安定していたから、1イテレーションでこなせるタスク量はほぼシステム規模と近似しており、安定していたのだろうと推測している。
また、人を増やしてもイテレーションごとの終了チケット数が変化しなかったという事実は、生産性が最後のイテレーションは低かったのではなく、開発チームのベロシティが安定していたことを示しているのではないか、と直感している。

但し、その時の事例はチケットの粒度が安定していたからベロシティが分かりやすく出現したわけであって、普通のチケット駆動開発では、チケットがタスクだけでなく、バグ修正やQA、課題なども入り乱れるので、チケットの粒度の幅が大きくなりやすい。
だから、チケット駆動開発上でベロシティを計測するには、チケットの属性にストーリーポイントを必ず入れるしかないだろうと思う。

【4】XPのプロジェクト速度ないしScrumのベロシティは上昇させるものではなく、安定させるべきものという主張は、XPの「適切なペースの仕事」が暗示していることと同一だと思う。
プログラマにとって人生で一番悲しい言葉、そしてプログラマの権利: プログラマの思索で書いたけれど、プログラマにプレッシャーを与えて仕事をさせたとしても、生産性は上がらない。
開発チームが安定してアウトプットを出せる環境を作り、維持していくのが大事。

イテレーションのリズム、適切な仕事のペース、Scrumのベロシティが主張していることは、潮の満ち引きのように、ソフトウェア開発には安定したリズムが必要であることを意味していると思う。

Scrumは、本来の意図がどうであったか分からないが、XPの弱点を補強する形で、アジャイル開発のマネジメントの概念を明確に定義してくれていると思う。

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

2011/05/01

bitbucketとTortoisehgは最強だ

@kaorun55さんのBlogのやり方で、bitbucketとTortoisehgを設定したら、bitbucketのMercurialリポジトリと連携できた。
ありがとうございます。

【元ネタ】
WindowsでTortoiseHg 2.xとbitbucketを使う - かおるんダイアリー

BitBucket と TortoiseHg で快適分散型バージョン管理生活 - さよならストレス

Gitユーザのための、Bitbucket+Mercurial経由でのデプロイ方法 ? blog.udzura.jp

渋日記: Bitbucket買収?そもそもそれ何?という人のためのBitbucket紹介

bitbucketの使い方メモ - 記憶は削除の方向で

Windows での Mercurial/Bitbucket の使い方(クイックスタート) - Usagi Project

ちょっとはまったのは、Pagent.exeをバックグラウンドで起動しておかないとPushする時にエラーになる。
知っている人なら多分当たり前だろうが、はまった。

@Sean_SFさんが推奨する通り、bitbucketは無料でプライベートリポジトリが使いたい放題なので、とてもありがたい。

PC上で作業する時、ファイル名に日付を付けてバックアップしながら作業する時が多いけれど、それはバージョン管理が必要な事実を示唆していると思う。
プログラミングだけでなく、WordやExcelの設計書、PowerPointのプレゼンでも同様だ。
PC上で作業する人は、GitないしMercurialのような分散バージョン管理が必須ではなかろうか?

TortoiseHgもTortoiseSVNと同じぐらい機能強化され、とても使いやすくなっているので、Windowsの人は使ってみるといいと思う。

TortoiseHg2.0が公開されている: プログラマの思索

作業履歴が残っていて、いつでも過去のリビジョンに戻せるという安心感はとても心地よい。
下記でも書いたが、バージョン管理を使ってコミットログを後から眺めると、やる気が出る。

バージョン管理ツールを使うとやる気が出る: プログラマの思索

構成管理にはたくさんの可能性を秘めていると思う。

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

日商簿記の勉強に役立つリンク

日商簿記の勉強に役立つリンクリンクをメモ。
下記の記事の日商簿記の勉強はとても役立つ。

独学で効率よく簿記三&二級に合格するための僕の方法 - ミームの死骸を待ちながら

何故、ITエンジニアに簿記が必要なのか?
中島さんの下記のBlogがその理由になるだろうと思う。

Life is beautiful: 「メインジョブ・エンジニア、サポジョブ・MBAというのが最強」の意味

(引用開始)
「戦闘力の強い戦士をメインジョブとして選び、回復系の魔法が使える白魔導士をサポジョブとして選べば、一人でかなりのことが出来るから最強」などである。必ずしもどれが正解ということはないようにちゃんとバランスを考えて作られてはいるのだが、このキャラクター作りの面白さがFFXIの成功に大きく寄与したことは間違いない。
こんなFFXIを遊んでいる時に、働きながらMBAを取得したために、「メインジョブ(大学・大学院で勉強したこと)はエンジニア、サポジョブ(仕事をしてしばらくして取得した資格)はMBAが最強」、と言った次第である。
ソフトウェアの世界も、私が働きはじめたころ(80年代)は、プログラムさえ書ければプロフェッショナルとして簡単に世界で通用したが、今やネコも杓子もプログラムを書ける時代。この世界で成功しようとするのであれば、ビジネスのことも分かっている必要がある、という意味である。
(引用終了)

簿記の知識はプログラミングが書けない業務SEやPMだけが必要と思っていたが、今の時代はビジネスの仕組みをPGも知っておく必要があり、ビジネスの基本である財務会計の知識をマスターするには簿記を知っておくのが一番手っ取り早い。
日経新聞で、キャッシュフロー、転換社債、満期保有証券、有価証券売却などの言葉を見たときに、反射的に仕訳が連想できるのは強み。

簿記3級検定試験のパターンは既に決まっている。
1問は仕訳、3問は試算表、5問は精算表、2問と5問は伝票や補助簿。

簿記では、仕訳を制するものが簿記を制する。
下記HPで簿記3級・2級の第100回~127回までの仕訳の過去問と解答をフリーで公開してくれているので、このPDFを毎日5問ずつ解いていけば力はつくはず。

日商簿記検定3級・仕訳問題対策【簿記検定ナビ】

日商簿記検定2級・仕訳問題対策【簿記検定ナビ】

過去問のうち、試算表と精算表は、仕訳とT字形勘定で整理できて、かつ自分で電卓で計算できなければならない。
下記のリンクの説明が分かりやすかったのでメモしておく。

[一緒に学ぼう!XHTML+CSS]-チャレンジ・ザ・簿記3級/試算表-

[一緒に学ぼう!XHTML+CSS]-チャレンジ・ザ・簿記3級/決算(1)-

[一緒に学ぼう!XHTML+CSS]-チャレンジ・ザ・簿記3級/決算(2)-

試算表の作成 -わかりやすい 簿記

精算表の記入方法(1) -わかりやすい 簿記

精算表の記入方法(2) -わかりやすい 簿記

精算表の記入方法(3) -わかりやすい 簿記

なお、精算表では、期中の仕訳だけでなく決算整理仕訳も理解しておく必要がある。
3級で出てくる決算整理仕訳は7種類しかないので、最終的には暗記した方がいい。
そのうち、繰延べ・見越しに関わる経過勘定科目(前払費用、前受収益、未払費用、未収収益)は理解しづらかったが、下記HPの解説が分かりやすかった。

経過勘定と未決済項目

経過勘定は会計の発生主義に関わるため、完全に理解するには簿記1級の会計学が必要になるだろうと推測する。

簿記は過去にたくさんの人たちが勉強してきた歴史があるので、語呂合わせで暗記すると役立つ時もある。
「しーくりくりしー」「くまのみみ」は特にそうだ。
下記リンクでまとめられている。

日商簿記検定と語呂暗記【簿記検定ナビ】

なお、簿記2級は商業簿記と工業簿記の2科目に増える。
商業簿記は簿記3級の延長だが、工業簿記は製造業の会計であるため、生産管理システムの開発などに経験していなければ、用語や概念すら理解しづらい。
下記HPにある1999年の工業簿記の過去問がスラスラ解けるレベルになれば、生産管理のモデリングもかなり楽になるだろうと思う。

 序章.工業簿記の手ほどき

工業簿記は勘定連絡図とシュラッター図の2つさえ理解すれば、同じようなパターンによる解答に過ぎない。

工業簿記が分かれば、渡辺さんの本「生産管理・原価管理システムのためのデータモデリング」の用語も読みやすくなるし、何故そんなデータモデルが必要になるのか、何故そのようにモデルを変形していくのか、理解しやすくなる。
平鍋さんは渡辺さんの本「生産管理・原価管理システムのためのデータモデリング」「業務別データベース設計のためのデータモデリング入門」を「日本人が書いた業務モデリングのアナリシスパターン」と呼んでいたがまさにそれを実感している。

オブジェクト納涼祭の感想: プログラマの思索

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

« 2011年4月 | トップページ | 2011年6月 »