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

2010年11月

2010/11/30

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

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

【元ネタ1】
少人数開発に役立つ5つのまとめ

(引用開始)
<チケット管理システムを正しく運用するための1記事と1冊>
チケット管理システムといえば、RedmineかTracです。
ここではRedmineを取り上げます。
バージョンのないRedmineプロジェクト~TiDD初心者が陥りやすい罠
Redmine導入時にやってしまいそうなことが、よくまとまっています。
導入は簡単です。
しかし、適切に運用するためにはそのツールで使っている用語の意味を知ることが大事です。
これを読んでから、Redmineの運用を始めると、よりRedmineを活用できるでしょう。
さらに、この記事でも紹介されていますが、こんな本も出ています。
今までRedmineに関する本はその導入の仕方や使い方がメインだったので、嬉しい一冊です。
(引用終了)

Blogと本を紹介して下さってありがとうございます。
RedmineやTracのインストールは簡単ですが、チケット駆動開発でSW開発のプロジェクト管理をサポートするには、ノウハウがまだ必要です。
Redmineによるタスクマネジメント実践技法」に今理解しているノウハウはすべて書き込んだつもりです。
今後は、この本の内容は当たり前になって、色んな人が他のベストプラクティスを見出していくだろうと思っています。

上記のBlogでは「体制を整えるための2記事」「バージョン管理システムを一新するための2記事と2アプリケーション」「テストを自動化するための3記事」など他の記事もとても興味深い。
特に下記の記事は、Gitによる構成管理のベストプラクティスを紹介してくれている。
後で感想をまとめる予定。

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

【元ネタ2】
Twitter / Stargazer: Redmineによるタスクマネジメント実践技法読了。いや素晴らしい。実践知の宝庫だった。今やってる仕事で早速試してみたい。しかしHudsonって日本発だったんだ、知らんかった。Hudsonのあたりももう少し掘り下げられてるとなお良かった。

ありがとうございます。
Hudsonは僕も単なるビルド管理でしか運用できてませんが、Hudsonにはもっとたくさんの可能性を秘めています。
個人的には、並行ビルド、環境の仮想化、Seleniumによるテストの自動化、ビルドエラーメールによるRedmineチケット登録などの使い方を、Redmineによるチケット駆動開発のように、ベストプラクティスとしてまとめたいです。

他にもあったら探してみる。

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

2010/11/28

ソフトウェアテスト技法ドリルの感想

秋山さんが執筆された「ソフトウェアテスト技法ドリル―テスト設計の考え方と実際」を読んでみた。
テストケース作成技法がとても実践的で、しかもフリーのツールを色々説明していて役立ちそうな感触を持った。
感想をメモ。

【元ネタ1】
【感想】ソフトウェアテスト技法ドリル/秋山浩一 - Software Quality Topics.

ソフトウェアテストの勉強室: ソフトウェアテスト

本棚3

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際」は、テストケース作成技法を初心者~中級者レベルに向けて書かれていると思われる。
同値分析、境界値分析の使い方から原因結果グラフ、HAYST法、ペアワイズ法など各種の技法が説明されている。
僕が興味を惹いたのは、原因結果グラフからデシジョンテーブルを生成するツールCEGTestと、ペアワイズ法によって組み合わせを生成するツールPictMasterの説明がとても詳しかったこと。
練習問題を解きながらツールを使うので、とても分かりやすい。

【元ネタ2】
CEGTest - 原因結果グラフからテスト条件を作成するツール

原因結果グラフによるテスト設計支援ツール - CEGTest: ソフトウェアテストの勉強室

(引用)
CEGTest(セグテスト)は、複雑な論理関係を持つソフトウェア・プログラムの組合せテスト条件作成を支援するツールです。本ツールを用いることで、従来ある程度の経験と知識が必要であったテスト技法「原因結果グラフ技法」を、ブラウザ/JavaScriptベースで直感的に実践することができます。また、成果物であるテスト条件に関する「デシジョンテーブル」は同時に自動生成されるため、作業者はソフトウェア対象・テストベースの分析に集中することができます。よって、本ツールを利用することで、より効果的・効率的なテスト設計が行えます。
原因結果グラフ技法はソフトウェア・プログラム仕様の分析や整理をするためにも用いられます。本ツールはテストエンジニアだけではなく、プログラマやソフトウェアエンジニアにも品質向上の一助になると考えています。

業務系ソフトではデシジョンテーブルがまさに仕様そのものであり、単体テストや結合テスト、受入テストのテストケースの元ネタになる。
デシジョンテーブルの使い道としては、システムの状態遷移表として扱ったり、たくさんのパラメータをインプットにしてテストする時があるだろう。
例えば、小売系Webシステムならば、会員・商品・注文の種類に応じて、注文結果をデシジョンテーブルで表現してテストケースを作る時が多いだろう。

だが、デシジョンテーブルの項目は、仕様を奥深く考えないと、間違いが起きやすい。
また、うまく考慮しないとすぐにケース数が発散してしまうので、使いこなすのは難しい。

原因結果グラフは、原因と結果を論理グラフとして表現したもの。
これをマトリクスに置き換えれば、デシジョンテーブルになる。

だから原因結果グラフを用いてグラフ化すれば分かりやすくなる。
しかし、原因結果グラフをきちんと書くのは難しい。

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際」にも書かれている「Meyersの三角形」の例のように、テストケースを作るのはそれなりの知識を必要とする。

株式会社アーツテック | テストとはどんな仕事だろう?

CEGTestは原因結果グラフをWeb上でお絵描きできてデシジョンテーブルを出力してくれるツール。
実際に使ってみると、HTML+JSだけだが、そのままでは結果が表示されない。
XAMPのhtdocsに配置後、URLにアクセスして、サンプルをインポートすると、結果が出る。

【元ネタ3】
ダウンロード - PictMaster - SourceForge.JP

組み合わせテストケース生成ツール 「PictMaster」 とソフトウェアテストの話題

特集:組み合わせテストをオールペア法でスピーディに!|gihyo.jp … 技術評論社

データパターンの組み合わせからテストケースを自動生成するツール: プログラマの思索

PICTで出力したテストケースをTestLinkへ取り込む: プログラマの思索

テストケースの作り方: プログラマの思索

PictMasterは、ペアワイズ法によるテストケース作成のためのExcelマクロ。
MSのPICTをベースに作られている。

以前から知っていたものの、マニュアルを読んでも使いづらかった。
ソフトウェアテスト技法ドリル―テスト設計の考え方と実際」を読んで、具体例を見て、ようやくイメージできた。

ペアワイズ法と比較されるテストケース作成技法として、直交表をベースとしたHAYST法もある。
下記にあるPDFが詳しい。

『HAYST法』の解説と学習
『HAYST法』の解説と学習

ペアワイズ法とHAYST法はそれぞれに長所と短所はある。
テストケースを作成する時に、因子(パラメータ)と水準(パラメータがとりうる値)をまず洗い出して、その組み合わせを考える。
しかし、禁則(実際にありえない組み合わせ)を考慮しなければ、いくら組み合わせを作っても、実際のテストケースでは実施不可能のケースが殆どを占めてしまう。
だから、禁則を考慮した組み合わせがペアワイズ法でもHAYST法でも重要なのだが、それをExcel上で手作業で行うのは至難の業。

特にHAYST法は理論として優れていても、フリーのツールが無いので、実際の現場では使えない。
ペアワイズ法の場合、PICTがフリーで提供されているので、禁則の使い方をマスターすれば、テストケース作成に使えるだろう。

要件から設計する時に、テストケースの作成も実施するようにすれば、W型モデルの開発になる。
仕様をプログラムの観点とテストケースの観点から見るようにすれば、特に異常系の漏れが少なくなるだろうと思う。

色々試してみたい。

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

2010/11/27

ツールを設計技法の一つとして使いたい

ツールをいくら使いこなせたとしても、開発がスムーズでなかったり、システムの品質が良くない時もある。
下記の記事を読んで考えた事をメモ。

【元ネタ】
テストツールとテスト設計意識: ソフトウェアテストの勉強室

状態の洗い出しへHAYST法かpairwise法の適用: ソフトウェアテストの勉強室

TestLink Home

TestLinkを使いこなせば、大人数でのテスト作業を効率化できる。
でも、それだけではシステムの品質は保証できない。

TestLinkを運用してみて、テストケース作成の技術がとても重要だと体で感じた。
いくらテストしても、テストケースでカバーしていない仕様は、結局バグの温床になる。
かと言って、テストケースをたくさん作っても、テストが納期までに終わらない。

リスクベースドテストでは、プロダクトリスクの高い機能やバグを先にテストするが、それだけでも不十分。
もう一段階上のテストケース作成技法が必要。
テストでは、網羅性が非常に重要。
だが、実際のテスト工数は限られれているので、有限のテスト工数でどれだけ質の高いテストケースでテストできるか、が重要になってくる。

テストケース作成の基本は、システムや業務フローの状態遷移図を一通りテストできるようにすること。
そのためには、状態を漏れなく重複無く洗い出し、状態遷移のフローを漏れなく洗い出す事が大事。
それは、設計技法そのものだ。

単に、顧客の要望を吸い取ってそのままプログラミングすればいい訳ではない。
矛盾無く整合性が取れたシステムを作るには、設計や実装で試行錯誤しながら、穴がないプログラムを作っていかなければならない。

テスト管理や品質管理は日本のお家芸とも言える技術。
この技術をテスト前の設計技法に組み込んで、ツールでサポートするようにしたい。

今はRubyやPythonなどの軽量言語で簡単にプログラムを書けるし、PHPやRailsで簡単にWebシステムを作れる。
直交表やPairwise法のアイデアをツールで実現して、テスト前の設計工程で、設計技法の品質を高めたい。
ExcelやPowerPointだけで設計できるものではないはずだ。

追記:
ソフトウェアテストの書籍は最近はたくさんある。
下記のリンクの解説はとても分かりやすいのでメモ。

参考文献

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

SVNのコミットログの書き方

SVNのコミットログの書き方について記事があったのでメモ。

【元ネタ】
コミットコメントの書き方(我流) - 地平線に行く

僕は下記のようなコメントをコミットログに書くように奨励している。

【変更理由】プルダウンに特定の項目が表示されないバグを修正
【チケット】 #1234

1行目は、ソースを何故修正したのか、一言で書き表す。
2行目はチケットNoを書く。

ソースの修正理由は、修正内容よりも、修正した理由をできるだけ書いた方がいい。
ソースを差分比較すれば修正内容は分かるので、理由が一言でもあれば、ソースを理解しやすくなる。

コミットログにチケットNoを書いておくと、RedmineやTracはチケットとバージョン管理をリンクしてくれるので、謎のコミットが減る。
チケットに修正の発端となった要望やバグの内容を書いておけば、コミットログから修正理由の詳細をチケットへ遷移することで探しやすくなる。

何よりも、ソースから「yyyyMMddに障害管理No.xxxxの修正をした」などの無駄なコメントが消えて、ソースが綺麗になる。

コミットログがきちんと書かれてないと、ライブラリアンがリリースする時や、他の人がバグ修正する時に困る。
書いた本人すら、何故こんな変な修正を施したのか、理由もすぐに忘れるから。

チケットとリンクしておけば、チケットにソース修正の発端となったバグや仕様変更、問合せが分かるので、同類バグ調査などがやりやすくなる。

まちゅさんは上記の運用ルールを「No Ticket, No Commit!」と呼んでいた。
この運用ルールに一度慣れてしまうと、コミットログにチケットNoを書かないシステムは怖くて触れなくなる。

バージョン管理を使う人は全員、この運用ルールに慣れて欲しいと思う。

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

TortoiseHgからBTSチケットへリンクできるようになった

TortoiseHgがTortoiseSVNと同様に、BTSのURLを設定しておけば、BTSチケットへリンクできるようになったのでメモ。

【元ネタ】
Better issue tracking with TortoiseHG and Kiln - Our Blog - Offroad Code - We make websites that work

TortoiseHgの設定画面で、Issue Tracking という項目が増えている。
Issue Tracking項目を開くと、ITS(BTS)のURLやチケットNoのリンクを設定できるようになっているので、ここに書けばよいようだ。
この方法を使えば、MercurialのコミットログからRedmine・Trac・MantisなどのBTSチケットへ簡単に連携できるようになる。

TortoiseSVNでは、下記の記事のようにBTSと連携する方法は既に知られていた。

ソフト/Bug Tracking/trac/TortoiseSVNやSubclipseとチケットを連動 - discypus

TortoiseHgもTortoiseSVNと同じように、VerUpするに従ってどんどん使い勝手が良くなっている。
個人的には、TortoiseHgはファイル毎の履歴表示が使いづらいのが唯一の欠点なので、改良して欲しいと思う。

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

2010/11/23

障害管理における重要度と優先度の使い分け

障害管理における優先度と重要度の使い分けについてメモ。

【元ネタ】
ふたたび、優先度と重要度と緊急度のお話:シェアウェア販売者の独り言:So-netブログ

バグの優先度は意思決定プロセスの結果: プログラマの思索

TestLinkを運用して気付いたことpart9~後追いテスト: プログラマの思索

レビュー計画

【連載】実践ソフトウェアテスト考現学 (12) テストの新たなアプローチ - 複数の視点の組み合わせ | エンタープライズ | マイコミジャーナル

はじめてのバグジラ ver2.16-ja編

TracTickets -- mi

障害管理では、重要度と優先度の項目がチケットに普通は付いている。
Mantisには重要度と優先度は元から付いている。
だが、Redmine・Tracには優先度だけで重要度は付いていない。

はじめてのバグジラ ver2.16-ja編では、重要度は下記のように書かれている。

Blocker 開発やテストが出来なくなるくらいに極めて重大なものです。
Critical クラッシュやデータの損失、メモリリークなどの重大なものです。
Major 機能が動かないなどの大きな欠陥があるものです。
Minor 小さな欠陥で、簡単な代替手段があるものです。
Trivial ミススペルや誤った文章などといった機能そのものの動作に影響を与えない、さほど重要ではないものです。
Enhancement 機能強化の要望です。

「Trac入門」の一節では、重要度と優先度の違いについてうまく説明されていた。
Tracでは優先度のみ付属しているが、開発チームの内部では、重要度を付けるべきかどうか議論があったらしい。

TracTickets -- miでは下記のように書かれている。

バージョン 0.9 以前の Trac では 分類 (Type) 属性がありませんでしたが、代わりに 重要度 (Severity) 属性が提供されており、 優先度 (Priority) 属性のデフォルトの値も異なっていました。この変更を行ったのは、やや不鮮明な 優先度 (Priority) と 重要度 (Severity) の区別を排除し、チケットモデルを簡素化するためです。しかしながら以前のチケットモデルも利用可能です

普通の開発チームは、優先度しか使わず、重要度は特に運用していないのではなかろうか?
僕の考えでは、重要度と優先度の使い方は下記になる。

重要度
→ユーザ、業務の観点
 利害関係者のレベル
  チーム内、プロジェクト内、会社内、顧客調整事項など
 ストーリーカード
 プロダクトリスク

優先度
→開発チーム、作業の観点
 作業の優先順位
  緊急(blocker)、普通、trivial
 タスクカード
 プロジェクトリスク

つまり、重要度はユーザの観点であり、利害関係者のレベルで付ければいい。
優先度は開発チームの観点であり、作業の優先順位として付ければいい。

Agile開発の観点では、重要度はストーリーカードの観点、優先度はタスクカードの観点から付ければいいだろう。
普通は重要度が高ければ優先度も高くなるが、必ずしもそのようなパターンに当てはまらない作業もありうる。
その時、重要度と優先度を組み合わせたマトリックスで障害やタスクを一覧化すれば、作業の優先順位が見えやすくなるだろう。

例えば、顧客の業務で重要な機能だが非常に稀な潜在バグがあると判明した場合、重要度は高いけれど優先度は低いバグに相当する。
この場合は、リリース直後なら作業は一旦保留としておき、プロジェクトが落ち着いてからバグ修正に取り掛かる手法を採用することもあるだろう。

あるいは、今は本番稼動中で安定しているが、今後の2次開発で機能をリファクタリングして綺麗にしないと機能拡張しづらい場合、重要度は低いが優先度の高い作業に相当するだろう。
その場合は、あらかじめスケジュールを組んでおいて、進行中の作業に混ぜ込むなどする手法があるだろう。

特に、開発チーム内部でクリティカルパス上にある作業がボトルネックになっている場合、最優先で取り掛かなければ、プロジェクトは危険な状態に陥るだろう。
だから、重要度が低くても優先度を高くして、早めに手を打つのが必要なときもありうる。

品質管理の観点では、重要度はプロダクトリスク、優先度はプロジェクトリスクの観点になるだろう。
ここで、プロダクトリスクは製品(システム)の品質がユーザや社会に対して与える影響度であり、プロジェクトリスクは開発プロジェクトへ与える影響度を指す。
つまり、プロダクトリスクはユーザの観点、プロジェクトリスクは開発チームの観点に相当する。

特にリスクベースドテストでは、プロダクトリスクの高い要素を重視してバグを潰していき、プロジェクトリスクの要素は取捨選択して行う手法だ。
昨今のテストやレビューでは、作業範囲や作業量が大幅に増えているため、全てのバグを潰すことは難しくなっているから、リスクベースドテストが主流になっているだろう。

TestLinkを運用して気付いたことpart9~後追いテスト: プログラマの思索や「Redmineによるタスクマネジメント実践技法」で説明した後追いテストとは、プロダクトリスクの高いバグを潰した後に、プロジェクトリスクのバグを潰す手法の一つだ。
昨今は、iPhoneのソフトウェアアップデートやWebシステムのデプロイ作業のように、システムをすぐにアップデートしやすくなっている環境があるので、後追いテストのようなテスト手法も取りやすい時代背景がある。


BTSの解決状況(Resolution)は障害管理の名残り: プログラマの思索にも書いたけれど、BTSの項目には、障害管理の歴史から積み重ねられたノウハウがたくさん詰まっている。
それらノウハウはソフトウェア開発のベストプラクティスにつながると思っている。

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

2010/11/21

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

最近は、yuguiさんや色んな人のつぶやきに触れて、励まされたり、ハッとしたりする時が多い。
Redmineによるタスクマネジメント実践技法」を出版してから、チケット駆動開発が今後進むべき道について再考してみた。
ラフなメモ書き。

【元ネタ】
Twitter / Yugui (Yuki Sonoda): redmineがtracの劣化クローンだった時代など最早信じられないな。機能も著しく向上し、実装も改良され、更にはいろんな先進的なプロジェクト管理の試みをするひとたちが集まるコミュニティを得た。

Twitter / Yugui (Yuki Sonoda): 一読しただけでは微妙に未消化でその時が来たらもう一度読まねばならないけど、『Redmineによるタスクマネジメント実践技法』は良い本だ。Redmineという特定の製品に依存した話はそんなに多くなくて、むしろTiDDの背景解説とパターンの本。

Twitter / オダジーロ: @akipii SW開発歴17年PL歴10年です。「Redmineによるタスク~」を54ページまで読みました。モーレツに感動しました。技術書で涙が出そうになったのは初めてです。今まで、迷いながら、手探りでやってきたことは、諸先輩が通ってきた道だったことが確信できました。感謝です。

Twitter / Mr.Goofy33: あきぴーさんのプログラマの思索のRedmineに関するエントリ。具体的な使い方から使う上での思想まで詳しく書かれているのでじっくり読む。 プログラマの思索 カテゴリRedmine http://bit.ly/be5MPR

Twitter / takuya Dosancole: 【Redmineによるタスクマネジメント実践技法】チケット駆動開発(TiDD)をRedmineでどう実現するか、考え方が記載されていてgood。いろいろ試したくなった。 http://bit.ly/daFZpm #monocolle

Redmineを触ってみて、まちゅさんによるチケット駆動開発のアイデアに触れて、チケット駆動開発に従来のソフトウェア開発を大きく変える可能性をすごく感じている。

RedmineだけでなくTracやMantis等のBTSでチケット駆動開発も運用した経験を通じて、チケット駆動開発には下記4つの大きな特徴があると思う。

1・ロードマップで長期と短期のリリース計画を使い分ける
2・ワークフロー管理を透過的にサポートする
3・成果物のトレーサビリティを実現する
4・進捗報告をチケット集計機能で自動化する

1番目は、ロードマップがチケット駆動開発で最も重要な計画プロセスの成果物であることを意味している。
つまり、ロードマップに示された複数のリリース予定バージョンが長期のリリース計画であり、一つのリリース予定バージョンには、短期の観点であるイテレーション計画が含まれている。
更に、ロードマップが将来に向けたリリース計画であり、リリースされたロードマップは自然にリリース履歴として残される。

2番目は、チケットの種類をワークフローで識別することによって、チケット管理が変更管理プロセスになることを意味している。
一つのチケットを終了する過程で、レビューアとレビューイ、開発者とテスター、開発者と設計者などのように複数人が一つの成果物を作ってチェックすることによって、品質を確保するだけでなく、お互いにより深くシステムを知るきっかけになるし、信頼関係が醸成される。

3番目は、要件や仕様からソース、設計書、ビルドモジュール、テスト仕様書などの成果物へのトレーサビリティをチケットを経由して実現出来ること。
RedmineやTrac、TortoiseSVNでは、コミットログにチケットNoを書けば、リビジョンとチケットが自動的にリンクされる機能が付いている。
更に、RedmineのSubtasking機能を使えば、チケットの親子関係が使えるので、ストーリーカードとタスクカードを紐付けて要件からタスクまで簡単にトレースできるようになる。
トレーサビリティによる利点は、仕様変更が来た時の影響範囲を調べやすくなることやソースから仕様をリバースエンジニアリングしやすくなることがあげられる。
システム監査における監査証跡としても扱えるかもしれない。

4番目は、BTSに一括管理されたチケットを集計すれば、進捗や品質、コストなどの情報をいつでも簡単に取り出せるようになることを意味している。
チケット管理の運用ルールさえ徹底できれば、開発者は進捗報告を逐一報告する必要もないし、管理者はリアルタイムに進捗や品質の情報をモニタリングできる。

従来のプロジェクト管理では、上記4つの作業を散在したExcelや大量の紙媒体で管理していたから、メンバーも運用に慣れるのが大変だし、プロジェクトリーダーもプロジェクトの状態を把握するのが困難だった。
Redmineによるチケット駆動開発なら、上記4つの作業を全てRedmineで一括管理できるし、一括管理できるからこそ、他ツールと連携して更に価値を高めることができる。

一言で言えば、ソフトウェア開発をサポートする道具がようやく時代に追いついた気がする。

と言うのも、開発プロセスやソフトウェア開発のノウハウは既に出し尽くされている気がするからだ。
CMMI、Agile、Scrum、XP、RUP、PMBOK、ITIL、テスト管理、品質管理など各種の技法や開発プロセスは2000年以前に既に提唱されており、その運用ノウハウやベストプラクティス、アンチパターンも、その界隈では既に知られていた。
だが、それらの知識を経験していない人にとっては、それらの技法やノウハウは高嶺の花だった。

でも今は違う。
RedmineやTrac、TestLink、Subversion、Git、Wikiなど優れたOSSのツールが普及し、誰もが簡単に構築して運用できるようになってきている。
ツールが揃ってきている今だからこそ、それら開発プロセスの実装、運用ノウハウを皆が知りたがっているのだ。
それら抽象論は既に聴き飽きた人が多いのではないかと思う。

そんな状況にある今、チケット駆動開発というアイデアでやってみたいことは、ソフトウェア開発のベストプラクティスをオープンソースのツールで実現してみることだ。

ツールの機能やプラグインにソフトウェア開発のベストプラクティスを実装すれば、その機能に慣れるだけで、自然に良い習慣が身につく。
そうすれば、ソフトウェア開発をチームで開発する経験が少ない若手にとって、良いお手本になるだろうと思う。

更に、ソフトウェア開発のベストプラクティスを「オープンソース」のツールで実現する点も重要だ。
MSやIBMのツールは確かに優れているかもしれないが、高価だし、ソースの中身を見ることもできないから、自分たちで機能拡張もできない。
もっと重要な点は、オープンソースという場を通じて、ツールを使うユーザとツールを開発するコミッタが有意義な議論を深めることによって、ツールの機能を拡張しながら、ソフトウェア開発の新しいプラクティスを実現する可能性を秘めていることだ。

実際、Redmine本家のフォーラムやチケットの議論を眺めていると、Redmineはアジャイル開発のプロジェクト管理と相性が良いことに気づいた人達が、アジャイル開発のアイデアをRedmineの機能へ注入するだけでなく、アジャイル開発そのものをブラッシュアップしようとする気概が見受けられる。

チケット駆動開発を運用できるツールによって、ソフトウェア開発のベストプラクティスを誰もが簡単に経験できるようになれば、ソフトウェア開発はもっと楽しくなるだろうと思っている。

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

2010/11/20

アジャイル開発とソフトウェアプロダクトラインの関係

平鍋さんの記事が面白かったのでメモ。

【元ネタ】
Agile Software Product Line を考える:An Agile Way:ITmedia オルタナティブ・ブログ

(引用)
「まずは、Agile Product Line というものがあるとしたら、What is it ? であり、What is it for ? というところから考えなくてはならない」
という方針のもとに、
* AgileもSoftware Product Line(SPL)も、Business Valueが目的(Goal)である。ただし、そのアプローチが違う。(3つの○。上位目的がBusiness Valueで、右がAgile、左がSPL)
* 経済的観点から、SPLはAssetベース。AgileはFlowベース。SPLはB/S志向であり、AgileはP/L、さらにはキャッシュフローベース。
* SPLはProduct Familyのドメイン知識をAssetとして蓄え、その再利用によって効果的な製品開発を行う。キーとなるソフトウェア品質は「再利用性」。
* Agileはワンショットのプロジェクトにおいて、フローベースでROIを最適化する。1プロジェクト毎のコンテキスト重視。キーとなるソフトウェア品質は「変更可能性」。
* 両者を融合するには、ワンショットのプロジェクトをAgileで、プロジェクト終了時に、得たknowledgeのアセット化により、SPLへフィードバックする。
* これにより、企業ワイドで、再利用資産を使うことにより、さらなる製品のAgility(早期の市場投入)ができるようになる。
という概要を書き出しました。

アジャイル開発とソフトウェアプロダクトライン(SPL)は、密接に絡んでいるようでいて、水と油みたいだと思っていた。
SPLはWF型開発を前提とした開発プロセスの実践例が多いと思うから、そもそもアジャイル開発とは相容れない所が多い。

しかし、SPLは再利用するためにコア資産を育てていく発想があり、その観点はアジャイル開発における小規模リリースの発想に似ている。
アジャイル開発でも、システムを小刻みにバージョンアップさせながら、品質も機能も改善していく発想だからだ。

特にソフトウェア品質の観点は密接に絡んでいると思う。
アジャイル開発では、保守性(平鍋さんの言葉では変更可能性)を重視する。そのためにリファクタリングという手法が編み出された。
SPLでは、移植性(平鍋さんの言葉では再利用性)を重視する。コア資産をベースに製品ファミリーを増やしていく開発スタイルだからだ。
この開発スタイルは、製造業の多品種少量生産に似ている。

そしてSPL、アジャイル開発のどちらも並行開発になるから、メインラインモデルをベースにタスクブランチ、トピックブランチなど各種の構成管理手法が必要になるはず。
つまり、高度なソフトウェア工学の知識や経験を必要とするように思う。

「SPLはB/S志向であり、AgileはP/L、さらにはキャッシュフローベース」という平鍋さんの言葉が興味深い。
確かに、SPLはコア資産をまさに資産として扱う。コア資産の品質を維持しながら、時代に合わせて機能拡張しなければ、資産価値が落ちる。
Agileの場合、タイムボックス(イテレーション)単位の開発だから、イテレーションが終わればストーリーはリセットされる。その発想は、期末になれば売上と費用が集計されて、翌月の初めから新たに売上と費用がゼロから発生するのに似ている。
そして、顧客に価値あるソフトウェアを届けるのを信条とするアジャイル開発は、まさにキャッシュフローベースとも言える。

SPLがソフトウェアファクトリーの発想に影響を受けたというKan先生の言葉も興味深い。
Scrumも野中先生の論文が提唱元になっている。
実は、日本発のアイデアが今の主流のソフトウェア開発に影響を与えている点が何となく逆説的な気がする。

アジャイル開発とソフトウェアプロダクトラインの関係は今後も追いかけていく。

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

Redmineのトラッカーやステータスの付け方

Redmineのトラッカーやステータスの付け方の記事があったのでメモ。

【元ネタ】
Redmine チケットのトラッカーとステータス項目の意味と設定 - developer

(引用)
* トラッカー
o ドキュメント
+ ドキュメント書き。
o 調査・検証
+ 調査、検証、研究など。
o 機能
+ 機能の追加や変更など。
o 不具合/バグ
+ バグや不具合登録する。
o 要望
+ ユーザーからの要望。
+ 後で「機能」や「バグ」に変化する可能性がある。
o サポート
+ ユーザーからの問い合わせは、とりあえず登録。
+ 後で「要望」や「バグ」に変化する可能性がある。
o 障害
+ なんらかの障害が発生したら、とりあえず登録。
+ このチケットに関連した「不具合/バグ」のチケットが後から追加される可能性あり。
o 環境
+ 環境構築・環境整備や設定変更など。
o アイデア
+ アイデアを登録。
o タスク
+ 上記以外は全てタスクにする。
+ タスクのトラッカーが多い場合は、トラッカーの項目を見直す必要あり。
* ステータス
o 未着手
+ 新規登録したチケットのデフォルトステータス。
o 作業に着手
+ 担当者が作業を行っている状態。
o 対応待ち
+ なんらかの対応を待ってからではないと進められない保留状態。
o 保留
+ 対応待ち以外の保留状態。
+ 保留状態が長く続くようであればチケットを見直す事も必要。
o 作業終了(review待ち)
+ 担当者が作業を終了した状態
+ 担当変更(作業者⇒レビューを行う人)
o フィードバック(差戻し)
+ 差し戻す場合に。
+ 担当変更(差し戻し先に)
o 終了
+ チケットを完全にクローズ。
o 却下(終了)
+ 作業を行わずに終了。
+ チケットの目的を果たす必要が無くなったもの。
+ チケットを誤って登録した場合など。

MyNETS - Ticket - Usagi Project Redmine

(引用)
o 「バグ」チケット
バグと認められたものを登録する。公式ドキュメントの誤りも「バグ」とする(ドキュメントの作成・更新作業は「ドキュメント」チケットを登録する)。
チケットをみるだけで、バグの修正ができるように、バグの詳細について再現手順を記載する。
o 「機能」チケット
実装することが決まったものを登録する。仕様を記載する。チケットを見て、その機能がどういうものかわからない場合は、説明を追加するように担当者に依頼する。仕様不明でテスターがテストできない場合も同様。
o 「ドキュメント」チケット
公式ドキュメント作成・更新に関するチケットを登録する。
o 「要望」チケット
要望を忘れないようにするために登録する。一般に記載できる掲示板(例:サポート掲示板等)・開発SNS日記・今後作られる掲示板等で開発SNSメンバーがこれは面白いと思う要望の内、日記などで寸評交え叩いてみて反響があった等の提案について、チケットを発行する。
o 「タスク」チケット
プロジェクト管理に必要なタスクを把握・管理するために登録する。

Redmineによるタスクマネジメント実践技法」にはトラッカーやステータスの重要性について色々書きましたが、トラッカーやステータスのテンプレートは提起していません。
その部分は、自分たちが話しあったり、試行錯誤しながら作った方がフィットすると思うからです。

トラッカーはワークフロー管理そのもの。
開発プロセスの観点では、トラッカーが非常に重要。
現場リーダーがトラッカーのバリエーションをどれだけ保持して効果的に運用出来ているか、を見れば、そのプロジェクトの状態やシステムの品質も推測しやすいだろうと思う。
トラッカーは多すぎればメンバーに浸透しにくいし、トラッカーを複雑にすると、実際の運用がうまくいかない。
そのバランス加減を実際のたくさんの現場で見てみたいところでもある。

ステータスはワークフローの状態を指す。
ステータスは普通は作業者が切り替わるタイミングで発生する。

例えば、テスターがバグを起票して、開発者がソースを修正してコミットして、テスターが再検証する。
開発者が実装済みなら、設計者がレビューする。
開発者が仕様の不明点を起票して設計者が回答して送り返す。

その作業フローを「Redmineによるタスクマネジメント実践技法」では「ペア作業」と呼んでいる。
実際、場所も時間も離れていても、一つの成果物を二人以上の目を通すことで品質をチェックする利点がある。

従来はExcelで、開発中・検証中・レビュー中・リリース完了などのステータスを管理台帳で管理していたから、共有しにくいし、最新化しづらい。
このステータスを管理して最新化するために、現場リーダーの仕事の大半は割かれていると言っても過言ではない。
その作業はRedmineやTracのようなITS上でリアルタイムに最新化されて、全てのメンバーが共有されるべきものだと思う。

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

2010/11/17

Strutsの終焉

Strutsが時代遅れになっていると指摘した記事を見つけたのでメモ。

【元ネタ】
いつまでStruts1を使い続けるの? - 達人プログラマーを目指して

Seasar3開発中止 - ひがやすを blog

JavaかRubyかGAEか | K's Diary

僕はJavaでWebプログラミングに入ったので、そういう時代になったのか、と感慨深い。
2002年頃、StrutsはベストなWebフレームワークだった。
Seasarを使っているJavaプロジェクトは日本国内で多いだろうが、その理由の中に使い慣れたStrutsがあることも含まれているだろう。

しかし、ひがさんのBlogによれば、Seasarは今後メジャーバージョンアップもしないみたい。
Webプログラミングの最先端技術は別の方向に向かっている現実がある。

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

国際会計基準IFRSがビジネスに与える影響

簿記を勉強したおかげで、IFRSの内容がちょっとずつ分かるようになってきた。
気になる記事をメモ。

【元ネタ】
第9回 研究開発費プロセスに与える影響(1)開発費の資産化 - IFRSが内部統制に与えるインパクト:ITpro

有給休暇、ストックオプションが会社を変える:日経ビジネスオンライン

特番サイト「IFRS――利益激変」:日経ビジネスオンライン

普通の経営者なら、費用よりも負債を嫌うだろうなと思う。
費用は1年ごとに必ずゼロにクリアされるけど、負債はずっと残り続ける。

個人で言えば、住宅ローンが将来にわたって残っているなら、支払い続けなければならない。
一括払いで支払いが終われば、費用は増えるが、将来に支払う義務はない。

有給休暇の給料が費用計上か負債計上になるか、その判断はとても大きいだろうと思う。
日本の場合、サービス残業というぐらいだから、有給休暇も残業代も費用として計上していたのだろうが、IFRSになれば、負債として計上されるかもしれない。
そうすると、会社が社員へ支払う義務が発生する。

又、研究開発費がどこまで資産計上されるのか、というのも影響が大きい。
サーバーの増設やLAN、HDDの交換は、費用計上ではなく、稼働中のサーバーの質を高めるのだから資産計上になるので面倒になる、という話を聞いたことがある。
資産になれば、毎年減価償却費が発生するから、費用が数年に渡って発生してしまう。

簿記で習った時に、日本は損益計算書を重視するが、欧米では貸借対照表を重視すると聞いた。
IFRSを日本の会社が導入した時のメリットやデメリットの話を聞くたびに、日本の会社は資産価値をあまり重視してこなかったのだろうな、という気がしている。

最近は、簿記の知識は経理の女性だけでなく、営業マンもプログラマも必須の知識となってきた状況がある。
簿記の知識は業務モデリングを補強してくれる重要なノウハウ。
ちょっとずつ勉強していこうと思う。

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

2010/11/16

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

Redmineによるタスクマネジメント実践技法」の感想を見つけたのでメモ。
ありがとうございます。

【元ネタ1】
チケット駆動開発の参考書「Redmineによるタスクマネジメント実践技法」 - Basic

(前略)
このような「自分たちの手で現場の業務改善を図る」というのは昔から工場などの生産現場では良く行われており、そのような流れがようやくソフトウェア開発の現場に入ってきたことは素直に歓迎したい。ソフトウェア開発の現場では、仕様書や障害情報などを何でもExcelのファイルへ入れて管理することが多くこのようなツールの価値を軽視する傾向が強いけれど、そんな非効率的なチーム運営は、RedmineやTracという武器を使って効率良くラクして運営するチームには適わないのではないかという気がしている。開発現場の品質改善も開発者自身の手によりボトムアップの形で生まれているのだ。そんな優れたノウハウを自分の仕事に生かさないのは勿体ないことだと思う。
(後略)

僕個人は、現場で改善していくやり方が好き。
開発プロセスやフレームワークを強制させられるトップダウンのアプローチよりも、現場でアイデアを色々試してみて、自分たちで運用ルールを作りこんでいくボトムアップのアプローチが好きだ。
実際のシステムの詳細を知らない人たちがあれこれ言っても何も変わらない。

現場のリーダーや開発者が、朝会やふりかえりミーティングで方針を決めたり、フィードバックを受けて試行錯誤しながら改善していくやり方が好きだ。
そういう意味ではアジャイル開発、プロジェクトファシリテーションの発想はとても好き。

現場のリーダーや開発者の作業を支援するツールやアイデアを、チケット駆動開発をベースとして体系的にまとめたいと思っている。

【元ネタ2】
Twitter / さかば: 楽天ブックスのレビューがユニーク! 「Redmineによるタスクマネジメント実践技法」 http://books.rakuten.co.jp/rb/6742038/

楽天ブックス: Redmineによるタスクマネジメント実践技法 - チケット駆動開発+テスト工程管理のAtoZ - 小川明彦 : 本

夫が仕事関係で必要になり、購入を頼まれました。毎日付箋をつけているので、きちんと読んでいるようです。

ご主人の開発者はとても忙しい方なのだろう。
そんな人に一つのアイデアとして参考になれば嬉しいです。

他にもあったら探してみる。

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

メールでRedmineチケットを登録する機能の可能性

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

【2016/3/5 更新】
@netazoneさんのおかげで、現在も動作するThunderbirdのアドオンを見つけられました。

Redmine連携 :: Add-ons for Thunderbird

ThunderbirdとOutlookのRedmineアドオン: プログラマの思索

【元ネタ】
Thunderbirdで受信したメールをRedmineのチケットとして登録できる「Quick Ticket to Redmine」 | Redmine.JP Blog

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

Email-ext plugin - hudson - Hudson Wiki

RedmineとHudsonやTestLinkを連携させるプラグイン: プログラマの思索

Hinemos+Redmine for ITILで運用保守を改善する: プログラマの思索

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

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

RedmineのVer0.8の頃から、メールでRedmineチケットを登録できる機能は付いていた。
おそらくRubyのライブラリを使えば、実装はそんなに難しくない機能だろうが、メールによるチケット登録機能は、ソフトウェア開発のバックエンドの業務をサポートしてくれる可能性を秘めている。

使い道としては、インシデント管理におけるサポートデスクの作業を自動化する点だ。
サーバー監視ツールがOSやHDDのダウンを検知したり、ネットワーク障害を検知したら、普通は緊急障害のメールを自動で流す。
そのタイミングで、Redmineチケットを登録するメールを流せば、一つのインシデントとしてRedmineの障害管理として扱われる。
障害に対する応急処置、そして抜本的な是正措置に対する作業ログは全てチケットに追記すればいい。
Redmineの優れたワークフロー管理によって変更管理をリアルタイムにモニタリングできるし、SCM連携によるトレーサビリティによって、SCMリポジトリにあるソースや設計書、リリース手順書の変更も追跡できるようになる。

ここで、Thunderbirdで受信したメールをRedmineのチケットとして登録できる「Quick Ticket to Redmine」 | Redmine.JP Blogの記事で面白いのは、ユーザから届いたメールをサポートデスクのオペレータがメールソフトで受信した時、メールを転送するだけでRedmineチケットを登録できる仕掛けがあること。
Redmineチケットに起票すれば、一つのインシデントあるいは障害として見なされて、変更管理プロセスの一部として管理できる。

オペレータが解決できないインシデントは、開発チームや上級管理職へエスカレーションして、彼らに対応してもらえばいい。
そのワークフローもRedmineの優れたワークフロー管理機能で透過的にサポートしてくれる。

あるいは、@haru_iidaさんの講演内容Hudson × Redmineによれば、Hudsonのビルドエラーを検知したメールからRedmineチケットに登録するアイデアも紹介されていた。
この機能は、PFのソフトウェアあんどんの発想と全く同じだ。
ビルドエラーと言う重大な障害をすぐに皆で共有できる。

昨今のサーバー障害検知ツールやビルド管理ツールなどには、メールを自動で流す機能があるので、宛先をRedmineにするだけで、簡単にチケット登録できる。
緊急障害が発生した時は、チケットを起票したり更新したりする手間が惜しい場合が多いけれど、この機能があれば、チケットを関係者の情報共有の場にできる。

更に、Redmineのチケットに登録できれば、ワークフローを厳格に管理して運用もできるし、チケット終了後にRedmineの優れたチケット集計機能を使って、障害やインシデントの傾向分析を行うことも可能だ。

この機能は特に、ITILのインシデント管理に有効だろうと思っている。

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

2010/11/14

EM West掲載記事「アジャイルにおけるテスト開発プロセスの考え方」の感想

先日のAgileTourOsaka2010で配布されたEM Westという無料のIT雑誌がある。
その雑誌で掲載された記事「アジャイルにおけるテスト開発プロセスの考え方」を読んだ。
記事の筆者はXPJUG関西代表の細谷さんなので、内容についても以前から知己ですが、改めて読んだ感想をメモ。

【元ネタ】
EM WEST Vol.2

記事の内容は、テストプロセスにアジャイル開発の概念を注入して、テストプロセスの品質を上げる方策を提示していること。

面白いと思った点は二つ。
一つは、イテレーション単位に開発とテストを進めていって、最後のイテレーションでシステム全体の評価を行うテストを別途設けていること。
もう一つは、イテレーション単位でテストの観点やテストケースを深堀していくこと。

前者は、漸進型開発(インクリメンタル)から反復型開発(イテレーティブ)へ繰り返し型開発のスタイルを変換することを意味している。
つまり、最初は小規模リリースしながら、小刻みに機能拡張していく。
だが、そのままではシステム全体の品質は保証できないから、最後のイテレーションで、過去のイテレーションの成果物のフィードバックを受けて、システム全体のテストを行って、テストの精度を高めるやり方。

この方法は僕自身も、同じような開発経験を持っている。
最初は、Redmine+チケット駆動開発で、1~4週間のイテレーションのサイクルでガンガン開発していく。
この時は、開発者も現場リーダーもとても楽しい。
しかし、機能追加していくうちに、仕様変更の影響について考慮が漏れていたり、ユーザーインターフェースの統合性が崩れていたりする時がある。
だから、一通りの開発が終わったら、TestLink+Redmineで結合テスト、システムテスト、受入テスト、負荷テスト(ラッシュテスト)など、各種の観点で徹底的にテストしていく。
実際は、TestLinkのテスト計画をイテレーションとみなして、膨大なテストケースをテスト計画に分割して、段階的にテストする。

この手法の利点は、二つある。
一つは、従来のアジャイル開発では品質の作り込みが弱い点を別の繰り返し型開発である反復型開発でカバーしていること。
二つ目は、品質やアーキテクチャの作り込みの作業のスコープを制御することで、反復型開発の弱点をカバーしていること。
この発想は「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」や「実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)」にもよく出てくるので要注意。

後者は、過去のイテレーションのフィードバックを活かして、テストケースの品質を高めていけることを意味している。
TestLinkによるテスト管理を運用してみて分かったことは、テスト管理はそもそも計画主導の方がやりやすく、テストケースを後から変更するのは結構難しい点だ。
つまり、テスト管理や品質管理は、V字型モデルと呼ばれるウォーターフォール型開発の方がやりやすい特徴があるように思う。
しかし、実際のテストでも、仕様変更や設計漏れのためにテストケースを頻繁に修正する作業はとても多い。
だから、アジャイル開発の利点をテストプロセスに生かすノウハウが必要だろうと思う。

TestLinkでテストケースやテスト結果を管理している場合、TestLinkCnvMacroというExcelマクロでテストケースを修正インポートするのが可能なので、仕様変更やレビューによる指摘を受けてテストケースを修正することは簡単にできる。
又、テスト計画をイテレーションに見立てて順次実行するようにすれば、次のテスト計画で、テストの新たな観点を取り入れてテストケースを追加すればいい。

TestLink上で似たようなテストケースを一括編集するのは面倒なので、Excelマクロをうまく使って一括インポートするようにした方が良いと思う。

最近思うのは、タスク管理についてはRedmineやTracなどの優れたツールが出てきて、そのノウハウも色々揃ってきているのに、テスト管理やレビューについては、良いツールが少なくて運用ノウハウも少ない。
色々試してみたいと思っている。

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

2010/11/13

GnuCashの使い方

フリーの財務ソフトウェアGnuCashの使い方が書かれていた記事があったのでメモ。

【元ネタ】
GNUCashでのフリーランス青色申告用、勘定科目テンプレート | SawanoBlog 2G

GNUCashで始めるフリーランス青色申告 | SawanoBlog 2G

続・GNUCashで始めるフリーランス青色申告 =請求書からの掛取引編= | SawanoBlog 2G

フリーの財務ソフトウェア | GnuCash

GnuCash/GnuPG 日本語翻訳 Japanese translation - 日本語入力の問題

MSMoneyのLinux版GnuCash: プログラマの思索

上記の記事の人は、個人事業主の立場でGnuCashを使っているらしい。
GnuCashはまさに複式簿記そのもの。
簿記の勉強に丁度よいかもしれない。

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

アジャイル開発を前提とした受託開発

永和システムマネジメントさんがアジャイル開発を前提とした新しい契約形態での受託開発サービスを発表していた記事があったのでメモ。

【元ネタ】
新しい契約形態での受託開発サービス | 永和システムマネジメント

プライベートセミナー『アジャイルに適したまったく新しい契約形態での受託開発サービス トライアルのご紹介』(2010/11/24) ? 株式会社永和システムマネジメント コンサルティングセンター

永和システムマネジメントの新しい受託契約がすごく面白い - ただのにっき(2010-11-11)

WEB技術者の事業貢献度をもっと高めたい - GoTheDistance

受託開発の契約をアジャイル開発を前提とした形態にしてSIビジネスする発想はとても興味深い。
責任者は木下史彦さんと公開されていて、XP祭り関西などで何度もお話を聞いていたから、なるほどと思った。

SW開発が製造業と異なる収益構造を持つ特徴は、製造業がPoint of Sales、SaaSがPoint of Useである点だろう。
つまり、製品は販売した時点で価値が一番高いけれど、所有した途端に減価償却が始まって、数年後には価値がゼロになる。
実際、車にしても家電製品にしても、所有した時点で中古品となり、価値が半減する。

SaaSの場合、モノを所有するのではなく、サービスを利用する形態になる。
特にアジャイル開発を前提としたSaaSの場合、倉貫さんが話す通り、システムは常に機能改善されていくので、利用者は最新機能を使えるようになる。

第7回 クラウドサービスの開発に活用 - 幸せを呼ぶアジャイル開発:ITpro

SaaSはアジャイル開発に向いている: プログラマの思索

SW開発のビジネスモデルとしては、SaaSの方がアジャイル開発に向いているし、受託開発よりもソフトウェアの価値も高くなるだろう。

しかし、受託開発において技術者として難しいと思う点は、プログラムを改変する権利がプログラマになく、パッケージ製品ベンダーや顧客にある場合だ。
下記に状況を書いた。

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

特に受託開発では、システムの納品と共に、ハードとソフトを一括して納品する時が多い。
その場合、システムの著作権は顧客にある。
その理由は、システムが顧客の業務に関わる場合が多いから、守秘義務が発生しやすいから当然のこと。

すると、せっかく受託開発で作ったライブラリやフレームワークは、他の案件で使えなくなる。
ソフトウェアの再利用が難しいから、また一からスクラッチ開発しなくてはならない。

永和システムマネジメントさんのプレスリリースで興味を惹いたのは、顧客はシステムを利用する契約であり、システムの著作権はSIにあると明記していること。
この契約なら、受託開発で作ったライブラリもソフトウェアもその後の案件で流用可能。

しかし、はてなブックマーク - kanu-orzのブックマークで書かれているように、羽生さんも似たようなビジネスを展開していたけれどあまり売れなかったという話もある。

次回のイベントで、ビジネスの動向に関する経験談が聞けるかもしれない。
今後の動向に注目したい。

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

2010/11/12

RedmineとHudsonやTestLinkを連携させるプラグイン

RedmineとHudsonやTestLinkを連携させるプラグインが最近色々でてきたのでメモ。

【元ネタ1】
Twitter / やのつとむ: Hudson Email Extension Pluginで、hudsonの発行するエラーメールをredmineに対応させて、エラーメールを即タスクとして登録するテク #hudsonstudy

Twitter / Naoki Nishiguchi: Hudson Email Redmine Plugin でテスト失敗時にRedmine にチケット登録かー。凄い

Twitter / akipii: @haru_iida なるほど。うまいやり方ですね。ソフトウェアあんどんをビルド通知メールだけでなくビルド失敗チケットにしてしまうわけですね。

プラグインのリンク先が無いので分からないが、Redmineの各機能から眺めたチケット駆動開発の課題: プログラマの思索にも書いたけれど、Hudsonでビルドエラーが発生した時、エラーメールをRedmineに送って、チケットを自動登録する機能は、ソフトウェアあんどんの発想と全く同じ。

ビルドモジュール作成に失敗した状況がメールによって皆にアナウンスされるだけでなく、チケット登録されることで、障害の一つとしてカウントされる。
ビルドエラーチケットをプロジェクト終了後に集計すれば、何故ビルドエラーが多発するのか、という原因調査に役立つだろう。

【追記】
hudsonstudy#1-5, hudsonstudy#1-5 gihyojp on USTREAM. 会議を見ると、下記のHudsonプラグインでビルドエラーメールを流す時に、宛先をRedmine宛にしてチケット登録するやり方らしい。

Email-ext plugin - hudson - Hudson Wiki

【元ネタ2】
2016/3/5 ThunderBirdのメールからRedmineチケットを起票するアドオンは下記にあります。
Redmine連携 :: Add-ons for Thunderbird

ThunderbirdとOutlookのRedmineアドオン: プログラマの思索

メールソフトThunderbirdからメールをチケットとしてRedmineに登録できるアドオンらしい。
例えば、社内サーバーにあるRedmineへ外部からアクセスできない場合、携帯からメール送信してRedmineにチケット登録することも可能。
使い道としては、RedmineをSW開発のタスク管理というよりも、プライベートなToDo管理として使う場合に便利かもしれない。

【元ネタ3】
Redmine TestLink Link プラグイン Wiki - SourceForge.JP

RedmineのWikiマクロを使って、TestLinkのテストケースやテストプロジェクトへリンクするプラグイン。
TestLinkのテストケースからRedmineチケットへリンクする機能はあるので、このプラグインを使えば、RedmineとTestLinkを相互リンクすることが可能になる。

Redmine TestLink Link プラグインの利点は、Redmineチケットの発生源が失敗したテストケースにある場合、チケットからTestLinkテストケースに辿れること。
バグでもタスクでも要望でも、すべての情報はチケットに集約すればいいのだ。

アイデアさえあれば、すぐに実装できるのがRedmineの良い所だと思う。

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

Hudsonで並列分散処理

Hudsonが並列分散処理の基盤を持つ可能性があると示唆した記事をメモ。

【元ネタ1】
川口耕介さんを囲む会でHadoopプラグインについて質問してきました - n-3104の日記

(前略)
Hudsonが並列分散処理基盤として可能性を秘めていることを知れて興奮しました。
(中略)
* 並列して負荷テストとかするというのは便利そうだと思いました。
* Androidの実機を複数台まとめてテストできるというのもすごいと思いました!

2009-03-15 - 川口耕介の日記

Cloud computing competition by Hapyrus

HudsonのHadoopプラグインがあるのは知っているけれど、どう使えばいいか、正直分かってない。
だが上記の記事によれば、携帯の実機を複数台まとめて並列テストとか、負荷テストを並列で実施するやり方も可能らしい。

僕がHudsonで実現したいと思う機能は、JUnitのビルドを並行実行させて、ビルド時間を短縮させることだ。
XPが提唱したテスト駆動開発のアイデアは素晴らしいけれど、システムが複雑化するほどJUnitのプログラム本数は増えて、一晩かかってもビルドできないくらいになる。

あるいは、複数のコンポーネント(jar, dll)をビルドしないとシステム(war, exe)が作れずにテストできない状況にある場合、複数のコンポーネントを直列でビルドするとビルド時間が倍以上かかってしまう時もある。
そうなると、継続的インテグレーションの利点が薄れてしまう。

だから、Hudsonでビルド作業を並列化して、ビルド時間を劇的に短縮させたい。

【元ネタ2】
仮想環境で本番環境と同等の環境を作るHudson と Vagrant - maeshimaの日記

開発環境と本番環境の環境が違って、開発環境だとうまくいくけど本番環境だとエラーみたいなことがよくある
→仮想環境 & 自動化で解決!みたいな話。
(中略)
エントリ中では、ruby で Hudson を使うための hudson.rb を使ってCLIで操作してた。
(中略)
大まかな流れ
1. VirtualBox を入れる
2. vagrant(VitrualBox用の仮想環境を作るのを自動化するツール)で仮想環境を作る
3. puppet でDBやWebサーバ等を入れる
4. Hudson で Railsアプリを作ってテスト

Hudsonで並列ビルドできたら、ビルド環境そのものも仮想化して、開発環境も本番環境も同等な環境でビルドするようにしたい。
いくら開発環境で開発がスムーズにいったとしても、本番環境が開発環境と大きく変わっていると、本番リリース作業にかなりの労力を取られてしまう。

最近はサーバーもメモリもHDDも安いし性能も良くなっているので、環境を仮想化して、いつでもどこでも同じ環境で開発できるようにした方がいい。
更にHudsonを使って、環境構築作業まで自動化してしまえばいい。

Hudsonには大きな可能性が秘められていると思う。

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

2010/11/10

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

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

【元ネタ1】
CentOS 5.xにRedmineをインストールする

ニコニコカレンダー、FAQ、蔵書、コードレビュー、Wiki拡張などのプラグインのインストール方法が詳しく書かれているので参考になる。
蔵書プラグインは「書籍や物品管理機能を追加します。貸し出し管理、書籍(物品)レビュー記載が行えます。」とのことなので、運用してみると面白いかもしれない。

【元ネタ3】
あるプログラマの本棚 不具合管理・問題管理編

(「Redmineによるタスクマネジメント実践技法」の感想として)
チケット駆動開発を行うためのノウハウ本。Redmine自体の解説は少なく、チケット管理をどううまく実践で行うかをしっかりと解説している。Subversion/TestLinkとの連携も取り上げている。チケットを書きっぱなしでうまく活用できない人には特にお薦め。

Redmineなどのツールのインストールよりも、Redmineで何ができるか、チケット管理を使うとどのようにAgile開発をサポート出来るのか、に重点をおいて書きました。
感想ありがとうございます。

他にもあったら探してみる。

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

2010/11/09

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

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

【元ネタ1】
Redmineによるタスクマネジメント実践技法 - Luck is for losers

この本は良い本だと思います。
僕の考える良い本(技術書)の定義の一つは、
* 引用や参考文献がちゃんと載っていること
って思っていて、この本は参考文献などのリストが本文中にも書いてあるし、
最後の方のページにはリスト化して書いてあります。
だからこの本を読むと、この本がハブとなって、他の本の存在を知る事ができる。
(後略)

本の内容は独自のアイデアというよりも、コミュニティの人達や書籍から得たものが多かったので、参考文献と参考リンクは知っている限りの引用元を書きました。
ありがとうございます。

【元ネタ2】
[#TiDD] 二つのチケット駆動開発と「方法論」: ソフトウェアさかば

Amazon.co.jp: Redmineによるタスクマネジメント実践技法: 小川 明彦, 阪井 誠: 本

うまくまとまっていて読みやすかったけど、わりと得られるものは少なかった印象。Redmine と TestLink の使い方の研究レポートという感じでした。ひとつの開発方法論というには、まだ未成熟ではないでしょうか。今後に期待します。
(後略)

RedmineやTestLinkを題材に開発プロセスを分析するやり方で書いたので、確かにツールを使った報告内容が多いです。
参考になります。

他にもあったら探してみる。

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

頻繁なVerUpがソフトウェア開発の本質

WF型開発とAgile開発の本質的な違いはどこにあるのか?
プロセスや技術の観点から見れば、WF型開発は本番リリースが1回しかないのに対し、Agile開発は定期的なリリースを基本とする特徴がある。
その観点をもう少し深めて考えてみた。
ラフなメモ書き。

【1】WF型開発は、シーケンシャルに工程単位に開発を行い、フィードバックプロセスをできるだけ排除するプロセス。
半年~1年に1回だけ本番リリースするのが普通だろう。

特に日本のSIは製造業から派生した会社が多いから、ソフトウェア工場の発想に影響を受けている。
つまり、前工程の品質をできるだけ確保するために、レビューやテストを事前にしっかり行い、仕様漏れや検証漏れを前工程で十分に行って、後工程のフィードバックや突然割り込んだ変更要求をできるだけ排除するやり方。
たいていは、スコープは長期間固定化するのが普通で、最後の1回の本番リリースを成功させる手法になる。

だが、人月の神話以来昔から知られているし、僕自身も何度も経験したけれど、本番リリースが1回だけのプロジェクトは必ず失敗する。
本番リリース前に作業量はピークになり、残業や休日出勤も続くから、開発者はリリースさえできれば全て丸く収まると思っているけれど、実際は本番リリース後の方が大変だ。

いくらテストをやっても、本番環境で、実際にユーザが使った実績がないから、その品質はテスト品質に過ぎず、本番品質あるいは運用品質まで至っていない。
本番環境と開発環境は物理的に全く違うから、動かしてみないと分からない部分はとても多い。
そして、実際に稼働させて、ユーザが実業務に使ってみなければ、業務に耐えうる品質なのか、分からない。

だから、本番環境で動かしてみて初めて分かるバグが、たくさんの障害報告として押し寄せる。
もちろん、軽度のバグも大量に発見されて報告されるだろう。

更に、ユーザが初めて業務で運用してみて、やっぱり使いづらい、などと言った改善要望も大量に押し寄せる。
また、半年前、1年前にあげた要望は、その後のビジネス環境の変化や、ユーザの組織構造の変化を反映していないわけだから、元々の要望から変わっている時が多い。
だから、現在のビジネス環境やユーザ環境に見合った機能へ改善して欲しいと言う要求が大量に来るだろう。

つまり、WF型開発では、最初で最後の本番リリース後に必ずデスマーチになる。
障害報告や改善要望といったたくさんのフィードバックを開発チームが処理しきれなくなるのだ。
開発チームの能力を超えたフィードバックが来た場合、もはや優先順位付けや棚卸しすらも不可能になる。
たとえチケット駆動開発であろうとも、そんな状況では役立たない。

【2】Agile開発は、イテレーション単位に定期的にリリースするのが前提のプロセス。
XPでは、この開発スタイルは、小規模リリースと言われる。
つまり、定期的なリリースで、品質を維持しながら、小刻みに機能を拡張していく開発プロセス。

Agile開発では、頻繁なリリースが最大の特徴だから、頻繁なVerUpが当たり前だ。
WF型開発と違って、複数回のリリースをあらかじめ計画に織り込んでいるから、どの機能をいつリリースするのか、という観点でスコープをコントロールすることになる。

つまり、イテレーションというタイムボックスに、顧客の要望を実現する機能を入れることができるし、新たなイテレーションを実施する前に、機能を入れ替えることも可能。
タイムボックスというサイズの制限があるから、スコープにも上限があるから、顧客にも、事前にあがってくる要望へリリースの制限をかけることができる。

XPの「変化を抱擁せよ」のキャッチフレーズと同じく、Agile開発はソフトウェアの変化を前提とする。
VerUpしないソフトウェアは価値がないのだ。

ハードウェアもミドルウェアもソフトウェアも1年後には大きく変わっている。
昨今のハードウェアの性能改善、WebサービスのUIの改善は著しい。
環境が変わったのだから、ソフトウェアも環境の変化に合わせて進化した方が使いやすくなる。

【3】しかし、不用意なVerUpはデグレを起こす危険性がある。
きちんと精査されていない機能改善は、逆にデグレを起こし、品質を落とす危険があるのだ。
特に最近は、HWやOSやブラウザ、ミドルウェアのバージョンの組み合わせが複雑になっているため、安易なVerUpですぐにソフトウェアは動かなくなる。

だから、頻繁なVerUpを安全に行うには、ITILの変更管理の考え方が必要。
本番リリース後のソフトウェアを安全にVerUPして、運用品質を維持していくには、運用保守の作業を定型化しておくのが大事。
しかし、ガチガチの変更管理プロセスは、開発チームの生産性を落とす。
複雑なドキュメントやワークフローが開発チームの機動力をなくす。

だが、チケット駆動開発なら、ワークフロー管理はチケットの種類別のステータス管理として透過的に管理できる。
ITILによる運用保守の観点をチケット駆動開発の中で運用することも可能だ。

【4】また、Agile開発は自然に並行開発になるため、構成管理の観点も重要だ。
何故なら、一度リリースしたソフトウェアはそれで終了ではなく、本番リリースブランチとして、ユーザの業務に使われて生き続ける。
更に、開発チームはその裏で、次のリリースに向けて、ガンガン機能拡張するソースをtrunkへコミットしている。
つまり、trunkと本番リリースブランチと言う二つのコードラインが発生し、その二つのコードラインの品質を常に維持し続けなければならない。

並行開発の構成管理は、パッケージ製品や組込製品の開発で従来から知られているように、とても難しい。
1本のコードラインをリリースする品質まで持って行くのも大変なのに、二つのコードラインを並行して保守せざるをえないからだ。
また、その2本のコードライン間でマージ作業が頻繁に発生するが、手作業のマージ作業はとてもミスが多い。

この状況に対する構成管理の解決手法は、メインラインモデルとして知られていて、オープンソースでは広く知られている開発スタイル。
特にMercurialやGitのような分散バージョン管理では、ブランチを管理しやすい。
チケット駆動開発はメインラインモデルとも相性がいい特徴がある。

【5】更に、Agile開発と構成管理手法を絡めると、緊急リリースをタスクブランチとして実現することもできる。
そのやり方は下記に書いた。

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

つまり、本番リリースブランチやtrunkとは別に、新たなバージョンを計画して、タスクブランチ上で突発的な改善要望を実現するやり方。
割り込みのバージョンを意図的に作り出して、顧客の要望とシステムの品質という相反する要素を実現しようとする。
分散バージョン管理のように、強力なマージ機能があれば、とても実現しやすいはず。

ソフトウェア開発は、頻繁にリリースしながらVerUPするたびに、機能も品質も改善していくのが王道だと思う。
例えば、AppleはiPodという製品から、iPhone/iPadという製品を派生させてVerUpさせながら、機能も品質も拡張してきている。
MSもOffice製品やWindowsOS、IEのように、Ver3.0になって初めて使い勝手も品質もよくなると言われていた。
GoogleのWebサービスも永遠のベータ版のまま、頻繁にリリースしてVerUpしながら、機能も品質も改善し続けている。

頻繁なVerUpがソフトウェア開発の本質ならば、その変化を開発者の手のひらに収まるように制御するノウハウが重要になってくる。
そのノウハウが最近になって、色々出尽くしてきたような気がする。

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

2010/11/06

Redmineのロードマップ画面に表示される進捗率と原価計算の関係

Redmineのロードマップに表示される進捗率の計算方法と原価計算の関係について、考えたことをメモ。
ラフなメモ書き。

【元ネタ】
ロードマップ画面に表示される進捗率の算出方法 | Redmine.JP Blog

脱Excel! Redmineでアジャイル開発を楽々管理 - @IT自分戦略研究所

見かけ上の進捗: プログラマの思索

チケット駆動開発にEVMの概念を導入してみる: プログラマの思索

RedmineプラグインRodmapsにEVMの機能を追加する: プログラマの思索

Redmineのロードマップには2種類の進捗率が表示される。
薄い緑色は、チケットの進捗率から得られた見かけ上の進捗。
濃い緑色は、終了チケットから得られた実質の進捗。

Redmineが他のBTSよりも優れている点の一つは、ロードマップを見れば、実質の進捗と見かけ上の進捗の2つの進捗が見れること。
見かけ上の進捗: プログラマの思索にも書いたけれど、実質の進捗と見かけ上の進捗に大きな差がある場合、そのプロジェクトは黄色信号。

例えば、仕掛り中のチケットは多いのに、どのチケットも完了ステータスまで到達しておらず、90%のまま停滞している状態。
こういう状態のプロジェクトは、開発者の単体テストは終わったけれど、レビューでたくさんの指摘を受けては直すことを繰り返していたり、バグ修正したのにデグレしていたり同類バグ調査の分析が漏れていたりして、何度も同じ作業を繰り返している場合があるだろう。
ソフトウェア開発では、進捗率が90%のまま停滞する時がとても多い。
つまり、開発プロセスに問題があり、プロジェクトの生産性が落ちている事実を示している。

この発想はPMBOKのEVMに関係していることは以前書いた。
つまり、終了チケットから得られる進捗はEV(実質の価値)、作業中のチケットから得られる見かけ上の進捗はAC(実際のコスト)を表している。
PV(予定している価値)は、予定している終了チケットの進捗から得られるから、EV・PV・CVの3つを計算することによって、プロジェクトのスケジュールやコストをリアルタイムに把握することは可能。

更にこの発想は原価計算にも関連する。
終了チケットは倉庫にある完成品、作業中の未完了チケットは仕掛品に相当する。
つまり、在庫にある商品の状態とイメージすることもできる。

すると、在庫に仕掛品がたくさん残っている場合ほど、その工場の生産性は低いことになる。
完成品でなければ、すぐに販売して売上に変えることができないからだ。

工業簿記に出てくる原価計算の場合、大量規格品の総合原価計算と少品種少量生産の個別原価計算の2種類があるが、ソフトウェアは後者に相当するだろう。
但し、どちらにせよ、直接材料費と加工費、あるいは直接費と間接費の2種類から製造原価を求める手法に変わりはない。
製造原価が求まれば、どれだけ利益を上乗せして販売すればよいか、利益計画を立てることができる。
つまり、製造原価を知らなければ、本来どれだけの販売単価で顧客に売ればよいのか、分からないから、赤字になりやすい。

ソフトウェア開発では、ソフトウェアは人の頭から作られるから直接材料費は殆どゼロだ。
つまり、製造原価の殆どはPGやSEの労務費、パソコンや電気代の経費などの加工費になる。
実際のソフトウェアの製造原価の殆どは人月計算に示される労務費だから、チケットにある実績工数と人月単価で計算できる。

だが、昨今は原価の殆どが間接費になっているため、各製品に間接費を按分すると、本来の製造原価が歪んでしまって、どの製品が本来コストが高いか、どの製品が本来利益が出ているのか見えにくくなる。
その問題意識から出てきたのが、バランス・スコアカードを作ったキャプラン・ノートンが提唱した活動基準原価計算(ABC:Activity Based Costing)。
下記の記事が分かりやすい。

ABC(Activity Based Costing:活動基準原価計算)とは[ITCサンシャイン・ブレインズ]

上記の記事では、電話オペレーターという活動は本来どれだけの原価なのかを計算するために、電話オペレーターの活動を細かく洗い出して、それぞれの活動時間からコストを計算している。
つまり、活動基準原価計算では、資源(リソース)がどの活動に使われて有効活用されたのか、という発想につながるので、ホワイトカラーの生産性を計算することに使える。
活動基準原価計算の具体例としては、役所やNPOなど公的活動で使われた経費が本来の利益や貢献をもたらしているのか、という評価に使える。

もちろん、ソフトウェア開発の原価計算にも活動基準原価計算の発想は使えるはず。
つまり、時間という限られた資源からどれだけの成果物(実際は動くシステム)が作られたのかを追跡することは可能。
Redmineによるチケット駆動開発ならば、チケットに予定・実績工数と予定・実績の開始・終了日を入力する運用ルールが徹底できれば、活動基準原価計算によって精度の高い製造原価を求めることは可能。

製造原価の計算方法については、TOCのスループット会計という発想もある。
下記の記事が分かりやすい。

簿記2級対策 工業簿記1 - 中小企業診断士 中村俊基 - Yahoo!ブログ

スループット計算

スループット会計では活動基準原価計算とは逆に、細かな原価計算をしても無意味で、ボトルネックになる製品の原価を求めることに注力する。
クリティカルパス上の作業が本来の原価計算の源だからだ。
ソフトウェア開発もクリティカルパスがあるから、スループット会計によって、ボトルネックによる制約条件から原価計算することも可能。
TOCの方が本来の製造原価に近いかもしれない。

Redmineにはたくさんの可能性が秘めている。

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

All_in_one_testlinkjp_20101031_185bがリリースされている

TestLink1.8.5b+XAMPのワンクリックインストーラーが公開されていたのでメモ。
このパッケージがあれば、Windows上で解凍するだけでTestLinkが使えるようになる。

【元ネタ】
ダウンロード - TestLink日本語化 - SourceForge.JP

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

2010/11/03

チケット駆動開発は仕事をさばく仕組み #agileto2010 #tidd

10/30に行われたAgileTourOsakaのライトニングトークスで、@kami_teruさんのLTがとても興味深かったのでメモ。
下記のUstreamで見れます。

【元ネタ】
AgileTourOsaka2010 LT, Recorded on 10/10/30 tetsu_m on USTREAM. 会議

Atsuteru Kamiya (kami_teru) on Twitter

「チケット駆動開発をやってみて」というタイトルで、@kami_teruさんのチケット駆動開発の導入経験談。
率直な感想は、とても面白いし、とても興味深かった。

@kami_teruさんによれば、XP祭り関西2010のチケット駆動開発セッションを聞いたのが、Redmineによるチケット駆動開発をやるきっかけだったとのこと。
詳細は上記のUstreamを見て頂きたい。僕が興味を惹いたのは2つ。

一つは、いきなりチケット駆動開発を導入するのではなく、小さく始めること。
彼の話を聞くと、現場リーダーらしく現場への導入方法がうまいなあと思った。

まず、RedmineをToDo管理としてメンバーに使ってもらって、慣れてもらった。
そして、コードレビュープラグインを入れて、コードレビューに使ってもらった。

r-labs - Code Review - Redmine

コードレビュープラグインによる生産性はとても高かった、という指摘が興味深い。

更に、作業工数もお願いして入れてもらって、2週間後には、必ず工数を入れないと実績として扱わないと強権発動した(笑)、とのこと。

最後は、チケットで全てのタスク管理やイテレーション管理、SCM連携、カテゴリ別のチケット集計、バックログのチケット化など、手を変え品を変えて現場にチケット駆動開発を導入していった、とのこと。
それらの導入も、理由があって意図的に少しずつ運用を始めた、と彼が話している途中で切れてしまったので、個人的には、運用を始めた理由や意図を詳しく聞きたかった。

Redmineだけでなく、TracやJiraなどでチケット駆動開発を導入しようと考えている現場リーダーには、とてもよい参考例になると思う。

もう一つは、チケット駆動開発で仕事をさばく仕組みができたこと。
彼の話によれば、突然の仕様変更やバグ修正が来てもう無理だと思った時に、上記のチケット駆動開発の環境が揃っていたので、SEがチケットに優先度と期限を付けてくれていた。
だから、メンバーはそのチケットに従って作業をこなせば良かったから、最終的には20日間で約170枚のチケットを全て完了させたらしい。

場所や人にとらわれず、チームが自律的に仕事をさばく仕組みができた、とのこと。
これはまさに、ScrumやリーンSW開発の自己組織化そのものだ。

彼のチームは7人で、うち3人も新卒がいたらしく、大変だっただろうと思う。
でも、彼の会社の方も来られていて、懇親会などで話を聞いたら、チケットでタスク管理するのはすぐに慣れて、むしろチケット無しでやるのは考えられないという感想を話していた。
新人の女性にもチケット駆動開発の感想を聞いたら、タスクをチケットに起票してから始める(チケットファースト)や、ソースのコミットログにチケットNoを書く(No Ticket, No Commit)運用ルールは既に習慣となっているらしく、それほど難しくなかったです、と言っていた。
他の普通のプロジェクトがどんなルールでやっているか分かりませんけど、と言っていた。

良い習慣を身に付けた開発者は品質の良いプログラムが書けるようになるはずだから、彼女は今後も成長するだろうなと思う。
PSP(Personal Software Process)では自分の作業記録を残しながら、自分の作業を改善していく手法を取るけど、そのやり方に何となく似ている気がする。
チケットに作業履歴を残す習慣があれば、他人と情報共有できるだけでなく、自分自身の作業を振り返る時にチケットが役立つだろうから。

僕個人の経験では、30代以上ですでに自分のやり方を持っていて、Excelで管理するのが大好きな人には、チケット駆動開発に拒否反応を起こす。むしろ新人や若手の方がスムーズに導入できるし、SEやマネージャよりもプログラムをガンガン書く開発者の方がチケット駆動開発に慣れてくれる。

こういうチケット駆動開発の事例がもっと増えると、プラクティスやアンチパターンなども共有できてくるので面白いと思う。

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

2010/11/02

BTSの解決状況(Resolution)は障害管理の名残り

Mantisのチケットでは、ステータスだけでなく「解決状況」も重要な属性だ。
又、Jiraのワークフローをカスタマイズしようとしたら、結構大変で、色々資料を探ったら、「ステータス」と「解決方法」をペアで設定する必要がある資料を見つけてようやく理解した。

各種BTSの解決状況(Resolution)について、情報をまとめてみた。
以下はラフなメモ書き。

【Bugzilla】
はじめてのバグジラ ver2.16-ja編
バグの重要度(Severity)
処理方法(Resolution)

【Mantis】
Mantisメッセージの日英対訳 - korakuriderの日記
Resolution=解決状況

【Trac】
Tracのチケットは終了基準が大切 - Basic

TracTickets -- MIST Project

チケットの使い方 - Meadow - Trac チケットを閉じるときの resolution はどう選ぶべきか? ¶

バグトラッキングシステムTracをつかう/TIPS集 - きのさいと
解決方法 (Resolution) - チケットが解決された際の理由。修正した (fixed)、無効なチケット (invalid)、修正しない (wontfix)、他のチケットと重複 (duplicate)、再現しない (worksforme)など。

【Jira】
JIRA ユーザーガイド

'解決状況' フィールドの値を定義する - JIRA (ジラ) 関連資料 - Go2Group Wiki

1.9.1. JIRA ワークフロー

【1】はじめてのバグジラ ver2.16-ja編にある処理方法(解決方法、解決状況:Resolution)の一覧が分かりやすい。
解決状況とは、バグがどのような作業によって終了したかの状態を表している。

普通のバグ修正ならば、「修正済み」(Fixed)で終わるが、「発見したバグは仕様通りです」という検証結果になったら、「修正しない」(Won't fix)になる。
あるいは、発見したバグは、以前見つけたバグの原因と同じなので、同類バグの扱いとなり、以前見つけたバグの修正と検証によって、「同件完了」(重複:Duplicate)で終了になる時もある。
あるいは、見つけたバグを再現することができず、修正方法が分からない場合は、「問題を確認できません」(worksforme)として保留状態となり、放置される。

BTSにおいて、解決状況を使う理由は、終了状態ごとにバグを集計して、システムの品質やテストプロセスの品質を探りたいからだ。
「修正済み」のバグが普通は多いだろうが、「重複」のバグが多いならば同類バグが多いことになり、バグの原因の深堀りが出来ていないことになる。
TestLinkなどのテスト管理ツールにあるブロックを使えば、似たようなバグを見つけることもなく、別の原因のバグを見つける工数を確保することもできたはず。

あるいは、「修正しない」バグが多いなら、そもそもテスターはきちんとテストしているのか、という疑いも発生する。
つまり、「重複」「修正しない」バグが多いなら、テスターの作業品質が悪いのではないか、という推測も成り立つ。

以下、Mantis、Trac、Jiraの解決状況の使い方について理解できたことを書いてみる。

【2】Mantisの場合、チケットのステータスは担当者の作業状態(修正中、解決済みなど)を表す。
チケットの解決状況はそのバグの終了状態を表すが、解決状況が「実装済み(Fixed)」の場合のみ、変更履歴画面に出る仕組みになっている。それ以外の解決状況では、ロードマップに表示されるものの、変更履歴画面に表示されない。

つまり、ロードマップに示された修正予定バージョンごとに、対応すべきチケットは一覧表示されるが、「実装済み」の解決状況の場合だけ本当にバグ修正されたので、変更履歴画面に示された修正済みバージョンごとに表示されることを意味している。
「実装しない」「保留」の解決状況のチケットは、ソースに何の修正も混じっていないので、変更された履歴に表示する必要もないわけだ。

【3】Tracの場合、解決状況はチケットの単なる属性に過ぎない。
普通は、MantisやBugzillaと同じく、チケットを終了する時に、その終了状態の意味を持たせることもできる。

Tracの優れたクエリ機能を使えば、解決状況ごとにチケットを集計して、プロジェクトの状況を探ることもできるだろう。

【4】Jiraの場合、解決状況はチケットの終了条件に関わる属性であるが、更にワークフロー設定と関係する機能になっている。
例えば、1.9.1. JIRA ワークフローによれば、ステータスが新規又は担当中のように作業中の場合は、解決状況は「オープン」のままになる。
そして、ステータスが完了になる場合、解決状況は「修正済み」「再現不可能」などの値を設定する必要がある。

Jiraの解決状況は、JIRA ユーザーガイドを読む限り、課題(チケット)を集計表示する時に重要な項目の一つであるようだ。

Jiraのワークフロー設定はRedmineと同様に自由にカスタマイズ可能だが、分岐が多くなるときちんと設計しなければ分からなくなるので注意。
普通は、ワークフローのテンプレートをあらかじめ作っておき、そのテンプレートを流用する方が良いと思う。

【5】だが、Redmineには解決状況というチケットの属性は存在しない。
カスタムフィールドを作れば対応出来るだろうが、あえて作る程でもないように思う。

結論を言うと、BTSの解決状況(Resolution)は障害管理の名残りだ。
チケット完了(Closed、Fixed)の定義が状況で異なる為に、解決状況(Resolution)が必要になったように推測される。

正直、BTSの解決状況(Resolution)はステータスに統一した方が運用は楽だ。
成果物が作られたり、その品質向上に役立つ作業のチケットは「終了(Close)」で終わるのが普通だろうが、中には「対応不要なので却下」「別のチケットと同じなので重複」「同類バグなので別チケットで対応」などのように終了状態が異なる場合もある。
バグの検証時に、ステータスの更新だけでなく解決状況という属性までも更新するのは二度手間のように思える。

終了の意味が違うならば、却下、無視などのステータスを増やせばいいだけのことだ。

Agile開発の場合、終了条件(Done)の意味はとても単純だ。
Doneとは、システムをリリースすること、つまり、顧客へ動くシステムを手渡すことを意味している。
Doneの意味を、ステータスや解決状況という属性にまで細かく分ける必要は特にはないはずだと思っている。

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

RedmineのWorkTimeプラグイン

RedmineのWorkTimeプラグインがとても使いやすいのでメモ。

【元ネタ】
WorkTime - kusu - A redmine plugin to view and update TimeEntry by each user. - Project Hosting on Google Code

Twitter / tkusukawa: WorkTimeプラグインのご紹介、ありがとうございます。書籍に載せて頂けるなんて!やる気出ちゃいました。 @akipii 「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart2

RedmineのWorkTimeプラグインは、チケットの実績工数を入力しやすくしてくれる。
マネージャが好きそうなプラグインだ。

管理が好きなマネージャなら、あらかじめWBSを洗い出して、その担当者と予定工数を計画しておき、Redmineへ一括インポートしておく。
日々の開発では、開発者が毎晩退社前に、担当のチケットへ実績工数をWorkTimeプラグインの画面から入力するように運用する。
そうすれば、日々の予定工数と実績工数を把握できるので、PMBOKのEVMなどの発想を使えば、スケジュールが遅延しているのか、コストがかかりすぎているのか、を精査することができる。

上記のリンクからWorkTimeプラグインの画面を見れば分かるけど、1ヶ月間の日別の実績工数やチケット単位の実績工数を入力しやすいし、一目で参照しやすい。
どのチケットにどれだけの工数がかかっているのか、開発者自身も後から振り返ることができる。

更に、Chartsプラグインを使うと、予定工数や実績工数をグラフ化してくれるので便利だ。

Redmine - PluginCharts - Redmine

プロジェクトの作業工数がどのように増減しているのか、一目で分かるので、プロジェクトの遅延やコストを見える化できる。
バーンダウンチャートのように使ってもいいだろう。

昨今のSW開発では、開発者の工数が製造原価に直結するから、どんな作業にどれだけの時間を費やしたのか、を細かい部分まで把握しておきたい。
そうすれば、活動基準原価計算(Activity Based Costing)の発想を使って、限られた資源(時間)をどのような活動でどれだけの成果物を生み出したのか、を追跡できるから、どの作業にコストをかけ過ぎているのか、最も効率の良かった作業はどれなのか、を探ることもできる。

作業者にとって実績工数を入力するのは結構面倒なのだが、WorkTimeプラグインはその労力を省力化してくれるだけでなく、PSP(Personal Software Process)のように自分の作業を後から振り返って自己改善していくツールとしても使えるだろう。

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

2010/11/01

フォールト・アボイダンスからフェイルセーフ、フォールト・トレランスへ

セーフウェアについて良い記事があったのでメモ。

【元ネタ】
ソフトウェアの安全性を考える - Basic

セーフウェアが必要な理由~ソフトウェアが凶器になる時: プログラマの思索

セーフウェア: プログラマの思索

Webシステムのリリース作業とフォールトトレランス: プログラマの思索

下記の解説が素晴らしい。

(前略)
記事では、製品に占めるソフトの割合が増えるにつれて、日本のモノ作りの「アキレス腱」になってきている現状を指摘した上で、個別最適化から全体最適化への発想の転換を促している。
すなわち、個々の構成要素の信頼性を高めることで安全性を確保する(フォールト・アボイダンス)の考え方から、構成要素が故障しても必ず安全側に落ち着く設計(フェイルセーフ)や、冗長化や多重化等の別手段によって機能を維持する設計(フォールト・トレランス)への変換が必要になってくるのだ。
人海戦術でバグを潰して満足するような日本型開発の限界が見えてきている以上、開発の方向性も変えていく必要がある。
実際、欧米では既にそのような考え方が広まっているようだ。
(後略)

日本の製造業が20年前に比べて輝きを失いつつあるのは、組込ソフトウェアの重要度が増すにつれて、日本が得意としてきた技術のすり合わせの良さが打ち消されつつあるのだろう。
いくらハードの信頼性が高くても、ソフトも一体化されたハードの信頼性が高くなければ、全体の信頼性は落ちる。
しかも、昨今の流れは、各部品の信頼性を高めるよりも、全体最適化の方に重点が置かれているから、日本が得意とする各部品の高信頼性に依存した手法は、効果が出にくくなっているのだろう。

また、ソフトウェアはハードにはない特徴がある。
製造業の発想である「後戻りの無いように計画的に作業の品質を高める」やり方が有効に作用していない。
むしろアジャイル開発のように、試行錯誤しながらVerUpしていく過程で、品質も使い勝手も改善していく手法の方がうまくいく。
例えば、Microsoftの製品はVer3.0になってから品質も使い勝手も良くなると以前から言われていたし、AppleのiPod/iPhone/iPadも小刻みにモデルチェンジしながら品質も使い勝手も改善してきている。

つまり、失敗や障害を発生させないように前工程の信頼性を高めるフォールト・アボイダンスの発想だけではうまくいかない。
ソフトウェアのバグをすべて潰すことはできないという現実に対して、誤動作や故障が発生しても安全に動作させるフェイルセーフや、故障を見越して冗長化させておくフォールト・トレランスの設計手法が重要になってきているのだろう。
当然、ユーザが誤った操作をしても安全に動作することを保証するフールプルーフな設計も大事になってきている。

この発想は組込みソフトウェアだけでなく、Webシステムでもアクセシビリティやユーザビリティなどにもつながっているように思える。

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

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