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

2012年2月

2012/02/27

ITガバメントとは何か?

特許庁のシステム中止の記事を読んで思ったことをメモ。

【元ネタ】
[スクープ]特許庁、難航していた基幹系刷新を中止へ - ニュース:ITpro

特許庁次期基幹システム開発中断~真の問題は役所にITエンジニアが不足していること - 木走日記

特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐 (Publickey) - BLOGOS(ブロゴス)

問題は、アジャイル開発を適用すれば解決するとか、スコープを制御するとか、そういうレベルではない。
本来のあるべきシステムとは何か、という問題のレベルだと思う。

戦略としてどれが必要なのか。それを実現するには何が必要なのか。
グランドデザインを描く能力。フィージビリティスタディを深く問い詰める能力。

こういう話を読むと、ERP導入の失敗事例を連想させる。
あるべき姿はあっても、自分たちの身の丈に合う機能やシステムまで分析できていない。
実際にシステムを稼働した後、本当に価値を生み出しているのか、測定して改善するサイクルが無い。

CIOという役職の人は、そういうことを考えるためにいるのかもしれない。

| | コメント (0)

2012/02/25

チケット駆動開発の適用範囲Part2~チケット駆動開発の運用パターン

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

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

Twitter / @akipii: チケット駆動開発にはいくつかのパターンがある。タスクカードのように扱うタスク駆動が一番やりやすい。システム運用保守やコールセンターはインシデント駆動。システム提案や要件定義なら課題駆動。

Twitter / @akipii: チケット駆動開発では僕は課題駆動が一番難しいかもと最近思う。SEは顧客から本質的な問題を見つけるために課題を何度もぶつけて探す。設計書は課題の回答をパッチのように更新して出来上がる。ソースと同じだ

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

Twitter / @akipii: 影舞、Bugzilla、Mantis、Trac、Redmineに至る歴史を辿れば先人の知恵が分かってくる。BTSの一つ一つの機能には過去の開発者がバグ解決に苦労した形跡がうかがえる。WF型開発でもAgile開発でもSW開発の基本はバグ管理だ。バグ管理を見ればチームのレベルが分かる

Twitter / @akipii: WF型開発とAgile開発ではバグ管理の入り方が違う。WF型開発は信頼性を高めてMTBF(バグが出ない時間)を長くする手法を取る。Agile開発は保守性を高めてMTTR(バグ修正時間)を短くする手法を取る。システムの稼働率を高めるためにAgileとWFは考え方が全く違うのが面白い

Twitter / @akipii: @cointoss1973 Redmineの使い方を他の人はどのように説明しているのか興味があります。Agile開発を重視するのか、厳格なワークフロー管理を重視するのか、GTDのようなタスク管理なのか、課題管理に使うのか。100人分のRedmineの使い方が知りたい。

【1】チケット駆動開発にはいくつかのパターンがある。
一つの観点は、補完チケット方式か完全チケット方式。
もう一つの観点は、トラッカーの観点。

補完チケット方式は特定の工程や特定の作業にチケット駆動開発を適用するやり方。
よくある例は、テスト工程のバグ管理、設計・開発工程のレビュー管理があるだろう。
@machuさんがチケット駆動開発を提唱された時も、テスト工程における細かな作業の管理に使われていた。
その考え方については下記に書いた。

補完チケット方式はチケット駆動開発の先祖返り: プログラマの思索

障害管理からチケット駆動開発へ発展した歴史から見れば、補完チケット方式は先祖返りの開発スタイル。
高機能化したBTSの機能(レポート、ワークフロー、Wiki、SCM連携など)を使えば、より効果的に作業を管理しやすくなるのは当たり前だ。

完全チケット方式はソフトウェア開発で発生する全ての作業をチケット化して管理していく。
以下、完全チケット方式を前提に話を進める。

【2】トラッカーの観点とは、チケットの発生源が何であるか、によって変わってくる。
随分前にも色々考えた。
Redmineを使って気付いたことpart6~チケットの発生源: プログラマの思索

タスクカードのように扱うタスク駆動が一番やりやすい。
GTDのようなタスク管理もできるし、作業指示書として厳格なワークフロー管理の配下に置くこともできる。
僕がアジャイル開発へ適用した時も、タスクカードのように扱うやり方で行った。
要件や仕様の粒度を小さくすることができれば、ストーリーカードのようにチケットを扱ってもっとアジャイルに開発することもできるだろう。

タスクカードのように扱う場合、チケットはすぐに溢れるので、チケットの取捨選択が重要になってくる。
基本は、バージョンをイテレーションに同一視する(「Version is Iteration」)ことによって、アジャイルっぽい開発スタイルになる。
イテレーション単位にタスクを区切っていくタイムボックス的なタスク管理が一番やりやすい。

【3】営業マンや社内の事務の人がITSでタスク管理を行う場合、チケット入力のユーザインタフェースの改良が重要になってくるだろうと思う。
元々チケットは障害報告票が起源なので、入力項目が多すぎたり、複雑な操作になりがち。
それほどITに慣れていない人達にチケット駆動開発に慣れてもらうためには、デスクトップアプリのように使いやすいUIにすることが重要になってくる。
WebならAjaxなりJQueryなりCSSなり、クライアントサイドの技術が必要になってくるだろう。

Redmineのユーザインターフェイスは使いやすい: プログラマの思索

また、WebのUIは一時保存や自動保存の機能が弱いので、せっかく入力した内容が消えてしまってガッカリする時も多い。
そんな場合は、RedmineならDrafts pluginを導入して、自動保存する機能を追加すればいいだろう。

作成途中のチケットを自動保存するDrafts plugin #redmine: プログラマの思索

RedmineでUI改善に可能性を感じる機能は、REST機能だ。
RESTの使い道としては、例えばiPhoneやAndroidなどのスマートフォンからURLを叩けば欲しい情報を取得したり更新したりすることがあげられるだろう。
つまり、スマートフォンやタブレット、TV、携帯ゲーム機などの各種デバイスからサーバーにあるRedmineへアクセスすれば、ブラウザの画面と同じように操作できるUIを作ればいい。
そうすれば、各種デバイス向けにITSの機能を逐一作る必要もない。

RedmineのRESTful APIを使う: プログラマの思索

SOAPからRESTへ: プログラマの思索

RedmineのREST機能は@yohshiyさんの下記のWikiがとても参考になる。

Redmine REST API - r-labs

スマートフォンからRedmineを操作できるならば、外出先で営業マンがタスクを検索したり更新することも楽になる。
あるいは、CIツールJenkinsやテスト管理ツールTestLink、他の外部システムからRedmineへアクセスして欲しい情報を取得したり連携することもできるだろう。
REST機能によるUI改善は大きな可能性を秘めていると思う。

【4】システム運用保守やコールセンターで障害や問合せの管理を行う場合はインシデント駆動になる。
例えば、ネットワーク障害やハード障害が検知されたら、その障害をまず管理票として起票した後、暫定対応を実施したり、影響範囲や根本原因を調査して根本対策を実施したりする。
ITILの概念に慣れていれば、適用しやすいだろうと思う。

ITILのプロセス関連図: プログラマの思索

その場合、技術的に面白い点は、他システムのチケット発行をトリガーとしてチケットを自動登録する機能だ。
よくある例は、障害検知したら普通は障害ログのメールが発行されるタイミングでチケット登録すること。
Redmineにはメールを送付すればチケット登録できる機能があるので、この機能を簡単に実装することができる。

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

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

@haru_iidaさんは、Hudson(Jenkins)から発行されるビルドエラーメールをRedmineに投げて、チケットを自動登録する事例を紹介されていた。

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

チケットを自動登録できる利点は、障害の検知から調査、暫定対応、対応完了に到るまでの作業履歴をチケットに集約しやすいこと。
チケットに作業履歴が一元化されれば、その後の運用保守で過去の事例として参考になるし、障害別にレポート出力すれば障害の傾向分析にも使える。

そして、インシデント駆動の場合はタスク駆動以上にレポート機能が重要だ。
普通は障害の発生原因は特定のパターンがあるし、障害が発生しやすい環境を是正する対策作りにレポートがとても役立つからだ。

【5】システム提案や要件定義でチケット駆動開発を運用するなら課題駆動になる。
僕は課題駆動が一番難しいかもと最近思っている。
何故なら、SEは顧客から本質的な問題を見つけるために課題を何度もぶつけて探すからだ。
そして、提案書や設計書は課題の回答をパッチのように更新して出来上がる。

課題管理のチケット駆動開発: プログラマの思索

顧客の曖昧な要望、作れたらいいなという希望から実際に使えるシステムへ変換する作業はとても難しい。
アジャイル開発はその作業の一つの手法だが、多分それだけでは足りない。

もっと基本的な手法が必要な気がしている。
つまり、要望をシステム要件に落とす時、フィージビリティスタディ(実現可能性)をどこまで深く考えているか、という能力に大きく左右される気がしている。
その技術はよりソフトウェア設計の基本的なものだ。
この辺りはもう一度まとめ直す。

| | コメント (0)

2012/02/12

@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を解読してみる #RxtStudy #47redmine

@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を@sakaba37さんと読みながら、自分が理解してなかった点がたくさんあることが分かった。
気付いたことをメモ書き。
間違っていたら後で直す。

【shinagawa.redmineの講演資料】

【RxtStudyの講演資料】

【1】SVNリポジトリのスケールアップ

チケット駆動開発の特徴は、ITSにSCM連携の機能があることで、トレーサビリティやソース変更履歴を即座に確認できる利点がある。
しかし、5人ぐらいの小規模開発チームから数百人以上の大規模な組織で運用する場合、SVNリポジトリがダウンしてしまうケースが出てくる。
そもそもRedmineのようなOSSのITSでは、大規模な運用における可用性や信頼性に関してはまだまだ弱点がある。
それについては下記で書いた。

Redmineの大規模化の壁: プログラマの思索

@daipresentsさんの現場ではユーザ4000人がRedmineを使っていると言う。
多分、日本でも最大規模の運用事例だろう。
上記の講演資料では、SVNの構成方法について、マスタ・スレーブ方式で解決する方法が示されている。

この仕組みは、ReadOnlyの参照用SVNリポジトリとReadWriteの更新用SVNリポジトリをsvnsyncでリアルタイムに同期させることで実現している。
すなわち、ITSからリポジトリブラウザの閲覧は参照用SVNリポジトリ、コミットログにチケットNoを書いてSVNコミットする場合は更新用SVNリポジトリで使い分ける手法だろうと思う。

この手法の利点は、大量ユーザがアクセスする参照用SVNリポジトリと更新頻度が少ない更新用SVNリポジトリを別に配置することによって、負荷分散する点にある。

@daipresentsさんは過去の記事で、SVNの構成方法についてたくさん考察されており、実際にたくさん試されている。

Subversionのシステム構成を考えてみた | 世界

svnsyncを使ってリポジトリレプリケーション | 世界

更に、SVNのWebDAV transparent write-through proxyを使えば、複数の更新用SVNリポジトリを同期させることができるので、よりスケールアップしやすくなる。
Apacheサーバーのスケールアップは既に色んなノウハウがあるが、SVNリポジトリでも同様にスケールアップは可能。

Subversion1.5のWebDAV transparent write-through proxy | 世界

Subversion 1.5.0 での新機能 (WebDAV Write Through Proxy)

エンタープライズ環境におけるSubversionの複製アーキテクチャ - インターネットコム

Subversionを見直せ: プログラマの思索

SVNリポジトリのスケールアップが必要な理由は、RedmineチケットとSVNリビジョンを紐づける仕組みでも使いたいからだ。
普通はコミット後、RedmineのSVNリポジトリ画面をリフレッシュしないと紐付けが実施されない。
だから、Webサービス機能を使って、リアルタイムに同期させる手法が普通だろう。

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

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

しかし、この機能は大量ユーザのコミットや大量データのコミットに向かない。
スケールアップするには、JenkinsでSCM連携をポーリング化する手法があるだろうと思う。
そのアイデアは下記に書いた。

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

Redmineの運用が大規模化するにつれて、RedmineそのものがIT企業の基幹システムになり、可用性や信頼性がよりシビアになってくる。
@daipresentsさんの講演資料にはたくさんのアイデアが含まれていると思う。

【2】Parkinglot Chart Pluginの利点、そしてITSの概念とプロセスのマッピング

@daipresentsさんは以前から、Redmineプラグインの中でパーキングロットチャートプラグインを絶賛されていた。

Redmineプラグイン開発 -- パーキングロットチャートプラグインリリース | 世界

3年使ったRedmineの使い方について共有したい10のこと | 世界

パーキングロットチャートはフィーチャ(ユーザ機能)の進捗を示すための図だ。

ユーザ機能駆動開発FDDを再考: プログラマの思索

パーキングロットチャートが何故そんなに重要であり、開発者だけでなくマネージャや経営層にも使われるようになったのか?
Redmineのパーキングロットチャートプラグインは、Redmineのバージョンをフィーチャ(ユーザ機能)に対応付けて運用する。
Redmineのバージョンはリリース予定(済)バージョンだから、実際にリリースされるシステムのバージョンに相当する。
そもそもリリースするバージョンには、顧客の要望にあるビジネス要求を実現するための機能が含まれていて、その機能がリリースされることで顧客価値が実現される。
だからこそ、Redmineバージョンは単なるリリース予定バージョンだけでなく、顧客のビジネス要求を実現する日を示しているのだ。

従って、顧客のビジネス要求の単位でフィーチャを作り、フィーチャをRedmineバージョンに対応付ければ、フィーチャが今どんな進捗状況であり、いつリリースされてそのフィーチャが使えるようになるのか、を示すことができる。
システムのバージョンは単なるSCMタグやITSバージョン、Agile開発のイテレーションに対応するだけでなく、ビジネス要求のフィーチャにも対応付けている点がとても重要だ。

@daipresentsさんの講演資料では、パーキングロットチャートが100個以上並んでいる絵が貼られており、Redmineがビジネス要求の実現のために運用されていることがとてもよく分かる。

この発想を更に突き進めると、Redmineのプロジェクト・バージョン・チケットの概念はプロセスのどれにマッピングできるか、という問題にぶち当たる。
その問題については下記で考えてみた。

ITSと開発プロセスのマッピング: プログラマの思索

@daipresentsさんの講演資料では、タスクをFeature・Release・Iteration・Taskの4つの概念に分けて、Scrumのようなアイデアでタスク管理を回そうとされている。
僕の理解では下記のようになる。

(2-1)Feature:顧客の本来の要望。PivotalTrackerのIceBoxと同様。つまり「~の機能が欲しいなあ」というレベルの要望であり、実現可能性(フィージビリティスタディ)は考えられていない。

(2-2)Release:リリース計画に入れられたFeature。PivotalTrackerのBacklog、Scrumのバックログと同様。Featureの実現可能性(フィージビリティスタディ)を考慮して、実現可能なサイズのストーリーへ更に分割する。
Featureに優先順位がつけられて、優先度の高いFeatureから順に開発対象となりリリースされていく。

(2-3)Iteration:XPのイテレーションやScrumのスプリントと同じ。PivotalTrackerのTaskBoardと同じ。2~4週間のサイクルでFeatureを開発してリリースしていく。

(2-4)Task:実際の作業。タスクカード。3~4人日というサイズから推測すると、ストーリーカードに近い。

@daipresentsさんの講演資料では、Feature・Release・Iteration・Taskを下記のようにRedmineの機能へマッピングしようとしている。

Feature →Redmineのプロジェクト?
Release →Redmineのプロジェクト?
Iteration →Redmineバージョン
Task →Redmineチケット

僕の考えでは、FeatureやReleaseはRedmineのプロジェクトではなく、Redmineバージョンに対応付けるべきだと思う。
理由は、Redmineプロジェクトは製品に対応付けられる概念であり、FeatureやReleaseは顧客に届ける製品の一機能に過ぎないからだ。
むしろ、FeatureやReleaseはリリース日が無期限のRedmineバージョンに対応付けるべきだと思うからだ。

つまり、FeatureやReleaseにあるTask(チケット)は、優先度が決められてリリース予定日が確定すれば、該当するRedmineバージョン(イテレーション)に移動されて、開発の対象(リリース対象)になる運用になる。
僕も、「内部課題」「仕様変更の要望」といったリリース予定日を100年後に設定した特別なバージョンを用意しておき、似たような運用はしている。

なお、PivotalTrackerやそのクローンであるFulcrumは下記で書いた。
よりアジャイルに開発したい人はそれらのツールを使ってもいいかもしれない。

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

Pivotal TrackerクローンのFulcrum をインストールしてみた: プログラマの思索

上記の概念を実運用されている@daipresentsさんの講演資料はとても参考になる。

【3】リスク主導のタスク管理とタスク主導のタスク管理の違い

@sakaba37さんと話しながら思ったことは、僕や@sakaba37さんのチケット駆動開発と@daipresentsさんのチケット駆動開発は違っていること。
@daipresentsさんのチケット駆動開発は、本来のAgile開発に近いと思う。

@daipresentsさんの講演資料では、ユーザストーリーマッピングの写真が出てきて、FeatureやReleaseに出てくるTask(実際はおそらくストーリーカード)を並べる作業が出てくる。
ユーザーストーリーは、昨年のAgileJapanで懸田さんが講演された時に説明を受けたが、それは、縦軸を優先度、横軸をリリース日としてユーザストーリーを並べて、ユーザストーリーの依存関係や本来あるべきビジネス要求の開発順序を考えるために使われていると聞いた。

ユーザストーリーマッピングが最強という@daipresentsさんの資料があるけれど、その意味は、ユーザストーリーマッピングを使って、顧客のビジネス要求を優先度(実際はビジネスの重要度)やリリース日の観点で分類して、タスク管理をやりやすくすることに使っているのだろうと思う。
つまり、FeatureやReleaseレベルのストーリーは、ユーザストーリーマッピングで複数人のSEが自由に議論しながら、ビジネスの重要度やリリース日の観点で精査した後、直近の優先度の高いストーリーから順に開発対象に回して、アジャイルに開発していく運用フローなのだろうと推測する。

その運用フローは、まさにアジャイル開発のタスク管理そのものであり、Redmineをわざわざ使うこともない。
TracでもJiraでもいいし、アナログのPostItでやってもいい。
RedmineチケットはFeatureから「あらかじめ」洗い出されたタスクカード(ストーリーカード)であり、予期しないタスクではない。

逆に、僕や@sakaba37さんのチケット駆動開発は、障害管理の発想を受け継いだ開発スタイルなので、もちろん当初予定されていたタスクはRedmineチケットにあるが、開発中に発生した予期しないタスクもRedmineチケットへ随時発行して管理していく。
だからこそ、リリース日には、当初見込んだタスクよりも2倍近いチケットが実際はこなされている時が多い。
つまり、タスク管理だけでなく、リスク管理や課題管理としてRedmineを運用している。
そして、Redmineをソフトウェア工学の観点で、メトリクス収集のツールとしても重要視している。

本来のAgile開発のタスク管理では、イテレーション中にストーリーカードやタスクカードが増えることはない。
イテレーション実施中の2~4週間はスコープは固定されているのが前提。
でも、僕が実運用していた時、緊急の障害修正や突然の仕様変更に対応する場合は結構あったから、イテレーション中にスコープ変更はやっていた。
だから、本来のAgile開発とは言えない部分がある。

どちらの手法が正しいといわけではないけれども、本来のAgile開発のタスク管理は@daipresentsさんの講演資料の方が近いだろうと思う。
色々考えてみる。

| | コメント (0)

課題管理システムJIRA入門

課題管理システム JIRA入門」が今月出版されるらしいのでメモ。

Twitter / @akipii: ついに出た!これで、Redmine・Trac・Jiraという有名ITSが一通り書籍で揃った。 課題管理システム JIRA入門: Patrick Li, リックソフト株式会社, 大貫浩, 渡辺裕美, 樋口晃, 小川環:

Tracは2刷、Redmineは3冊が既に刊行されている。
どの本も良い本だと思います。

しかし、JiraはITSの古株にも関わらず出版されていなかった。
だから、Jiraで不明点が出たらネットから探すしなかった。
だが、ようやくJira本が出ることによって、Redmine・Trac・Jiraという有名ITSのインストール方法や使い方に関する書籍が一通り揃う事になる。
ITS導入やITS運用で情報収集や比較する場合、これらの書籍が役立つだろうと思います。

| | コメント (0)

2012/02/11

Redmine1.4.0で待望のRuby1.9サポート

Redmine1.4.0でRuby1.9がサポートされるらしいのでメモ。

【元ネタ】
Twitter / @yusuke_kokubo: #redmine v1.4は開発始まってまだ2ヶ月くらいだけどけっこう色んな機能が実装されてる。今残ってるのはMultiple SCMとRuby1.9supportなんだけどどっちも鬼門だな。JPLの長期休暇前にはリリースできるのかな。 redmine.org/versions/40

1.4.0 - Redmine

Feature #4050: Ruby 1.9 support - Redmine

Feature #4796: Rails 3 support - Redmine

Ruby1.8.7の今後につきましてによれば、Ruby 1.8系統は2013年6月でメンテナンスが終了してしまう。
つまり、Ruby1.8の寿命は2013年6月で途絶えてしまう。
だから、Redmineが今後も発展するためには、Ruby1.8.7のメンテナンスが終了するまでにRuby1.9へ対応しなくてはならない。

RedmineをRuby1.9やRails3に対応して欲しいという要望は、随分前から数多くのユーザからあがっていた。
一部のユーザは、RedmineのRuby1.9やRails3に対応した、とアナウンスしていたが、Redmine公式サイトではそれらのパッチは取り込まれていない。
Redmineコミッタ丸山さんに聞いた所、Redmineのテストはとても厳しいのでテストソースもなければパッチを受け付けられないと聞いた。
Ruby1.9対応ではたくさんのパッチとテストソースが必要だから、そう簡単に実現できないのだろう。

Redmineロードマップを見る限り、Ver1.4は3個のチケット以外はすべて終了されている。
Ver1.4にRuby1.9対応が含まれていることから、Redmineコミッタもその重要性を認識しているのだろう。

Ruby1.9対応では丸山さんが精力的に更新されているので、そう遠くないうちにリリースされるだろうと期待しています。
RedmineがRuby1.9に対応されることによって、今後も先進的なプロジェクト管理の実験場としてRedmineが使われていくだろうと思っている。

| | コメント (0)

2012/02/05

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

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

【1】hinoのバインダー / Redmineによるタスクマネジメント実践技法 - メディアマーカー

(引用開始)
・チーム内の仕事をタスクカード(=チケット)で管理するというのは、カンバン方式と同じで、それを電子化したモノなので、ソフトウェア開発だけではなく、他の仕事でも使える方法という気がする。
・紹介されているアプリは、Windows環境で動作し、インストールもパッケージ化されて簡単で、しかもオープンソースで無料の為、導入し易いと思う。
・要求、仕様、ソース、テスト結果、バグ管理をチケットに紐付けて管理するというのは面白いと考え方だと思う。
・派生開発のXDDPでも、要求と仕様、ソースを要求仕様TMでExcelにマトリックスを作成する事を推奨していて興味深かったのだが、Excelの為、マス目の数に限界があり、制約となっていた。
 その点、チケット駆動開発では、チケットをデータベースで管理する為、Excelのような縛りもなく、検索・抽出も容易に思えるし、考え方もXDDP的な所もあり、好感が持てる。
 (引用終了)

XDDPの特徴とチケット駆動開発のトレーサビリティを比較しているのが面白い。
僕もXDDPからは沢山の刺激を受けているので参考にしている。

【2】時々、Twitterに感想を見かけるのでメモ。
Twitter / @akipii: ありがとうございます! RT @islandcoral: これマジ良い本だなあって読んでて思った。Redmine使ってなくても参考になる内容だと思う。 Redmineによるタスクマネジメント実践技法 小川 明彦

Twitter / @akipii: ありがとうございます RT @empiriLLC: 小川明彦、阪井誠著「Redmineによるタスクマネジメント実践技法」を時間をかけて通読した。すばらしい。RedmineとTestLinkを一部操作しながら読んだのでイメージが掴める。時代はチケット駆動だ!

Twitter / @yagian: 【Redmineによるタスクマネジメント実践技法/小川 明彦 他】プロジェクトに限らず定型的業務の継続的改善にも使えると思った。ただ、組織のメンバーが受容してくれるかが問題。 →http://bit.ly/uR0d1n #bookmeter

Twitter / @mihoko_az: 『Redmineによるタスクマネジメント実践技法』読了!何個かハッとしたところがあった。特にインクリメンタルとイテレーティブのところ。

Twitter / @TakuSugioka: 『Redmineによるタスクマネジメント実践技法』を読んだ。Redmineは2007年にチケット駆動開発というネーミングに魅かれて自分のプロジェクトに導入して以来ずっと使い続けているけど、はじめて知る内容も多く面白かった。

Twitter / @haradaj: Redmineによるタスクマネジメント実践技法 "Redmineのインストールなど普通の入門書に書いてあることから、実際のプロジェクト管理の手法やRedmineを適用する際の注意などまで言及してあり、読了した時点で現場に適用できるのではと思わせる良書と思います。" http://goo.gl/RQLwP #byflow

Twitter / @yutabnbn: "Redmineによるタスクマネジメント実践技法"という本を楽天で買おうとしたらこんなレビューが。「夫が仕事関係で必要になり、購入を頼まれました。毎日付箋をつけているので、きちんと読んでいるようです。」何の参考にもならんw http://ow.ly/6NHKR

他に、チケット駆動開発を自分たちの製品開発で使っているつぶやきを見つけたのでメモしておく。

Twitter / @monchan_dennen_: 第3の特徴はアジャイル開発との親和性が高い「チケット駆動開発」だ。リリース計画、スコープ管理、タスク管理は全てをチケット駆動で行なっている。また、SaaSの利点を生かし、非常に短いサイクルでリリース(改正対応、機能追加、バグ修正)を行なっている。ちなみに現状は一週間のサイクルだ。

Twitter / @monchan_dennen_: 補足② 開発設計書の変更履歴はすべて自動的に管理され、チケット駆動と結びつくことで、開発者、QA担当者は、変更の数や影響を即座に把握できる。またお問い合せ、バグ等の不具合や改善要望、それら全ては開発部門の「チケット管理」に連携して統合され、機動力のある効率よい開発を実現している。

他にも、チケット駆動開発の感想をメモしておく。

Twitter / @altnight: しかしチケット駆動開発はとても理にかなってるし洗練された手法だと思う。やるべきタスクをとにかく箇条書きでもどんどん上げる。そのうえで優先度をつけてチケットをこなす。お互いやるべきタスクが一目瞭然だ。もしtracやredmineがなかったらという時代を想像できない

チケット駆動開発をアジャイル開発の一実装例として使っているのが興味深い。
アジャイル開発を実運用したい時、チケット駆動開発が最も簡単な方法の一つになるだろうと思っている。

| | コメント (2)

Googleのバグ予測アルゴリズム

Googleのバグ予測アルゴリズムの記事があったのでメモ。

【元ネタ】
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している - Publickey

グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開 - Publickey

Googleのバグ予測アルゴリズムを実装した「bugspots」のSVN版を作ってみた - 現場のためのソフトウェア開発プロセス - たかのり日記

【1】バグの予測に関する研究は従来からたくさん行われてきた。
信頼度成長曲線もそうだし、クローンプログラムのメトリクスもそうだ。
上記の記事によれば、もっとシンプルにコミットログからバグの傾向分析を導くアルゴリズムのようだ。

(引用開始)
彼らが発見したのは、そのコードに対してこれまでバグフィックスのコミットが何回行われたかをランキングすることで、コードの中のホットスポットを見つけられるだろう、というものです。まさにシンプル! そしてこれは私たちの直感、もしも何度もバグフィックスが必要なファイルはデベロッパーが苦労しているところだからホットスポットに違いない、というものにマッチするのです。
(中略)
つまり、より高頻度にバグを修正し、かつ最近になって集中的に直しているほど、スコアが大きくなります。そしてスコアが大きいほど、相対的に見てそのコードにはバグがある可能性が高い、というのがこのアルゴリズムが示すところです。
(引用終了)

面白い点は、直近に頻繁に修正しているほどバグが埋め込まれている可能性が高い、ということ。
バグを見つければ、普通はできるだけ早く直そうとする。
だが、バグ修正時に新たなバグを埋め込む危険性が高い事実は、従来から知られていた。
また、バグ修正時にコードレビューやデザインレビューの作業も含める時が多い。
でも、バグが頻発すれば、作業をShortcutするときも多く、バグを根治するのは難しい。

バグ予測できれば、現状の品質がどれくらいなのかを把握することができるし、後どれくらいテストすれば品質を担保出来るか、という見積りにも使えるだろう。

【2】チケット駆動開発の観点では、コミットログに必ずチケット番号が振られている特徴から、ソース修正のリビジョンがどんな変更理由で修正したのか、をチケットから追跡する仕組みがある。
この仕組みによって、ソース修正がバグ修正なのか機能追加なのか、を区別できるし、チケットの属性にある優先度や障害原因、影響度も分析の対象にすれば、より詳細なバグ予測情報を提供できるはずだ。

つまり、コミットログに紐づけられたチケットの情報を拾い出すことで、ソフトウェアメトリクスに関するいろんな情報を引き出すことができる。
そんなアイデアは、下記で一番最初に書いた。

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

BTSに一元化されたデータ、SVNコミットログは、ソフトウェアメトリクスを研究する研究者にとって、一攫千金の宝物が秘められている。

【3】バグ予測に関しては、僕も別のアイデアを下記に書いた。

Redmineにお勧めソース機能が欲しい: プログラマの思索

SVNコミットログにあるチケット番号を収集して、ソース修正時に過去のチケット履歴から他のソースにも注意した方がいいよ、みたいなサジェストが行えるきのがあればいいな、というアイデア。
技術的には、レコメンドエンジンを使えば実装可能だと思う。

また、オープンソースのツール(Eclipse、Apache)のコミットログを対象に、金曜にバグを発生させるコミットが多い事実を指摘した論文についても下記に書いた。

金曜にバグを発生させるコミットが多い: プログラマの思索

プログラムは人間が書くものだから、人間の生活や特性に関係してくる点からそういう経験的事実が出てくるのだろうと思う。

Redmineでは、Redmine Graph Activitiesプラグインを使うと色んな観点でメトリクスを一覧表示してくれるのが面白い。

活動ログを解析するRedmine Graph Activitiesプラグイン: プログラマの思索

ソフトウェアメトリクスの中でも、コミットログはたくさんの可能性を秘めていると思う。

| | コメント (0)

2012/02/04

【告知】AgileJapan2012でチケット駆動開発の講演とパネルディスカッションやります #aj12

開催決定!! 
Agile Japan 2012
今こそ語り合おう、アジャイルのABC ~Agileを知る、Businessをつくる、Changeを起こす~

2月17日(金)までの申込は参加費が50%OFFとなります。
お申し込みはお早めにどうぞ!
お申込み・詳細はこちらから。

★ facebookページ ★
★ Twitter ★

■━━━━━━━━━━━━━━━━━━━━━━━━━━━■

大好評のうちに幕を下ろした Agile Japan 2011 からはや9カ月、
みなさま、いかがお過ごしでしょうか?
今年もAgile Japanの開催が決定し、コンテンツが続々公開されています!

4回目を数える Agile Japan、今年のテーマは
『今こそ語り合おう、アジャイルのABC』 ~Agileを知る、Businessをつくる、Changeを起こす~
このテーマのもと、実行委員会もチャンレンジしています。

チャレンジのひとつとして、実行委員長も平鍋さんから
パナソニックAVCマルチメディアソフト(株)の西河さんへ、
メイン会場も東京から大阪に移して開催いたします。

この開催にかける想いは、是非、西河実行委員長のご挨拶をご覧ください。

基調講演は以下の2本立てが決定いたしました!

----------------------------------------------------------
【キーノートセッション-1】

「アジャイルラムライ」著者 Jonathan Rasmusson 氏による
『The Surprising Science Behind Agile Leadership』
~ アジャイルリーダーシップの背後にある驚くべき科学について ~
----------------------------------------------------------
【キーノートセッション-2】
ゴールドラット・コンサルティング・ディレクター 岸良 裕司 氏による
『全体最適のマネジメント改革』
~ 変えるのは現場ではない、マネジメントである ~
----------------------------------------------------------

セッションはABC(Agile/Business/Change)の軸で開催します(以下、抜粋)
アジャイルジャパン2012プログラム

----------------------------------------------------------

【Agile セッション】
『アジャイル開発 基本のキ』
株式会社永和システムマネジメント 西村 直人 氏

『チケット駆動開発の課題と展望』
XPJUG関西  小川 明彦 氏
株式会社SRA 阪井 誠 氏
TIS株式会社 中村 洋 氏

<講演内容>
昨今、高機能化した課題管理システムをソフトウェア開発のプロジェクト管理に適用して、Agileに開発するチケット駆動開発(TiDD:Ticket Driven Development)が静かに広まっています。
昨年は関西(RxtStudy)関東(Shinagawa.redmine)のRedmineコミュニティが発足し、チケット駆動開発の運用事例や運用ノウハウも数多く知られるようになってきました。
本講演の前半は、チケット駆動開発には現在どんな課題があり、今後どんな方向へ進化すべきなのか、についてお話します。
後半では、チケット駆動開発を実践されている阪井さんと中村さんも交えて、経験談を中心にパネルディスカッションします。

『アジャイルな開発からアジャイルな組織へ』
~ 継続的に価値を届けるために進むべき道 ~
株式会社アイ・シー・アイ 吉羽 龍太郎 氏

----------------------------------------------------------

【Business セッション】
『「大規模アジャイル開発体験からのメッセージ」+ミニパネル討論』
株式会社オージス総研 鈴木 淳三 氏/細谷 竜一 氏/藤井 拓 氏

『アジャイルをも活用した新しいビジネスモデル』
株式会社永和システムマネジメント 市谷 聡啓 氏
株式会社ソニックガーデン 藤原 士朗 氏
株式会社アッズーリ 濱 勝巳 氏

----------------------------------------------------------

【Change セッション】
『常識の壁を打ち破れ』
~大手ベンダーにおける新たな取り組みへの挑戦事例~
NECシステムテクノロジー株式会社 高橋 康 氏
株式会社富士通関西システムズ   中江 功 氏

『現場に続くAgileの道を語ろう』
~アジャイルサムライ読書会が変えてきたこと~
株式会社アルティネット 梶浦 毅一 氏
株式会社エイチーム 矢島 卓 氏
----------------------------------------------------------

なお、今回も昨年に引き続き、「地方サテライト開催」を実施いたします。
基調講演をストリーミング配信し、午後は各会場のオリジナルセッションでお届けします。
東京を含む、各会場の詳細は随時公開しておりますので、是非ご覧ください。

=============================
Agile Japan 2012 開催概要
=============================

■開催日時 2012年3月16日(金)

■開催場所

ATCホール(南港ポートタウン線「トレードセンター前」下車すぐ)
大阪市住之江区南港北2-1-10

■主催 アジャイル ジャパン 2012実行委員会

■参加対象

IT関連企業、ユーザ企業に所属され、 ソフトウェア開発のプロジェクトマネージャ、チームリーダーの方

■参加人数:200名

■参加料:有料
(通常10,000円/早割5,000円/ペア割り15,000円/ペア早割7,500円)
※2月17日(金)までのお申込は特別価格となりますので、
是非、お早めにお申し込みください! お申込はこちら

●プログラム・詳細
公式サイト
facebookページ
____________________________

みなさまのお申込みをお待ちしております。
是非、同僚のみなさまや、お友達もご一緒にお越しください。

┏━━━━━━━━━━┓
公式Facebookページ
┗━━━━━━━━━━┛

既にご存知かもしれませんが、公式のFacebookページをご用意いたしました。
セッションの詳細、おすすめ情報などなど、Agaile Japan2012に関する情報を
随時お伝えしていきますので、ぜひチェックお願いします!

【お問い合わせ】
アジャイルジャパン事務局(株式会社ピーク・ワン内)
〒160-0004
東京都新宿区四ツ谷2-4-1 ルネ四谷ビル2F
tel:03-6273-1008 E-mail: info@agilejapan.org

| | コメント (0)

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