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

2010年9月

2010/09/26

TestLinkとRedmineでシングルサインオン認証の連携

SundayWalkerさんがTestLinkとRedmineの認証でシングルサインオンの連携の方法を試されていたのでメモ。

【元ネタ】
TestLink1.9b6 CAS (SSO) パッチ (Testlinkjp-users) - TestLink日本語化 - SourceForge.JP

Redmine - Plugin List - Redmine

シングルサインオン認証を使うために、Tomcatを使い、TestLink1.9beta6とRedmineのCAS-single-sign-on-authentication-pluginを組み合わせた方法を提案している。

TestLinkとRedmineの両方でシングルサインオン認証ができれば、一つのログインIDとパスワードで複数のWebシステムにログイン可能になるので、操作が簡単になる。
ログイン認証がたくさんあるほど、ユーザは自分のパスワードを忘れやすくなり、Web管理者の作業が煩雑になりやすい。

似たような他の例としては、LDAP認証がある。
Redmineでは、LDAP認証がデフォルトで設定可能になっている。

Redmine.JP | LDAP認証

LDAP認証でADユーザを使ったredMineへのログイン - あぁ そうだった

また、TestLinkでもLDAP認証は設定可能だ。

TestLink:LDAPで認証: 気の向くままに・・・

TestLinkとRedmineでLDAP認証できれば、自社のWebシステムのログイン認証も共通化できるので、パスワード忘れがなくなる利点がある。

今後、ソフトウェア開発では、複数のWebシステム(Subversion, Redmine, TestLink etc.)をプロジェクト単位に使い分けたりする時に、シングルサインオン認証やLDAP認証できれば、より便利になるだろう。

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

2010/09/25

電子書籍の作り方part6

ChainLPというソフトを使うと、画像ファイルを簡単にepub化できる。

【元ネタ】
No.722

ChainLP

厳選! PDFフリーソフト        ChainLPの詳細

Kindle 3 ChainLP で快適に

iBooks用のEPUB形式電子書籍の作り方 | iPod/iPhone/iPadのすべて

お先に!iPadのためにePubを作成する方法 | EeePC カフェ

手元にある画像ファイルをChainLPへ読み込んで、目次やタイトルを付ければ、epub以外にPDFやKindle形式にも出力可能。
但し、zip32.DLL、zip32j.DLLもChainLPと同じ場所に配置しておく必要がある。

さっそく、画像の素材を電子書籍化して、CalibreでiPod touchに同期して、Stanzaで読んでみた。
雰囲気はとてもいい感じなのだが、画像が縮小されてしまい、文字が小さくて見づらい。
iPadなら十分に読めるだろうと思う。

とはいえ、ChainLPは機能も豊富で、ZIP化した画像ファイルも取り込めるし、青空文庫を直接読み込むことも可能だし、テキストファイルを縦書きにするのも可能みたい。
写真集を作るならChainLPが一番いいかもしれない。
SigilとChainLPを使い分けてもいいかもしれない。

最近は、自分のBlogを電子書籍化したり、Web上で気になった記事をepubで作ったり、試験勉強で覚えた単語をepubでまとめておいたりしておき、空き時間にiPod touchで読み返している。
結構、読みやすい。

個人的には、他人のBlogをepubへ一括変換するツールが作れないか、色々試している。
RubyやPerlならすぐに作れそうなのだが、目次やタイトルを凝りだすとなかなか作りにくい。
Webもepubに見合った形式に今後変換されるといいけれど。

電子書籍は数多くの可能性を秘めている。

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

TortoiseHgもRedmineチケットへの接続をサポート

TortoiseHgもRedmineチケットへの接続をサポートしたことをHaru Iidaさんのつぶやきから見つけたのでメモ。

【元ネタ】
Twitter / Haru Iida: TortoiseHgもサポート Redmine: Activity - Plugins: RE: TortoiseSVN plugin to visualise the issue list in Commit windows

Redmine - TortoiseSVN plugin to visualise the issue list in Commit windows - Redmine

redmine-projects - Project Hosting on Google Code

どうやら、TortoiseSVNだけでなく、TortoiseHg、TortoiseGitのコミットウィンドウからもRedmineチケットへリンクできるようになったらしい。
つまり、何もEclipseのような重いSVN/Mercurial/Gitクライアントを使わなくても、TortoiseSVNやTortoiseHgでRedmineチケットと簡単に連携できる。

何よりもTortoiseHgやTortoiseGitとRedmineが連携できるようになったので、日頃はTortoiseHgを使っている自分としては嬉しい。
分散バージョン管理の利点は、リポジトリのクローンをローカルに簡単に作れるので、サクサクCommitできるのが気持ちいい。
その時にサーバーにあるRedmineチケットと連携できるのはありがたい。

関係ないけど、redmine-projects - Project Hosting on Google Codeにある亀アイコンの甲羅が赤色なのが可愛い。

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

2010/09/24

「Redmineによるタスクマネジメント実践技法」が翔泳社オンラインショップで予約販売開始 #TiDD

Redmineによるタスクマネジメント実践技法」が翔泳社オンラインショップで予約販売開始されました。

Redmineによるタスクマネジメント実践技法 - 株式会社翔泳社:SEShop.com

Amazonと内容は変わりありませんが、表紙に注目して欲しいです。
サブタイトルは「チケット駆動開発 + テスト工程管理のAtoZ」で、「チケット駆動開発」という単語が入りました。
又、「No Ticket, No Commit!」「現場発! 下流工程の劇的改善法」という販売文句も掲載されています(笑)
その経緯は、さかばさんが書いてくれています。

[TiDD] 出版裏話1:没になった原稿 - なぜ「チケット駆動開発」と呼ぶのか -: ソフトウェアさかば

[#TiDD] 出版裏話2:大人の事情で「タスクマネジメント」: ソフトウェアさかば

[#TiDD] 出版裏話3:中堅技術者向けのRedmine&TiDDの本: ソフトウェアさかば

それから、「Redmineによるタスクマネジメント実践技法」の表紙にRedmineのロゴ(赤い洞窟のデザイン)も入れてもらいました。
Redmineのイメージと「Redmineによるタスクマネジメント実践技法」が結びつくと嬉しいです。

Redmineのロゴ: プログラマの思索

Redmine - Logo - Redmine

おかげさまで、Amazonのコンピュータサイエンスのランキングで瞬間1位を記録した後、2週間以上2桁でランクインしています。

[#TiDD] まさかのカテゴリ1位「Redmineによるタスクマネジメント実践技法」: ソフトウェアさかば

チケット駆動開発が何故そんなに注目されるのか、さかばさんの記事が分かりやすいです。

[#TiDD] チケット駆動開発は従来型開発とアジャイルの隙間を埋める: ソフトウェアさかば

販売が待ち遠しいです。

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

2010/09/23

販売管理システムで学ぶモデリング講座

渡辺幸三さん著の「販売管理システムで学ぶモデリング講座 (DB Magazine SELECTION)」を一通り読んだ。
内容はとても奥深い。
最初に断っておくが、前提知識としてデータモデリングだけでなく簿記3級程度の知識も知っておかないと、この本の凄さは分からないと思う。

本の内容は、卸売業の販売管理システムを渡辺さん作成のツールで作ったリファレンスモデルで解説している。
販売管理システムの業務を、仕入・受払・売上の3種類で説明している。
仕入と売上は実際の業務をイメージしやすいが、受払という在庫管理の業務はなかなかイメージしにくいが、簿記の知識があれば腑に落ちる。

在庫管理では、庫入れ・庫出しで商品の単価が変わる。
その流れは商品有高帳という補助簿で追跡できる。
在庫にある商品の単価は、先入先出法や移動平均法などで計算されるが、昨今のようにIT化されているなら、移動平均法が普通だろう。
面白かったのは、直送(自社倉庫を経由せず、仕入先から客先へ直接納品する)でも在庫の単価が変わること。
その背後には、在庫の評価基準が曖昧であると税務署から言われないようにするため、と言う点も興味深い。

渡辺さんが編み出したオリジナルの手法である在庫推移監視方式が在庫引き当て方式よりも有利である点も詳しく書かれている。
この部分は、MRPや簿記2級の工業簿記にある原価会計の知識がないと、完全に理解出来ないだろうと思う。

データモデリングとしては、2次識別子(主キーではないがデータを一意に決める非キー属性)や外部キーの使い方が面白い。
2次識別子を外部キーとして上手に使えば、テーブルのカラムをあまり増やすことなく、業務ロジックをER図へ反映させることができる。

また、売上に伴う出庫(倉庫にある商品を出荷する)では、出荷と同時に在庫数が減り、同時に売上の仕訳が計上されるロジックをトリガーファンクションで実装するのを勧めている点も面白い。

在庫引き当てのロジックは、どの業種でも複雑で、かつ実装も難しい部分だ。
排他制御やデッドロックの危険性も考慮しながら実装する必要があるので、在庫引き当ての実装は、普通は最もスキルの高い開発者が担当することが多いだろう。

販売管理システムで学ぶモデリング講座 (DB Magazine SELECTION)」の内容は後日まとめてみる。

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

統合型プロジェクト管理のススメ

梅田弘之さん著の「統合型プロジェクト管理のススメ (DB Magazine SELECTION)」を読んだ。
とても面白い。

統合型プロジェクト管理のススメ (DB Magazine SELECTION)」は2010/9に出版されたばかりなのだが、まるでチケット駆動開発の本を読んでいるかのような気分になった。
「脱Excel!」「プロジェクト管理のERP」というフレーズは、まさにRedmineやチケット駆動開発が目指している方向のように思える。

受託開発している顧客の業務をIT化・Web化するのが我々IT技術者の仕事なのに、IT企業の業務の根幹であるプロジェクト管理は手作業であり、IT化されていない所がほとんどだろう。
そんな現状がずっと続いているから、ITプロジェクトは成功率が低い、とか、仕事がきつくて残業が多い、などと言われ続けている。

現場の開発者だけでなく、現場リーダーも、プロマネも、IT企業の社長も、本当は自分の会社の現状を誰も知っていないのだ。
実際、工事進行基準がSIに課されているとはいえ、プロジェクトの原価をリアルタイムに追跡出来る仕組みを持っている会社は少ないだろう。
だから、今まで順調と思われていたプロジェクトが突然赤字で計上されたりする時も多いだろう。

統合型プロジェクト管理のススメ (DB Magazine SELECTION)」は、PMBOKの観点でプロジェクト管理のERPを作って、そのERPの使い方を通じてプロジェクト管理の運用が詳しく書かれている。
興味深いのは、プロジェクト管理のERPソフトから、営業支援システムや会計システムと連動して、受注案件と情報連携したり、プロジェクトの原価を即座に会計システムへ反映して会社の業績をリアルタイムに集計できるようにしている点だ。

チケット駆動開発はあくまでもソフトウェア開発のプロジェクト管理に特化しているので、上記の考えはスコープ外なのだが、RedmineのREST APIを使えば、外部システムからWeb API経由でRedmineにある開発現場の作業実績を簡単に取得できるから、Redmineと会計システムを連動させることは原理的に可能だ。

統合型プロジェクト管理のススメ (DB Magazine SELECTION)」はまだ読みかけなので、考えは後でまとめる。

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

TortoiseHgのダメ文字対応DLLとhgsubversionパッチ

TortoiseHgもver1.1.3になって随分使いやすくなった。

だが以前から「ソ」などのダメ文字はアイコンオーバーレイが有効にならない症状があった。
下記のDLLで置き換えると、正常に表示できるようになるらしい。

【元ネタ1】
marutosi / TortoiseHg / wiki / Home.ja ― bitbucket.org

marutosi / TortoiseHg / wiki / Home ― bitbucket.org

TortoiseHg Windowsシェル拡張UNICODE化の紹介 - mercurial-ja | Google グループ

但し、僕の環境(Ver1.1.3)では、DLLを入れ替えると「ログを表示」のコンテキストメニューが出なくなったので不便。元に戻している。
アイコンオーバーレイが有効でなくても、Mercurialのリポジトリには確かにコミットされているので問題はないけれど。

又、TortoiseHgのどのバージョンからか、hgsubversionと相性が悪くなったので、下記のパッチが必要みたい。

【元ネタ2】
koie blog : hgsubversionでFreeBSD svnをもってくる

.hg/localtagsがあると遅い - mercurial-ja | Google グループ

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

2010/09/22

Testlink 1.9 RC 1がもうすぐやって来る

Testlink 1.9 RC 1がもうすぐやって来るとTwitterで見かけたのでメモ。

【元ネタ】
Testlink RC 1 - Join Test Link QA Team

TestLink . View topic - Join Test Link QA Team

リリースするために、テスターを募集しているようだ。
TestLinkのVer1.9への拡張は、ゆっくりと確実に進んでいたみたい。
HudsonのTestLink PluginなどもVer1.9以降で使えるようだから、早くリリースして欲しいと思う。

HudsonのTestLink Plugin: プログラマの思索

TestLink Plugin - hudson - Hudson Wiki

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

2010/09/20

付加価値と限界利益

付加価値と限界利益についてメモ。

【元ネタ】
決算診断情報:決算診断「第1回 決算における重要な損益計算書と貸借対照表の関係」

tnlabo's blog: 付加価値の正確な理解を

限界利益と付加価値はほぼ同等な概念。
いずれも、付加価値=限界利益=売上-変動費 として覚えれば良い。
更に、限界利益率は、限界利益/売上 で計算される。
そして、損益分岐点は、固定費/限界利益率 で計算される。

限界利益が意味することは、会社は最低限、固定費を限界利益以下に抑えないと赤字になることを意味する。
そこから損益分岐点を計算できる。
つまり、損益分岐点よりも大きい売上をあげなければ、会社は赤字だと言うこと。
だから、固定費を下げるか、限界利益率を上げる、つまり、付加価値(限界利益)を増やすしかない。

固定費を下げるには、人を減らして人件費を下げたり、安い家賃に会社を移すなどの対策があるだろう。
付加価値を増やすには、売上を増やし、営業費用や外注費用などの変動費を減らすしかない。

下記の記事を読むと、IT企業が人月ビジネスになってしまう理由が示唆されている。

SIerについて気になったので調べた - I18n and L10n in My Life

システムインテグレーター - Wikipedia

おそらく、ITビジネスはプロジェクト型の案件が多く持続的な案件が少ないため、従業員の終身雇用モデルを維持するには、繁忙期は外部から人を借りて、散関期は社内から人を減らす手法が必要なのだろう。
つまり、人件費を固定費から変動費へ変えてしまうことで、調整弁として使おうとしているのだろう。

簿記や会計の観点から、業界特有のビジネス構造が透けて見える。

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

2010/09/19

コマンドラインのBTS ditz

コマンドラインのBTS ditzについてリンクしておく。

【元ネタ】
Home - ditz-ja - GitHub
Ditz

Ditz はとても素晴らしいと思います! - ¬¬日常日記
やらなきゃならないことを Ditz で管理する - たかみやの日記

MOONGIFT : 魅惑のコマンドラインBTS「Ditz」 オープンソース・ソフトウェア/フリーウェアを毎日紹介

タスク管理やバグ管理をditzでやるようにしてみた - dann@webdev - dann's portal

ditzめも - Konnichiwa, A doumo
2010-07-15 - こくぼ@Everything is the experience.

ditzはRubyGem化されていて、コマンドラインでチケットを更新して、ローカルのテキストデータにチケットなどの情報を保持する。
普通のBTSがWebのインターフェイスを持ち、DBにデータを一括管理するのとは違ったツール。
ditzは、かおるんさんが分散BTSと呼んでいるものに相当するのかな?

使い道としては、GitやMercurialのリポジトリへチケットなどの情報を保持して、履歴管理できるようにするみたい。
そうすれば、外部からアクセスできるし、データが無くなることも無い。
ただ、分散バージョン管理のリポジトリにデータがあるため、複数人が一つのチケットを更新しようとする時、アクセス権がなければ、フォークされて乱立してしまう不安がある。

おそらく一人用のタスク管理として使うのが無難かもしれない。

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

数学や物理は背景にある思想を知らなければ理解できない

帰省して、中学・高校・大学時代に読んだ本を久しぶりに読んだ。
考えたことをラフなメモ書き。

【参考】
量子革命がコンピュータ革命を引き起こした: プログラマの思索

【1】数学を理解するには、公式の背景にある思想を理解して、更に自分の手で計算しなければ理解したことにはならない。
微積分と無限に対する考え方は、教科書だけでは多分理解出来ないだろう。

僕は高校時代に偶然、遠山啓著の「数学入門〈上〉 」「数学入門 下 」を読んで、微分と積分、無限に対する思想を理解することができた。
微分の背後にある無限の考え方は最終的には、ε-δ論法につながる。
無限数列は、演算の順序を変えれない、とか、その結果が求まらない場合もある、という考え方が面白かった。

また、ニュートン、ケプラー、オイラー、ライプニッツ、ガリレオなどの偉大な数学者がどのような論争を行って、今の数学に至るのか、その歴史がとても分かりやすい。
ケプラーの3法則を微分方程式で鮮やかに証明する節が一番面白く、そして後々役立った。
数式で一部証明を書いているが、その背景の思想が詳しく書かれているので、数式は後で理解できればいい。

物理の公式は結局、微分方程式から得られた結果だから、公式だけ覚えても無意味。
公式を暗記するだけでは、他の数学や物理の問題は解けない。
問題の解決方法を知ってこそ、色んな物理の問題を解けるし、3体問題のように何故微分方程式が解けないのか、という話題も理解することができる。

遠山啓著の「数学入門〈上〉」「数学入門 下」は1960年代に出版された本なのだが、その内容は今も色褪せない。
高校生だけでなく中学生にも、数学の考え方を知る上でお薦めだと思う。

【2】物理を理解するには、物理特有の考え方、つまり、自然に対する科学者の態度を知らなければ、物理がどれだけ自然に対してこれだけの知識を得ることができたのか、理解出来ないだろう。

物理の公式をいくら覚えても、物理学者の態度を知らなければ、新しい問題を解くことができないだろう。
僕は高校時代に、アインシュタイン著の「物理学はいかに創られたか(上巻)」と朝永振一郎著の「物理学とは何だろうか〈上〉」を読んで初めて、古典力学の公式やエントロピーの概念を理解することができた。

物理学者が自然を理解する態度には、自然の根本は粒子(原子)であるという主張と波動であるという主張の2つがあり、それぞれの対立がある。
アインシュタインは前者の立場なので、何故、加速度が力を生むのか、モノの重さに関係なく落ちる速度が同じなのか、古典力学の説明がとても分かりやすい。

後者の立場は量子力学であり、おそらく現代物理学を知るには量子力学を制覇しなければ、化学も分子生物学も理解出来ないだろう。
朝永振一郎著の「物理学とは何だろうか〈上〉」では、エントロピーなど量子力学の考え方がとても分かりやすい。

高校生は、物理を学ぶ前に「物理学はいかに創られたか(上巻)」「物理学とは何だろうか〈上〉」上下4冊の本を読んでおけば、実際の入試の問題を解きやすくなるだろうと思う。
いずれの本も数式はほとんど書かれておらず、分かりやすい文章で書かれているのでお薦めだと思う。

他に、「物理数学の直観的方法」の本も初版で読んで、なるほどと思った。
特に、量子力学で必ず使われる解析力学について、その発端となった問題、ニュートンの最速降下線の問題の解き方がとても印象に残っている。
物理や数学の公式や概念は、特有の考え方、発想方法があるので、それを知らなければ、禅問答みたいでいつまで経っても分からない。

物理学者は、ある仮説を立てて、その仮説を確かめるために観測する。観測結果が仮説と合致していなければ、仮説を見直すけれども仮説が間違っていなければ、観測方法を変えたりして、実験を繰り返す。
つまり、徹頭徹尾、仮説重視の仮説検証スタイル。

この手法の代表例がフェルミ推定。
フェルミ推定とは、「シカゴの(ピアノの)調律師は何人いるか?」という問題が有名だろう。
物理学者フェルミが本来、原子爆弾の威力を机上の仮説から計算した手法なのだが、その発想方法をコンサルタントの一技法にフレームワーク化されたもの。
地頭力を鍛える 問題解決に活かす「フェルミ推定」」がおそらく最も有名な本だろうが、面白く読める。

フェルミ推定 - Wikipedia

【3】分子生物学は、生物は機械と同じような構造を持ち、物理法則に支配されているという発想で生物の秘密を解き明かすのが前提。
以前はなかなか良い本がなかったけれど、最近は「生物と無生物のあいだ」が読みやすい。

分子生物学の発端は、シュレディンガーの本生命とは何か―物理的にみた生細胞 (岩波文庫)にある。
量子力学を編み出したシュレディンガーは、その後の物理学者の進むべき道は生物の秘密を解明することにある、と宣言した。
つまり、生物は神秘の現象ではなく、その構造は未知の物理法則に支配されているはずだ、と。
一つは、原子が余りにも小さく、生物が原子よりも余りにも大きいのは、統計法則に従えば、生命が突飛な動きをしないようにたくさんの粒子が集まって動きの誤差を小さくせざるを得ないことにある。
もう一つは、エントロピー増大の原則に反して生命が生きるには、負のエントロピー(秩序)を食べてエネルギーを補充する必要があること。
この発想に多くの物理学者が知的刺激を受けた。

そして、ワトソン・クリックは、DNAが4種の要素による2重らせん構造であることを示して、DNAは自己複製機能を持つこと、そして、4種の要素(A・T・G・C)によって生命の情報を全て表現できることを示唆ないし暗示させた。
ここから、今の分子生物学の隆盛に至るわけだ。

実際、物理学者による生物の研究は、それ以前の生物の形態の観察とは全く違う。
実験動物の食物に放射性同位体をあらかじめ入れ込んでおき、実際の食物がどのように消化されていくのかを追跡する手法などは、まさに物理学者が考えそうな実験方法だ。

【4】そんな過去の本を読み直しながら、中学・高校・大学生向けに学問の背後にある思想や歴史を分かりやすく説明する本は改めて重要だと思う。
こういう良書はなるべく人生の早いうちに触れた方が勉強に役立つと思う。

僕が今回出版する本「Redmineによるタスクマネジメント実践技法」は上記の本ほどレベルは高くないけれど、僕が理解して説明できる範囲内で、Agile開発とチケット駆動開発を説明し、チケット駆動開発がソフトウェア開発プロセスでどのような位置を占めているのか、その利点と課題や可能性は何か、を全て書いたつもりだ。
2冊目を書く事になったら、もっと良い本を書いてみたいと思っている。

【追記】
小飼弾さんが遠山啓著の「数学入門〈上〉」「数学入門 下」の感想をBlogに書かれている。

(引用開始)
ケプラーの法則から万有引力の法則を導出する場面は本書の一番の見所で、この場面を楽しめれば三角関数は克服できたも同然なのだ
(引用終了)

この本の優れた所は、微分に関する無限の考え方を分かりやすく説明している点と、小飼弾さんが言う通り、微分方程式から万有引力のような本質的な法則を導き出す点にある。

404 Blog Not Found:書評 - 数学入門

404 Blog Not Found:残り物には勝因がある - 新旧対決 - 数学入門/いかにして問題をとくか

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

2010/09/17

TortoiseHg Reviewboard extension

TortoiseHg にコードレビューWebシステムReviewboard でPost-reviewするためのプラグインを見つけたのでメモ。

TortoiseHg Reviewboard extension available for testing ? Michael De Wildt

http://bitbucket.org/michaeldewildt/tortoisehg_reviewboard

fork of http://code.google.com/p/mercurial-reviewboard/. this fork is a functional superset of the original postreview tool and adds a number of features, including: ability to automatically create a review for outgoing changes or entire branches, adding all commit messages to the review description, automatic repository selection and ability to open reviews in a browser window automatically.

ReviewboardとMercurialを連動してうまく使えないか、考えてみる。

|

2010/09/16

リリース履歴の重要性

Redmineには、変更履歴と言うリリース履歴の機能がある。
この機能がいかに重要か、ラフなメモ書き。

【1】チケット駆動開発では、バージョンをリリースしたら、自然にリリース履歴が残る。
SVNコミットに必ずチケットをリンクさせれば、終了チケットがリリース履歴になる。

リリース履歴は何故重要か?
いつ何をリリースしたのか、という記録だから。
手作業でリリース履歴を作ろうとすると作業漏れがおきやすい。

RedmineのようなBTS、Hudsonのようなビルドツールを使っていないチームでは、リリース履歴を自動作成することができないので、リリース履歴をExcelのリリース台帳で管理しているだろう。
例えば、開発者が修正したソースにタグを付けてリリース台帳に記載して、ライブラリアンはリリース台帳を見てビルド&デプロイを実施するワークフローにしているだろう。

このワークフローはExcelのリリース台帳が一番重要。
このリリース台帳が壊れたり紛失したら、リリース作業に大きな支障を残す。
また、手作業のワークフローが多いので、ミスも多いだろう。

RedmineやMantisでは、ロードマップというリリース計画にチケットを一覧表示できるし、リリース予定バージョンでチケットをグループ化しておくと、先の予定のリリース作業が見えやすくなる。
そして、リリースしたバージョンの履歴が変更履歴として残るので、どのバージョンでどんなバグ修正を取り込んだのか、すぐに分かる。
つまり、BTSがリリース履歴を一括管理していることになる。

Hudsonの場合、RedmineやTrac、MantisなどのBTSと連携する機能がある。
実際、Hudsonがつけたビルド番号に、SVNリビジョンがひもづけられている。
そして、SVNのコミットコメントにチケットNoがあれば、Hudsonのビルド番号とリンクされる。
これによって、Hudsonでビルドしたモジュールに反映されたチケットを探すことができる。
これがトレーサビリティに当たる。

この機能があるからこそ、ビルドモジュールからSVNリビジョン、チケットを経由して、仕様や要件まで辿ることができる。

また、BTSで管理していれば、全文検索が可能だから、キーワードで検索できる。
従って、運用保守で、過去のパッチの修正意図を過去の終了チケットから探り出し、リバースエンジニアリングすることも可能。

【2】WF開発でも、設計工程のタスク管理にチケット駆動開発を使うと良い。
設計書は必ずSVNにコミットして、SVNの配下に置く。
つまり、設計書もバージョンアップしていく対象と捉える。

設計書の修正は必ずチケットを起票して、チケットに作業履歴を残す。
そうすれば、チケットとSVNリビジョンの関係を通じて、設計書とチケットが結びつく。

バージョンをマイルストーン単位にする。
マイルストーンは、設計書の提出時期、進捗報告の単位になる。

変更履歴に、マイルストーン単位の作業履歴が残る。
いつ誰が、どんな仕様を設計書に反映したのか、作業履歴が残る。
だから、何故こんな仕様が反映されたのか、後日になって検索して調査することも楽になる。

実際の設計書は、顧客から引き出した曖昧な要件を試行錯誤して詳細化しならが作られていく。
たくさんの課題を各チケットに起票しながら、そのチケットを解決する度に設計書をバージョンアップしていく。
たくさんのチケットを課題としてあげて、そのチケットを解決するほど、自然により良い設計になってくる。
ソースがたくさんのパッチで成長するように、設計書もたくさんの課題を反映することでより緻密になっていく。

リリース履歴には、構成管理の配下にある成果物の作業履歴であり、成長した履歴でもあるのだ。

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

2010/09/12

Agile開発の肝はイテレーションにあり

Redmineでチケット駆動開発を運用するまで、Agile開発を体で理解できていなかった。
XPを実践したいと思っていても、本当のAgile開発は何か違うのでは?と思っていた。

何故、僕はTracではなくRedmineを使ってAgile開発を発見できたのだろうか?

RedmineがAgile開発と相性が良いのは、Redmineの「バージョン」の概念がAgile開発の「イテレーション」「スプリント」と自然に一致するからだ。

Redmineでは、バージョンに紐づくチケットが全て完了ステータスになって、進捗率が全て100%になれば、いつでもそのバージョンをリリースできる仕掛けが入っている。
つまり、バージョンをイテレーションと見なせば、各バージョンを次々にリリースしていけば、自然に小規模リリースを実現できる。
小規模リリースこそが漸進型開発、つまりインクリメンタル型開発の最大の特徴なのだ。

Agile開発は運用しにくい、と思っている人達の原因の殆どは、イテレーションという概念を自分たちのプロジェクトで見つけられてないのだろうと思っている。

僕がTracを初めて運用した時にうまく使いこなせなかったのは、イテレーションをTracの機能で見つけられなかったのが最大の理由だと思う。
だから、Redmineでチケット駆動開発を実践してAgile開発の運用に成功した後、Tracを再び使う事になった時、Tracの機能をもう一度精査し直した。

Tracには、マイルストーンとバージョンという概念がある。
Agile開発のイテレーションと一致するTracの機能は「マイルストーン」だ。
理由は、Tracのロードマップ画面に表示されるのはTracのマイルストーン単位の完了チケット率であり、TracのマイルストーンのライフサイクルはAgile開発のイテレーションと一致するからだ。
実際、Tracでは、マイルストーンの「完了」ステータスを選択すれば、そのマイルストーンはロードマップ画面から消える仕掛けになっている。
つまり、リリースされたので、Tracのマイルストーンは見せる必要がなくなったということ。

Tracの「バージョン」はSVNのタグのような機能に過ぎない。
だから、Tracの「バージョン」はイテレーションにはなりえない。

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

だから、Tracのマイルストーン単位にタスクをチケットで分類して、小刻みにリリースする開発スタイルになってから、自然にテンポよくプロジェクトの作業が流れるようになった。

Mantisでもイテレーションの概念はある。
Agile開発のイテレーションの概念は、Mantisの「修正済みバージョン」に相当する。

Mantisの使い方: プログラマの思索

更に、Mantisにも「ロードマップ」「変更履歴」の機能があり、それらはRedmineと同等の機能だ。
実際、Mantisのロードマップは、修正済みバージョン(リリース済み・リリース予定バージョン)ごとにチケットがまとめられていて、変更履歴はリリース済みバージョンのチケットの履歴になっている。

Roadmap [MantisBT]

僕は、Redmine、Trac、Mantisを使ってみて、いずれのツールでもチケット駆動開発は可能であり、Agile開発のタスク管理を行うことは可能だと経験したし、確信している。

そして、イテレーションの概念や小規模リリースの利点は、開発チームにリズムが生まれること、そして、そのリズムがプロセス改善を生んでくれることだ。

イテレーション単位にリリースするから、ユーザもいち早くシステムに触ることができるし、開発チーム自身も実際のシステムに触れて、設計漏れや要件漏れにいち早く気づくことができる。
何よりも、定期的にリリースするリズムがあるから、メンバーもそのリズムに合わせるようにタスクを調整するようになる。

そして、リリース後にKPTでふりかえりミーティングを開けば、今回のリリースの良かった点だけでなく反省点を洗い出せるから、次のリリースに向けて、自分たちのプロセスを改善していく雰囲気が生まれる。
定期的なふりかえりによって、自分たちのチームの特徴にあった運用ルールを作りこんでいけばいい。

チケット駆動開発はツールに依存しすぎだ、と言われることもあったが、今は気にしていない。
Agile開発を確実に運用するには、従来のやり方とは違った手法が必要であり、高度なツールを必要とすることを体験できたからだ。

更に、ソフトウェア開発プロセスの基本は結局バグ管理であり、BTSをいかに使いこなすかにかかっているのではないか、と直感している。

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

2010/09/11

【告知】「Redmineによるタスクマネジメント実践技法」を出版します #TiDD

さかばさんと共著で「Redmineによるタスクマネジメント実践技法」を2010/10/13に出版します。
世界初のチケット駆動開発の本になります。

【元ネタ】
[TiDD] 速報!史上初の「チケット駆動開発」の本が出版に: ソフトウェアさかば

過去3年間、RedmineやTestLinkなど各種ツールを駆使して、チケット駆動開発という開発プロセスの上でAgile開発をいかに運用するか、をテーマにして、試行錯誤した経験と今まで思索してきた内容を全て書きました。
そのため、350ページ近くまで膨れ上がりました(笑)

最初に断っておきますが、RedmineやTestLinkのインストール方法には特に触れていません。
XPなどのAgile開発の文脈の上で、チケット駆動開発という開発プロセスを世界で初めて定義して、その応用分野や今後の課題についてひたすら書いています。

読者層は、BTSに不満がある人、Agile開発の運用に悩んでいる人、ソフトウェア開発のプロジェクト管理に苦労している人が対象になります。

目次は下記の通り。

第1部 チケット駆動開発技法 ─BTSによる作業管理─
 第1章 障害管理ツール(BTS)
 第2章 BTSとツールの連携
 第3章 チケット駆動開発 .チケットによるタスク管理.
 第4章 チケット駆動開発(TiDD)のはじめかた

第2部 Redmine によるタスク管理
 第5章 Redmine の運用方法
 第6章 Redmine の高度な使い方
 第7章 チケット駆動開発の実践的な運用方法
 第8章 チケット駆動開発を発展させるアイデア

第3部 RedmineとTestLink の連携
 第9章 TestLink の運用方法

Amazonで予約販売が開始されているので是非ご購入下さい。

最後に改めて「Redmineによるタスクマネジメント実践技法」を出版するにあたり、まちゅさんとNakaさんに深く感謝します。

まちゅさんが公開したアイデアであるチケット駆動開発の概念に触れなかったら、そもそも、今回の本を出版することにはならなかったでしょう。
また、Nakaさんからテスト管理のノウハウを聞くことがなければ、TestLinkの背後にあるテスト管理の奥深さを知ることも無かったでしょう。

チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

なお、10月末、11月初旬に出版記念講演を予定しています。
こちらも是非聞きに来て下さい。

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

韓国SIがIT技術を日本に逆輸出

韓国SIがIT技術を日本に逆輸出の記事を見つけた。

韓国の企業が、日本の金融システムを構築「IT技術を日本に逆輸出」-韓国(サーチナ) - Y!ニュース

半導体や家電製品で韓国企業の躍進をよく聞くけれど、基幹システムと言う受託開発を韓国SIが受注したことは、今は小さな記事に過ぎないかもしれないが、今後大きな影響を及ぼすだろう。
日本の殆どのSIは海外競争力がなく、国内の受託開発を収益の源泉にしているからだ。

ソフトウェアプロダクトラインが組込み企業の技術力を左右する: プログラマの思索にも書いたように、韓国ではソフトウェアプロダクトラインの世界的権威である先生がいるので、その存在が大きいのかな、と思ったりする。

又、IPAが書いたアジャイル開発の研究会報告書: プログラマの思索にも書いたように、韓国SIはAgileとは言えなくても反復型開発に近い開発プロセスの経験を持っているように読める。

今後の動向を注視していく。

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

2010/09/10

チケット駆動開発の概念は海外に存在するのか?

下記のBlogをたまたま見つけたのでメモ。

【元ネタ】
「チケット駆動開発」について分かったことと、日本の開発現場での課題 - I18n and L10n in My Life

【Twitterログ】
Twitter / ショーン: やっぱそうなんすね! RT @kuranuki チケット駆動開発は日本の言葉ですね~。 RT @Sean_SF: 「チケット駆動開発」について分かったことと、日本の開発現場での課題 http://d.hatena.ne.jp/Sean_SF/20100909/1284028848

Twitter / ショーン: お~。 @machu さん、はじめまして。名付け親でしょうか? RT @kdmsnr チケット駆動開発は @machu さん発で、その論文っぽいものは間違いじゃないかと。

Twitter / 角征典 KADO Masanori: @Sean_SF あ、わかった。最初は @machu さんが「チケット駆動開発(TDD)」と言っていて(http://www.slideshare.net/machu/yet-another-tdd)、TDDをTiDDに変えたのがえと~さんという人みたい。ソースはないですけど。

Twitter / MATSUOKA Kohei: @Sean_SF ITpro Challenge2007のライトニングトークで名付けました。TracやRedmineのチケットでバグと要望を合わせて管理するのはオープンソース開発でよくある手法なので、概念は昔からあったかと #TiDD

Twitter / MATSUOKA Kohei: @Sean_SF (続き)テスト駆動開発TDDと同じ略になるのでLTのネタにしたのがTiDDと名を変えて広まった感じですね。


チケット駆動開発のアイデアは、まちゅさんの ITpro Challenge のライトニングトーク資料が発端。
元々はTracのチケット管理をプロジェクト管理に使おうという発想だったと認識している。

チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

そのアイデアに刺激を受けて、Redmineでチケット駆動開発を実践したら、自然にAgile開発になっていた。
その体験談をXPJUG関西で議論して、発表したのが、関西Ruby会議01@関西-KOF2008の資料になる。

日本Rubyの会 公式Wiki - 関西Ruby会議01@関西-KOF2008

Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ

そこから、チケット駆動開発について@ITに記事を書いたり、SQIPで発表したりしてましたが、一部の人しか受け入れないだろうと思ってました。
実際、ネットで検索しても海外ではヒットしないみたい。

個人的には、Agile開発を運用するための一つのプロセスとして興味をもつ人が多いのかな、と思っている。

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

2010/09/06

HudsonのTestLink Plugin

下記のTiwtterで、HudsonのTestLink Pluginがあるのを知った。

Twitter / ASR: TestLinkのv1.9ではテストの自動実行ができるようになってるんだなー、とhudsonのプラグインから知る

TestLink Plugin - hudson - Hudson Wiki

説明文にはこう書いている。

This plug-in integrates Hudson and TestLink and generates reports on automated test execution.

TestLink1.9betaに対し、Hudsonで実行した自動テストをTestLinkのテストケースにある自動テストのレポートに登録するみたい。

HudsonのTestLink Pluginがどこまで使い物になるのか、試してみたい。

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

2010/09/05

電子書籍の作り方part5

電子書籍の作り方、ビジネスの可能性についてメモ。

【参考】
OpenOfficeのWriter文書をEPUB文書へ変換する拡張機能「writer2epub」

こもれび

ひとりWikiについて

EPUB形式の電子書籍に動画と音声を埋め込む方法。サンプルEPUBファイルあり - ガジェットダイスケ.com

Pagesアップデートで判明、Appleが取り組む「EPUBでビデオ」 - builder by ZDNet Japan

自分のBlogをepub化した電子書籍はとても読みやすい。
電車の通勤時間、待ち時間、ちょっとした隙間時間に、気軽に電子書籍が読めるのはいい。
やり方は下記に書いた。

Blogを電子書籍化して公開する方法: プログラマの思索

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

更に進めて、自分がローカルで保持しているテキストをepub化して、iPod touchのStanzaで読む方法を考えている。
epub化するイメージは、「テキスト→HTML→epub」だ。

一つの方法は、ひとりWikiを使って、Wiki記法でテキストを書いてHTML化して、epub化する方法。

ひとりWikiでテキストをhtml化する
→SigilにHTMLを読み込んでepubを作成
→CalibreでiPod touchのStanzaと同期して、iPod touchでepubを読む

もう一つの方法は、Wordからepub化する方法。
普通のライターはWordで原稿を書いて書籍にするので、Wordから直接epubへ出力できると便利。

OpenOfficeのWriter文書をEPUB文書へ変換する拡張機能「writer2epub」によれば、OpenOfficeの文書を保存時にepubを選択できるみたい。
この方法が使えるならば、OpenOfficeで原稿を書いて、直接、電子書籍にできる。

実際の出版作業はどうやらDTPを使って手作業で行っている。
IT化されていないし、アジャイルでもない。
epubで原稿を電子書籍化できるならば、原稿そのものをバージョン管理して、デイリービルドでepubないしPDF出力すればいい。
そして、レビューアやユーザからのフィードバックは、TracやRedmineのチケットで管理して、SCMにある原稿と結びつければいい。
そのアイデアは下記に書いた。

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

epubの利点は色々ある。
ビジネス上の利点は、下記に書いた。

電子書籍の作り方part2: プログラマの思索

つまり、流通コストや在庫コストが殆どゼロになるので、価格破壊が起こること。
そして、ロングテールのマーケティング手法が使えるので、過去に絶版となった本も販売可能になること。

だが、epubがWebと違うのは、情報の品質が徹底的に違うからだ。
電子書籍はやはり書籍であるからには、Web上の玉石混交の情報よりもはるかに価値がある。
そして、書籍にはその著者の考え方、生き様、思想が反映されているから、内容も濃いし、価値も高い。

epubの使い道は色々ある。
EPUB形式の電子書籍に動画と音声を埋め込む方法。サンプルEPUBファイルあり - ガジェットダイスケ.comによれば、電子書籍をポッドキャストで流すことも可能だ。
epubは所詮XHTML+CSSなので、HTML5の機能を使えば、動画や音声を盛り込むことができる。

Pagesアップデートで判明、Appleが取り組む「EPUBでビデオ」 - builder by ZDNet Japanによれば、AppleのiBookでは、epubに動画を表示させることも可能らしい。

epubに動画や音声が付属できる利点は実は、ポッドキャストにリンクを貼ることができることにある。
つまり、ポッドキャストで流される電子書籍は広告になる。
ハイパーリンクにあるAmazon商品を買ってくれれば、アフィリエイトで収入を得るということも可能。

電子書籍は書籍の単なる電子化だけでなく、ビジネスとしても我々の知的生活にも大きな影響を与える可能性がある。

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

2010/09/04

エンタープライズRails

エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術」を読んだ感想をメモ。
ラフなメモ書き。

【元ネタ】
DOAはRailsの銀の弾丸か - 書評:エンタープライズRails - ひがやすを blog

404 Blog Not Found:Rails使いでなくても有用 - 書評 - エンタープライズRails

RailsとかDOAとかCASCADEとか。 - Dis Communication - 符号無し

エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術」はRailsのHowTo本と思っていたが、実際の中身はDOA。
Railsをスケールアップするには、DB設計やサーバーの配置のようなアーキテクチャをしっかり作りこまないといけないという主張。

当初はほんの少しのユーザがアクセスするだけしか想定しないRailsアプリ(例えばTwitter)が、あまりにも多くのユーザを引き寄せて、そのパフォーマンスやスケーラビリティを確保するのに随分苦労した話が最初に説明されている。
アーキテクチャを後付けで追加ないし変更していくのは非常に難しいのだ。

Railsだからアーキテクチャは不要ではなく、考慮して作ればいい。
何よりもRailsもRubyも表現力が高いから、DOAを使ってDBをしっかり作りこんでおけば、スケールアップがやりやすくなる。

エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術」のDB設計は正統派の部分もあれば、微妙にずれている所もあって面白い。
参照整合性制約を使うとか、トリガーを使ってビジネスルールをチェックするやり方は普通。

参照整合性制約を使う状況は例えば、商品マスタから商品を削除する場合、注文明細に該当の商品があれば削除できないチェックをDBMSで制御する場合がある。
そうすれば、注文情報の整合性をアプリケーションロジックに書く必要はない。

トリガーを使う状況は例えば、注文・注文明細にデータを登録した際に、注文履歴テーブルへそのデータを登録する時がある。
あるいは、合計金額のような導出属性をトリガーで自動計算させる方法もあるだろう。

マテリアライズドビュー(更新可能なビュー)を使うやり方は面白い。
とはいえ、Oracleならマテリアライズドビューを使うのは普通だろうが。

複合キーを使うために色々工夫しているけれど、ひがさんが話すように、サロゲートキーを使うのがいいと思う。
サロゲートキーの方がRESTful Webサービスと相性がいいからだ。

RailsやSeasarのような優れたWebフレームワークのおかげで、業務ロジックの実装が楽になっただけに、DB設計の重要性が逆に高まっている。
DB設計がしっかりしていれば、リリース後の本番運用で、スケールアップがやりやすくなるからだ。
つまり、Railsのおかげで、OOAよりもDOAに注目せざるをえない状況になってきていると思う。

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

Redmineの次なる機能 nested Gantt Chart

Redmineの次バージョン1.1に盛り込む機能のアイデアが公開されていた。
その機能の中で皆が注目していると思われるnested Gantt Chartについてメモ。

【元ネタ】
Redmine - My thoughts on Redmine 1.1 - Redmine

Redmine - Feature #6276: Gantt Chart rewrite - Redmine

nested Gantt Chartとは、Redmineのガントチャートにプロジェクト・バージョン・チケットとそれらの親子関係を一覧表示した機能。
更に、ソート順を変えたり、プロジェクト・バージョンの進捗率を表示したりできるみたい。

ガントチャートをよく使うユーザはうれしい機能だろう。
つまり、マネージャクラスの人達にとっては、プロジェクトの進捗をガントチャートでよく見るだろうから、彼らにアピールできる機能になるだろう。

Redmineのチケット集計機能を強化することは、プロジェクト管理機能を強化することにつながるので、良い方向だと思う。
色々調べてみたい。

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

Twitterは最速のメディア

Twitterの使い方はまだよく分かってない。
でも、Twitterを使ってみて、最速のメディアだと感じた。
朝刊の新聞よりも、新聞の号外よりも、Blogよりも、日経のHPよりも、情報が早く伝わる。
だから、皆がTwitterに注目しているのだろう。

孫さんのような社長、政府の閣僚がTwitterで情報を流しているのも、Twitterの社会的影響力が大きいから。
Twitterは新聞などのマスコミとは違うニッチな市場で育って、今はかなり大きな威力を持っている。
その理由は、瞬時にフォロワーに自分の意見が伝わるから。

僕は、Twitterで特定のキーワードで情報収集している。
Redmineの最新情報を知りたいなら、Redmine.JP | Redmine on Twitterを見るのが一番良い。
最新バージョンはどんな機能が注目されているのか、どんなプラグインがあるのか、皆がどんな使い方をしているのか、よく分かる。

僕は他にも、Twitter / Search - testlinkTwitter / Search - tortoisehgは常時追いかけている。

あるいは、特定の人をフォローして、最新情報を手に入れる使い方もある。
入門Redmine 第2版 Linux/Windows対応」を書かれているMAEDA, Go (g_maeda) on Twitterさんを追いかければ、Redmineの最新情報を知ることもできる。

Twitterの使い方にはどんな可能性があるのか、色々調べてみたい。

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

2010/09/03

セーフウェアが必要な理由~ソフトウェアが凶器になる時

セーフウェアに関する記事を読んだのでメモ。

【元ネタ】
ソフトウェアが凶器となる日 - ある組込みソフトエンジニアの日記

ソフトウェアが凶器となる日 - ある組込みソフトエンジニアの日記

ソフトウェアの特性を考慮せず事故が起きた事例 - ある組込みソフトエンジニアの日記

プリウスブレーキ制御ソフト改変についての考察 (まとめ) - ある組込みソフトエンジニアの日記

セーフウェアの解説その二 - ある組込みソフトエンジニアの日記

勝手にソフトウェア保守開発: SEA Forum Feb 2010 「セーフウェア - システム安全とコンピュータ」聴講記

トヨタ自動車の大規模リコール (2009年-2010年) - Wikipedia

自動車が電気自動車になれば、今の日本の製造業が得意とする高度なすり合わせ技術は必要ではなく、部品やソフトウェアを組み立てることで簡単に作れるようになる。
だが、その未来は決して明るいわけではない。
人々は、ソフトウェアが予期せずに暴走してしまう危険にいつもさらされている。
トヨタの大規模リコール事件は、セーフウェアの重要性を認知させたという事実があるからこそ、重要だと思う。
その事件の本質には、技術者が良かれと思った改良が、実は乗用者の安全を脅かしていたと言うこと。

プリウスブレーキ制御ソフト改変についての考察 (まとめ) - ある組込みソフトエンジニアの日記の記事では、「酷なようだが、これはソフトウェアの変更管理的にいうとソフトウェアの変更によるデグレードだと思う。」という厳しい指摘を述べている。

つまり、安全性(セーフウェア)は、信頼性や可用性、保守性とは別個の品質特性であるということだ。
信頼性がいくら高くても、可用性が高いとは言えないように、安全性も高いとは言えない。

セーフウェアの本は600ページ以上の分厚い本だが、具体例が数多く掲載されているので、参考になる。

トヨタの大規模リコール事件が起きた今、今後、組込製品のソフトウェア開発は安全性と言う品質を重視せざるを得なくなるだろう。

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

BABOKをアジャイル開発へ拡張

InfoQにBABOKをアジャイル開発へ拡張したドラフトが公開された記事があったのでメモ。

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

システム化立案や要件定義と言う超上流工程をいかにAgileに回すか?
反復型開発をどのように取り入れているのか?

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

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