« 2012年3月 | トップページ | 2012年5月 »

2012年4月

2012/04/29

IPAの定量的プロジェクト管理ツール #redmine

IPAの定量的プロジェクト管理ツールがRedmineプラグインとして実現されたらしく、非公式デモサイトで見れたのでメモ。
@g_maedaさん、ありがとうございます。

【元ネタ】
Twitter / @FARENDTechCorp:IPAが4月27日に公開した「定量的プロジェクト管理ツール」のRedmine用非公式デモサイトを立ち上げました。 http://ipf.redmine.jp/redmine/

Twitter / @akipii: かなりすごいです。見てびっくり。RT @FARENDTechCorp: IPAが4月27日に公開した「定量的プロジェクト管理ツール」のRedmine用非公式デモサイトを立ち上げました。 http://ipf.redmine.jp/redmine/

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

Jenkinsをメトリクス収集ツールとして使うアイデア: プログラマの思索

Redmineチケットに、専用のカスタマイズ項目を追加して、データが投入されていれば、バッチ処理でメトリクスを集計してくれるみたい。
その集計結果は進捗管理、品質管理、コスト管理、課題管理のなどの観点で表示し、Tomcat上で動作しているようだ。
詳しい使い方は膨大なマニュアルを読まないといけないようなので、分からないけれど、使いこなせるとすごそう。
もう少し調べてみる。

【定量データ収集画面】
Photo

【定量データ集計結果画面】
_00

個人的には、これだけの豊富な機能を現場にどこまで浸透させて運用できるか、が課題になるだろうと思う。

【追記】
定量的プロジェクト管理ツールはアジャイル開発のタスク管理をサポートすることにも使えるらしい。
そういう目的で作られたとは思わなかった。

情報処理推進機構:ソフトウェア・エンジニアリング

(引用開始)
Redmine、Tracを使った「定量的プロジェクト管理ツール」の紹介

アジャイル型開発においては、頻繁なリリースに対応するための機能追加やバグ修正、あるいはリファクタリングによるソース修正をコントロールするために、ソース修正に対するタスク管理を行うことが重要です。ところが、イテレーション計画が頻繁に変更されるため、リアルタイムなタスク管理を行うことが難しくなっています。この問題に対応するため、IPA/SECでは、ソース修正の自動収集を行い、さらに定量データに基づきプロジェクト管理とバグ管理を行うツール「定量的プロジェクト管理ツール」を開発し、オープンソース・ソフトウェアとして公開しました。本セミナーでは、同ツールの概要について説明します。
(引用終わり)

| | コメント (2)

Mercurialのhgsubversion資料

@cointoss1973さんのMercurialのhgsubversion資料が公開されていたのでメモ。
SVNがmasterとして存在していて、クライアント側でMercurialを使う時にどのような点に注意すればよいか、とても詳しく分かりやすく書かれている。
git-svnでも同様の考え方を適用できるだろう。

以前、TorotiseHg+hgsubversionを試したけれど、まだ発展途上だった。
でも今は実用に耐えれるレベルになってきたようだ。

TortoiseHg2.03でhgsubversionが動くようになった: プログラマの思索

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

hgsubversionの使い道は、マスターリポジトリがSVNであり、SVNから移行できない場合にMercurialをクライアントのラッパーとして扱う時だろう。
Git使いがgit-svnを使う理由と同じだ。
クライアントで分散バージョン管理が使えるようになることで、バグ修正や機能追加のパッチをtrunkと同期させながらトピックブランチで試すことができる。

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

git-flow による構成管理とRedmineの関係: プログラマの思索

但し、hgsubversionにはいくつかの指摘が上記で示されている。
一つは、コミット履歴に分岐が発生しないように直線的になるようにすること。
SVNは複数のheadを保持することは当然できないから。
だから、rebaseを使ってコミット履歴に挿入したり、transplantでコミット履歴のheadへマージしたりする。

rebaseのイメージ: プログラマの思索

Mercurialの黒魔術: プログラマの思索

もう一つは、ファイル名が日本語のファイルには対応していないこと。
以下のBlogによれば、fixutf8を使えば大丈夫らしい。

HgSubversionでMercurialとSubversionを連携させる - azuki note

分散バージョン管理には、チケット駆動開発以上にたくさんの可能性があると思う。

| | コメント (0)

2012/04/27

RedmineがVer2.0でRails3へ移行予定

Redmineのtrunk(最新開発版)がRails 3に移行したらしいのでメモ。

【元ネタ】
Redmineのtrunk(最新開発版)がRails 3に移行 | Redmine.JP

Redmine moves to latest Rails 3 - Redmine

Twitter / @g_maeda:Redmineのtrunkがr9528でRails 3.2に移行した。

Twitter / @yusuke_kokubo:rails-3.2ブランチがもうtrunkにマージされた。Redmine v2.0は思ったより早くリリースされそうだな

Twitter / @matsuu: Redmineは次のメジャーバージョンアップ(2.0)でRails 3.2.xに移行します。おー。 / “Redmine moves to latest Rails 3 - Redmine”

Twitter / @evasys01:RT @akipii: あれだけ機能改善してるのにすごい RT @bomcat: Redmineのソースを読んでて思ったのは本当にDRYが徹底されてるなってこと。

単なる機能追加よりも、土台となるアーキテクチャの変更の方がはるかに難しいのはソフトウェア開発者なら誰でも知っている。
見た目の機能は変わらなくても、ライブラリがバージョンアップして対応するだけでも大変なのは、Windowsの頻繁なアップデートやApacheのセキュリティパッチなどの例を見ればよく分かる。
機能をデグレードさせないように、ユーザに見えない部分のライブラリやフレームワークのVerUpはとても神経を使うものだ。

だから、RedmineがRuby1.9に対応できたことでもすごいと思っている。
だが、RedmineコミッタはRails3へ本気で移行しようとしているようだ。

Redmineはファンクショナルテストが厳格だと聞いたことがあったので、Ruby1.9の対応も外野から見ればさほどの混乱もなくスムーズに移行できたのかもしれない。
RubyやRailsの最新版に対応することで、Redmineが延命できるだけでなく、性能改善や今後の機能改善もやりやすくなるだろう。

今後のRedmineの動向にも注目していく。

| | コメント (0)

2012/04/24

メールでRedmineチケットを登録する機能のアーキテクチャ

メールでRedmineチケットを登録する機能のアーキテクチャについて考えたことをメモ。

【元ネタ】
メールによるチケットの登録 | Redmine.JP

メールによるチケット登録で使用できるキーワード | Redmine.JP

メールのエンコードをiso-2022-jpにする(文字化け回避) | Redmine.JP

メールでチケット登録時に題名が文字化けする問題を修正 | Redmine.JP Blog

メールでRedmineチケットを登録する機能の可能性: プログラマの思索

Redmineで受信メールによるチケット登録や既存リポジトリ情報を登録する方法: プログラマの思索

Redmineのチケット登録をITILへ応用する: プログラマの思索

メールによるチケットの登録 | Redmine.JPに書かれた@g_maedaさんの詳しい記事を参考にすれば、作れる。
(@g_maedaさんに感謝!)

メールによるRedmineチケット登録で注意すべき点はいくつかある。
一つは、2種類のアーキテクチャがあること。
「メールサーバからメールを転送」する場合は、メールを受信するたびに受信メール用APIがHTTP経由でRedmineへチケット登録するので便利。
但し、メールサーバーにrdm-mailhandler.rbを配置する必要があるので、メールサーバーのセキュリティ上配置できない場合は実現できない。
「IMAPサーバからの受信」する場合は、Cronでrakeタスクを実行して受信メールを取得後、Redmineへチケット登録する。
メールサーバーへ定期的にポーリングして受信メールを取得するので、タイムラグが発生する点は注意が必要。

もう一つは、メールの内容をチケットへ転記する際に文字化けする現象があること。
上記の記事のように、本文が文字化けする場合は、ActionMailerJaのRedmineプラグインをインストールする。
更にSubjectも文字化けする場合は、@g_maedaさんのパッチを当てる必要がある。

また、Redmineの認証を通過しなければチケット更新できない設定の場合、受信メール専用のRedmineユーザをあらかじめ作っておく必要もある。
そして、メールサーバーにある受信メールが溜まっていく設定ならば、月1回はチケット登録済みのメールを削除するバッチ処理も必要になってくるだろう。

メールでRedmineチケットを登録する機能のアーキテクチャは意外に奥が深いように思う。


| | コメント (0)

TortoiseHgでBitBucketのチケットにリンクさせる

TortoiseHgでBitBucketのチケットにリンクさせる設定が簡単だったのでメモ。

【元ネタ】
TortoiseHg で BitBucket の issue と連携 - 負けないように頑張る日記

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

TortoiseHgでチケット番号をクリック可能なリンクにする at endflow.net blog

TortoiseHgを使っているなら、リポジトリサーバーはGitHubよりもBitbucketを使うのが普通だろう。
TortoiseHgのリポジトリ設定>課題管理で、上記の設定を追加すれば、コミット時に「#チケット番号」を書けばBitbucketの該当チケットへリンクする。
但し、Mercurialのコミットログにあるチケット番号からBitbucketのチケットへリンクするが、Bitbucketのチケットにはリビジョン一覧が表示されないようなので注意。

個人的には、Bitbucketがリポジトリサーバーの中で最強だと思う。
理由は、MercurialやGit、SVNに対応していて、プライベートリポジトリが使いたい放題だから。
もちろんGitHubのように、folkやPullRequestの機能も付いている。

Bitbucket で pull request が来たとき - A Day in Serenity @ Kenji

Bitbucketリポジトリのフォーク - Bitbucket ドキュメンテーション - Atlassian Japan Confluence

色々試してみる。

| | コメント (0)

rebaseのイメージ

@yusuke_kokuboさんのつぶやきでrebaseのイメージがようやく分かったのでメモ。

【元ネタ】
Twitter / @akipii: とても分かりやすい RT @yusuke_kokubo: ブランチのmergeは2つのブランチが合流するのに対して、 rebaseは一方のブランチがもう一方のブランチに(分岐元から派生した分を)吸収するようなイメージをしてる

Rebaseとトピックブランチ: プログラマの思索

mergeは衝突がなければ、派生ブランチをtrunkへ取り込んでくれるが、衝突があれば、マージしてくれない。
rebaseは、trunkへ派生ブランチで育てたパッチを合流するように取り込んでくれる。
つまり、rebaseはtrunkの履歴を壊さず、その履歴の上に派生ブランチの履歴を取り込んでくれる。
入門Git」にもrebaseについて詳しく解説されている。

trunkに派生ブランチのパッチを取り込む時、派生ブランチの全てのコミット履歴を取り込むのではなく、一部のコミット履歴のみつまみ食いして取り込みたい時もある。
Mercurialの場合、transplantというコマンドを使えば、派生ブランチのどのリビジョンを取り込むのか、Yes or No形式で取り込んでくれる。
Gitならcherry-pickを使えばいいらしい。

hg transplantを試してみた - 文殊堂

Subversion, Git, Mercurialそれぞれでのcherrypicking - watawata日記

koie blog : hg transplant

SVNならmergeコマンドしかないけれど、MercurialやGitはマージ作業のコマンドが豊富で、色んな使い方がある。
マージ作業のRedo、Undoができることで、トピックブランチで並行開発するのがとても楽になっている。

CVS、SVNそしてGit、Merucurialに至るバージョン管理の歴史はソフトウェア開発そのものの歴史なのかもしれない。
Mercurialはとても奥が深いので色々調べてみる。

| | コメント (2)

RedmineのWiki機能強化

RedmineがVer1.4になって、更にWiki機能が強化されているのでメモ。

【元ネタ】
Redmine 1.4新機能紹介: Wikiの全ページを一括してPDFに出力 | Redmine.JP Blog

Redmine 1.3新機能紹介: PDFエクスポート機能の改善 | Redmine.JP Blog

Ver1.3では、画像込みでPDF出力できるようになった。(但し、RMagickが必要)
Ver1.4では、Wikiの全ページを一括出力できるだけでなく、PDFのしおり機能も追加されている。

PDFエクスポート機能は@naitohさんが機能改善で貢献されていたが、正直ここまで使いやすくなっているとは気付かなかった。
上記記事のコメントにもあるように、開発マニュアルをWikiに書いておけば、PDFで出力して紙媒体で納品することも可能だ。

以前書いたけれど、プラグインを入れれば、WikiをFreeMind対応できるので、マインドマップをよく使うリーダーや開発者は対応するとよいかもしれない。

changeworld / redmine_free_mind / overview ― Bitbucket

RedmineのFree Mind Plugin: プログラマの思索

RedmineのPDF出力は、細かな機能改善がユーザインターフェイスを使いやすくし、作業効率を上げてくれる良い例だと思う。
ツールが我々の思考や作業そのものに制約をかけている。
ツールの新しい使い方、使い勝手が思考や作業の幅も深さも広げてくれるのだ。

| | コメント (0)

2012/04/22

PullRequestは分散バージョン管理の利点を生かしたパッチ取り込み

PullRequestは分散バージョン管理の利点を生かしたコードレビューのパッチ取り込みなのだと下記の記事を読んでようやく分かった。
考えたことをラフなメモ書き。

【元ネタ】
「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とご飯と甘いもの @ sotarok

Twitter / @obionekenobey: RT @akipii とても良い記事。Pull Requestの機能をRedmineで実現するのは可能なはず。「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とご飯と甘いもの @ sotarok

現在の開発では、trunk(マスター)に対して各開発者がブランチを作ったり、2次開発や大きめの機能の開発、別の顧客向けにカスタマイズする開発などでブランチを作るのはとても普通だ。
すると、マージ作業が発生し、そのマージ作業に非常に大きなコストがかかるのは従来から知られていた。

だが、GitHubが提供しているPullRequest機能を使えば、ブランチ作成(フォーク)→パッチ作成→PullRequest時にコードレビュー→OKならマージ完了という流れがスムーズに行える。
マスターからフォークすることで自分用のブランチを作り、そこで育てたパッチをマスター開発者へ送る時にPullRequest機能を使う。
そこで、自分が作ったパッチはマスター開発者の目にさらされるし、PullRequestによるパッチを誰が誰に送り、どんな議論があったのか、を他の人が参照することもできる。

僕がRedmineで並行開発を行なっていた時、その作業はチケットを経由してやり取りしていたが、コミット後にコードレビューしていたから良い運用とは言えなかった。
チケット単位のトピックブランチによる開発でも、そのトピックブランチはRedmineの管理下にないため、トピックブランチのパッチを手作業でチケットにアップしなくてはならない手間がかかる。

だが、RedmineのVer1.4以降では、SCMのマルチリポジトリ機能があるので、すべてのトピックブランチを登録して、PullRequestをチケット経由で行うようにするやり方もある。
そうすれば、チケットにコードレビューの結果が残るし、どんな経緯でそのパッチが作られて取り込まれたのか、という履歴が残るので、その後の運用保守で非常に役立つ。

できれば、RedmineでもPullRequestの機能を追加できるといいだろう。
実際の運用イメージとしては、マスターとなるリポジトリからブランチを派生できる機能、そのブランチのパッチをマスターへPullRequestする機能があればいいだろう。
つまり、ブランチがマスターのどのリビジョンから派生して、どのリビジョンへ取り込まれたのかが分かるような機能になれば良い。

GitやMercurialがコミット履歴の維持や改変の機能を強化しているように、コミット履歴や作業履歴はソフトウェア開発でとても重要なのだ。
仕様という結果だけではなく、その仕様が決まった経緯も知りたいのだ。

RedmineとGit又はMercurialを組み合わせたチケット駆動開発は、並行開発に関わるソフトウェア開発を大きく変える可能性があると思う。

| | コメント (0)

Mercurialリポジトリの統合と分割

Mercurialリポジトリの統合と分割のコマンドconvertの使い方がわかったのでメモ。

【元ネタ】
Mercurial の convert 拡張を用いてリポジトリの内容を一括で変換する (フェンリル | デベロッパーズブログ)

紹介マニアどらふと版: convert と filemap を利用した hg リポジトリの分割と統合

Mercurial リポジトリを分割する - ursmの日記

Convert でリポジトリを分解する / hg tip

schrome.net - Mercurialリポジトリへの分割と変換を行うシェルスクリプト

Mercurialリポジトリを統合したり分割したい理由は、新規開発や2次開発で一旦作ったものの、それらのライブラリを後からまとめたり、多すぎるので分割したりしたい時があげられる。
その場合、修正履歴もそのまま引き継ぐようにしたいが、Mercurialは履歴の引き継ぎも統合・分割時に行なってくれるので便利。

例えば、srcリポジトリをtargetリポジトリのsrcフォルダへ統合する場合は下記になる。
echo rename . src > map.txt
hg convert --filemap map.txt src target
cd target
hg merge
hg commit -m "srcを追加"

もちろん、CVS・SVN・GitなどのリポジトリをMercurialへ移行することも可能。
hg convert --helpを見ると、ほとんどのSCMに対応しているみたい。

hg convert [OPTION]... SOURCE [DEST [REVMAP]]

別 SCM のリポジトリから Mercurial リポジトリへの変換

Accepted source formats [identifiers]:

- Mercurial [hg]
- CVS [cvs]
- Darcs [darcs]
- git [git]
- Subversion [svn]
- Monotone [mtn]
- GNU Arch [gnuarch]
- Bazaar [bzr]
- Perforce [p4]

但し、tortoisehg-2.2.2-hg-2.0.2では正しく動作するが、tortoisehg-2.3.1-hg-2.1.1ではhg convertを実行するとエラーになるので注意。
Mercurialのバグかもしれない。

MercurialやGitを触ってみると、従来のCVSやSVNとは全く異なるバージョン管理ツールであるのがよく分かる。
過去の修正履歴を保持しながら、移行作業も可能だし、過去の修正履歴を改変することも可能だ。
そのような機能があるおかげでマージ作業も移行作業もRedoやUndoが可能になるので、失敗を恐れずに作業できる余裕が生まれる。

ツールが新しい使い方を提唱することで、アジャイルなソフトウェア開発を更に補強してくれる。
ツールがプロセスを改善していく。

色々触ってみる。

【追記】
Mercurial2.1.1ではsplicemapを使えばhg convertが成功するらしい。試してみる。

Twitter / @karbou_12: @akipii Hg 2.1.1だとconvertにはsplicemapオプションが必要です。2.1.2では直っているみたいです。 http://goo.gl/td6TO

mercurial-2.1.2.tar.gz: mercurial-2.1.2/i18n/ja.po | Fossies Archive


| | コメント (2)

Redmineとチケット駆動開発の感想を集めてみた

はてぶやTwitterからRedmineとチケット駆動開発の感想を集めてみたのでメモ。
とても励みになる。

【元ネタ】
はてなブックマーク - atsushifxのブックマーク - 2008年12月16日
Redmineを使って、高速・高品質なシステムを開発するための方法 2008/12/16

オクガクブログ::KOF2008

(引用開始)
2つ目は、「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」というもので、RoRでつくられたBTSを活用した事例紹介でした。
これは素晴しくよかった。
プロジェクト管理しかもアジャイル的にBTSを活用して行うということで、興味深さ満載でした。是非うちにも導入したい。早速試してみようという内容でした。
(引用終了)

はてなブックマーク - atsushifxのブックマーク - 2009年1月13日
XPから始まったアジャイル開発で今後の主流になるプロジェクトマネジメントの方法論。XPが普及期に入ったってことかも 2009/01/13

Twitter / @yusuke_kokubo: TracにしてもRedmineにしてもこのブログはタメになるので必読です。 http://forza.cocolog-nifty.com/blog/2009/05/redminetrac-905.html

はてなブックマーク - かおるんのブックマーク - 2010年12月15日
あきぴーさんがすごいのは、周りになんと言われても自分の信じた道を突き進んで、本を出すまでになった継続力だと思う。 2010/12/15

はてなブックマーク - jiska - 2011年4月4日
Redmineの設定方法や使い方よりもRedmineを用いてのアジャイル開発手法に重きを置いて解説してた チームメンバーに是が非でも共有したい する 2011/04/04

Twitter / yotii23: とりあえず今日明日中に「Redmineによるタスクマネジメント実践技法」読んで、まとめ作って、関係者全員に配る。全員に読ませるのは無理だけど、せっかくRedmine使ってるんだから、いい文化を根付かせてやる。

Twitter / akiko_pusu: Redmineによるタスクマネジメント実践技法 やっと買いました。導入は簡単だけど、ワークフローをいろんなプロジェクトで共有していくのって難しくて困っていたので、もう一回メンバと利用を考えていきたいです。

Twitter / k_0kamoto: 「Redmineによるタスクマネジメント実践技法」を読んでる。良い感じ。まだ冒頭中の冒頭だけどいろんな疑問が解消されるわ。

Twitter / miwa719: MS Project は顧客向けの進捗報告かー。うまいこと言うなあ。 - Redmineによるタスクマネジメント実践技法 / 小川明彦 http://htn.to/wjFor5

Twitter / kozy4324: Redmineによるタスクマネジメント実践技法とやらを読み始めたお、冒頭で過去プロジェクトの問題点=Excelと言い切っているところに男気を感じる

Twitter / ngmy: 『Redmineによるタスクマネジメント実践技法』を買ったけど、これは良書ですね。前半はRedmineに依存しないチケット駆動開発一般の説明ですが、実際の事例をいろいろと紹介してくれているので参考にしやすいです。

Twitter / sjisjis: 「Redmineによるタスクマネジメント実践技法」読み終わった。エンジニアじゃなくても結構プロジェクト進める上で参考になるなこの本。 redmineは基本的にはBTSだけど一般的にタスク管理ツールって何が使われるんだろう。
http://goo.gl/mWd4q

Twitter / itsmypleasure: 【Redmineによるタスクマネジメント実践技法/小川 明彦 他】Redmineって何ぞ?からベーシックな利用方法まで解説している。これを読んである程度イメージが理解できたらRedmine利用に関する... →http://bit.ly/naN21g #bookmeter

Twitter / @akipii: 細かい所までよく探してる@Posaune @biac @kanu_ p137「チケット駆動開発はアジャイル開発を実現するプロセスの一部である事実を示唆していると筆者は考えます」p153「筆者はチケット駆動開発を実践してみてこれがアジャイル開発なのだ!という気づきを体験しました」

Twitter / @akipii: チケット駆動開発はバグ管理からアジャイル開発へ発展した手法だ。チケット駆動開発をうまく運用できてないチームはバグ管理の基本から見直した方がいい。BTSの一つ一つの機能には今までの世界中の開発者の経験と知恵が込められているのを感じ取って欲しい。

Redmineによるチケット駆動開発でアジャイル開発をようやく理解できた経験をしたけれども、多分それは僕の一事例にすぎない。
アジャイル開発の運用方法は他にもやり方がたくさんあるし、アジャイルは知れば知るほど奥が深い。
でも、チケット駆動開発が面白い点は、自分でツールの機能を作ったり運用することによって、色んな観点で実験できることだ。
プログラミングできる技術があれば、ソフトウェア開発のマネジメントも実験できる。

今の時代はソフトウェアが世界を動かす時代。
例えば、TwitterやFacebookのようなソーシャルなツールも所詮お遊びに過ぎないと思う人は多かったかもしれない。
でも、東日本大震災でTwitterやFacebookが携帯やテレビよりも安否確認に有効に使えると分かって普及したように、ソフトウェアは使い方を発見すれば大きな威力を発揮する。
「チケット駆動開発はAjaxみたい」と言われた上田さんの言葉が象徴的なように、BTSという古いツールをソフトウェア開発のタスク管理へ応用すれば、アジャイル開発にも適用できる。
新しい使い方を発見すれば、新しい効果が生まれる。

今後もRedmineやチケット駆動開発について色々考えてみる。

| | コメント (0)

2012/04/21

AWS MarketplaceでRedmineも動く

AmazonのクラウドアプリのマーケットプレイスAWS Marketplaceが今日公開されていて、その中にRedmineのインスタンスもあったのでメモ。

【元ネタ】
Amazon、クラウドアプリのマーケットプレイス「AWS Marketplace」開始。数クリックでクラウドアプリが利用開始 - Publickey

Twitter / @tomyankuns: おぉ、SugerCRMとかRedmineがaws marketplaceに上がってるなー。やべぇがんがんポチりそうだw

AWS Marketplace: Search for Products : Redmine

Redmine powered by BitNami on AWS Marketplace

BitNami :: Redmine

AWSはいわゆるPaaSだが、アプリケーションも一緒に提供すれば、IaaSないしSaaSとも言える。
RedmineはRailsゆえにインストールは楽だが、それでもハードルは高い。
だが、SaaS形式でインスタンスを提供してくれれば、すぐにアプリケーションを稼働できる。
しかも従量制だから、好きな時に使って、不要になれば捨てればいい。
また、AWSならスケールアップも自動的にやってくれるし、面倒なインフラ管理もしなくてもいい。

AWS Marketplaceを見ると、MantisやBugzilla、SugarCRM、WordPressなど有名なオープンソースアプリが提供されている。
そもそもBitnamiでは従来から、RedmineのVMware仮想イメージやAmazon Machine Images(Amazon EC2 上に BitNami スタックを設置できるインスタンス)が提供されていた。
だから、Redmineを一から構築するのが面倒な人は、VMイメージをAWS上に載せて動かしたりすればいいだろう。

Windows上でも、CentOSのVMイメージを持ってきてRedmineをインストールすることも可能だ。
僕も下記の記事で試してみたがとても簡単だった。
ギガビットEthernetのようなLAN環境があれば、10G以上のVMイメージも20分ぐらいで簡単にコピーできる。

Index of /Linux/centos

VMware PlayerでCentOSをインストール

Linux: RedmineとSubversionのインストール・設定例

一昔前に比べると、いろんな環境でいろんな事を試せる事ができる今はとても楽しい。

【追記】
Twitter / @akipii: 既に1年以上前からAWS+Redmineの事例はあったんですね。 AWS CloudFormationを使ってみよう - redmine編 - http://www.slideshare.net/kentamagawa/aws-cloudformation-redmine

| | コメント (0)

2012/04/20

Redmineで受信メールによるチケット登録や既存リポジトリ情報を登録する方法

Redmine.JPを見ながら、改めてRedmineの機能の使い道に気づいたのでメモ。

【元ネタ1】
Twitter / @uchiunyo: 取り敢えずZabbixに関わらず全監視ツールからのメールをRedmineで自動登録する事によるインシデント管理の自動化、可視化。問題管理も扱えるよねと言う所まで妄想した。

Twitter / @uchiunyo: Redmineってメールでチケット登録出来るのか。これってめっちゃ素敵やん?

メールによるチケットの登録 - Redmine

メールによるチケットの登録 | Redmine.JP

Redmine for ITIL: プログラマの思索

メールでRedmineチケットを登録する機能の可能性: プログラマの思索

Redmineでは受信メールからチケット登録する機能があ。
この機能を使って、サーバー監視ツールから障害検知メールを発行してRedmineにチケットを自動登録する方法がある。
一度チケットに登録すれば、バグのワークフロー管理ができるし、チケットにすべての作業履歴が集約されるので、検索もしやすいし、追跡もしやすい。
蓄積されたバグチケットを集計して傾向分析もできる。

特にインシデント管理では、顧客の問合せや障害の集計結果からの傾向分析が重要だ。
品質管理の分野では、「1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在する」というハインリッヒの法則なる経験則が既に知られている。

ハインリッヒの法則 - Wikipedia

サーバー監視ツールが、単なる軽微なエラー検知をしてくれたとしても、その件数が多い場合、重大な事故につながる予兆があるかもしれない。
特にソフトウェアは常に機能改善という名の下にどんどん手を入れて変化していくので、品質が劣化しやすい。
バグ修正したはずなのに、新たなバグを埋め込んでしまったという経験はないだろうか?
だから、軽微な障害や問合せの集計結果から、サーバーがダウンするような重大なリスクを早めに嗅ぎ取るようにしたいものだ。

【元ネタ2】
既存リポジトリをプロジェクトで利用する | Redmine.JP

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

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

Redmineで空のリポジトリを登録する時は問題ないが、既存リポジトリのリビジョンが1千以上を超えている場合、リポジトリを登録するとRedmineがタイムアウトしてダウンしてしまう時がある。
例えば、従来のBTSからRedmineへ移行した場合、既存リポジトリが膨れ上がっている時が多く、リポジトリを登録するとタイムアウトしてダウンしてしまう現象は何度も経験した。
そのため、リポジトリの登録を諦めてしまった時もあった。
すると、No Ticket, No Commitのルールを運用できず、単なるタスク管理にしかRedmineを使えない片肺飛行の運用の時もあった。

だが、上記の記事によれば、既存リポジトリを設定する場合、リポジトリからの情報の取得をオフラインで行う手法があるとのこと。

ruby script/runner "Repository.fetch_changesets" -e production (すべての有効なプロジェクトのチェンジセットを取得)
または
http://redmine.example.com/sys/fetch_changesets?key=&id=foo (指定したプロジェクト(例:foo)のみチェンジセットを取得)

この手法を使えば、巨大な既存リポジトリも、後から登録することが出来る。
つまり、この手法はリポジトリ情報の登録をバッチ処理化したものと思える。

すると、RedmineによるSCM連携で、Jenkinsから上記のコマンドを叩けば、定期的にリポジトリ情報をRedmineへ登録することも可能のはず。
そのアイデアは下記に書いた。

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

リポジトリ情報をDBに登録するバッチ処理は、メトリクス集計ツールでは非常に重要な機能であるが、従来はこの機能の実現が大変だったという事情がある。
一度、DBにリポジトリ情報を登録出来れば、いろんな操作でいくらでも多種多様なメトリクスを計算することが可能になる。

Jenkinsをメトリクス収集ツールとして使うアイデア: プログラマの思索

Redmineには単なるチケット駆動開発のインフラだけでなく、ITILと組み合わせたインシデント管理も可能だし、メトリクス収集&集計のツールでもあり、多種多様な顔を持つ。
色々考えてみる。

| | コメント (0)

2012/04/18

Jenkinsをメトリクス収集ツールとして使うアイデア

Jenkinsは単なるビルド管理ツールではなく、強力なメトリクス収集ツールなのだ、というアイデアについて考えたことをメモ。
ラフなメモ書き。

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

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

チケット駆動開発とJenkinsの連携: プログラマの思索

「Hudson」改め「Jenkins」で始めるCI(継続的インテグレーション)入門 (3/4) - @IT

「Hudson」改め「Jenkins」で始めるCI(継続的インテグレーション)入門 (4/4) - @IT

Jenkinsをたった1コマンドで公開用Mavenリポジトリにしてしまう方法 #jenkinsja | 世界のdaipresents

【1】継続的インテグレーション(CI)というアイデアは、本来、プログラムから動くモジュールへビルドする作業を自動化することから生まれた。
CIは常時統合とも呼ばれ、コミットと同時にユニットテストもしてビルドして、リリース可能なモジュールを作る作業になる。

JenkinsのようなCIツールはSCMリポジトリをインプットとして、ビルドモジュールをアウトプットにするだけでなく、ユニットテスト結果やLOC、ソフトウェア複雑度などの単体テストレポートもアウトプットとして出力する。
すなわち、JenkinsはSCMリポジトリからプログラムのメトリクス(LOC、ユニットテスト結果、複雑度など)を出力するツールとして代用することも可能。

【2】何故メトリクスを収集するのが重要なのか?
何故メトリクスを収集するのが従来は難しかったのか?

WF型開発や日本の従来の品質管理では、安定したプロセスを基盤として、各工程のメトリクスを収集して品質管理を行うことで、高い品質を保持していた。
信頼度成長曲線や管理図、ヒストグラムなどがそれに当たるだろう。
メトリクスに関しては、日本では品質管理の技法として既にたくさんのノウハウがある。

だが、ソフトウェア開発では、製造業とは違ってメトリクス収集が非常に難しい。
メトリクスを収集するプログラムそのものを作りこまないといけないし、定期的にメトリクスを開発者に報告させるようにすると、開発者に負担がかかる。

Jenkinsの特長 - メトリクス収集サーバの視点から -: ソフトウェアさかばの記事にその苦労が書かれているけれども、メトリクス収集ツールのインストールだけでも大変だし、メトリクスの元ネタとなるデータの入力も手間がかかるし、定期的に収集する手間もかかる。

【3】Jenkisの機能はビルド管理が一番の特徴だが、メトリクス収集ツールの特徴としていくつか面白い点がある。
一つは、高機能なCronであること。
Jenkinsには、SCMリポジトリを設定する画面で「SCMをポーリング」というチェックボックスがあり、Cronの形式で入力すれば、定期的にSCMリポジトリからチェックアウトしてジョブを実施する仕組みがある。
本来は定期的にビルドする仕組みなのだが、1時間または1日1回SCMリポジトリからメトリクスを集計する仕組みに応用できる。
つまり、ポーリング機能として使えるし、イベントフックのように使ってもいい。
このCronの機能をプログラムで一から作りこむのは車輪の再発明であり無駄。
むしろJenkinsを流用した方がGUIで制御できて楽だし、たくさんの機能を使うこともできる。

2つ目は、ビルドパイプラインを使ってジョブを組み合わせてバッチ処理のようにできること。
つまり、複雑な処理を分割して、ジョブフロー図のように処理をUnixのパイプのようにつなげれば、複雑な集計処理を実装することが可能。
更には、集計バッチ処理を並列処理にすれば、処理時間を半減できるから性能改善も可能。
業務システムのバッチ処理の設計技法を使えば、メトリクス集計のバッチ処理は会計のバッチ処理のように設計できるはずだ。

3つ目は、多種多様なビルド結果をリアルタイムに表示する機能があること。
Jenkinsでは、ビルド結果の履歴を時系列に表示したり、単体テスト結果だけでなくコードカバレッジを表示したり、静的コード解析ツールを入れておけば例えばCheckStyleやFindBugsなどのメトリクスも表示してくれる。
つまり、SCMリポジトリを指定しておけば、好きなだけいくらでもメトリクスを集計して表示してくれる仕掛けがある。
複雑度と単体テストケース数の相関関係: プログラマの思索の記事に書いたけれど、ソフトウェア複雑度と単体テストケース数には密接な関係があるので、その知識を使えば、テスト駆動開発におけるテストケース作成に応用できるだろう。
そもそもソフトウェア複雑度が30を超えるようなプログラムは、リファクタリングするよりも、処理をメソッド抽出で分割するか、一から作り直す方が品質が良くなるはずだ。

4つ目は、AntやMavenのようなビルドスクリプトを使えば、メトリクス集計のプログラムをキックしたり、組み合わせる処理が簡単に書けること。
AntやMavenはビルドするために必要なライブラリを取得したり、プログラムをビルドするために使うけれども、メトリクス集計のプログラムを呼び出したり、メトリクスの出力フォーマットを指定する処理へ適用することも可能。

JenkinsはSVN・Mercurial・GitのようなSCMリポジトリをインプットにするが、RedmineやTracのようなITSのDBもインプットに入れれば、ITSのDBからデータをロードしてバッチ処理を行うことも可能のはずだ。
ITSのチケット集計機能はリアルタイムな集計しかできないけれども、そのようなアイデアを実現出来れば、バッチ処理を行う集計結果も可能になる。
バッチ処理を行う集計結果としては、会計の締め処理のように、週次・月次のようなある一定期間でのバグや進捗に関するメトリクスがあげられる。
例えば、週次・月次でのEVMによる集計があげられるだろう。

これらのJenkinsの特徴をうまく利用して、高機能なメトリクス収集ツールとして実現して、チケット駆動開発を強化することができないか?
色々考えてみる。

| | コメント (0)

チケット駆動開発の適用範囲part4~ウォーターフォール型開発への部分適用の注意点

以前のJSOLさんのTiDDの運用事例の記事を読み直してみて、自分の理解不足の面があったのでメモ。
ラフなメモ書き。

【元ネタ】
「チケット駆動開発」の適用について考える|コラム「ITよもやま話」|特集│株式会社JSOL

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

チケット駆動開発の適用範囲: プログラマの思索

チケット駆動開発の戦略: プログラマの思索

裏プロセスは並行プロセス: プログラマの思索

「現状のソフトウェア開発は間違っていないか?」(プロセス編) - @IT自分戦略研究所

繰り返し開発の罠: プログラマの思索

段階リリースとアジャイルリリーストレイン: プログラマの思索

WF型開発におけるプロマネのテクニック: プログラマの思索

僕は、チケット駆動開発をアジャイル開発へいかに適用するか、という問題意識しなかったので、従来型の開発やWF型開発への適用はあまり考えていなかった。
上記の記事を読むと、WF型開発に特有の課題に対して、チケット駆動開発をどのようように適用したら効果的なのか、という点をよく研究されているという印象を持った。

「チケット駆動開発」の適用について考える|コラム「ITよもやま話」|特集│株式会社JSOLの記事では、主に二つの課題、(1)ウォーターフォール開発でも内部にある小さな開発サイクルでの適用と、(2)プログラム改訂に関係するタスク以外のタスクや情報のチケット管理に適用した話が載っている。

(1)が意味することは、WF型開発でも短期間の開発サイクルの作業が存在しており、その作業にチケット駆動開発を適用しようとすること。
実際、要件定義、設計、実装、単体テストという工程が終わった後、ビッグバン結合で初めて大きな問題が次々に判明し、障害という名の元で短い開発サイクルの作業が生まれる。
その作業は障害管理に過ぎないけれども、障害をチケットに起票するのが起点となり、修正、レビュー、テスト、自動テスト、ビルド、リリースという一連の流れが全てチケットに作業履歴として残る。
だから、チケットにすべての情報が集約されるので、関係者同士の情報共有が楽になるし、SVNやGitなどの構成管理やJenkinsのようなビルド管理とRedmineを連携すれば、より強力に早く開発できる。

また、(2)では、設計書のレビューなどもチケットに作業履歴を残すことで、レビューの品質をあげようとする目的が示されている。

だが、(1)(2)の本当の問題点は、要件定義や設計、開発、テストの各工程で、一連の短い開発サイクルという裏プロセスが存在することにある。
WF型開発の定義では、前工程が完全に終了して次の工程に成果物が渡るので、手戻り作業や反復作業は基本ありえない。
しかし、実際の現場では、そんな綺麗事で開発できるわけがないし、リスクが高い。
だから、経験のあるプロマネは、裏プロセスという技を取る。

萩本さんの記事「「現状のソフトウェア開発は間違っていないか?」(プロセス編) - @IT自分戦略研究所」に書かれているけれど、要件定義・設計などの各工程で、PDCAサイクルを裏で回してリスクヘッジしているが、表に出さないようにプロセスを回す。

特に上流工程のPDCAサイクルは、実験的なアプリを作って画面イメージをすりあわせるプロトタイプという手法をよく取るがそれに当たる。
だが、プロトタイプはあくまでも暫定的なアプリのため、開発工程では結局一から作り直す場合も多い。
つまり、アジャイル開発における小規模リリースとは性質が全く違う。

そういう要件の検証、アーキテクチャ検証をあらかじめ実施するプロセスがあるのだが、教科書通りのWF型開発ではその認識が漏れていて、各プロジェクト独自のプロセスになりがち。
その裏プロセスを表に出すと、特に大手SIが自社で定めている開発標準とずれてしまうため、表に出さないようにわざわざする場合も多い。
だから、裏プロセスと呼ばれるわけだ。

また、別の手段として、段階リリースという方法もよく取る。
段階リリースとは、WF型開発において、サブシステム単位に複数回のWF型開発を回すこと。
大規模システムですべての機能を設計した後に開発して結合テストを実施するのはとても危険なので、意味のある業務の単位でシステムを分割し、その単位で段階的にリリースしていくプロセスを指す。
ビッグバン結合というリスクを回避するために、システムのサイズを小さくしてテストしてリリースするわけだ。

その意味ではアジャイル開発のイテレーションやスプリントの概念に似ているけれども、性質は全く違う。
イテレーションは2~4週間の定期的な開発サイクルであり、段階リリースではリリースサイクルは1ヶ月の時もあれば3ヶ月の時もあり不定期だ。
更に、イテレーション期間中は計画の変更は現状に合わせて行われるし、設計・開発・テストは並行して作業するのに対し、段階リリースの期間中はミニWF型開発なので、設計・開発・テストの工程の順に進んでいく。
だから段階リリースと言っても、結局はWF型開発であるからには最後のリリースにしわ寄せが来る。

そういう弱点がWF型開発には根本的にあるけれども、チケット駆動開発の恩恵は確かにある。
@sakaba37さんは、AdaptableWFと呼んで、WF型開発への部分適用でも十分な効果があると言われている。
とはいえ、WF型開発への適用は、WF型開発の特徴から来る根本的な問題をよく考えてみることが大事なように思う。

| | コメント (0)

2012/04/17

Redmine1.4におけるNo Ticket, No Commitの強化

Redmine1.4の機能改善において、No Ticket, No Commitの強化につながる機能があったのでメモ。

【元ネタ】
Redmine 1.4新機能紹介: チケットとリビジョンの関連づけの追加・削除 | Redmine.JP Blog

Twitter / @mkinside82: ほんとにCommit Relation Editor Pluginそっくりですね/Redmine 1.4新機能紹介: チケットとリビジョンの関連づけの追加・削除 | Redmine.JP Blog

Twitter / @mkinside82: Commit Relation Editor - Plugins - Redmine

Twitter / @mkinside82: @akipii もともとチケットが上がっていたようですね ⇒ http://bit.ly/HPLVM5 @haru_iida さんのCommit Relation Editor プラグインを使わさせて頂いてるのでUIがそっくりなのに驚きましたw

チケット駆動開発の基本ルールは@machuさんが提唱された「No Ticket, No Commit」にある。
この運用ルールは本来、障害管理において、どの障害に対してソースの修正がなされたのか、その修正履歴とバグチケットを紐づける運用から生まれた。
そこから、「チケット無しでソースのコミット不可」の運用ルールとなり、チケット駆動開発では、成果物の変更があったら必ずチケットに作業履歴を残す運用へ発展していく。
つまり、「No Ticket, No Commit」は成果物の変更のトレーサビリティを保証してくれる非常に重要な運用ルール。
この運用ルールがあるからこそ、開発者は変更管理を意識しなくても、変更管理を厳格に運用できる。

しかし、コミット時にチケットのNoを間違えたり、他のチケットNoも追加したくなる場合は多い。
GitやMercurialがコミット履歴の改変を行える方向へ進化したように、チケットとソースの紐づけも後から修正できるようにしたいと思うのはとても自然だ。
Mercurialの黒魔術: プログラマの思索でも書いたように、マージ作業のUndoやRedoができるればマージ作業の修正ミスを恐れることなくマージ作業ができる。
同様に、チケットと成果物のトレーサビリティの保証も、RedoやUndoができれば、BTSにたまったチケットのデータを保守することで、意味ある作業情報を蓄積できるようになる。

既に@haru_iidaさんが Commit Relation Editor pluginを公開されていたが、その機能とRedmine本家の機能がほとんど同じらしい。
記事を読む限り、画面UIはとても使いやすそうだ。

こういう細かい機能改善が積み重なることによって、ツールが使いやすくなるだけでなく、ソフトウェア開発のベストプラクティスがツールの1機能として実現されていくのだろう。
それによって、ツールの運用に慣れれば、自然にソフトウェア開発の良い習慣が身につくようになるのだろう。
更に、世の中の問題をできるだけソフトウェアで解決できる問題へ変換することによって、プログラマが活躍できる場が増えていくのだろう。

Redmineの機能はまだまだ進化する余地がたくさんあるように思う。

| | コメント (0)

2012/04/16

Mercurialの黒魔術

Mercurialで過去のコミット履歴を改変するやり方が書かれたBlogを見つけたのでメモ。
とても面白い。
Gitも同様にできる。

【元ネタ】
Mercurialでアレを元に戻す108の方法 - TIM Labs

gitでアレを元に戻す108の方法 - TIM Labs

gitで一度行った変更をなかったことにする方法4つ - TIM Labs

TortoiseHgを入れれば、hgコマンドを叩くとすぐにMercurialをコマンドベースで操作できる。
mercurial.iniにrebase, strip, transplantなど数々のExtensionを追加すれば、いろんな操作が可能になる。

一度コミットしたリポジトリに対して、コミット履歴を改変したい理由は、マージしたものの何らかの理由で間違っていて消したかったり、元に戻したい時があるからだろう。
つまり、頻繁にマージ作業が発生する場合、一度コミットしたソースを取り消したりなかったことにしたい時がある。
すなわち、マージ作業のUndoやRedoを行うための操作に相当するだろう。

そもそもバージョン管理とは、ソース修正のUndo、Redoを行うためにソース修正履歴を保持する仕組み。
だから、マージ作業でもその考え方を適用するのはとても自然だ。
マージ作業のUndo、Redoが行えるならば、たとえ間違っても修正可能だから、自信を持ってマージできる。

これらのコマンドは一人の作業ではあまり使わないかもしれないが、マージ作業が普通に発生する場合ではとても重要になるだろう。
すなわち、trunkとリリースブランチの2本の並行開発や製品ファミリー開発のようなソフトウェアプロダクトラインでは、MercurialやGitのようにマージ作業をサポートするツールが今後必須になっていくだろうと思う。

色々試してみる。

| | コメント (0)

2012/04/14

Redmine 1.4.0 released !

ついにRedmineの待望のVer1.4.0がリリースされた。

【元ネタ】
Redmine 1.3.3 and 1.4.0 released - Redmine

Twitter / @naitoh: #Redmine 1.4.0 リリース http://bit.ly/HR0SPj 新機能は1プロジェクトでのマルチSCM、wiki PDF一括出力、Ruby 1.9 & JRuby サポート!あとBundlerサポートによりインストールが劇的に楽になってます。おめでとう!

(引用開始)
Redmine 1.4.0 is the new feature release. Here are the highlights:
・Support for multiple SCM per project
・Multiselect custom fields
・Redesigned and merged copy/duplicate and edit/move functionalities for issues
・Better handling of issue update conflict and uploaded attachments on failure
・Next/Previous navigation links on issues
・REST API: project members management, attachments upload
・Official ruby 1.9 and jruby support
You can review all the 46 features and improvements of this new release on the Changelog. Enjoy!
(引用終了)

何と言っても、Ruby1.9に正式対応したことが一番の目玉だろう。
Redmine1.4.0で待望のRuby1.9サポート: プログラマの思索にも書いたけれども、Ruby1.8.7のサポートが2013年には終了してしまうため、Ruby1.9への対応は重要な作業だった。

僕もRedmineはVer0.6の頃から使っているが、Ver1.3.2までのバージョンでは、従来の環境のままバージョンアップしても移行作業はとてもスムーズにできた。
Railsというフレームワークでは、DBのスキーマ構造をアプリ内部で履歴として保持しているため、マイグレーションも恐れることはあまりない。
また、Railsのディレクトリ構造やソースそのものも分かりやすいので、Rubyの勉強にもなる。

但し、RedmineプラグインがVer1.4.0で正常動作しない可能性が下記の記事で指摘されている。
Redmine本体だけで運用しているなら問題無いだろうが、普通はプラグインで機能拡張しているだろうから、プラグインも含めたRedmineを移行するのは注意が必要だろう。

Redmine 1.4.0 もうすぐリリース。大量のプラグインが動作しない可能性あり | プログラマーズ雑記帳

残る課題といえば、Rails3対応だろう。
ロードマップを見るとVer2.0で予定されているようだ。

とはいえ、RedmineがVer1.4.0でRuby1.9に対応したことで、新しい局面に入ったと言える。
今回のVerUpによって、RedmineはRubyのキラーアプリとして、そして先進的なプロジェクト管理の手法を試すアプリとして今後も使われていくだろうと思う。

| | コメント (0)

チケット駆動開発はApplication Lifecycle Managementを目指す

Application Lifecycle Managementに関して、MSが公開しているVisualStudioの資料が分かりやすかったのでメモ。

【元ネタ】
Visual Studio ホワイトペーパー

Visual Studio vNext: アプリケーション ライフサイクル管理

アジリティ (俊敏性) 向上のためのツール(ケント・ベック)

アプリケーション・ライフサイクル・マネジメント - Wikipedia

アプリケーション・ライフサイクル・マネジメント(ALM)は、ソフトウェアの開発や保守を含めた全体のライフサイクルをツールで継続的にサポートする考え方と僕は理解している。
MSのTFS、IBMのRational製品がALMを実現した有償ツールになるだろう。
もちろん、Redmineによるチケット駆動開発にもALMの考え方を適用することもできる。

ケント・ベックのホワイトペーパーでも、時速10キロの馬から時速100キロの車に移動手段が変わったことによって移動速度の向上が移動に関する人々の考え方や価値観を変えてしまったことを例にして、年1回のリリースが1ヶ月に1回、更には1日1回のリリースに変わると開発プロセスも抜本的に変わってしまうことを示唆している。
ツールが人々の考え方や価値観を大きく変えてしまうわけだ。
アジャイル開発は単にウォーターフォール型開発を発展させたものではなく、むしろ両者は質的に断絶している。

すると、報告のジレンマの話のように、リーダーだけでなく開発者の管理業務も大きくコストがかかっているのが分かってくる。
だから、自分がどのような作業をしているのか、逐一報告するのではなく、ツールに報告させるような形へ進化するだろう、と。
チケット駆動開発のようなツールは、チケットという媒体から緩やかに作業ログを収集して進捗レポートを出力する機能があるがまさにそれに当たる。

これは作業の透明化につながる。
自分自身が報告しなくても、周囲の誰でも自分の作業進捗が分かるし、逆に自分も他人の作業進捗が分かるからだ。
作業の透明化によって、情報共有が促進され、コミュニケーションが活性化する組織的効果も出る。
互いの役割を超えて自由に議論できる雰囲気が生まれれば、様々な問題解決で多様なリソースを使いやすくなるだろう。
朝会やふりかえりなどプロジェクトファシリテーションのプラクティスを連携させれば、より効果的になるだろう。

同様に、継続的デリバリーも、リリースサイクルが年1回から数分に1回へ質的に変わった現象から発生した概念と捉えることもできる。

色々考えてみる。

| | コメント (0)

GitコードレビューツールGerrit

GitコードレビューツールGerritの情報をリンクしておく。
以下ラフなメモ書き。

【元ネタ】
Gerritを約1年運用してみて | ちとろぐ

Lhaz開発課 - ちとらソフト開発部

gerrit - Gerrit Code Review - Google Project Hosting

Google製のGit用ソースコードレビューシステム「Gerrit」 - MOONGIFT|オープンソース・ソフトウェア紹介を軸としたITエンジニア、Webデザイナー向けブログ

Twiwt:Blog / jugyo : 僕が Gerrit について理解している数少ないこと

Jenkins Gerrit Trigger Plugin の使い方 | Aiming 開発者ブログ

GerritはGitだけのためのコードレビューツール。
上記の記事の感想で面白い点は、addやcommitのような基本的コマンドだけでなく、rebaseやmergeなどのGitコマンドの使い方が分かったという点。

トピックブランチ上で修正したパッチがコードレビューされてOKの後、trunkへマージされる時に、どのような方法でマージすべきなのか?
コンフリクトが起きた場合、rebaseを使えば過去の修正履歴も保持したままturnkの最新の修正履歴も反映させてマージしてくれる。
Mercurialでもrebaseはあるし、mqやtransplantのようにMercurial特有のコマンドもある。
この辺りの機能は、複数のブランチを保守しながら開発していく並行開発で必要。
特に、基本的な仕様は似通っているが細部の仕様が微妙に違う製品ファミリーの開発、組込製品の派生開発で重要なテクニックになるだろうと思う。

Gerritで興味深いのは、コードレビューのステータスとして、+1 Verified,+2 Looks good to me, approvedがあること。
単にパッチが動くものだけではなく、ソースとして綺麗だよ、と言うレベルまでレビューできるか?

Jenkins+Git+Gerritを連携させた仕組みも興味深い。
チケット駆動開発とJenkinsの連携: プログラマの思索にも書いたけれども、turnkへトピックブランチで作ったパッチをマージさせたら、自動テスト・ビルド・デプロイまでの一連の流れを自動化した方が楽だ。
これがビルドパイプラインの考え方であり、継続的デリバリーの概念へつながっていく。

色々考えてみる。

| | コメント (0)

2012/04/12

電子教科書や電子雑誌を作る方法

AppleのiBooks AuthorやGoogleカレントなどの電子書籍アプリに興味を引いたのでメモ。

【元ネタ】
Flipboardの強力なライバルに?:Google、電子雑誌アプリ「Googleカレント」を日本でも公開 - 電子書籍情報が満載! eBook USER

Twitter / @akipii: メルマガは電子書籍になるべきなのか RT @WandLT: メルマガ取り始めたんだけど、EPUB見やすいねー。普通の携帯に届くの見づらすぎて、読むきになれないもん。

電子書籍作成ツールまで無料:今度は“教科書を再発明”――Apple、「iBooks 2」「iBooks Author」「iTunes U」アプリ発表 - ITmedia +D PC USER

アップルの電子本作成ツール『iBooks Author』のココが○! ココが△!

iBooks Authorで電子書籍の未来は変わる?!日本市場でiBooksを公開する方法 | Chrome Life

紙の本を電子書籍にするよりも、メルマガや週刊誌、漫画を電子書籍にしたほうがいいと思う。
メルマガはメールを頻繁に使う人には良いが、むしろepubにすべきではないのか?
細切れの文書よりも、まとまった電子媒体の方が、過去の記事も読めるし、気になった文章を後から全文検索できる。
そもそもメルマガは文章だけだし、文章の量も少ないから、epubにしてPodcastingのように配布した方が使いやすいはず。

そんなことを考えると、現代は普通の人でも自分が編集者の雑誌を作れる時代なのだと思う。
自分に興味のある記事を書いて、毎週毎月、定期的に雑誌をネットで配布する。
iPhone・iPod touch・iPadのようなクライアントがこれだけ普及しているのだから、コンテンツの質が良ければ読んでくれる。
世に出回るフリーペーパーは1千~5万部までマチマチだが、電子書籍なら配布コストはゼロ。
読者層が多いほど、その雑誌はたくさんの人に影響させる力がある。

同様に、自分が編集者の電子教科書も作ることもできる。
epubならJavaScriptも入れることができるから、インタラクティブなユーザインターフェイスを作り込むことも可能。
特に、物理や生物のような自然科学系が向いているかもしれない。

すると、出版社や雑誌を作る会社から製本して配布するという物理的インフラは消えて、良い本や雑誌を作るという本来の役割に特化していくだろう。
それは、出版コンサルティングみたいな役割。
つまり、本の企画、コンテンツの収集、原稿の書き方など、良い本を書くための役割に特化していく。
逆に言えば、1千~1万字の記事を書く能力が優れている人は、電子書籍として配布するインフラがあるのだから、すぐに作家になれるわけだ。

HPやBlog、Wikiも良いけれども、まとまった電子媒体を配布することは、政治的にも大きな影響力があると思う。
色々考えてみる。

| | コメント (0)

Redmine運用の感想を集めてみた

Twitterを眺めていたら、Redmine運用の感想が目を引いたのでメモ。

【元ネタ1】
Twitter / @polo_kwsk: Redmineが優秀すぎる・・・普通にソフト会社に開発させたらウン千万取られるところだ・・・PJ管理インシデント管理その他もろもろ使えるいいオープンソースソフトやでぇ。社畜SEさんにもおすすめ。

Twitter / @Sean_SF: そういうのってホントにあるんだなぁ? RT @sonoyu670 あるお客さんのところでは「それredmineでええやん」という使い勝手の悪い独自のPJ管理システムを持ってて、これウン千万とかかけて作ったんだろうな、馬鹿だな、って思ってた。

フリーのBTSがまだ普及していない頃、障害管理やタスク管理の重要性に気づいた会社は独自でBTSやITSを作り込んでいた。
そういう会社は先見の明があったに違いない。
だが、長年使ってくると、オープンソースのBTSやITSの方が普及してかつ高機能になって、逆に足枷になっている場合が見られる。
システムを長く使うのか、それとも新しいシステムにリプレースして移行するのか、判断が難しい。

【元ネタ2】
Twitter / @process_ok:Redmine を使い始めてすぐに気づいたこと。 やっぱり、チケットの発行単位とか、報告ルールとか、メトリクスの設定とか、マネジメントの本質的な価値の部分はツールだけでは決まらないので、自分で決めなくてはいけない、ということ。運用次第で、使えるツールにもゴミにもなる。

Twitter / @process_ok: あと、Redmineのようなツールが多彩な機能を持っているからと言って、それに引きずられて業務フローを考えるとか、ついやりたくなってしまうけど、危険危険。 あくまでやりたいことを先に書いた方が良い。

Twitter / @process_ok: たとえば、Redmineを使えばチケットを記入したり、ガントチャートを眺めたり、というのはすぐできるのだけど、それはあなたのマネジメント目的のどの部分に合っているのか、報告する必須の情報は何なのかを説明できないといずれ行き詰まると思う。

Twitter / @process_ok: それでも、きちんとしたツールがあれば、マネジメントはマネジメント本来の業務に集中することができるので、非常に助かる。さっき書いたのはツールがまともであれば発生する贅沢な悩みだ。

Remineのカスタマイズと運用 - satospo

RedmineやTracを上手に活用する6つのポイント ? Offside

小さなチームでの Redmine 運用で気をつけている 3 つのこと - Born Too Late

Redmineによるチケット駆動開発は、プログラマ上がりの現場リーダーのための開発プロセスだと思っている。
マネジメントの経験は少ないかもしれないが、手を動かす方が好き。
マネジメントで行き詰まる時は、技術力でカバーする方が多いだろう。

そんな状況で、ツールを使って進捗管理や課題管理、コスト管理、リスク管理などをフォローしていけば、自分なりのノウハウが色々貯められるだろうと思う。
既に、CMMI・PMBOK・ITIL・RUP・Scrumなど各種プロセスのベストプラクティスもアンチパターンも公開されているのだから、ツールを使って実際に試してみればいい。

すると、Redmineのようなツールはソフトウェア開発のERPのようなものだと思える。
開発チームという貴重なリソースをいかに有効活用して、顧客へ価値ある製品を届けるのか、という問題をソフトウェアで解いていく問題に置き換えてくれる。

Redmine導入はERP導入に似ている #tidd: プログラマの思索

ALMはSW開発のERPと同義: プログラマの思索

また、Redmineによるチケット駆動開発で面白い点は、ソフトウェア開発のタスク管理以外にも、課題管理・インシデント管理・ストーリー管理にも適用できること。
受託開発のタスク管理だけでなく、運用保守におけるインシデント管理、アジャイル開発のかんばんに似たストーリー管理も可能なのだ。
チケット入力の運用ルールさえしっかりしていれば、色んな観点のビューでプロジェクトの状況をモニタリングできる。

チケット駆動開発の適用範囲: プログラマの思索

チケット駆動開発の適用範囲Part2~チケット駆動開発の運用パターン: プログラマの思索

チケット駆動開発の適用範囲part3~ストーリー駆動のチケット駆動開発: プログラマの思索

他にも集めてみる。

| | コメント (0)

2012/04/11

チケット駆動開発とJenkinsの連携

Jenkinsは単なるCIツールではなく、高機能なCron以上のツールとして使えないか、思ったことをラフなメモ書き。

【元ネタ】
Subversion, Git, Redmine, Hudson ? 今考えている連携 ≫ tune web

Jenkins Gerrit Trigger Plugin の使い方 | Aiming 開発者ブログ

Jenkinsで1つのジョブで複数のGitリポジトリをビルドする方法 - Hirohiroの日記

JenkinsとGitとSpockで独り継続的インテグレーション - Naoki_Rinの学習 - 補助記憶領域

Redmineチケットにタスクを書いて、GitやMercurialへコミットしたとしよう。
その後、コードレビューしてOKなら、そのパッチをtrunkへマージして、即ビルドして製品を出力するようにしたい。
その時の仕掛けとして、パッチをtrunkへプッシュしたら、単体テストを通してビルドするようにしたい。
ビルドエラーが出れば、そのパッチはコミットされないようにしたい。

上記の記事を読むと、JenkinsのGitプラグインをうまく使えば可能らしい。
このやり方の利点は、開発者のトピックブランチ上で自由に開発してもらい、正式にパッチを取り込む時に自動ビルドしてtrunkへ取り込んでくれるようにしてくれること。
やはりtrunkへのマージ作業は手作業が多くて面倒だからだ。

Gerritというコードレビューツールも面白い。
ReviewBoardほど高機能ではないがお手軽に見える。

また、JenkinsのBuild Pipeline Pluginも面白い。
継続的デリバリー」にもビルドパイプラインという概念が出てくるけれど、それはまさにこのプラグインが実現する機能そのものだろう。
つまり、結合テスト・受入テスト・ビルド・デプロイ・リリースまでの作業を全てつなげたもの。
これは、バッチ処理のジョブフロー図に近い。
とすると、バッチ処理のジョブをJenkinsで制御するようにできないのか?という発想も出てくる。

色々考えてみる。

| | コメント (0)

アーキテクチャではトレードオフは避けられない

間違いだらけのソフトウェア・アーキテクチャ」を立ち読みして面白かったのでメモ。

【参考】
技評刊「間違いだらけのソフトウェア・アーキテクチャ」は面白い - Macテクノロジー研究所

書評「間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価」 データベースコンサルタントのノウハウちょい見せ

アーキテクチャーではトレードオフは避けられない - Strategic Choice

Peace Pipe: ソフトウェアアーキテクチャ その9 - アーキテクチャ設計の実際 [arch]

アーキテクチャをレビューする方法(ATAM) データベースコンサルタントのノウハウちょい見せ

宇宙人、SE、アジャイル教の教祖とか、皮肉っぽい登場人物との会話が面白い。
興味深かったのは、「アーキテクチャのインプットは非機能要求が必ず入る」「非機能要求は品質特性図から考えた方が分かりやすい」という指摘。
その手法として、ATAM(Architecture Tradeoff Analysis Method)やADD(Attribute Driven Design)という考え方がある、とのこと。

実は、「実践ソフトウェアアーキテクチャ」にATAMもADDも既に説明されている。
ATAMは、品質特性図というツリー状の要求分析によってシナリオを作りアーキテクチャを検証する。
ADDは「品質特性駆動型設計」の訳語の通り、品質特性からアーキテクチャを考えて設計していくこと。
これらの考え方はいずれもソフトウェアプロダクトライン、つまり製品系列の開発につながるのが意外だった。
おそらく、コア資産という共通部品や基本アーキテクチャを作るには、性能や汎用性などの可用性、保守性、移植性などの品質特性を考慮しなければ、作っても意味がないことを示唆しているのだろう。

ソフトウェアの品質は掴みどころがない。
品質といえば、信頼性の意味で捉えがちだが、性能要件という可用性(Availability)や保守性、移植性、使用性などたくさんある。
そこからシステムを考えるというやり方は、実はソフトウェア開発者は正直やっていないのではないか?

ソフトウェア品質特性

また読み直してみる。

| | コメント (0)

2012/04/07

コミットフックの強化方法

コミットフックを強化する方法が公開されているのでリンクしておく。
「No Ticket, No Commit」を強化するための方法なのでチケット駆動開発ではとても重要な設定になる。

【元ネタ1】
hg commitと同時にRedmineのリポジトリ情報を更新する - いろいろな何か

Mercurial のフックを利用して Redmine のチケット操作を自動化する (フェンリル | デベロッパーズブログ)

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

Mercurialでコミットする時に、SVNコミットの時と同様にRedmineのWebサービス機能を使えば、コミットフックしたらコミットログに書かれたチケットNoに自動リンクさせることができる。
小規模なチームならこの方法が一番お手軽だろう。

【元ネタ2】
TurtleMineプラグインを導入してTortoiseHGのコミットメッセージにRedmineのチケット内容を自動で入れる (フェンリル | デベロッパーズブログ)

redmine-projects - Home of Redmine programs and plugins - Google Project Hosting

InstallAndSetupSvn - turtlemine - Instructions on how to install and setup the plugin for use in Tortoise Svn. - Tortoise Redmine Plugin - Google Project Hosting

InstallAndSetupHg - redmine-projects - Instructions on how to install and setup the plugin for use with TortoiseHg. - Home of Redmine programs and plugins - Google Project Hosting

TortoiseSVNやTortoiseHgでコミットする時に、コミットログ画面からRedmineチケット一覧を表示してコミットログにチケットの概要を自動保管してくれる。
EclipseのMylynと同じ機能。
コミットする時に逐一ブラウザを開いてチケットを確認する必要がないので、楽になる。
TortoiseGitでも同様の機能があるらしい。

【元ネタ3】
Twitter / @mikoto20000: Gitのブランチ名からチケットに対応付けるプラグインRedmine Git Branch Hook Pluginをリリースしました。http://goo.gl/t8WHN

mikoto20000/redmine_git_branch_hook ・ GitHub

Gitのトピックブランチ上で修正したら、コミットログに書かれたブランチ名から該当のチケットNoへ自動リンクしてくれるらしい。
トピックブランチとチケットが1対1に対応するように運用していれば、コミットログを書くのが楽になる。
@LightningXさんも似たようなパッチを公開されている。

Twitter / @LightningX: gistで晒してみる。 http://bit.ly/HbDond RT @LightningX: Redmineをいじって、hoge-234というブランチにコミット/プッシュすると自動的に234のチケットに関連づけるパッチを作成してみた。

Redmine branch-ticket relation(like hoge-123 branch relate to ticket 123). ? Gist

Redmineによるタスクマネジメント実践技法」に書いたけれど、トピックブランチとチケット駆動開発はとても相性が良い。
トピックブランチを作るタイミングは普通はバグ修正や機能改善パッチなので、チケット1個に収まる作業量になりやすい。
GitやMercurialのように、各開発者のトピックブランチ上で修正後にtrunkへプッシュまたはリベースしてトピックブランチを廃止する運用が普通ならば、気持よくチケット駆動開発を運用できるだろう。

構成管理とチケット駆動開発の連携方法はまだまだ改善の余地がある。

【追記】
Gitでも、コミット時にRedmineチケット一覧を表示してチケットNoを補完してくれるパッチがある。

Twitter / @itmammoth: こりゃあ便利だ。チケット駆動開発に拍車がかかるぜ。 Git-Redmine: GitのコミットとRedmineを連携する。チケット駆動開発にも。 (ゆめ技:ゆめみスタッフブログ) http://yumewaza.yumemi.co.jp/2011/08/git-redmine-integration-using-rest-api-python.html.

gitとRedmineを連携: プログラマの思索

Git-Redmine: GitのコミットとRedmineを連携する。チケット駆動開発にも。 (ゆめ技:ゆめみスタッフブログ)

| | コメント (0)

チケット駆動開発の適用範囲part3~ストーリー駆動のチケット駆動開発

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

【元ネタ】
Twitter / @akipii: ストーリー駆動のチケット駆動開発はチケット管理以上に牛尾さんが提唱されたストーリー供給力とストーリー検証力の方が重要ではないかと最近考えている。ストーリーの整合性、実現可能性、ビジネス戦略の観点+PivotalTrackerのようなかんばんに近いアジャイル開発の組合せが多分ベスト

チケット駆動開発の適用範囲Part2~チケット駆動開発の運用パターン: プログラマの思索

【1】チケット駆動開発は本来はタスク管理から生まれたし、タスク駆動が一番やりやすい。
でも、チケット駆動開発の面白さは、課題管理やインシデント管理、ストーリー(要件)管理のように、他のやり方にも応用できる点にある。

ストーリー駆動の場合、チケットはストーリーカードと見なす。
実際の運用は、PivotalTrackerやそのRailsクローンFlucrumのように、顧客と開発者が一体になって、チケットを書き起こして作業してリリースしていく流れになるだろう。
そして、タスク駆動のチケット管理の運用ルールが「No Tikcet, No Work」なら、ストーリー駆動の場合は「No Ticket, No Release」(@kuranukiさん談)になる。
つまり、チケットにシステムに実装して欲しい機能を書かなければ、システムに反映されてリリースされないのだ。
顧客がリリースして欲しいと思うならば、まずチケットに書いてもらわないといけない。

【2】ストーリー駆動のチケット管理はまさに典型的なアジャイル開発だが、実際の運用はノウハウがなければ難しいだろうと思う。
その理由はいくつかある。
一つはチケットの粒度が大きいと、進捗管理がやりにくいこと。
この理由は下記に書いた。

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

アジャイルに開発したいなら、チケットの粒度は1人日以下になるように、ストーリーを細かく分割しておく必要があるだろう。
すると、ストーリーをそれだけ細かく分割できるくらい、システムや要件を知り尽くしていなければ、そもそも分割すらできないだろう。

2つ目は、アーキテクチャが安定しないと機能改善ではなく障害修正ばかりになってしまいがちなこと。
@Sean_SFさんが似たようなTwitterを述べられている。

Twitter / @Sean_SF: 「いわゆる「チケット駆動開発」はレベルが高い。チケットを発行してまわるぐらいアーキテクチャとプロセスが安定している必要がある。チケット駆動にしたからといってプロセスが安定するわけではない。運用、改善フェーズには良い」 #devsumiC

Webシステム開発の場合、RailsやSeasarなどのように強力なフレームワーク上で細かいUI改善や機能改善が主な作業になるので、ストーリー駆動の開発がやりやすい。
でも、アーキテクチャを一から作るプロジェクトの場合、共通部品がまず揃ってからの開発になる。
それら共通部品を使いながら機能を開発していくが、実際は開発しながら共通部品のバグを見つけたり、共通部品の使いにくい部分を改善してもらったりする場合が多いだろう。
すると、共通部品の修正が発生して、他チームや他の機能まで影響してしまい、プロジェクト全体の開発が遅延してしまいがちになる。
特に製品系列開発や派生開発のように、コア資産をベースに次々に似たような製品や機能を開発していく場合、共通部品やアーキテクチャの信頼性や保守性が高くなければ、ストーリー駆動のチケット駆動開発は安定しないだろう。

【3】3つ目は、ストーリーそのものの品質が悪ければ、思うように開発できないこと。
ストーリーは顧客観点で書かれた要件だから、開発者視点とは違う。
だが、その要件がシステムとして実現可能性があるかどうか吟味した上でストーリーを作るべき。
すると、一つの要件を実現するために、たくさんの要件が芋づる式に出てきたり、既存の機能に影響を与えてしまったりする場合が頻繁に出てくる。
牛尾さんは、AgileTourOsaka2010で「ストーリー供給力」「ストーリー検証力」というアイデアを発表されたが、まさにそういう事象を指していると考える。

Agile Tour 2010 Osakaで講演してきました - メソッド屋の日記

Agile開発に足りないもの~モデリング技術: プログラマの思索

つまり、イテレーションを実施するために必要なストーリーをイテレーション開始前に8割以上は出せるようにする。
この作業が「ストーリー供給力」であり、普通は最初のイテレーション(スパイク)で、実装はせずに要件定義を中心に作業する方法もあるだろう。
そして、供給されたストーリーの整合性を取り、システムとして実現可能かどうか、矛盾していないか、MECEになっているか、などの観点でストーリーを吟味して、ストーリーを整理していく。
この作業が「ストーリー検証力」であり、アーキテクトという役割の人が最も活躍する場でもある。

【4】最近は「アジャイルサムライ−達人開発者への道−」のように、アジャイル開発のノウハウが公開されて、誰でも試せるようになってきた。
ストーリー駆動のチケット駆動開発は多分難しいだろうが、本来のアジャイル開発に近いだけに、是非とも実施できると面白いだろうと思う。

| | コメント (0)

2012/04/05

チケット駆動開発のリズムとXPのリズムは似ている

オブジェクト倶楽部のXPの開発プロセスの図がとても分かりやすかったのでメモ。

【元ネタ】
- eXtreme programming FAQ
にある「エクストリームプログラミングの開発プロセスは?」の図

Comparison of issue tracking systems - Atlassianウェブサイト-ドキュメンテーション - アトラシアン ウィキに書いた「TiDDの運用サイクル」の図

XPの開発プロセスをプロジェクト・イテレーション・開発・コーディングの4つのタイミングでうまく図示している。
XPなどのアジャイル開発の特徴の一つが開発にリズムがあること。
その理由は、イテレーションが生み出すリズムがプロジェクト・開発・コーディングの断面でもリズムをもたらしていること。

同様に、チケット駆動開発にもリズムは発生する。
バージョンをXPのイテレーション、Scrumのスプリントのように扱えば、そこから開発のリズムが生まれる。
チケット駆動開発では、プロジェクト・イテレーション・1日(デイリー)・1作業(タスク)の断面でリズムがあり、それぞれの断面でITSを中心とした3種の神器が透過的にサポートしてくれる。

開発のリズムがあるからこそ、それに合わせて作業できて、XPの言う「持続可能な作業ペース」「週40時間労働」が実現される。
これがウォーターフォール型開発の場合、設計・開発・テストの工程を経るたびに作業負荷が増して、最後のリリースとリリース後の対応で作業がピークになる。

Scrumも似たような開発サイクルがある。

スクラム Visual Studio

チケット駆動開発もXPやScrumのように上手に理論化してみたい。

| | コメント (0)

Pandocのリンク

Haskellで書かれたPandocを使うと、テキストファイルからPDF・HTML・epubなどを出力できるらしいのでリンクしておく。

Markdown/HTML/LaTexを相互変換「Pandoc」 - MOONGIFT|オープンソース・ソフトウェア紹介を軸としたITエンジニア、Webデザイナー向けブログ

hon.jp DayWatch - EPUB電子書籍にも対応、関数プログラミング言語Haskellで書かれた万能ドキュメント変換コマンド「Pandoc」

Utotch Blog: Pandoc で Blogger の記事を書く

RadioAgeCom:ReVIEWとpandoc

pandoc - general markup converter - Google Project Hosting

かゆいところに手が届く? Pandoc | hexacosa.net

I can 'cause I think I can! - Pandocでxelatexを使って日本語を含むMarkdownをPDFにする

Pandoc - Pandoc User’s Guide

Pandoc - Creating an ebook with pandoc

CIツールと連携させれば、電子書籍を常時ビルドして出力できるようになるはず。

| | コメント (0)

2012/04/01

パターンランゲージの適用例

パターン、Wiki、XP」の本を読んでからパターン・ランゲージに興味をもつようになった。
パターン・ランゲージをプレゼンテーションや学習パターンに適用した事例を見つけたのでリンクしておく。

【元ネタ】
井庭崇のConcept Walk | 授業「パターンランゲージ」のグループワークで制作したパターンを冊子化

学習パターン (Learning Patterns)

プレゼンテーション・パターン (Presentation Patterns)

創造的プレゼンの秘訣を言語化した「プレゼンテーション・パターン」 - GIGAZINE

「プレゼンテーション・パターン」の反響 - Togetter

パターン言語事例 - 慶應SFCの『学習パターン』 - @IT情報マネジメント

パターン、Wiki、XPは良書: プログラマの思索

『パターン、Wiki、XP ? 時を超えた創造の原則』から感じた時を超えたソフトウェア開発の道 | daipresentsの世界

パターン・ランゲージの良い点は、現場の事例をボトムアップで抽象化し、他人に共有できる形式知へ変換できる点だと思う。
いわゆる経験知や暗黙知の内容を他人に説明する時に役立つと思う。
そして、パターンで表現されたベストプラクティスがどの問題に有効であり、他の問題で何故有効でないのか、という理由も明確に表現してくれる。
パターンは実例に基づくだけに大きな説得力がある利点もある。

上記の例では、プレゼンテーションや学習のパターンをピックアップしているが、MECEの観点から見れば、これだけでは不十分かもしれない。
でも、パターンを適用することでヒントや気づきが得られるだろう。
文章だけでなく、柔らかい絵も付いているので、想像力を働かせやすいし、年齢層を問わないだろう。

パターン・ランゲージは、単に経験知をパターン化するだけでなく、複数のパターンが有機的に作用する点も大きな特徴の一つ。
だから「生成的(generative)」というキーワードがよく出てくる。

- XPとパターン Ralph Johnson'sの見解にも下記のように書かれている。

(引用開始)
XP には「信頼性」や「理解容易性」に直 接関連するパターンが無いにも関わらず,「プラクティス」全体が結びついて, 信頼性が高く理解が容易なシステムを生成(generate)しています.
パターン同 様,一つ一つのプラクティスには名前があり,それ自身を学ぶこともできます.
パターン同様,プラクティス全体が結びつくことで,個々の単純な足し合 わせよりも大きな効果が得られるのです.そして,XP は極端にインタラクティブで,さらに,計画は可能な限り小さくなっています.
(中略)
Kent は,『デザインパターン』はパターンの創発的な特性を十分に強調していない,すなわち,生成的(generative)でないと考えました.
XP はこの点を より強く強調しています.
XP は1ダースのパターン(実際にはもっと多い)とし て知られるようになりましたが,「変更しやすさ」や「信頼性」に関して直接 の言及をしていないにも関わらず,パターンに従うことでこういった特性が生
成されるのです.
XP は長期のスケジュールをどちらかというと重視していな いにも関わらず,プロジェクトは進捗の予測可能性がより高く,予定通り出荷できる可能性もより高い,とXP支持者は言います.
(引用終了)

複数のパターンが組み合わさること(生成的(generative))で、より大きな目的が達成されることを示唆している。
実際、XPのプラクティス、Scrumのフレームワーク、アジャイル開発の多種のプラクティスを思い出せば、各プラクティスが相互作用して初めてアジャイルな特徴が出ている。

チケット駆動開発も同様だ。
「No Ticket, No Commit」「Ticket First」の基本プラクティスから「No Ticket, No Work」「Small Release」「No Ticket, No Release」のようなプラクティスが派生し、更にトレーサビリティやワークフロー管理、並行開発などの特徴も生まれて、個別プロジェクトの課題に適用できるような柔軟な仕組みが生まれている。
色々考えてみる。

| | コメント (0)

« 2012年3月 | トップページ | 2012年5月 »