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

2011年3月

2011/03/31

開発プロセスの型をツールで構築する #tidd

@daipresentsさんがRedmineを1000人のユーザで運用している事例をアップしていたのでメモ。
僕もこの規模まで運用したことはないので、とても参考になります。

【元ネタ】
受託開発でTracを導入してよかったことや失敗したこと | 世界 - daipresents!!

Redmineが1000人のエンジニアに使われるまでのこと | 世界 - daipresents!!

Twitter / @kamatamadai: 導入から2年で1000人以上にRedmineを使わせる楽天の実例。各種プラグインが参考になる / Redmineが1000人のエンジニアに使われるまでのこと | 世界 - daipresents!! http://htn.to/yWM5HK

資料にもあるように、楽天で、9万個のチケット、900個のプロジェクト、1300人のユーザでRedmineを運用されている。
この記事で面白いのは、「開発プロセスの型をツールで構築する」ということ。

CMMIでもPMBOKでも開発プロセスやプロジェクトマネジメントの標準化が重視されている。
その理由は、開発チームごとの能力のばらつきを抑えて、平均の能力を上げることにあると思う。
しかし、プロセスの標準化の作業は実際はとても面倒だ。

標準化された手続きをこなすための膨大なマニュアルと大量の中間的ドキュメントが要求される。
更に、皆が決められた手続きを守るために、稟議書のような承認フローが必要とされる。
もっと身軽に開発したいのに、標準化を頑張るほど、開発の速度が遅くなっていく。

CMMIを推進する立場の品質管理部門やプロジェクトマネージャと開発チームを支援するPMOは、その標準化作業の先頭に立つけれども、普通は開発チームと利害が対立しがちだ。
開発チームにお仕着せのプロセスを押し付けるから、開発チームはそれを実際は嫌がる。
トップダウンで頑張るほど、現場は疲労していく。

Redmineのようなツールによるプロセス改善は、それとは逆でボトムアップによるプロセスの標準化を進める。
プロジェクト管理やソフトウェア開発の作業に必要なツールが用意されていれば、メンバーもチームもそのツールに合わせて作業すればいい。
鈴木雄介さんのスライド「Agile Japan 2010 「変化を受け入れるアジャイルなプロジェクトマネジメントと現場・ツール・環境篇」」にある主張「コトそのものではなく、コトの外側を標準化する」がそれを意味していると思う。
実際の作業(コト、トランザクション)ではなく、コトの外側(開発環境、プロジェクト管理に必要な環境)をツールで標準化することで、開発チームの手順をどのチームも同じようにする。
それによって、要員の流動化も可能だし、メンバーのスキルも底上げできる。

僕自身もチケット駆動開発を運用してみて、プロジェクト内部の作業が全てチケットにあがっていれば、そのチケットを引継するだけでいい。
新人はRedmineでのタスク管理やSubversionによるバージョン管理、障害管理のプロセスに慣れれば、ツールにはソフトウェア開発のベストプラクティスが実装されているので、自然にソフトウェア開発をチームで作業するスキルを身に付けてくれる。

又、@daipresentsさんの事例で面白いのは、アジャイル開発の概念をRedmineのプラグインでどんどん実現して実際の運用がスムーズだったこと。
特に、アジャイル開発は進捗管理のビューが優れていると言う指摘は面白い。
確かに、タスクボードは単なるガントチャートやチケット一覧よりも分かりやすいし、バーンダウンチャートはプロジェクトの現状を的確に指摘してくれる。
そして、アジャイルな開発をもっと実践するために、チケットをタスクカードからストーリーカードへ、ガントチャートからタスクボードへ昇華していったという言葉が意味深い。

タイムボックス的な開発を行うには、ある程度の粒度が揃った要件の束が必要だし、イテレーション単位の進捗を測るには精度の高い見積りが重要になる。
だから、タスク管理や要件管理の作業の精度が要求されてくるのだろう。
つまり、プロジェクト管理の質がどんどん上がっていったことを意味しているのだろう。

@daipresentsさんの事例では、史上最高のチーム、タスクボード、バージョンバーンダウンチャート、パーキングロットなどのプラグインが紹介されていて、非常に参考になる。
個人的には、Redmineのチケット集計機能はまだまだ不足していると思うので、もっと強化されていいと考えている。
もっとたくさんの種類のビューを用意して、現場リーダーは状況に応じてビューを使い分けてもいいはずだ。
進捗管理でもガントチャートだけではなく、バーンダウンチャートやカンバンもあるといいし、品質管理やリスク管理、要員管理でも色んなビューがあると便利なはず。

プロジェクト管理の各種の状況に応じて必要なビューは何があるのか、という問いを今一度精査し直す必要があるように思う。

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

2011/03/27

要求開発×アジャイル開発の資料

@ryuzeeさんのTwitterで、要求開発×アジャイル開発を組み合わせた素晴らしい資料があったのでリンクしておく。

【元ネタ】
Twitter / @Ryutaro YOSHIBA: 開発プロセスの整備だけじゃなくて総合力を高める / 要求開発×アジャイル開発のポイント http://htn.to/BJ8Cg1

要望から要求や要件の洗い出しプロセスで要求開発を使い、実際の開発はアジャイル開発でガンガン作っていくというハイブリッドな開発スタイル。
要求開発の弱点である「要求は洗い出したけど実際に作ってみないと分からない」部分と、アジャイル開発の弱点である「アーキテクチャや品質の作り込みが弱いので後にシステムを大規模化したり派生開発しづらい」部分をお互いに補完し合っている。
これならとても現実的だろうと思う。

僕の考えでは、上流工程におけるシステム化提案や要件定義プロセスは、DDD(Domain Driven Design) よりも日本独自に発展してきたDOAの方がやりやすいと思う。
うまく説明できないけれど、ドメイン駆動開発はOOAの発展形であるが、理論としては分かるものの、実際に使いづらいように思う。

この辺りもいつか綺麗にまとめてみたい。

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

BitBucketを使ってみる

GitならGitHubという優れたSaaS形式のリポジトリがある。
MercurialならBitBucketがあり、無料でプライベートリポジトリが使いたい放題なので、下記の記事を参考に使ってみた。
結構いい感じ。

【元ネタ】
home – Bitbucket

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

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

Setting Up the Bitbucket Issues Service - Bitbucket - Atlassian Documentation - Confluence

BitBucketにはITS機能もあるので、複数人で共同作業する時にも使えそう。
WordやPowerPointのようなバイナリファイルも何とかなりそう。
但し、日本語テキストは試してないので気になる。
TortoiseHg 2.0では設定方法が分からず、コマンドラインでBitBucketと連携はできた。
もう少し調べないと分からない。

色々試してみる。

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

kdmsnrさんの翻訳のノウハウ

@t_wadaさんのFacebookからkdmsnrさんの翻訳のノウハウのリンクを見つけたのでメモ。
手馴れた感じで上手いな~と思った。

【元ネタ】
私の翻訳のやり方 - capsctrldays(2011-03-26)

kmuto/ReVIEW - GitHub

【特徴】
(要約開始)
* 英文テキストからwcでワード数をカウントして、工数をざっくり見積もる
* xyzzyとPDICで翻訳していく
* 日本語の扱い方は『日本語の作文技術』を参考にする
** 修飾は長い順にする
** 「あなたは」を省略する:日本語は主語を省くことが多い
** 「あなたの」を省略する:自明なので
** 無生物語を主語にしない:人を主語にする
** 受動態を避ける:能動態にする
** 否定形を避ける:反対にする
** 二重否定を避ける:肯定形にする
** 「~が、」を避ける
** 文のつながりが唐突なことが多いので、なめらかになるような接続詞を補完する(しかし* その結果* つまり)
** 「~だ。~だ。」と語尾を連続させない。「~だ。~である。~だ。」のように交互にする。
* ReVIEWというツールで章単位に翻訳した作業ファイルを作る
 更にReVIEWでHTML、PDF、InDesign用XMLを出力する
* ReVIEWでPDF化した原稿をiPadに入れて、ファミレスで校正する
(要約終了)

出版作業はいまだに手作業が中心でデジタル化されておらず、Adobe製品でDTP化しているので、電子書籍にしづらい。
ReVIEWで出版作業をデジタル化できれば、原稿という元ネタをPDF・HTML・InDesignなど各種のフォーマットに変換できるから便利なわけだ。
但し、ReVIEWは青木さんが作られたツールと思うが、興味を持っているもののマニュアルを読んでも使い方が分かっていない。

色々調べてみたい。

技術書をアジャイルに作る: プログラマの思索

Blogを電子書籍作成プラットフォームにする: プログラマの思索

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

TortoiseSVN、TortoiseHgのオーバーレイアイコンが表示されないときの対処法

TortoiseSVN、TortoiseHgのオーバーレイアイコンが表示されなくなったので、原因を探してみたら下記の記事で対処できた。

【元ネタ】
TortoiseSVNのオーバーレイアイコンが表示されないとき ? tune web

TortoiseSVNのアイコンオーバーレイが表示されない - espresso3389の日記

TortoiseSVN のオーバーレイアイコンが表示されない

(前略)
Windowsではオーバーレイさせるアイコンをレジストリで記憶していますが、最大で15個という制限があるそうです。それ以上もレジストリに登録できるのですが、最初に登録されたものから無効になってしまうそうです。
(中略)
対処法としてはレジストリをチェックして15個以上登録されてないか確認し、不要なものをアンインストールするか、レジストリの不要項目を削除すればOKです。チェックするレジストリは”HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers”です。
(後略)

結構はまった。

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

2011/03/26

アジャイル開発の始め方

天野さんが「アジャイル開発の始め方」という資料を公開されていたのでメモ。
とても分かりやすい。

Twitter / @Kenji Hiranabe: 「アジャイル開発の始め方」esmプライベートセミナー資料公開。 http://slidesha.re/hYRqsG.

同じタイトルで検索したら、渡辺幸三さんの記事も引っかかった。

「アジャイル開発の進め方」はもう聞き飽きた: 設計者の発言

コンテキストは違うけれども、僕も、アジャイル開発を進めるにはプロジェクトファシリテーションだけでなはなく、SW構成管理という技術力がなければ、アジャイル開発を運用するのは難しいだろうとチケット駆動開発の経験を通じて思っている。

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

Firefox4で動作しないアドオンを動作させる方法

FirefoxのVer4が出た。
早速使ってみたが、とても早くなっていて使い易い。
IE9よりもダウンロード数も半端なく多いらしい。

「Firefox 4」が正式公開後24時間で720万ダウンロード、IE9の3倍 - ニュース:ITpro

但し、Firefoxのバージョンを上げると、今までのアドオンが動作しなくなるので不便。
Firefox4で動作しないアドオンを動作させる方法があったのでメモ。

Firefox4で動作しないアドオンを動作させる方法 - GIGAZINE

Nightly Tester Tools :: Add-ons for Firefox

Nightly Tester Tools

Nightly Tester Toolsというアドオンを使うと、古いバージョンのアドオンでも使えるようになる。

ブラウザもIEだけでなくFirefox、GoogleChromeなどたくさん出てきた。
今後の鍵は、JavaScriptの高速化とHTML5の完全サポートだろう。
ブラウザの動向にも注目してみる。

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

2011/03/25

TiDD初心者が陥りやすい罠~マイルストーンの役割を誰も理解していない

ITS(Issue Tracking System:課題管理システム)の導入がうまくいっていない状況があったという記事があったのでメモ。
とても参考になります。

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

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

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

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

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

(前略)
「ソフトウェアのリリースとITSのマイルストーン、リポジトリのブランチはそれぞれ同期する」なんてITS使ってる人には常識。
これはプログラマの思索であきぴー さんが再三指摘されていることなので、理論的な部分についてはそちらを見てほしい。
この理解がないとチケットの収拾がつきにくく、wont fix していいのかどうかの判断もできない。
結果、関係者に話を聞いてまわることになり、ITSを使う意味がなくなる。
(後略)

筆者の言う通り、ITSを実プロジェクトで運用する時、最も注意すべき点はプロジェクトのマイルストーンとITSのマイルストーンとSCMのリリース予定バージョンを対応付けるようにすること。
そうすれば、マイルストーン単位にイテレーションのリズムが生まれて、自然にアジャイルな開発スタイルになる。

更に、チケットでタスク管理した時に、チケットの取捨選択の基準がとてもはっきりする利点もある。
手持ちのチケットは直近のマイルストーンに間に合わせるべきなのか、次のマイルストーンまで延期してもいいのか、という判断がやりやすくなるからだ。
マイルストーンでタスク管理するという意味は、Scrumのバックログによる要件管理、PMBOKのスコープ管理とも共通する。
つまり、スコープを調整することで、スコープ・コスト・納期のバランスを取るマネジメントを行っているのだ。

マイルストーンはITSの機能の一つに過ぎないが、この機能をどこまで開発チームが運用出来ているか、という観点で見れば、ITSの導入度合いやアジャイル開発の度合いを評価できるだろうと思う。

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

2011/03/24

ソフトウェア構成管理がソフトウェア開発の作業手順に制約をかける

ソフトウェア構成管理がソフトウェア開発の作業手順に制約をかけるのではないか?という記事を見つけたのでメモ。

【元ネタ】
構成管理手段が作業手順を定義している ? tune web

InfoQ: 分散バージョン管理システムの詳細なガイド

(引用開始)
構成管理ツールと言うのは単に機能を提供するだけではなくて、ソフトウェアの手順を暗黙的に決めてしまいます。
逆に考えると、新しいツールを使うときは新しいやり方を最大限活かせるように作業手順を作りなおさないとダメでしょうね。
(引用終了)

BTS、SCM(バージョン管理)、CI(ビルド管理)という3種の神器は、ソフトウェア開発に何をもたらしたのか?

アジャイル開発、派生開発、ソフトウェア製品ファミリー開発のいずれも、高度な構成管理技術を要求する。
高度な構成管理のインフラがなければ、いくらアジャイルを唱えた所で、絵に描いた餅に過ぎない。
高度な構成管理のインフラがなければ、オリジナルの製品から移植したり、大幅な機能を追加したり、複数の似たような製品を短期間に作り出したりするのは、規模が大きくなるほどいずれ困難になる。

アジャイル開発の最大の特徴である頻繁なリリースを実現するには、優れた構成管理技術が前提条件にある。
技術力がなければ、アジャイル開発も派生開発も製品ファミリー開発も安定して開発できない。
アジャイル開発は運用しづらいと思ってしまうのは、単に開発チームの技術力が低いという事実を指摘しているだけだ。

BTS、SCM(バージョン管理)、CI(ビルド管理)のツール群は最終的にはソフトウェア構成管理を形成し、それがソフトウェア開発の作業手順やワークフロー、開発プロセス全体に制約をかけている。
古いツール、従来の成功体験に基づく開発プロセスでは、ソフトウェア開発に進歩はない。
PDCAサイクルを早く回すには、プログラミングと言う最も基本的な作業の品質をもっと上げるべき。

BTS、SCM、CIという3種の神器と密接に絡むチケット駆動開発は、ソフトウェア開発の開発プロセスの制約条件を研究するのにとてもよい環境のように思う。

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

レガシープログラマかどうかを判断する基準

レガシープログラマかどうかを判断する良い記事があったのでメモ。

【元ネタ】
2011-02-18 - ITは芸術だ レガシープログラマかどうかを判断する10項目

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

(引用開始)
【レガシープログラマの判断項目】
* 使われるローカル変数をすべてメソッドの最初に宣言する。
* ローカル変数の宣言時に空文字("")や新しいオブジェクト(new Xxx())で初期化する。その後にすぐ別の値をセットする。
* メソッドの戻り値がすべて成功・失敗を表す 0 か -1 になっている。
* 複数のデータをまとめて扱う際は毎回配列を使う。配列の上限数はありえなさそうな数を指定する(1000とか)。
* 基本データ型(stringやint)と配列だけでデータ構造を表現しようとする。
* 変数の命名規則にハンガリアン記法*2を使う。
* クラスのフィールド変数をグローバル変数のように利用する。
* 配列やリストを毎回forループで処理する(例: for (int i = 0; i < array.Length; i++))。
* クラスやクラスメンバの可視性を意識していない(privateメソッドがpublicになっている等)。
* 変更履歴をコード中にコメントとして残す (ADDやDELみたいなコメントがたくさん付いている)。
(引用終了)

Cobol、C、VBで腕を鳴らしたプログラマも、Java、C#、Ruby、Python、JavaScriptなどで書いてみると、以前の習慣が古くさくなっている時が多い。
過去の成功体験が新しい技術の習得の邪魔をしていないか、もう一度胸に手を当ててみる。

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

RubyがJIS規格に制定された

RubyがJIS規格に制定された記事を見つけたのでメモ。

【元ネタ】
RubyがJIS規格「JIS X 3017」に制定:CodeZine

WEB+DB PRESS vol.58 の Rails 3 / Ruby1.9.2 記事が素晴らしすぎる件 - まちゅダイアリー(2010-08-21)

Rubyは日本で生まれたプログラミング言語なのに、日本のSI業界では重要視されていないか、殆ど無視され続けてきている。
基幹システムにRubyは使えないという先入観があるからだろう。

日本のIT産業は国際競争力がないと批判され続けてきている。
でも日本の草の根のオープンソース活動は活発で、RubyやSeasarなど優れたプログラミング技術などを生み出している。
多分日本のSI業界がその現状を変えるのは難しく、オープンソースやそれを支えるコミュニティが現状変革の鍵を握っているように思える。

上流工程にこだわる業務SEほど、モデルからシステムを自動生成すれば動くシステムができあがると空想するMDAが好きだが、実際のソフトウェア開発はもっと泥臭くて繊細。
プログラミング言語に依存しないモデルを目指すというのはMDA(モデル駆動開発)と同じと思うが、MDAにこだわり過ぎている気がする。
MDAはAgile開発の対極にあると思うから。
ソフトウェアはモデルから自動生成できるものではなく、実際に作って動かして、開発者やユーザのフィードバックを受けて、機能も品質も改善してVerUpすることで完成形に近づくものだから。

| | コメント (0)

2011/03/23

デブサミ2011レポート~チケット管理システム大決戦

デブサミ2011のパネルセッション「チケット管理システム大決戦 JIRA vs Redmine vs Trac ~ユーザーが語る、なぜ私はこのツールを使うのか」の記事が公開されたのでリンクしておく。

【元ネタ】
デブサミ2011レポート なぜチケットを管理するのか、なぜそのソフトウェアを使うのか:CodeZine

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

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

2011/03/21

チケット駆動開発が進むべき道 part3~BTSを中心に構成管理・テスト管理を含めたプロジェクト管理の枠組みを作る #tidd

チケット駆動開発について考えたことをメモ。

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

[#TiDD] チケット駆動開発への思い - 現場のソフトウェア工学 - #devsumi: ソフトウェアさかば

チケット駆動開発が進むべき道part1~ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する: プログラマの思索

チケット駆動開発が進むべき道part2~プロジェクト管理サーバーは開発チームの資産: プログラマの思索

チケット駆動開発を開発プロセスへ理論化できるか?: プログラマの思索

アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索

今年に入ってデブサミまでの2ヶ月間、チケット駆動開発に関する講演をしてきて、講演を聞いた人から指摘された内容から新たな問題意識を持っている。

一つ目は、SEA関西の世話人の方から、「Redmineによるタスクマネジメント実践技法」はあきぴーさんとさかばさんの共著だが、二人の観点の違いがはっきり出ている。さかばさんの方は、チケット駆動の導入が直接現場にもたらす効果に焦点をあて、その適用についても「効果があれば使えばよいし、かえって大変になりそうだったら、やめておけばいい」という現実的なスタンスだが、あきぴーさんの方は、チケット駆動開発を軸にして、さらに構成管理・テスト管理とも連動した、より大きなプロジェクト管理の枠組みの構築を目指されているようだ、と言われたこと。

二つ目は、かおるんさんから、Scrumは9つの規律、かんばんは3つの規律があるがチケット駆動開発には規律はあるのですか?と質問されたこと。

前者は、さかばさんの立場は下記の記事で既に説明されている。

[#TiDD] チケット駆動開発への思い - 現場のソフトウェア工学 - #devsumi: ソフトウェアさかば

僕の理解では、ソフトウェア工学は正しく使わなければ欲しい結果が得られないこと、つまりコンテキスト(問題の文脈)を明確に定めなければソフトウェア工学のノウハウを適用しづらいこと、そして、チケット駆動開発は現場のソフトウェア工学ゆえにコンテキストが現場にマッチしやすい特徴がある、と認識している。

ソフトウェア開発におけるコンテキストの話は森崎さんが最近よく話されているが、僕の認識では、ソフトウェア開発の現場で現れる諸問題を明確に区別して、それぞれの問題に対して最適な解決方法を見出す話なのだろうと推測している。

そして、コンテキストの話は最終的にはパターンランゲージでより包括的にまとめることができると思う。
何故なら、パターンとはコンテキスト(問題)に対する一つの解決方法をボトムアップで吸い上げたモデルだからだ。
例えば、GoFのデザインパターンは、オブジェクト指向プログラミングにおけるコンテキストの諸問題を解決する一つのアイデアで、とても有用だ。
実際、Stateパターン、Strategyパターン、Adapterパターンなどはどのような場面で使うと有効か、そして使いすぎるとどんな副作用があるのか、まで詳しく解説してくれている。

つまり、ソフトウェア工学のコンテキストの話は、パターン(成功例)やアンチパターン(失敗例)で綺麗にまとめられるはずだと思う。
だから、僕もチケット駆動開発のプラクティスをまとめる時、パターンカタログを作って「Redmineによるタスクマネジメント実践技法」にもまとめている。
その方がパターンがどんな問題に対して有効で、そのパターンの本質は何なのか、をよりはっきりさせてくれるからだ。

SEA関西の世話人の方の話を聞いて、さかばさんの観点がよく理解できたと共に、僕がやりたいことは、チケット駆動開発をベースとして、BTSを中心とした構成管理やテスト管理を含むプロジェクト管理の枠組みが作りたいのだと改めて自覚した。
それは最終的には、プロジェクトリーダーの意思決定をサポートするプロジェクト管理サーバーの概念を明確に実現することだ。

だから、最近はRedmineと構成管理、ビルド管理ツールHudsonとの連携に興味を持っている。
そのアイデアは、チケット管理システム比較に詳しく書いた。
言いたいことは、Redmineのプロジェクト・バージョン・チケットという概念が構成管理のコードライン(trunk, branch)、タグ、リビジョンと対比でき、更にはHudsonのジョブ、ビルド番号、ビルドログと対応付けることができるということ。
その対応づけによって、チケット駆動開発に現れる諸概念をソフトウェア工学の概念で補強できるし、現場で運用される構成管理やビルド管理、リリース管理、変更管理などのプロセスが何故そのように厳格に運用すべきなのかという理由を明確に理論付けできる。

僕がRedmineでチケット駆動開発を実践して改めて痛感したことは、アジャイル開発は手抜きの開発ではないことだ。
アジャイル開発は現物主義であるがゆえに、無駄なドキュメントや無駄な作業を嫌う。
だからと言って、すべてのドキュメントや厳格なワークフロー管理が軽視されていいわけではない。
やるべきプロセスを省略すると、本番リリース後の障害によって、手痛い仕打ちを食らう。
例えば、バグ修正とバグ検証は担当者を変えずに品質チェックがそのままスルーしてしまうとか、バグ修正後のコードレビューを省いてしまうなどのプロセスがあげられる。
バグ検証や同類バグ調査、コードレビューと言うプロセスを省くと、ファウラーの言う技術的負債として必ず現れて、プロジェクトを混乱させる原因になるからだ。

チケット駆動開発の利点の一つは、厳格なワークフロー管理、開発プロセスの管理を透過的にサポートしてくれること。
バグのチケットは複数人で切り替えて成果物をお互いにチェックし合うワークフローにすればいい。
バグのチケットを起票したら、開発者は同類バグ調査を必ず行ってから修正すればいいし、テスト担当者はデグレしていないか、他の機能に影響していないかの観点も含めてテストするように運用すればいい。

つまり、チケット駆動開発によってアジャイル開発に規律や組織力を導入することができる。
しかも従来のプロセスのようなExcelを印刷して承認する時に判子を押すような無駄なワークフローを排除して、必ずチケットに作業履歴が残るような仕掛けがある。
アジャイル開発にあるコミュニケーションや人間重視という利点をそのまま生かしながら、規律や組織力を導入してスケールアップしやすくできるはずだ。

二つ目のかおるんさんの指摘はまさにその通りで、チケット駆動開発の規律は何か、という問題は僕もまだ解決出来ていない。
最終的には数学の公理体系のように、最小の個数の規律(公理)から他の規律やプラクティス(定理)が導かれるような体系をチケット駆動開発にもたらしたいと思っている。
僕の直感では、「No Tikcet, No Commit!」というたった一つの規律でチケット駆動開発の全てのプラクティスを導出できると思っている。

実際、「プロジェクト内部の作業はチケットを起票してから始める」というTicket Firstという規律も、プロジェクト内部の作業は必ず成果物が求められるので、チケット無しで成果物を作ってはならないという規律から演繹できる。
又、BTSバージョンをリリース予定バージョンに同一視することでイテレーションに対応付ける小規模リリースというプラクティスも、成果物を作るチケットをバージョンというリリース単位でグループ化し、そのバージョンを2~4週間でリリースすれば、自然にアジャイルな開発として実現できる。
更に、BTSプロジェクトをビルドモジュールに同一視することで並行開発を実現するプラクティスも、プロジェクト内部の作業を表すチケットを開発チームやコンポーネントの単位でグループ化すれば、自然にビルドモジュールとBTSプロジェクトが紐づいて、それがリリース単位になる。

チケット駆動開発の他のプラクティスも同様に、最小の個数の規律から全てのプラクティスを演繹できるはずだ。
そうすれば、最低限の規律を守ってチケット駆動開発を実践すれば、自然にアジャイル開発を運用できて、その裏では厳格なプロセスが動いているという仕組みを作れるだろう。

今後はこの辺りをもっと理論的にまとめてみたい。

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

TortoiseHg2.0が公開されている

TortoiseHg2.0.2をさっそく入れてみた。
GUIも大幅改善されて、随分使い易くなっている。

【元ネタ】
TortoiseHg

white ? TortoiseHgを2.0にアップデートした

TortoiseHg2.0でのMQ - watawata日記

TortoiseHg2.0のincoming,pull - watawata日記

TortoiseHg2.0 - 記憶は削除の方向で

Subversionが普及した最大の理由は、TortoiseSVNというWindowsクライアントがとても優秀な点に尽きると思う。
TortoiseSVNのおかげで、簡単にSVNコミットしたりコミット履歴を見れるだけでなく、BTSチケットへのリンクやExcelやWordの差分比較もできる。
単なる構成管理ツールだけでなく、ドキュメントの管理やBTSとの連携によってタスク管理、更にはチケット駆動開発へ発展させることもできる。

TortoiseHgはMercurialのWindowsクライアント。
分散バージョン管理はGitの方が有名だろうが、MercurialはWindowsとの親和性に力を入れているように思える。
TortoiseSVNと同様に、ExcelやWordの差分比較もできるし、BTSチケットにリンクすることも可能。
更にはSVNクライアントとして使うこともできる。

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

TortoiseHgもRedmineチケットへの接続をサポート: プログラマの思索

TortoiseHg+hgsubversionの導入方法: プログラマの思索

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

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

色々試してみる。

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

2011/03/20

セキュリティテストで使えるFirefoxのアドオン

セキュリティテストで使えるFirefoxのアドオンが以前よりもすごく増えていたので、リンクをメモしておく。

【参考】
Web Developer - ウェブ制作に役立つ機能満載のFirefox拡張機能

Firefox アドオン - Web Developer | Mozilla Japan

SQL Inject Me :: Add-ons for Firefox

XSS Me :: Add-ons for Firefox

Tamper Dataを使ってXSSやSQLインジェクションのテスト - ほんまの走り書き技術メモ

Tamper Data :: Add-ons for Firefox

Web Developerはプルダウンに不正値を入れてサブミット、テキストボックスの最大桁を超えた値をセットしてサブミットのテストに使う。
POSTする時に故意に不正なデータを飛ばすテストで使える。

SQL Inject MeはSQLインジェクションをチェックする。実際の手動テストはテキストボックスに「' OR 'A'='A」を入力してサブミットするのと同じ。

XSS Meはクロスサイトスクリプティングをチェックする。実際の手動テストはテキストボックスに「<script>alert('test');</script>」を入力してサブミットするのと同じ。

他にもTamper Dataなど色々あるみたい。
FireBugsは既に知られたツールだけれど、他にもこれらのツールを使えば、Webアプリのセキュリティに関する品質を向上できるだろう。
セキュリティテストはインプットのデータが限られているので、Seleniumなどでテストを自動化できるとより楽に運用できるはず。

色々試してみたい。

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

継続は力なり

Wataru Yukawa (wyukawa)さんの記事が秀逸なのでメモ。

【元ネタ】
Jenkinsは1.400に到達した。 - watawata日記

オープンソースコミュニティの運営について - 川口耕介の日記

HudsonからフォークしたJenkinsはビルド番号が400個を超えた。
その意味は単にビルド回数が増えただけではない。
オープンソースのツールが、そのアイデアをソフトウェアとして実現して、たくさんの開発者に使ってもらって、そのフィードバックを受けながら、品質も機能も改善してきた歴史に意味がある。

オープンソースのツールの中では、コミッタがやる気を失ってプロジェクトが頓挫したり、せっかく築き上げたツールをリプレースして作り直そうとして途中でプロジェクトそのものが潰れたりする時も多い。
そういう危険を避けて、コミッタとユーザの間でPDCAサイクルを回しながら、プロジェクトを運営してきたという事実が素晴らしい。

素晴らしいソフトウェアになるには、瞬間的に思いついたアイデアを実装するだけでは足りない。
たくさんの人に使ってもらって、そのフィードバックを受けて、ソフトウェアをより良く改善する方向へ進めることが大事。

ジョエルも下記の記事で似たようなことを言っている。

いいソフトウェアには10年はかかる。それに慣れることだ。 - The Joel on Software Translation Project

「良いソフトウェアは、ワインのように時間がかかるものなのだ。 」と。
継続は力なり。

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

社会的欲求の4タイプ

HATさんから、社会的欲求の4タイプについて教えてもらったのでメモ。

【社会的欲求の4タイプ】
4タイプ - Wikipedia

4タイプ

オタキングex 4タイプ判定テスト

岡田斗司夫著の人生の法則 「欲求の4タイプ」で分かるあなたと他人」が有名な本なのだろう。
岡田斗司夫レコーディング・ダイエット決定版 (文春文庫)などの著作もあり、人間関係の本質について洞察が鋭い気がする。

社会的欲求の4タイプとは、人を社会的欲求の観点で4タイプに分け、そのタイプごとの特徴や他タイプとの関係を解説しているのが秀逸。
オタキングex 4タイプ判定テストで簡単に自分のタイプを判別できる。

実際は、PGやSEは職人タイプ(理想型)、営業マンや女性はアイドルタイプ(注目型)、経営者やプロマネは指導者タイプ(司令型)が多いのではなかろうか?

社会的4タイプで面白いのは、右手の法則と対角線の法則。
右手の法則とは、自分のタイプの右側にあるタイプにあこがれるらしい。
例えば、理想型は注目型にあこがれるので、人間関係が良好になりやすい。
逆に対角線の法則は、自分のタイプの対角線にあるタイプを理解できないこと。
例えば、理想型は、司令型を理解できないので、敵対しやすいかもしれない。

そういう法則を覚えておけば、相手がどんなタイプであるかが分かった時点で、どのような人間関係を作ればよいのか、それなりの対策を打つことができる。

社会的欲求の4タイプを聞いて、コーチングで出てくる4タイプの話と似ているなあ、と思った。

【コーチングで使われる4タイプ】
実践コーチング

コーチング|「4つのタイプ分け」私見

その29 あなたのタイプは?|コーチングがいいんじゃない? ♯ コーチングブログ

コントローラーが管理者タイプ、プロモーターは営業マンタイプ、アナライザーは職人タイプが多いのではないだろうか。
それぞれのタイプにコーチングする時、違った言葉で話しかけないと逆効果になる、という話。

人間の人格を分類する手法はユング、フロイト、クレッチマーの頃から行われているけれど、その分類が必ず正しいとは限らない。
その人の特性は複数のタイプが交じり合っている時が多いし、年齢によって変わる時もある。
だから、こういうタイプ分けは好きな人もいれば嫌いな人もいる。
でも、営業マンなら、このような知識を使えば、どのような会話や交渉を行えばよいか、を経験的に知っている。
SEもPMも交渉術の一つの知識として持っていると強みになると思う。

大学時代に読んだ「役に立つ性格学 (現代教養文庫)」では、「タイプ分けは人を分類することではなく、タイプというモデルへ抽象化することによって、人格の本質を見出すことだ」という文章が書かれていて、なるほどと思った。

(引用開始)
本当の類型(タイプ)は、人間をできるだけ完全に分類することを第一の目的としているわけではない。類型にとって本質的なことは、どれほど多くの人々がその類型に属しているかということではなくて、類型が何を解明してくれるかということなのである。本当の類型は、決してものを集めておく箱でなはくて、焦点なのである。
類型において明確で正確なものは、常にその中核であって周辺ではない。型が鮮明な境界をもちえないということは、型というものの本質的な性質である。
(引用終了)

HATさんが、人間関係や営業技術に悩む若手は、こういう考え方もあるので参考にしてみて、と言っていたのが心に残った。
参考にしてみようと思う。

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

風姿花伝を読む

Passion For The Future: 現代語訳 風姿花伝の記事を読んで、現代語訳 風姿花伝を図書館で借りて読んでみた。
芸能人やクリエイターには必読の本かもしれない。
プレゼンにも役立つような気がした。

【元ネタ】
Passion For The Future: 現代語訳 風姿花伝

花伝書「風姿花伝」本文

風姿花伝 index

風姿花伝 - Wikipedia

風姿花伝は室町時代に活躍した世阿弥が書いた秘伝の本。
現代語訳 風姿花伝の本は100ページ足らずなので読みやすい。

(引用開始)
私流に超訳してしまうと、こんなことも言っている。
・開演は会場が静まるのを待ってから始めなさい。
・昼の公演では穏やかな出し物から少しずつ盛り上げていきなさい
・夜の公演ではいきなりテンションを高く始めなさい
・練習中の芸は地方巡業で磨き、ここぞという東京ドーム公演で完成形を見せなさい
・若い芸人は若さゆえの輝きを持つが、それは一瞬のことなので根気よく精進しなさい
・35歳で世の中に認められないなら一流は諦めたほうがいいかもしれない
(引用終了)

プレゼンは場慣れすれば上手くなる、と先輩から言われたことがある。
10人、100人、300人の聴衆の前で話すのは、やはり度胸がいる。
風姿花伝が言う通り、小さなコミュニティでお試し中のプレゼンをして、大きな舞台で完成形のプレゼンをするのが王道かもしれない。

また、プレゼンの極意: プログラマの思索にも書いたけれど、プレゼンでは「1つの主張を違った観点で何度も繰り返す」ことが大事。
プレゼンは、何か主張がなければ人の心に届かないし、かと言って同じ文言を何度も聞くと飽きてしまう。
だから、一つの主張を色んな角度で分析して、評価して、結論を出すストーリーがプレゼンには多い。
佐藤正美さんが解説した結論から入り、1つのことを違うふうに繰り返すの記事がとても役立った。

そして、プレゼンそのものの技術も以前よりもかなり変わっている。
デブサミ2011で感じたことは、高橋メソッドやプレゼンテーションzenのような技術を若い人達の方が習得していて、分かりやすくインパクトのあるプレゼンを行っていたことだ。
一つの絵や画像が直感的に訴える技法は、まさに芸術家ならではの技術のように思う。

こういうクリエイターの技術もきちんとまとめてみたい。

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

2011/03/19

裏木戸に立てかけさせし衣食住

HATさんから、日本の営業マンに古くから知られている会話術の一つを教えてもらったのでメモ。

【元ネタ】
裏木戸に立てかけさせし衣食住とプリントマネジメント|印刷コスト削減ならシナジーコミュニケーションズ

昔営業マンだった頃の企業研修で、話題作りに困った時の発想法に「たていたにうち... - Yahoo!知恵袋

会話術 ~恋愛・日常会話で実践できる~:②「会話術」「裏木戸にたてかけさせし衣食住」「適度に整理すべし」

きどにたてかけし衣食住って言葉知ってます?ひらがなの部分ってなんでしたか?も... - Yahoo!知恵袋

IT業界であっても、日本で交渉を始める前にまず人間関係の構築作りから始まる。
その時、気軽な話題から入っていくテクニックの一つとして、日本の営業マンは下記のことわざで覚えているらしい。
上から順番に話していくとよいらしい。
たとえ初対面で話題に困ったとしても、これだけのネタがあれば、何か話していけるはず。

(引用開始)
うら【裏話】→あまり営業では…ですよね。。
き【季節・気候】『そろそろ梅雨の時期ですね。』
ど【道楽・趣味】『お料理が得意との事でしたが、お料理教室なども通っていらっしゃるのですか?』
に【ニュース】『今朝のニュースご覧になりましたか?』
た【旅・旅行】『温泉へよく行かれるとおっしゃってましたが、お薦めの温泉ご存知ですか?』
て【テレビ(天気)】『本日は気温も低く、夕方から雨になるそうですね。』
※↑少々前は天気という方もいらっしゃいましたが【き】と少々同様になりうる事、現代はテレビが普及してるからという理由がある と教わりました。
か【家族・家庭】『先日、お子さんが小学生になられたそうですね。』
け【健康】『いつもお肌がきれいですが、何かお手入れや普段から体を気遣ったりされているのですか?』
し【仕事】『今後のプランをうかがってもよろしいでしょうか?』
衣【衣服】『そのブラウス素敵ですね。』
食【食べ物】『この近くにお刺身の美味しいお店があるんですが、今度ご一緒にいかがですか?』
住【住居】『お住まいはどちらですか?』
(引用終了)

営業技術の研修でよく出るらしいので、知っている人は知っているが、知らない人は知らないらしい。
僕は知らなかったので、参考になった。
営業トークや初対面の異性に声をかけるときに役立つかもしれない(笑)

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

2011/03/12

No Ticket, No Commit! #tidd

_shimadaさんが公開したNo Ticket, No Commitの画像を見つけたのでリンクしておく。
チケット駆動開発を実践しているチームならば、RedmineやTracのWikiにこの画像を張って、チケット駆動開発の唯一の規律である「No Ticket, No Commit!」を徹底させるといいと思う。

Twitter / @_shimada: @akipii TYPOでDevelopmentから"e"が抜けてました >< 修正版です http://gyazo.com/3f9088870decdeda66c7da5c8d952475.png

Twitter / @_shimada: @akipii 著書、参考にさせてもらってます!自分とこのプロジェクトRedmineのhomeに貼るために作りました。某レコード屋さんのインスパイアものなので、この画像は出所不明瞭なpublic domainという扱いでお願いします。(笑

チケット駆動開発の良い点は、チームでソフトウェア開発する経験が少ない若手や自分でプロジェクトを仕切った経験が少ない新米プロジェクトリーダーにとって、良い習慣を身に付ける格好の場であること。
下記のポイントは実践しているだろうか?

バグ報告票(チケット)を他人にも分かりやすく書いているか?
バグの修正と検証は必ず担当者を代えて、成果物をチェックしているか?
バグ修正したソースは必ずコードレビューを実施しているか?
バグを修正する前に、必ず同類バグ調査を実施して、影響範囲を見極めているか?
バグ検証では、残存バグや同類バグが他にないか、デグレしていないか、という観点でテストしているのか?

RedmineやTracは本来はBTSだから、障害管理のフローに慣れれば、ソフトウェア開発の基本フローが身につく。

プロジェクト内部の作業を実施する前に、必ずチケットに作業内容を起票しているか?
作業履歴や仕様確認のやり取りは、チケットのコメントで残しているのか?
自分が担当のチケットに対して、作業状態や進捗率、実績工数を常に最新化しているか?
チケット集計機能を使って、自分やチームの状態を把握しているか?
ロードマップや変更履歴を見て、チームのゴールやチームにおける自分の役割を自覚しているか?

チケット駆動開発はプロジェクト管理をサポートするので、作業履歴をチケット上に残すことによって、報告・連絡・相談が自然に身に付く。

SCMコミットログにチケットNoを必ず書く運用ルールを徹底しているか?
チケットが1回のコミットで完了するなら「fixes #チケットNo」、複数回のコミットが必要なら「refs #チケットNo」で使い分けてコミットしているか?
コミットする単位は、ビルドエラーが出ないだけでなく、JUnitも通り、機能的にリリースできるレベルのものであるか?

「No Ticket, No Commit! 」の運用ルールでBTSとSCMを連携させることによって、トレーサビリティが実現でき、そのおかげで開発者自身も、他の人がどんな意図で修正したのか、その修正はリファクタリングしても大丈夫なのか、を自然に考える習慣が身に付く。

チケットにプロジェクトのタスク、リスクを全て載せて見える化しているか?
チケットの棚卸しは定期的に行っているか?
リリース計画を意識しながら、チケットの作業順序を決めているか?
リリース計画に基づいて、リリース予定バージョンを意識しながら、チケットを取捨選択しているか?
RedmineやTracの優れたチケット集計機能とチケットの属性の関連を意識して、チケットの属性を決めているか?

チケット駆動開発を運用できれば、新米プロジェクトリーダーでも、チケットの作業順序や担当を色々試すことによって、プロジェクトの回し方が分かってくる。
そして、プロジェクトのリスクを把握する予兆をチケット集計結果から嗅ぎ取ることができる。
更には頻繁なタスクの変更をリリース計画に取り込んで最新化することで、リリース計画の重要性を身をもって経験できる。
羅針盤があるからこそ、チームのゴールも分かるし、メンバーにゴールを共有してもらうこともできるのだ。

チケット駆動開発は仕事をさばく仕組み #agileto2010 #tidd: プログラマの思索にも書いたけれど、良い習慣を身につけた開発者は品質の良いプログラムを自然に書けるようになるから必ず成長すると確信している。
なぜなら、チケット管理システムに含まれる障害管理、プロジェクト管理の機能に慣れれば、ソフトウェア開発のベストプラクティスを自然に身につけることができるからだ。

|

デブサミ2011のベストスピーカー賞を頂きました #devsumi #itsjp #tidd

デブサミ2011でベストスピーカー賞を頂きました。
チケット駆動開発の講演とチケット管理システム大決戦の2つです。
聞きに来て下さった人、Shibuya.tracの方、スタッフの人達に感謝です。

【元ネタ】
2011-03-10 - I have dreams - 夢は野山を駆け巡る

2010-11-23 - I have dreams - 夢は野山を駆け巡る

チケット駆動開発やチケット管理システムの初心者向けに話すように心がけたのですが、何らかのチケット管理システムを既に聴衆の半数以上が経験していて、アンケートでも既に出版した本を読んでいるのでそれ以上の話を聞きたかったという話もあり、ここまでチケット駆動開発が注目されているとは思っていなかったです。
実際のアンケート結果は、大澤さんのBlogにアップされています。

チケット管理システム使用状況の調査結果(デブサミ) - Atlassian Japanese Blog

Twitter / @鈴木雄介: 参加させていただいた「チケット管理システム大決戦」は、なんと総合ランク2位。3位もチケット駆動だし、開発プロセスネタは強いなぁ http://bit.ly/hxUTQ4 #devsumi

さかばさんの感想も既にBlogにアップされてます。

[#TiDD] チケット駆動開発への思い - 現場のソフトウェア工学 - #devsumi: ソフトウェアさかば

僕個人の感想としては、2008年に初めてデブサミに聴衆の一人として行きました。
その時はAgile開発に興味を持っていたものの、Redmineはまだ知りませんでした。
そして今年、講演者として参加し、ベストスピーカー賞まで取れたのは感慨深いです。

主催者のIWAKIRIさんのBlogを読んで、改めてデブサミっていいな、と思ってます。
IT業界の中でも特に開発者を支援するイベントであるデブサミは、運営も講演内容も雰囲気も素晴らしい。

Twitter / @Y.Namikawa / RT @kohsei: 一番嬉しかったアンケートのコメント「デブサミは他のIT系イベントとは違い、ITを通じて世の中を変革していこうと前向きにとらえる人にとって最大の援護射撃の役割を担っている。参加型講演がもう少しあってもいいと思う。」 #devsumi #4tate

僕がデブサミで最も心を揺さぶられたのは、1日目の最後のライトニングトークスで、IWAKIRIさんが話された講演のお話。
デブサミは日本の開発の現場から、世の中を変えていくことを話し合う 10 年計画のプロジェクトとして立ち上げた。
その中で、デブサミの発表者だった角谷さんは、アジャイル開発を実践するチームを作りたい、と過去のデブサミで発表して、そして本当に自分の会社でチームを作りビジネスを始めた。
(実際、同じ会社の木下さんが「これからの「アジャイル」の話をしよう ――今を生き延びるための開発手法とスキル」という講演で、受託開発の契約にアジャイル開発の要素を取り入れた新しいビジネスについて発表されている)
彼は、デブサミ2011のテーマである「未来につながるために 世界に帆を立てるために」の通り、夢を現実にして世界に向けて帆を立てた。
後続の開発者も夢を発表して実現して、世界へ向けて帆を立てて欲しい、と。

僕も一技術者として、世の中に何か貢献できるものを作っていければいいなと思っている。

【参考リンク】
デブサミの人気セッション、DevLOVE主催にて再演 デブサミアワード2011の表彰式も同時開催:CodeZine

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

2011/03/11

@yusuke_kokuboさんのRedmineプラグイン

yusuke-kokuboさんのRedmineプラグインが公開されていたのでメモ。

【元ネタ】
meeting/14 - Shibuya.trac Wiki - SourceForge.JP

うちの会社のRedmineプラグイン - こくぼ@Everything is the experience.

一つは、チケットに添付したファイルを一覧で見ることができるredmine_attachement_viewer。
もう一つは、見積もり/作業時間に対しての予実をみれるようにするredmine_yojitsu。

前者の使い道としては、バグの検証のためにアップしたファイル一覧を見たい時がある。
添付ファイル名に一定のネーミングルールを課せば、見えやすくなる。

後者は、RedmineのBacklogsプラグインと組み合わせて、予定と実績の工数比較に使うみたい。
yusuke-kokuboさんの凄い所は、Redmineによるチケット駆動開発に、ストーリーカードとタスクカードの使い分けをBacklogsプラグインで実運用している点だ。

【Redmine Backlogsプラグイン】
Redmine Backlogs :: Home

Redmine Backlogs :: Usage: Product Owner

Redmine Backlogs :: Usage: Scrum Master

Redmine Backlogs :: Usage: Team Member

上記の画面を見ると分かるように、Scrumのスプリント>ストーリーカード>タスクカードをRedmineのバージョン>親チケット>子チケットで表現しているのがミソ。
顧客や管理者の観点では、ストーリーカード単位で進捗を見たり、集計すればいい。
開発者の観点では、タスクカード単位で作業の状況を更新したり、集計すればいい。

チケット駆動開発を運用すると、チケットがどうしても増えすぎて、完了速度よりも登録速度が増えてしまう時が多い。
その時に、チケットの親子関係を使って、タスクを束ねて見えやすくしたいのだが、Redmineのデフォルトの機能では、チケットの親子関係をロードマップ上で綺麗に集計してくれないのが弱点。
本来は、ロードマップというリリース計画を、顧客の観点であるストーリーカードの一覧で見たり、開発者の観点であるタスクカードの一覧で見たり、色々切り替えて分析したいのだ。

現状は、Backlogsプラグインがその目的に一番かなっていると言える。

RedmineのVer1.0から実現されたチケットの親子関係は、ストーリーカードとタスクカードの使い分けを自然に実現できるだけでなく、要件からビルドモジュールまでのトレーサビリティを実現できる点に大きな意味がある。

つまり、チケットの親子関係で要件管理をRedmine上で実現できる可能性を秘めている。
その可能性に秘められた意味をもう少し考えてみる。

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

2011/03/06

候補キーと2次識別子に関する概念

DOAをもう一度勉強し始めたので、候補キーと2次識別子に関する概念を整理してみる。
ラフなメモ書き。
間違っていたら後で直す。

【元ネタ】
代理キー - Wikipedia

主キー - Wikipedia

外部キー - Wikipedia

連関エンティティと関連クラス: プログラマの思索

データモデル表記読み替えハンドブック: プログラマの思索

2次識別子を使ったデータモデリング: プログラマの思索

【1】主キー、候補キー、2次識別子(代替キー)

スーパーキーは、関係の属性を一意に決めることができるキーの組み合わせ。
候補キーは、スーパーキーから冗長な属性を排除したキーの組み合わせで、主キーの候補になるキー。
主キー(primary key)は関係の属性を一意に決めるテーブル上の唯一の識別子。
2次識別子(代替キー:alternate key)は、候補キーのうち主キー以外のキー。

スーパーキーに冗長性がないものが候補キー。
主キーは候補キーの一つ。
候補キーには、主キー以外に、2次識別子(代替キー)も含む。

スーパーキー > 候補キー > 主キー、代替キー のイメージ。

主キーは分かりやすい。
代替キーが存在すれば、候補キーは2個以上になる。

代替キーの例としては、社会保障番号やJANコードなどがあげられるだろう。
日本国民なら必ず年金をもらえる資格があるから20歳になれば社会保障番号が必ず付与されて、一意に決まる。
しかし、20歳未満の日本人には付与されないから、NULLもありうる。
つまり、代替キーの制約を実装するには、unique制約だけであり、NOT NULL制約が付与されるとは限らない。
渡辺さんの本「業務別データベース設計のためのデータモデリング入門」の46ページに易しく説明してくれている。

代替キーが混じると普通は、BCNFではない。
主キーが非キー属性に依存してしまうからだ。
だから、第3正規形に無理に分解すると、関係従属性が失われるので、第3正規形まででいいとよく言われる。
でも、渡辺さんの本「生産管理・原価管理システムのためのデータモデリング」によれば、その説明は間違いで、代替キーをうまく使えば、BCNF正規形にできると説明しており、「生産管理・原価管理システムのためのデータモデリング」の44ページに詳しく説明されている。

渡辺式ER図では、データモデル上で代替キーによる制約を課すことで、業務ルールを表現することを重視している。
特に製造業における入庫・出庫や在庫などの受払という概念では、2次識別子が重要な役割を果たす。
この辺りのモデリングのテクニックははもう一度整理する。

【2】自然キー、人工キー、代理キー

自然キー(natural key)は、システム外部から格納すべきものとして与えられる情報を格納する属性からなる主キー。
つまり、画面や帳票など、人が認識した現象の中で、一意に決める番号を指す。
例えば、人が決めた商品コード、顧客コードの体系、帳票に出力される製造指図書番号などが相当するだろう。
自然キーは、T字形ERのidentifierの概念を連想させる。

人工キー(artificial key)は、一意性を確保するためだけにシステム内部で生成され、利用者が関知しない情報を格納する属性からなる主キー。
例えば、Oracleシーケンスなどが相当するだろう。
つまり、DBMSが勝手に振った一意な連番を指す。

最近なら、RESTなWebアプリを作るために、全てのテーブルは代理キー(surrogate key)というシステムが付与した勝手な連番を主キーにする時も多い。
特にRailsが流行してから、Webアプリのデータモデリングはその傾向が強い。
代理キーを導入した方が、URLが簡単に書けるし読みやすくなる。
だから、Railsでは複合キーを代替キー(alternate key)かつ外部キーにしてしまい、代理キー(surrogate key)を主キーにする。

この手法は、複合キー(composite key)に含まれるキーの個数が多い場合にも使われる。
複合キーが4個や5個以上のキーから成る場合、代理キー(surrogate key)を主キーにした方が読みやすいし、プログラミングも楽になるからだ。
その場合も複合キーは代替キー(2次識別子)としてunique制約を課す。

例えば、入庫や出庫では、入庫番号や出庫番号が主キーで、倉庫コード・棚番号・商品番号が代替キーになる時が多い。本来は、倉庫コード・棚番号・商品番号が複合キーとして主キーになってもよいのだが、入庫番号や出庫番号が指図書に一意に表示されているので、そちらが主キーになる。

あるいは、小売業の在庫管理や販売管理では、商品の色やサイズなどで一意に識別できるSKU (stock keeping unit)というコードが振られる。SKUは在庫の単位でもある。
この場合、赤いLサイズのセーターのような商品は、商品マスタではSKUコードで一意に識別するため、SKUコードが主キーになる。
但し、SKUコードとは別に、商品コード、色コード、サイズコードなどの組合せでも一意になるので、これらが代替キーかつ外部キーとして設定される。

【3】外部キー、複合キー、リレーションシップ

テーブル同士の関連(リレーションシップ)は、外部キー又は複合キーとして表現される。
DOAを勉強して思ったのは、OOAは重複度を重視するが、DOAではリレーションシップが外部キーで表現されるのか、複合キーとして表現されるのか、という点を重視する点が面白い。

2個のテーブルの関連が複合キーとして表現される場合、連関エンティティが現れる。
これは、OOAの関連クラスに相当する。
「~ごとに」「~単位」で表現される業務ロジックは、連関エンティティで表現できる時が多い。

普通は、二つのテーブルの関連は、外部キーとして表現される場合が多い。
つまり、業務の制約は、外部キーとして表現されるケースが非常に多い。
例えば、社員は一つの部に属するが、部には複数の社員がいる場合などは、社員テーブルに部コードが外部キーとして張られるのが普通。

業務ルールをどのように外部キーとして張ればいいのか、という問題に対しては、T字形ERが鮮やかに解決している。

自分流モデリング探しの旅(2)~T字形ER データベース設計技法 - papandaDiary - Be just and fear not.

(前略)
* resourceとresourceをつなぐ場合:対照表を生成する。対照表はeventである。
 (例)従業員と営業所
     従業員-営業所の対照表を作成し、リレーションシップを保全する。
* resourceとeventをつなぐ場合:event側に参照キーを持たせる。
 (例)顧客と注文
     注文entityに顧客コードを持たせる。
* eventとeventをつなぐ場合
** 「1:1」「1:m」:時系列の遅い方に持たせる。
 (例)受注と請求(一つの受注に対し請求は一つ)
     請求に受注番号を持たせる。
** 「m:1」「m:m」:対応表を生成する。
 (例)受注と請求(複数の受注に対し請求は一つ)
     受注-請求の対応表を生成し、リレーションシップを保全する。
(後略)

例えば、顧客というリソースと受注というイベントにリレーションシップを持たせたい場合、イベントにリソースの主キーを外部キーとして追加すればいい。
あるいは、受注や出荷などのようなイベント系テーブルにリレーションシップを持たせたい場合、先行イベントの主キーを後続イベントに外部キーとして追加すればいい。

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

TiDD初心者によく聞かれる質問part1~チケットが放置されがちです #tidd

チケット駆動開発についての質問のうち、「チケットが放置されがちだがどうすればいいか?」「チケットの粒度はどれくらいがいいのか?」の二つはいつも聞かれる。
最初の質問について、自分なりに考えたことをメモ。

【元ネタ】
チケット駆動開発を導入しても変わらないこと - Basic

まずは箇条書きより始めよ - Basic

デベロッパーズサミットまとめ【チケット管理システム編】 ? prototype002

【1】「チケットが放置されがちだがどうすればいいか?」という質問の背景を類推すると、チケットを起票する運用はできているものの、チケット管理ができてないことを意味する。

チケット一覧画面で、一生懸命チケットをフィルタリングしながら、どのチケットが遅れているのか、どう対処すればいいのか、必死になって考えている間にも、どんどんチケットが増えていってしまっているのだろう。

チケットが放置されがちな状況では、下記の記事のように「Redmineプロジェクトにバージョン(イテレーション)という概念が無い」「工程単位にBTSプロジェクトやBTSバージョン(イテレーション)を作っているのでバージョンに紐づかないチケットが散乱している」アンチパターンが多発しているだろうと推測している。

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

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

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

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

【2】放置されたチケットは不良在庫と同じだ。
つまり、たくさん製品(設計書やソースという成果物)は作っているものの、売れない製品(顧客へ納品できる品質でないモジュール)をたくさん作っているのと同じ。
不良在庫が増えすぎれば製造業の会社がつぶれるように、放置されたチケットが開発チームの能力を超えた枚数になってしまえば、プロジェクトは破綻する。

デスマーチプロジェクトでは特にそういう状況に陥りがちで、もはやどのタスクをどの順番からこなせばいいのか、プロジェクトリーダーですら分からなくなる。
そんなデスマーチプロジェクトに火消しリーダーが入った場合、一番最初にやるのが課題や作業(チケット)の棚卸しだ。
つまり、プロジェクトが今どんな状況になっているのか、どの成果物は信用して使えるのか、今後のタスクや残課題は何か、を逐一洗い出す。
そうしなければ、火消しリーダーも、何から作業すればよいのか分からないからだ。
この作業が意味するのは、チケットの棚卸しという作業は定期的に行うべきということだ。

製造業や小売業でも、倉庫にある在庫の製品や商品を月末に必ず1回は数えなおして、帳簿上の在庫数と合っているか確認して、間違っていたら実際の数値に合わせ直す。
この作業は実地棚卸し、略して実棚と言われる。
実棚の作業を月末に行って、当月末繰越残高を決定して、当月の売上原価と利益を計算する。
そして、来月に前月末繰越残高として来月の月初の在庫数として確定させて、来月の売上原価に入れる。

実棚の作業が意味するのは、在庫は定期的な棚卸し作業が必須で、それがなければ、自分たちの会社が今どれだけの売上や経費がかかっているのか分からないことだ。
最近の製造業ならば、月末1回の棚卸し作業はビジネスの速度に遅すぎて、毎日頻繁に実棚をチェックする継続的棚卸しが普通になっているだろうと思われる。
そうでなければ、デフレでこれだけ製品が売れなくなっている状況では、タイミング的には高く売ってもいい状況で安く売ってしまって逆に損する場合も多い。

製造業や小売業の実棚作業のように、チケットも定期的な棚卸し作業が必須だ。
その実棚の作業も最低でも週1回、できれば毎日やった方がいい。
放置されたチケットはすぐに不良在庫になるから。

【3】ファウラーは、今リファクタリングすべきソースをやらずに先延ばしすることを技術的負債と呼んだ。
今やるべきタスク(チケット)を先延ばしにするのは、利子をつけて負債にしてしまうのと同じ。
実際、IF文がネストして汚いソースをリファクタリングせずに先延ばしして、仕様変更が来てから修正しようとすると、当初見積もった工数よりもはるかにかかってしまう場合が特にそうだ。

Martin Fowler's Bliki in Japanese - 技術的負債

InfoQ: 技術的負債、マネージャの視点

InfoQ: 技術的負債は技術的な問題か?

InfoQ: 技術的負債を貨幣化する

とはいえ、普通はタスクがどんどん増えがちなので、優先度の低いタスクは潜在的リスクとして後回しにする意思決定も多い。
その場合、優先度の低いチケットをバックログという袋(TiDDなら特別なバージョン)に一旦入れておく。
バックログに入れられたチケットは、プロダクトオーナーの役割で、顧客価値に直結する機能や製品は何か、という観点でタスクを優先順位付けし、どのスプリント(イテレーション)で実施するか決める。
優先順位付けするという意思決定プロセスを含むがゆえに、Scrumが編み出したバックログという概念はとても重要だ。

バックログというプロセスには、リリース計画作りという計画プロセスが含まれている。
放置されたチケットが多いという事実は、それらチケットをどのスプリント(イテレーション)で実施すべきなのか、という判断が入っていないことを意味する。
つまり、リリース計画が立てられていないので、イテレーションという概念がプロジェクトに存在しないのだ。
いつまでに何をリリースするのか、という意思決定ができていないのだから、タスク(チケット)が放置されるのも当たり前だ。

【4】Agile開発では、イテレーションというタイムボックスにタスクをアサインしてから開発を始める。
すなわち、タスクのスコープをコントロールしていることを意味している。
放置されたチケットが多いという状況は、PMBOKの言うスコープ管理というマネジメントの基本ができていないことを意味しているのだ。

定期的なイテレーションのサイクルで、チームが解決できる能力のレベルに合わせたチケットの枚数をアサインしてから作業を始める。
この概念は、最終的にはScrumの言うベロッシティ(Velocity:開発速度)に関係すると思う。
ベロッシティを超えたタスクの量を開発チームはこなすことができないのだ。

チケット駆動開発を実践しているならば、例えば1ヶ月単位でチケットの消化枚数を数えてみると良い。
僕の限られた経験では、チームの規模にもよるけれど、1ヶ月という長く思える期間ですら、チケットの消化枚数は50枚ぐらいでしかない。
すると、開発チームのチケット消化速度が大体分かるので、それ以上のチケットを発行しても消化できないので無理と分かる。
だから、リリース計画を立てて、1ヵ月後、2ヵ月後のイテレーションで実現するタスク、今は未決定のタスクはバックログというように、チケットを大きく分けてこなした方がはるかに現実的。

まとめると、「チケットが放置されがちだがどうすればいいか?」という質問には、「不良在庫」「技術的負債」「棚卸し」「リリース計画」「スコープ管理」「バックログ」「ベロッシティ」というキーワードを覚えておけば、何かしらのヒントが隠れているはず。

【5】チケット駆動開発では、プロジェクト管理をチケット管理に置き換えて、マネジメントを見える化する。
チケットの取捨選択こそがXPの計画ゲームであり、マネジメントそのもの。
チケット管理こそ、Agile開発チームの腕の見せ所なのだ。

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

TracのワークフローをExcelマクロから生成する

TracのワークフローをExcelマクロから生成する方法が公開されていたのでメモ。

【元ネタ】
tracのワークフローをExcelの図で作った状態遷移図から作ってみる: いつまでもとりあえず

状態遷移図からTracのワークフローを作るマクロにTracの設定の取り込み機能追加: いつまでもとりあえず

Redmineに負けないようにTracのワークフロープラグインを作る: いつまでもとりあえず

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

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

Tracのワークフロー: プログラマの思索

Tracでワークフローを改造するには、trac.iniを修正するしかないけれど、GUIではないので面倒。
だから、TracはRedmineよりもワークフロー管理が劣っていると言われていたけど、上記で公開されているExcelマクロを使えば、ワークフローを自動生成してくれるらしい。

考え方としては、ステータスの状態遷移図を状態遷移マトリックスに置き換える発想。
これは便利だ。

他にも、WorkflowEditorPluginを使えば、Trac上でワークフローを修正できるようになるらしい。

WorkflowEditorPlugin ワークフローを簡単に編集できるようにしました - 現場のためのソフトウェア開発プロセス - たかのり日記

ワークフロー管理は、ソフトウェア開発の業務をどのようにコントロールするのか、というプロジェクト管理の基本に相当する。
バグ修正だけのワークフローだけでは物足りないし、かと言ってワークフローの種類を乱発すると開発者が混乱して運用しづらくなる。
そもそも、自分たちのプロジェクトでどんな業務があるのか、どんなワークフローが必要なのか、すら分析できていない開発チームは多くないだろうか?
開発プロセスを標準化しているチームならば、ワークフローを洗い出すのは簡単かもしれない。

僕の考えとしては、バグ修正やQ&Aのように必ず二人以上のチェックを通してから終了の判断を行うペア作業と、ToDoのように一人がタスクを登録しては消しこんでいく一人作業で、ワークフローを代えた方がよいと思っている。

TracもRedmineも有志が色々ノウハウを公開してくれているので、非常に参考になる。

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

2011/03/02

Redmine・HudsonとSCMの機能の関連表 #itsjp #tidd

Redmine・HudsonとSCMの機能の関連表 をチケット管理システムWikiに追加した。

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

RedmineとSCMの機能の関連表~BTSとSW構成管理の密接な関係 #itsjp #tidd: プログラマの思索

特集:Hudsonを使ったアジャイルな開発入門|gihyo.jp … 技術評論社

CIツールHudsonを使いこなす: プログラマの思索

言いたかったことは、RedmineがSCM(構成管理)と密接に関係するだけでなく、ビルド管理ツールHudsonの機能とも対応していることだ。
つまり、下記の機能がそれぞれ対応する。

【1】SCMコードライン⇔Redmineプロジェクト⇔Hudsonジョブ

バージョン管理(Subversion、CVS、Git etc.)のリポジトリにあるtrunkやbranch単位で、ビルドモジュール(コンポーネント)が作られる。
Hudsonがビルドする作業の単位はジョブになる。
ビルドモジュールが複数個のコンポーネントを統合してビルドされる場合、下流ジョブにコンポーネント、上流ジョブにビルドモジュールというジョブの依存関係を設定する。

Hudsonを使ったアジャイルな開発入門:第3回 Hudsonによるチーム間の連携~上流・下流ビルド|gihyo.jp … 技術評論社

上流・下流ビルド(ジョブ)とは、依存関係のある複数のジョブでつけるHudsonの機能。
普通は、jarのような最小のコンポーネントを下流ジョブとして先にビルドした後に、warのように最後にビルドするモジュールを下流ジョブとしてビルドする。
つまり、ビルドの実行順序を上流・下流ビルド(ジョブ)で関係付ける。

Hudsonが無かった頃は、Antなどで手作業でビルドしていたから、ビルドの実行順序を間違うとすぐにコンパイルエラーになってしまう。
Hudsonがあるおかげで、複雑なビルドもGUI上で設定できて、かなり楽になった。

更に、ビルドモジュールを本番環境へリリースする場合、ビルドモジュールが本当に本番モジュールであるのか、を検証したいなら、ファイル指紋を使えばいい。
ファイル指紋はバイナリファイルのハッシュ(MD5)であり、ファイル指紋を比較することでより厳格にリリース管理を運用することも可能。

Hudsonを使ったアジャイルな開発入門:第3回 Hudsonによるチーム間の連携~ファイル指紋を記録|gihyo.jp … 技術評論社

【2】SCMタグ⇔Redmineバージョン⇔Hudsonビルド番号

Subversion(CVS) tagging pluginを使うと、SVN(CVS)タグからチェックアウトされたソースからビルドされる。
SVNタグをリリース予定バージョンとして厳格に扱う場合に有効。

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

イテレーションに紐づく全てのタスクが100%で終了したら、いつでもリリースできる。
SVN(CVS)タグはリリース予定バージョンであり、Agile開発ではイテレーションに相当する。

【3】SCMリビジョン⇔Redmineチケット⇔Hudsonビルドログ

SVNリビジョンに書かれたコミットログは、Hudsonのビルドログ(コンソールログ)に出力される。

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

HudsonのRedmine(Trac, Mantis etc) pluginを使えば、Hudsonのビルドログから各BTSチケットへ遷移できる。
又、RedmineのHudson pluginを使うと、RedmineチケットのSVNリビジョンの履歴に「SUCCESS」「FAILURE」などのビルド結果が追記されるので、どのビルド番号にどのリビジョンが反映されているのか、が一目で分かる。

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

Redmine - Hudson Plugin 0.1.0 - Redmine

つまり、ビルドモジュール→SVNリビジョン→チケット←仕様(要件) or ビルドモジュール→BTSバージョン(SVNタグ)→終了チケット というトレーサビリティを実現できる。

Redmineプロジェクトとビルドモジュールを対応づける理由の一つは、ビルドモジュールのリリース計画や変更履歴がRedmineプロジェクトのロードマップや変更履歴に対応するようにしたいからだ。
そうすれば、Redmineの各プロジェクトのロードマップを見るだけで、コンポーネントがいつどんな修正を反映してリリースされるのか、をすぐに一覧できる。

ソフトウェア開発のリリース管理では「いつ何をリリースするのか」「今のモジュールにどんな修正が反映されているのか」という2点がいつも重要になる。
しかしながら、リリース作業をきちんと記録して、厳格なワークフロー管理をしていないチームでは、デグレやリリース作業ミスが多発しがちで、開発メンバーのモチベーションを落としてしまう。
デグレやリリースミスほど、ソフトウェア開発で嫌なものは無い。

チケット駆動開発は、「いつ何をリリースするのか」はロードマップというリリース計画、「今のモジュールにどんな修正が反映されているのか」は変更履歴という過去のリリース履歴という機能に置き換える。
この2つの機能は、とても重要な意味を持っていると感じている。

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

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