header image

Ryuzeeについて

mixi Twitter Twitter

Categories

Archives

携帯対応

QRコード

RING

人気ブログランキング

新着記事

[翻訳]リーンアジャイルメソッドの概要 add Hatena Bookmark
2010/09/07 04:27:15 Agile・生産性向上 none Comments

Alan Shalloway氏がhttp://www.agilejournal.com/articles/columns/column-articles/3222-an-overview-of-lean-agile-methodsで書かれていた記事が良記事なので、適当翻訳。

かつては物事はシンプルでした。
90年代に、アジャイルを選択しようとすれば、XPを選択するしかありませんでした。そして、その後、Scrumがポピュラーになりました。組織がチームへのフォーカスによって、これらのアプローチの限界に突き当たるようになったのは最近の話です。それから、ソフトウェアにリーンの原則を適用することができるということが明らかになってきました。リーンソフトウェア開発および後のKanbanが一連の中に加わりました。今、もしアジャイルな開発手法を選ぼうとすると、非常に多くの選択肢があります。
単にどのメソッドを選ぶか、という点だけでなく、どこから始めて、トップダウンで行うのか、ボトムアップで行うのかを考え、自分の努力の範囲をどこまでにするか、というようなことも考えなければなりません。

色々考えなければならないことに気力をくじかれてしまうかもしれません。それをより少なくすることができるかどうか見てみましょう。

アジャイルって何だろうか？

アジャイルが意味するところを考えてみましょう。多くの人は、小さなステップ(反復)でソフトウェアを作ること、進捗やプロジェクトの健康状態は開発されたソフトウェアという観点で測定すること、作っているものが本当に有用であることを保証するために顧客のそばで働くことがアジャイルであるというかもしれません。
でもこれは、私が「チームのアジリティ」と呼んでいるものです。なぜならそれがフォーカスしているのが、チームとチームがどのように働くか、という点だからです。
現時点では、一番よく使われているアジリティの形で、多くの人に効果的であることは間違いないけれども、あなたが得ようとしている本当のゴールではありません。

わたしたちの仕事の本当のゴール＝成功 を測定するもっともよい指標は、開発組織が仕えるビジネスユニットがどれだけ素早い対応が出来ているかに着目することです。
私はこれを「ビジネスアジリティ」と呼んでいます。ビジネスアジリティはチームを超えたものをも内包しています。残念なことにビジネスアジリティを達成することはとても難しいことです。
ビジネスアジリティは、ビジネスまたはビジネスユニットがビジネス価値をクライアントに対してインクリメンタルに届けられる能力のことです。
ビジネスアジリティは、企業がマーケット環境が変化したり、新しい技術が出たり、新しいアイデアがでたときに、必要に応じて、すばやく反応することを可能にします。

ビジネスアジリティは素早く動ける、効率的な、必要なところに行ける車を持っているようなものです。
チームのアジリティは、ドライバーが望んでいる操作を可能にするよくチューニングされたエンジンのようなものです。言い換えると、ビジネスアジリティは本当の完全なるゴールであり、チームアジリティはそのための手段を意味します。
現時点では、十分に小さな組織においては、チームだけにフォーカスすることが適切かもしれません。しかし、一定規模以上の組織においては、チームにフォーカスすることによってにジネスアジリティを達成しようとすることは、ただエンジンのチューニングだけを繰り返してよりよいパフォーマンスをだそうとしているのと同じことです。
エンジンのチューニングも役にはたつでしょうが、トランスミッションやブレーキを改良したほうがよりよい結果が得られるでしょう。

一般的なアジャイルのメソッド：ScrumとXP

先に言ったように、Scrumと、今はちょっと少ないが、XPは、アジャイルムーブメントの中ではもっともポピュラーな手法でした。
XPはペアプログラミングやテストファーストや継続的インテグレーションや共同所有などの開発プラクティスにルーツをもつ開発手法です。
スクラムは一義的には組織の妨害事項をあらわにするプロセスのフレームワークです。
その根底にある想定事項としては、もし間違っていることをやっていても、問題は修正可能である、という考え方です。
Scrumの力は、数週間の中で問題を早期に明らかにできる、ということで、この点についてはウォーターフォールからの大きな改良であることに異論はないでしょう。
明らかになった問題への対応方法がはっきりしない場合があり、そのような場合の対応が課題となっています。

両方のメソッドは１から４週間隔のイテレーション、自己組織化、機能横断チームといったものを利用します。

Scrumはいくつかの理由によってよりポピュラーになってきました。
１つ目は、チームがXPの核となっているような技術的なプラクティスを採用しなくてもよいため、始めるのが簡単である、ということです。
XPが求めるような技術レベルの変化は、いくつかのチームにとっては非常に骨が折れるものなのです。
２つ目は、スクラムの認定プログラムが、スクラムを教えたり宣伝する「認定スクラムトレーナー（CST)を大量にこの世に送り出したためです。
結果として、多くの会社において、「アジャイルになる」ということは「認定スクラムマスター（CSM)」の資格を取得して、Scrumを適用することだ、と考えるようになってしまいました。

アジャイル界隈での挑戦

Scrumはウィルスによって成長しました。現在問題点が明らかになってきています。事実、スクラムの創始者のひとりであるケン・シュエイバー氏は、Agile Collabのインタビューにおいてこう言っていました。

「スクラムを使用する組織の75%は、Scrumに対して望む利点を得ることには成功しないだろう。」[1]

なぜそうなるのかについては多くの見解があります。著者は、含まれるであろういくつかの理由を以下に記述します。

  • 開発チームが直面する多くの問題が、実際にはチームの外部で起こります。例えば、一度にチームに対して多くのプロジェクトを与えることによってチームを過負荷にすること。
  • 多くの大規模組織は、ソフトウェアのデプロイメントメソッドが貧弱であり、それ故にソフトウェアを世に送り出すことを困難にしています。Scrumが妨害事項を明らかにする一方で、彼ら自身ではそれを解決できず、Scrumそれ自体はどのようにそれを解決するかの指針も持ち合わせてはいません。
  • 多くの組織ではScrumが要求するような機能横断的なチームを作ることは難しい。特定のスキル、例えばレガシーコードに関する知識をもった人や特定の専門分野をもった人たちはしばしば複数のプロジェクトのかけもちをすることを要求され、Scrumモデルのパワーをそいでしまう。
  • Scrumに不慣れな多くのチームが、製品開発フローの原則を教えられていません。
  • Scrumはもともと同一場所にいるチームのためのものとして設計されましたが、しばしば分散したチームでの開発を行っている。

多くの熱狂的なScrumファンは、組織がスクラムを利用した成功を経験していない本当の理由は、組織がそれらの問題を解決するのに必要な訓練や動機づけをまったくしていないからだ、と主張します。

原因が何であろうと、問題は残り続けます。この問題を解決するために、アジャイルに関する２つの他の方法が生まれました。それが、「リーンソフトウェア開発」と「ソフトウエアエンジニアリングのためのKanbanシステム（もしくは略してKanban）」です。
これらのメソッドは双方ともにScrumで行っていた場合に組織が抱えていた問題に対して直接的に取り組みます。
これが、私が５年前にリーン、３年前にKanbanに取り組み始めた理由です。

リーンソフトウェア開発

リーンソフトウェア開発は「リーン生産方式」の原則と製品開発手法がソフトウェア開発に適用可能であるという理解に基づいています。もちろん、プラクティスは異なりますが、マインドセット、考え方は同じです。

その起源は１９９０年代中盤のBob Charetteの記事にさかのぼります。
そして、メアリー・ポッペンディークとトム・ポッペンディークの本（最初の本は、「Lean Software Development, An Agile Toolkit」で2003年に出版されました)によってポピュラーになりました。
リーンソフトウェア開発は、無駄を省く（顧客にとって価値がない努力はしない）、全体最適（concept to cash)、素早い出荷、品質の作り込み、人に対する尊敬、絶え間ない改善、そして必要になるまで判断を遅らせる、といった考え方に基づいています。

Don Reinertsenの周り[2]から別の流れが起きました。
Reinertsenは、システムの中をどのように仕事のフローが流れているかを見ること通じて、人々が働いているシステムの評価や、その中にいる人達のスキルの育成や、仕事の滞在時間を観点としてリーンにアプローチしました。「フロー」によって彼はどこに遅れが生じるか、どこに大きなキューが生じるか確認することを意図していました。

どちらのアプローチを好むかにかかわらず、開発組織の内外の問題をどのようにして解決するかに関しての洞察を提供することは有用なことです。
フローのモデル（価値をより素早く届けるために、開発パイプラインの少しの小さなことに着目する）は、あなたのソフトウェア開発のバリューストリームを向上させる１つの方法は、開発チームは同時に複数の仕事を行うことを避けることだ、ということを示唆しています。
同時に多くのことをやっていたが故にどれだけ多くの開発チームが壊れてしまったかということを考えれば、直感的に分かるでしょう。

Kanban

Kanbanはリーンと制約理論の双方に基づいています。約５年前にDavid Andersonによって作られ、関心が高まっています。[3]
Kanbanはいくつかの基本的な原則の上に成り立っています。
まず１つ目は、組織がアジャイルをはじめるために、一度に大きな変化を経験することを要求することは逆効果であるかもしれないということです。
人々に対して新しい役割や仕事を採用しなければならないことを異なった方法で伝えることは、しばしば組織の中に変化に対する恐れを創りだしてしまいます。以前の仕事のやり方が捨てられてしまうことによって、人々は自分たちの価値が下がったというように感じてしまいます。

アジャイルムーブメントの最初の数年間は、Scrumは既にあるチームに導入され、開発者やテスターやアナリストたちは変化を望んでいました。しかしもはやそのようなことは現状では、たぶん別に遭遇する困難のために、当てはまらなくなっています。

多くのアジャイリストたちは、この大量な変化を克服する方法はトレーナーやコーチを雇うことだ、というでしょう。しかしながら、別のアプローチによって、それほど破壊的ではない方法で、スムーズに最終的なゴールに向けて移行することができるかもしれません。

Kanbanの本質はあなたがそこで３つのことから始めることです。

  • あなたのゴールは何か、開発者がある時点でどれだけの数のプロジェクトで働くかについて、ステークホルダーと合意を結ぶこと
  • バリューストリームマップによって、開発プロセスを視覚化すること。
    「バリューストリーム」とは段階の流れで、コンセプト→定義→構築→デプロイ→利用の順に遷移します。どうやったら仕事がバリューストリームを移動するかについては明確に定義してください。これがとても重要であるのは、それが管理者がこれらのアクションがどのようにチームに作用するのかを分かることができるためであり、また、これらの明示的なポリシーに関しての議論が学習を加速させることができるためです。
  • 各ステップにおいて行われている仕事の量（WIP）を管理すること。
    特に、チーム（と管理者）は仕事が後退してしまう場所を探す必要があり、それから、どうやって問題を取り除くのかについて理解する必要があります。この明確さが、チームが遭遇する妨害事項を解決するための洞察を提供してくれるのです。

Corey Ladasは、KanbanをScrumフレームワークに組み入れることで、「Scrumban」と呼ばれるハイブリッドな方法を作り出しました。
これはScrumチームにKanbanを適用する際に有効な方法になっています。

ビジネスアジリティの達成:どこから始めるべきか

それでは、あなたはどこから始めるべきでしょうか？それはあなたがどんな状況にあって、どうしたいのかにかかっています。
私の経験では、パイロットプロジェクトからアジャイルメソッドの適用を始めることは常にベストなわけではない、と思います。
車のエンジンのように、チームのメソッドは問題ではないかもしれません。もし改善が必要だとしても、完了したソフトウェア全体のコンテキストをみて、それから改善できることを選択することが望ましいのです。
以下の２つを推奨します。

  • バリューストリーム全体を見るところから始めること。どこに課題があって、何を改善しなければならないか？
    これは、チームの範囲を超えてあなたがコミットする、ということではなく、そうすることで、チームの進捗がビジネスの進捗やビジネスアジリティの実現につながるようなヒントを得ることができるだろうからです。

    • 　

  • チームにScrumかKanbanを選択させてください。彼らは直感的に自分たちにとって最良なのはどちらであるか分かるでしょう。人を尊敬する、ということは、仕事のやり方を彼らが選ぶことを許すことです。（もちろん、それはビジネスのコンテキストの範囲でですが・・・。）

全体のコンテキストを考えることは、「アジリティのスケーリング」と「大規模でのアジリティ」との差でもありますが、それについては別の記事にします。

もしKanban、Lean、ScrumそしてXPについて、より詳細を知りたければ、Net Objectivesのリソースページにアクセスしてみてください。
http://netobjectives.com/resources
そして、以下の２つのサイトでは、これから開催されるカンファレンスを含め、さらに豊富な情報を見ることができます。
http://www.leanssc.org　http://www.kanban101.com

XP祭りに行ってきた add Hatena Bookmark
2010/09/06 11:58:07 Agile・生産性向上 none Comments

9/4(土)に早稲田大学で行われたXP祭りに行ってきました。
細かいセッションの内容はPublickeyさんのサイトで解説されているので、僕は率直な感想とか。

細谷さんセッション

アジャイルなテストの話。「コンテキスト依存」という言葉が登場するように、テストをどこまで行うかは、案件の性質や置かれた状況によって異なる。だからこそ、テストの戦略を最初に決めておく必要がある。

開発会社の社内QA基準に従ってテストするっていう行為自体は、顧客にとって本当に価値がある話なんだっけ？っていうとそうじゃなくて、顧客にとっては、バグがあるとかないとか、そういうレベルの話ではなく、そのソフトウェアを使ってビジネス上の成果が出るかどうかが一番重要。
テストへの投資額は　バグが顕在化した際に受ける損失＜テストへの投資　であるべきで、
テストへの過度な投資によってマーケット投入が遅れ機会を失うリスク＞バグが顕在化した際に受ける損失であれば早期に市場に投入すれば良い。
Agileな開発との親和性が高いWebアプリケーション開発では、特にサービス提供会社はベータ版という位置づけでどんどん早期にマーケットに投入してくる。
SIerは、サービス系の会社とは業態が違うから、と一蹴するのではなく、何故彼らがそういう行動を取っているのかよく考えるべきなんじゃないだろうか。

平鍋さんセッション

仕事と家庭とバランスが大事、という話はすごく共感できた。
僕があまり残業しないのは、家族と夕飯一緒にたべて会話する時間が大事だから。早起きするのは、自分の時間を確保して勉強したいから。
もちろん忙しい時期もあるから完全にそのとおりにできるわけでもないけれども、自分にとっての持続可能なペースはこれかな、と思うし、このペースを維持しているから、家族の理解を得ながら色々な活動が出来ているのだと思う。
僕にとってアジャイルとは何か？という話をよくするんだけど、それは
「顧客の満足と価値を実現し、開発者のQOLを向上させ、さらに自社の利益もちゃんとあげるための道具」
ということ。
またその思いがはっきりした。

アジャイル本読部

@kompiroさんらと「Fearless Change」を読んだ。英語の文献を読むのは苦痛ではないけど、人に説明できるようにちゃんと読むのは難しい。
日頃から英文を読む機会は多いけど、分からない単語はとばして、どうしても重要なポイントだけ辞書を引くような読み方なので、こういう読み方もあるんだなぁと参考になった。前の会社の時に一時期、本田宗一郎や松下幸之助やジャック・ウェルチの本を半年くらい毎週輪読していたことがあったんだけど、いいよなー。
で、こういう輪読の際は「脱線上等！」が大事。本を読んで理解するだけじゃなくて、そこから何を考えるかが大事だから。

Agile Conference報告

楽天藤原さん、NECソフト安藤さん、静岡県立大学の細澤さんによるAgile Conference 2010への参加報告。先日楽天さんにお邪魔した際に話を聞かせていただいたけど、なんど聞いてもその場の熱狂が伝わってくる。安藤さんがすごいのは、お子様含めた家族も連れて行ったことがある、ということ。@kawagutiさんも会場にお子様連れてきてたし、そういうことができるというのは本当に素晴らしい。10月のとあるイベントで@kawagutiさんが家族参加をOKにできるよう交渉中、という話を聞いたので、もしそうなったら自分の息子(twitterのアイコンの人)を連れていこうと思う。
来年はソルトレークシティーということで、奥さん誘って、なんとか行きたいなぁ。
あと、今年は日本人による発表はなかったので、来年は誰か(@masayang師匠とか@holicさんとか)Submitしてほしいですね。

LT大会と基調LT

登壇者がみんなLT慣れしていて、(LT初という方もいらっしゃったけど、LTの秘孔を突いてきたｗ)、引き込まれた。
@tomohnさんのプレゼンは何度もお聞きしているが、相変わらずしゃべりも資料もすごかった。あの資料を３０分で作るのは人間技じゃないなぁ。
あとは、息子がポケモンバトリオゼロに夢中で、しばしば付き合っているので、ESM水越さんの発表は超笑えた。
僕もよくLTやるけど、LTは楽しい。

パーティ

７０人収容の会場に９０人くらいの人がいて、カオスな感じだったが、@hiranabeさんにご挨拶もでき、@samuraiRedさんたちとお話したりできて良かった。
他にも色々な方とお話をして結構よく聞いたのが、「現在自分だけ（もしくは自分のチームだけ）でアジャイルをやっていて、なかなか周りに理解されない」という悩み。
僕が答えを持ちあわせているわけではないけど、Fearless Changeにも出てくるように、「熱意をもって」取り組むしかないだろう。NECソフト安藤さんのように、社内にコミュニティ作ってゲリラ的に活動してみたり、@kawagutiさんのようにどんどん周りを巻き込んでみたり。
以前マイクロソフトさんでAgile導入に関する話をさせていただいたときにも、触れたけど、「説得ではなく、納得」が大事だし、「理解させるのではなく、興味をもってもらう」ところがスタートでしょう。

その他

アジャイルって本では伝わらないっていう平鍋さんの話もあったけど、こういうセミナーの熱気も文章だけだと伝わらない。
みんなもどんどん行ったら良い。ひきこもり体質の僕が変われたのは、リアルな場に思い切って行くようになって知り合いが増えたことが非常に大きい。　

その他２

多くの出版社さんから本を提供いただいたということで、私も１冊頂戴いたしました。

Implementing Automated Software Testing: How to Save Time and Lower Costs While Raising Quality

著者／訳者：Elfriede Dustin Thom Garrett Bernie Gauf

出版社：Addison-Wesley Professional( 2009-03-14 )

定価：￥ 4,054

Amazon価格：￥ 4,166

ペーパーバック ( 368 ページ )

ISBN-10 : 0321580516

ISBN-13 : 9780321580511


昨年発売された本で、テストの自動化に関する戦略について書かれた本。まだ邦訳はないし、たぶんでない気もする。テストの自動化やCIについては、Scrumを軸としている立場としても、スプリント０で絶対に環境を準備すべき、というスタンスなので、テストについても色々語れるようになりたいな。

自動テストのfixtureを効率的に管理する方法 add Hatena Bookmark
2010/09/03 05:48:35 日記 2 Comments

僕がやっている案件(PHP)はもともとテストコードのないレガシーなプロジェクトで、それを改善するためにずっと動作を確認するための結合レベルの自動テストを増やしてきた。
そんな中で僕のところではどうやってテスト用のfixtureを管理しているか事例として紹介したいと思う。

最初にコアとなるfixtureを用意する

みんなが沢山テストを作る前にコアとなるテスト用のfixtureは用意しておく。
さもないと、みんなが好き勝手にfixtureを作ってしまい、あっという間に混乱に陥る。
プログラム本体と同様に、DRYの原則で、同じようなテストデータを繰り返し作ってしまうようなことは避けるべきだ。
最悪なパターンは開発機や本番機のデータを引っこ抜いてきて、それをそのままテストデータとしてごっそり使う方法。流石に居ないと思いたいが、こういうことをやってしまうとテストデータの見通しが悪すぎて、テストが失敗した場合の検証が非効率だし、そもそもデータのロードに時間がかかりすぎる。

共通のfixtureとテストケースごとのfixtureを分離する

マスター系のテーブルとか、ユーザー情報のテーブルのためのfixtureはテストケースごとにバラバラに用意してはいけない。似たようなfixtureがあちこちに造られると、テストの数が増えてからの仕様変更の際にテストデータのメンテナンスだけでえらく時間が取られてしまう。
僕の場合は、共通fixture置き場に基本的なfixtureをテーブルごとに配置した上で、テストケースごとのfixtureを上書きでロードしている。
以下はPHPの場合だけど、基底クラスで、以下のようにCSVの取り込みロジックを作っておいて

protected function getDataSet()
{
    echo __FUNCTION__ . "\n";
    $dataSet = new PHPUnit_Extensions_Database_DataSet_CsvDataSet();

    if(is_array($this->fixture_path)) {
        foreach($this->fixture_path as $path) {
            echo "----" . $path . "\n";
            if ($dir = opendir($path)) {
                while (($file = readdir($dir)) !== false) {
                    if ($file != "." && $file != ".." && substr($file, -4) == ".csv") {
                        $table_name = str_replace(".csv", "", basename($file));
                        echo "===loading $file...";
                        @$dataSet->addTable($table_name, $path . "/" . $file);
                        echo " done!\n";
                    }
                }
                closedir($dir);
            }
        }
    }
    return $dataSet;
}

テストケースのコンストラクタあたりで

public function HogeTest()
{
    $this->fixture_path = array(dirname(__FILE__) . '/../fixture/',
        dirname(__FILE__) . '/./fixture/'
    );
}

なんてやって、fixtureを複数階層に分けてロードしている。
fixtureをYAMLやXMLで持ってても同じことができるんじゃないかな。

fixtureの内容をチェックするためのツールを作る

僕はPHPUnit＋Seleniumで結合試験を自動化していて、fixtureはテーブルごとにCSVファイルを用意している。これらのCSVをsetUp()で読み込むようにしているんだが、fixtureのカラム数があっていないと、すぐテストが落ちてしまう。(XMLでfixtureを保持していると楽かもしれないんだけど）
開発中は、当然カラムの追加や削除はあるが、その度にどのfixtureを修正しなければならないかを考えるのは面倒で仕方ない。
なので僕は、全fixtureをDBのスキーマと照合するツールを作っている。これがあればスキーマの変更の怖さはちょっと軽減される。

fixtureを自動生成するようなツールを作る

手で整合性の取れたfixtureを作るのはなかなか大変なので、Excelでfixtureをつくるようにしている。
予め用意しておいたシートに値を入れてマクロを動作させると、fixtureが自動で生成されるかんじ。
こういうツールもプロジェクトの早い段階で用意できていると効率的だろう。

日付や時刻等で、テストの成功・失敗条件に関わるテストデータはfixtureとは切り離す

例えば最終ログインから６０日たっていたらAをして、１２０日たっていたらBをする、というテストケースの場合、fixtureに最終ログイン日時をハードコーディングできない。ハードコーディングしてしまうと、そのテストは実行日によってテスト結果が変わってしまうテストであり、自動テストの条件を満たさない。
このような場合は、fixtureにて識別可能な適当な値を設定しておいて、別途テストの初期化メソッドで値を書き換えるような対応をする。

まぁまだまだ改善の余地はあるなぁと思うけど、大分楽になってきたのは確か。
とはいえあくまで外側の挙動が担保できるようになっただけなので、内部的なリファクタリングと、メソッドレベルのテストはこれから増やしていかないといけない。

テスト自動化について5分で分かるまとめ add Hatena Bookmark
2010/08/29 21:23:04 Agile・生産性向上 none Comments

紺屋の白袴ということで、試行錯誤中ではあるのだが、自戒を込めてまとめておく。

テスト自動化/テスト駆動開発について

  • XPのプラクティスの中で、最も単体で導入しやすいプラクティスの１つである。
  • このプラクティスのみで１冊の本が書けるくらい奥が深い
  • 基本的な方法
    • 失敗するテストを書く
    • できる限り早く、テストがパスするような最小限のコード本体を書く
    • リファクタリングをする
  • 適用範囲
    • 通常では、独立性の高いクラスやファンクションへの適用が良い。
    • GUIや分散オブジェクト、自動生成されたコード、DBのスキーマに関するテストは導入が難しい。
    • 既存システムにおいて、テストが準備されていない場合に、部分的に導入するのは難易度が高い。従って新規プロジェクトの初期から導入することが望ましい。
  • 問題点
    • 開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、誤解の検知は保証できない。あくまで開発者が作成するコードが、開発者が認識するテストコードに適合していることのみが保証される。

自動化されたテストが満たすべき性質

テストは以下の条件を満たしている必要がある。

  • 簡単実行
    • テストの準備に大量の時間や人手がかかるようにしない
  • 自己検証
    • テストが成功したか、失敗したかはプログラムが判断する。（人手で判断しない）
  • 繰り返し可能
    • 何回でも繰り返し実行できること。また実行ごとに結果が変わらないこと
  • 独立性
    • 環境や外部のコンポーネントに依存しないこと
    • テストケースの実行順序に依存しないこと

自動テストをどこまで作るべきか？

  • テストの自動化にはコストがかかるため、自動テストによるカバレージを100%にすることを目標としてはいけない
  • バグが無いソフトウェアは本当に良いソフトウェアなの？
    • 顧客のビジネス価値の実現に寄与できるのが良いソフトウェア
  • XPでは、「問題の発生しそうなところはすべてテストせよ」と言っているが、全てをテストせよ、とは言っていない。
  • カバレージ100%への最後の数%はいばらの道。残り数%のテストに、いままで作ったテストと同じだけの労力を必要とすることになる。
  • 常に品質最優先ではなく、コスト・スケジュールと照らし合わせた割り切りも必要。

テスト自動化のレガシープロジェクトへの導入

  • レガシープロジェクトとは？
    • 自動化されたテストが備わっていないプロジェクトのこと。
    • 利用している言語やフレームワークには関係ない。
  • レガシープロジェクトの問題点
    • 機能追加や改修の際に、現行機能に問題がないことを保証するためには、人力による再テストを実施するしかない。
    • 従って機能追加・改修が度重なるたびに、テストのスコープが膨れ上がり、開発コストの増大につながる。
    • 通常、ユニットテストによるテストを意識したモジュール間の依存性が低い状態になっていないため、テストしにくく、結合度の高さ故、変更を加えにくく、予期しない箇所に影響が出やすい。
  • どうやって導入するか？
    • 結合テストレベルのテストを先に用意し、想定されるアプリケーション全体の動作をチェックできるようにする。
    • これによって内部的なロジックを変更した場合でも、アプリケーション機能が壊れていないことは担保できる。その状態で、現行モジュールの修正に際しては、可能な範囲で、ユニットテストが可能になるように作り替えていく。（詳細はレガシーコード改善ガイドを参照のこと）
    • テストモジュールについてはSelenium等を利用すると良い。
    • 新規開発のテストにおいて、SeleniumでHTTPリクエストをトレースする形でテストを作成するのは難しい(UIの変更が頻繁に起こる可能性がありテストのメンテナンスコストが高い)が、一方でUIが既に存在するアプリケーションのSeleniumでのテストは書きやすい。

レガシーコード改善ガイド (Object Oriented SELECTION)

著者／訳者：マイケル・C・フェザーズ

出版社：翔泳社( 2009-07-14 )

定価：￥ 4,410

Amazon価格：￥ 4,410

大型本 ( 472 ページ )

ISBN-10 : 4798116831

ISBN-13 : 9784798116839

ということでレガシーコードと格闘中orz

VMwareの仮想OSのディスク容量を拡大する方法 add Hatena Bookmark
2010/08/28 03:55:14 Linux none Comments

超FAQだけど個人用メモ。

仮想OSのディスクサイズ拡張

vmware-vdiskmanager" -x 10GB hoge.vmdk

  • 作業自体は数分で終わる
  • インスタンスは停止して実行する。もし停止していても仮想OSのディレクトリに.lckファイルが残っていると作業に失敗するので、その場合は手動で削除

拡張したディスク領域を認識させる

GPartedのLive CDを使って仮想マシンを起動し、パーティション情報を修正する。
なお、GPartedはLVMには対応していないので、CentOSのように標準でLVMを使用するOSの場合は、別パーティションを作成し、そのパーティションをLVMに追加することになる。

以下GPartedの操作メモ。

GPartedのLiveCDで起動する。

キーマップの選択。何もせずOK。

キーボード配列の設定。Japaneseを選択。

表示言語は15の日本語を選択。

GUIで設定するほうが楽なので、0を入力し、Xを起動

標準でGPartedが起動される。！マークはLVMで編集できないことをさす。ここで拡張したディスクが未割り当てとして表示されているはずだ。

未割り当てのパーティションを選択して、Newをクリック。CentOSであれば通常ext3でOK。

まだ設定は反映されていないので、ツールバーのApplyボタンを押す。警告が出るので内容確認してダイアログ内のApplyボタンをクリック

反映完了。

結果として、先ほど未割り当てだった領域がsda3として新設されたことがわかる。

以上が終わったら、CDROMを取り出して、OS再起動。

LVMへの新たなパーティションの追加手順

新たに追加したパーティションはsda3なので、これをLVMに追加する。

追加したディスクパーティションをPV(物理ボリューム)として定義する

/usr/sbin/pvcreate /dev/sda3

追加したPVをVolGroup00という名前のVolume Groupに追加する

/usr/sbin/vgextend VolGroup00 /dev/sda3

論理ボリュームにディスク容量を追加する。

/usr/sbin/lvextend -L +2Gb /dev/VolGroup00/LogVol00

ファイルシステムサイズを再認識させてディスク容量の追加を反映させる。

/sbin/resize2fs /dev/VolGroup00/LogVol00

以上で完了。再起動も不要っぽい。

[どうでもよいこと]PHPで波ダッシュ問題にハマった add Hatena Bookmark
2010/08/27 20:10:34 日記 none Comments

自動テスト環境をWindowsからLinux環境にしたとたんに、テストが通らないものが頻発して、初めて開発者がhtmlの中に機種依存文字である波ダッシュを埋め込んでくれていたのに気づいた。。orz

以下Wikipediaから引用。

Unicodeの仕様書では、U+301C WAVE DASH（波ダッシュ）に、「JIS punctuation」（The Unicode Standard、Version 2.0より引用、「JIS約物」の意）という注釈を施しておきながら、JIS X 0208の波ダッシュの例示字形（“上がって下がる” 形「」）とは異なる形（“下がって上がる”形「」）を印刷してしまった。
このような間違いが発生した理由は、Unicodeの例示字形を検討するグループにいたメンバーの日本語に対する知識が不十分だったために、縦書きの例示字形「」を90度回転すればいいと誤って判断してしまったためである[4]。
この影響を受けて、Microsoft Windows（XP以前）ではUnicodeの波ダッシュ (U+301C, WAVE DASH) は“下がって上がる”形「」で表示される（MS 明朝、MS ゴシック、MS UI Gothicにおけるもの）。それに対し、Unicodeの全角チルダ (U+FF5E, FULLWIDTH TILDE) は“上がって下がる” 形「」で表示されるようになっており、Shift_JISの波ダッシュ (0x8160、WAVE DASH)「」と同一の文字として扱われる。
このようにWindowsは、Shift_JISの波ダッシュ (0x8160、WAVE DASH)「」を、本来割り当てるべきUnicodeの波ダッシュ (U+301C, WAVE DASH) ではなく、Unicodeの全角チルダ (U+FF5E, FULLWIDTH TILDE)「」に割り当てている。一方、Mac OSやMac OS XではShift_JISの波ダッシュ (0x8160、WAVE DASH)「」を本来のUnicodeの波ダッシュ (U+301C, WAVE DASH) に割り当てており、その字形も一般的な波ダッシュの形である“上がって下がる”形「」で表示される（Osakaフォントやヒラギノフォントにおけるもの）。このWindows独自のUnicode割り当てが産んだ非互換性により、波ダッシュ (U+301C, WAVE DASH) が環境によっては文字化けを起こす機種依存文字となってしまっている。

JAVAだけの話かと思ってたが、そうじゃなかったんだな〜。

[Agile]指示待ちしてしまうメンバーをどう扱うか add Hatena Bookmark
2010/08/27 12:37:43 Agile・生産性向上 1 Comments

よくある質問に適当に答えるコーナー第二回？。
前提は、アジャイル開発を採用しているシステム開発の場合で、ウォーターフォールでの開発や、その他の業界なんかはまったく想定していないし、ターゲットにしていない。

質問：自分のタスクが終わったら、周りを気にせず帰ってしまう人がいて困っています。

質問：メンバーが指示がないと作業が進められないと言って、待ちになってしまい、生産性があがりません。

回答

1)自分のタスクが終われば帰ってしまう人は、どんな価値を実現しているのだろうか?

顧客の価値を実現するために行動していないよね?
こうなってしまうひとつの理由として、その担当者からお客様が見えていな い、ビジネスの価値が分かっていない、という点があげられると思う。従って、とにかくお客様のところに連れて行き、お客様が何を考えているか理解させるようにすべき。
エンジニアはモノを作るのが仕事なんじゃなくて、価値を実現するのが仕事。

そもそも自分のタスクってなんだっけ？というのもある。Scrumであれば、タスクは自分でサインアップすることになるので、チームがコミットしたゴールに向けて、残っているタスクを自分でサインアップしてこなしていかなければならない。
スクラムマスターがタスクの割り当てをしてしまうから、自分のタスクが終わったら帰ってしまうメンバーが出てきたりするのではなかろうか？
なお、付き合い残業しろ、とかいうつもりはサラサラ無い。そんなの糞だ。
あくまで、チームとして(PMが勝手にではなく)コミットしたものがあるのにも関わらず、そのチームのコミットに対して責任を持たない人をスコープにした話である。

2)チーム内のコミュニケーションを活性化させる。

帰ってしまう人がいるチームは、往々にしてチームのコミュニケーションがうまくいっていない。
個人としてではなく、チームとして成果を出すんだ!という前提のもとに全員の問題をいつでも気軽に話せるようにしなければならない。話にくい雰囲気が出来ると、隠ぺい、先延ばしが発生してリスクになる。

3)勤務評価の軸を「顧客からの満足度・信頼度」やチームメンバーからの「信頼度」においてみると良いかも。

※評価を行える人にならないと無理な方法だけど、オープンな評価軸は組織の透明性を強化し、組織力の向上につながる。

4)待ちになってしまう人への対処は、ペアプログラミングやペアレビューによる地道な教育も効果的。

待ちになってしまう人は、技術力がない、とかチームのやり方が分からない、等といった理由で待ちをしてしまうことも多い。
技術を身につけ、チームのやり方に慣れるためには、その人をひとりにせず、ペアで活動すると良い。徐々に慣れてくるだろう。
日本のほとんどの企業はOJTでは数年上の先輩１人にくっつく形だが、アジャイルなOJTでは、チーム全体で人を育成することになる。
チーム全体がメンバーの能力を向上させる責任を負っている、と考えるべきだ。

5)何をやってもダメなら。

残念ながらそういう人がいるかもしれない。チームにずっとそういう人がいるとチームの士気が低下して周りにも影響を及ぼすようになる。上長と相談してメンバーを入れ替える、といった対忚が必要になる場合もある。

[Agile]似非アジャイルって何ですか？ add Hatena Bookmark
2010/08/25 15:55:29 Agile・生産性向上 none Comments

いままでアジャイルコーチ稼業をしてきて、よく聞かれた質問があるんだけど、それへの答えを定期的に掲載していってみようかと思う。もし質問があったらコメントでもTwitterでも何でも良いのでいただければ、速攻でブログに私見を書いていきます。

【質問】似非アジャイルって何ですか？

回答

例として以下のようなものがあげられると思う。他にもあるだろうけど代表的なところでは

  • アジャイルの4つの価値(ツールより人と人とのコミュニケーション、包括的なドキュメントより動作するソフトウェア、契約よりも顧客との協働、計画の遵守よりも変化への対応、をそれぞれ重視する)に反している
  • 開発すべきもの、期間が決まっている。
  • 顧客への確認にきっちりした資料が必要になる。
  • スクラムマスターがPMのように振る舞い、チームメンバーに全指示を出している。それによってチームが自律的に機能しない
  • チームが顧客の価値の実現のために働いていない
  • プラクティスのつまみ食い
  • プラクティスへの形式的な準拠に終始し、改善のプロセスが働いていない
  • コミュニケーションに形式が要求される。コミュニケーションが電子媒体に偏重して行われる
  • 問題が起こったときに個人が攻撃される
[Agile][翻訳]アジャイル関連書籍ベスト100 add Hatena Bookmark
2010/08/20 05:20:27 Agile・生産性向上 1 Comments

Top 100 Agile Booksというテーマで、Jurgen氏が書かれていたので、どのくらいの本が日本で翻訳されてるんだっけ？という興味もあり、日本語化されているものはその旨追記してみた。

なお、Jurgen氏によれば、Amazonで、「この本を買っている人は合わせてこれも買っています」みたいな情報によって本の一覧を抽出し、ランキングについては、AmazonとGoodReadsというサイトのデータを参考にして重みづけして集計したとのこと。

本が売れないから邦訳が出るのを時間をかけてまっても仕方ないという気もするので、この本翻訳まだー？みたいな人は英語で読んでしまうと良いのではないかと思う。

  1. Agile Estimating and Planning

  2. Clean Code: A Handbook of Agile Software Craftsmanship

    • Robert C. Martin
    • 2008
    • Clean Code

    • Clean Code アジャイルソフトウェア達人の技

      著者／訳者：Robert C. Martin

      出版社：アスキー・メディアワークス( 2009-05-28 )

      定価：￥ 5,040

      Amazon価格：￥ 5,040

      大型本 ( 528 ページ )

      ISBN-10 : 4048676881

      ISBN-13 : 9784048676885

  3. Working Effectively with Legacy Code

    • Michael Feathers
    • 2004
    • レガシーコード改善ガイド

    • レガシーコード改善ガイド (Object Oriented SELECTION)

      著者／訳者：マイケル・C・フェザーズ

      出版社：翔泳社( 2009-07-14 )

      定価：￥ 4,410

      Amazon価格：￥ 4,410

      大型本 ( 472 ページ )

      ISBN-10 : 4798116831

      ISBN-13 : 9784798116839

  4. Refactoring: Improving the Design of Existing Code

  5. The Art of Unit Testing: With Examples in .Net

    • Roy Osherove
    • 2009
  6. Agile Software Development, Principles, Patterns, and Practices

  7. The Pragmatic Programmer: From Journeyman to Master

    • Andrew Hunt, David Thomas
    • 1999
    • 達人プログラマー―システム開発の職人から名匠への道

    • 達人プログラマー―システム開発の職人から名匠への道

      著者／訳者：アンドリュー ハント デビッド トーマス

      出版社：ピアソンエデュケーション( 2000-11 )

      定価：￥ 3,990

      Amazon価格：￥ 3,990

      単行本 ( 333 ページ )

      ISBN-10 : 4894712741

      ISBN-13 : 9784894712744

  8. Kanban: Successful Evolutionary Change for Your Technology Business

    • David J. Anderson
    • 2010
  9. Succeeding with Agile: Software Development Using Scrum

    • Mike Cohn
    • 2009
  10. Growing Object-Oriented Software, Guided by Tests

    • Steve Freeman, Nat Pryce
    • 2009

  11. User Stories Applied: For Agile Software Development

    • Mike Cohn
    • 2004
  12. Lean Software Development: An Agile Toolkit

    • Mary Poppendieck, Tom Poppendieck
    • 2003
    • リーンソフトウエア開発～アジャイル開発を実践する22の方法

    • リーンソフトウエア開発～アジャイル開発を実践する22の方法～

      著者／訳者：メアリー・ポッペンディーク トム・ポッペンディーク

      出版社：日経BP社( 2004-07-23 )

      定価：￥ 2,520

      単行本 ( 307 ページ )

      ISBN-10 : 4822281930

      ISBN-13 : 9784822281939

  13. Domain-Driven Design: Tackling Complexity in the Heart of Software

    • Eric Evans
    • 2003
  14. The Art of Agile Development

  15. Making Things Happen: Mastering Project Management

  16. Agile Principles, Patterns, and Practices in C#

    • Robert C. Martin, Micah Martin
    • 2006
  17. Agile Testing: A Practical Guide for Testers and Agile Teams

  18. Practices of an Agile Developer: Working in the Real World

    • Venkat Subramaniam, Andy Hunt
    • 2005
    • アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

    • アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

      著者／訳者：Venkat Subramaniam Andy Hunt

      出版社：オーム社( 2007-12-22 )

      定価：￥ 2,520

      Amazon価格：￥ 2,520

      単行本（ソフトカバー） ( 220 ページ )

      ISBN-10 : 4274066940

      ISBN-13 : 9784274066948

  19. Behind Closed Doors

    • Johanna Rothman, Esther Derby
    • 2005
  20. Applied Software Project Management

    • Andrew Stellman, Jennifer Greene
    • 2005
  21. Agile Project Management: Creating Innovative Products (1st+2nd Edition)

  22. xUnit Test Patterns: Refactoring Test Code

    • Gerard Meszaros
    • 2007
  23. Scrum and XP from the Trenches

    • Henrik Kniberg
    • 2007
  24. Implementing Lean Software Development: From Concept to Cash

    • Mary Poppendieck, Tom Poppendieck
    • 2006
    • リーン開発の本質 ソフトウエア開発に活かす7つの原則

    • リーン開発の本質 ソフトウエア開発に活かす7つの原則

      著者／訳者：メアリー・ポッペンディーク トム・ポッペンディーク

      出版社：日経BP社( 2008-02-07 )

      定価：￥ 2,520

      Amazon価格：￥ 2,520

      単行本（ソフトカバー） ( 336 ページ )

      ISBN-10 : 482228350X

      ISBN-13 : 9784822283506

  25. Agile and Iterative Development: A Manager’s Guide

  26. Writing Effective Use Cases

    • Alistair Cockburn
    • 2000
    • ユースケース実践ガイド―効果的なユースケースの書き方

    • ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)

      著者／訳者：アリスター コーバーン Alistair Cockburn ウルシステムズ株式会社 山岸 耕二 矢崎 博英 水谷 雅宏 篠原 明子

      出版社：翔泳社( 2001-11 )

      定価：￥ 3,990

      Amazon価格：￥ 3,990

      単行本 ( 330 ページ )

      ISBN-10 : 4798101273

      ISBN-13 : 9784798101279

  27. Refactoring to Patterns

  28. Agile Coaching

    • Rachel Davies, Liz Sedley
    • 2009
  29. Agile Retrospectives: Making Good Teams Great

  30. Agile Adoption Patterns: A Roadmap to Organizational Succes

    • Amr Elssamadisy
    • 2008
  31. Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects

    • Johanna Rothman
    • 2009
  32. The Principles of Product Development Flow: Second Generation Lean Product Development

    • Donald G. Reinertsen
    • 2009
  33. Scaling Software Agility: Best Practices for Large Enterprises

  34. Crystal Clear: A Human-Powered Methodology for Small Teams

    • Alistair Cockburn
    • 2004
  35. Requirements by Collaboration

    • Ellen Gottesdiener
    • 2002
  36. Agile Software Development with Scrum

  37. The Productive Programmer

  38. Organizational Patterns of Agile Software Development

    • James O. Coplien, Neil B. Harrison
    • 2004
  39. Agile Project Management with Scrum

    • Ken Schwaber
    • 2004
  40. Extreme Programming Explained: Embrace Change (1st+2nd Edition)

    • Kent Beck, Cynthia Andres
    • 1999
    • XPエクストリーム・プログラミング入門―変化を受け入れる

    • XPエクストリーム・プログラミング入門―変化を受け入れる

      著者／訳者：ケント ベック

      出版社：ピアソンエデュケーション( 2005-12 )

      定価：￥ 2,415

      Amazon価格：￥ 2,415

      単行本 ( 189 ページ )

      ISBN-10 : 4894716852

      ISBN-13 : 9784894716858

  41. Managing the Design Factory

    • Donald G. Reinertsen
    • 1997
  42. Manage It!: Your Guide to Modern, Pragmatic Project Management

  43. Leading Lean Software Development: Results Are not the Point

    • Mary Poppendieck, Tom Poppendieck
    • 2009
  44. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum

    • Craig Larman, Bas Vodde
    • 2009
  45. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum

    • Craig Larman, Bas Vodde
    • 2008
  46. Agile Software Development: The Cooperative Game (1st+2nd Edition)

    • Alistair Cockburn
    • 2001
    • アジャイルソフトウェア開発

    • アジャイルソフトウェア開発 (The Agile Software Development Series)

      著者／訳者：アリスター・コーバーン Alistair Cockburn

      出版社：ピアソン・エデュケーション( 2002-08-30 )

      定価：￥ 3,360

      Amazon価格：￥ 3,360

      単行本 ( 400 ページ )

      ISBN-10 : 4894715791

      ISBN-13 : 9784894715790

  47. Test Driven Development: By Example

    • Kent Beck
    • 2002
    • テスト駆動開発入門

    • テスト駆動開発入門

      著者／訳者：ケント ベック

      出版社：ピアソンエデュケーション( 2003-09 )

      定価：￥ 3,150

      Amazon価格：￥ 3,150

      単行本 ( 217 ページ )

      ISBN-10 : 4894717115

      ISBN-13 : 9784894717114

  48. Continuous Integration: Improving Software Quality and Reducing Risk

    • Paul M. Duvall, Steve Matyas, Andrew Glover
    • 2007
    • 継続的インテグレーション入門 開発プロセスを自動化する47の作法

    • 継続的インテグレーション入門 開発プロセスを自動化する47の作法

      著者／訳者：ポール・M・デュバル スティーブ・M・マティアス アンドリュー・グローバー

      出版社：日経BP社( 2009-08-06 )

      定価：￥ 3,360

      Amazon価格：￥ 3,360

      単行本（ソフトカバー） ( 304 ページ )

      ISBN-10 : 482228395X

      ISBN-13 : 9784822283957

  49. Collaboration Explained: Facilitation Skills for Software Project Leaders

    • Jean Tabaka
    • 2006
  50. Changing Software Development: Learning to Become Agile

  51. Ship it! A Practical Guide to Successful Software Projects

    • Jared Richardson, William A. Gwaltney
    • 2005
    • Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック

    • Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック

      著者／訳者：Jared Richardson William Gwaltney Jr. でびあんぐる

      出版社：オーム社( 2006-08-26 )

      定価：￥ 2,730

      Amazon価格：￥ 2,730

      単行本（ソフトカバー） ( 224 ページ )

      ISBN-10 : 4274066568

      ISBN-13 : 9784274066566

  52. Agility and Discipline Made Easy: Practices from OpenUP and RUP

  53. Refactoring Databases: Evolutionary Database Design

    • Scott W. Ambler, Pramodkumar J. Sadalage
    • 2006
    • データベース・リファクタリング

    • データベース・リファクタリング

      著者／訳者：スコット W アンブラー ピラモド・サダラージ

      出版社：ピアソンエデュケーション( 2008-03-26 )

      定価：￥ 3,780

      Amazon価格：￥ 3,780

      単行本 ( 330 ページ )

      ISBN-10 : 4894715007

      ISBN-13 : 9784894715004

  54. Managing Agile Projects

    • Kevin J. Aguanno
    • 2005
  55. Beyond Software Architecture: Creating and Sustaining Winning Solutions

    • Luke Hohmann
    • 2003
  56. Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders

    • Andrew Stellman, Jennifer Greene
    • 2009
  57. Beautiful Testing: Leading Professionals Reveal How They Improve Software

    • Adam Goucher, Tim Riley
    • 2009
  58. Managing Agile Projects

    • Sanjiv Augustine
    • 2005
  59. Lean-Agile Software Development: Achieving Enterprise Agility

    • Alan Shalloway, Guy Beaver, James R. Trott
    • 2009
  60. Agile Product Management with Scrum: Creating Products that Customers Love

    • Roman Pichler
    • 2010
  61. Implementation Patterns

    • Kent Beck
    • 2006
    • 実装パターン

    • 実装パターン

      著者／訳者：ケント・ベック Kent Beck

      出版社：ピアソンエデュケーション( 2008-12-22 )

      定価：￥ 2,310

      Amazon価格：￥ 2,310

      単行本（ソフトカバー） ( 208 ページ )

      ISBN-10 : 4894712873

      ISBN-13 : 9784894712874

  62. Extreme Programming Installed

    • Ron Jeffries, Ann Anderson, Chet Hendrickson
    • 2000
    • XPエクストリーム・プログラミング導入編 ― XP実践の手引き

    • XPエクストリーム・プログラミング導入編 ― XP実践の手引き (The XP Series)

      著者／訳者：ロン・ジェフリーズ アン・アンダーソン チェット・ヘンドリクソン

      出版社：ピアソン・エデュケーション( 2001-08-10 )

      定価：￥ 2,520

      Amazon価格：￥ 2,520

      単行本（ソフトカバー） ( 348 ページ )

      ISBN-10 : 4894714914

      ISBN-13 : 9784894714915

  63. Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams

    • Greg Cohen
    • 2010
  64. Balancing Agility and Discipline: A Guide for the Perplexed

    • Barry Boehm, Richard Turner
    • 2003
  65. Effective Project Management: Traditional, Agile, Extreme

    • Robert K. Wysocki
    • 2003
  66. Emergent Design: The Evolutionary Nature of Professional Software Development

    • Scott L. Bain
    • 2008
  67. Fearless Change: Patterns for Introducing New Ideas

    • Mary Lynn Manns, Linda Rising
    • 2004
  68. Stand Back and Deliver: Accelerating Business Agility

    • Pollyanna Pixton, Niel Nickolaisen, Todd Little, Kent McDonald
    • 2009
  69. A Tale of Two Systems: Lean and Agile Software Development for Business Leaders

    • Michael K. Levine
    • 2009
  70. Just Enough Requirements Management: Where Software Development Meets Marketing

    • Alan Mark Davis
    • 2005
  71. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition

    • Lyssa Adkins
    • 2010
  72. Growing Software: Proven Strategies for Managing Software Engineers

    • Louis Testa
    • 2009
  73. Becoming Agile: …in an Imperfect World

    • Greg Smith, Ahmed Sidky
    • 2008
  74. Agile Game Development with Scrum

    • Clinton Keith
    • 2010
  75. Test Driven: TDD and Acceptance TDD for Java Developers

    • Lasse Koskela
    • 2007
  76. The Business Value of Agile Software Methods: Maximizing Roi With Just-in-time Processes and Documentation

    • David F. Rico, Hasan H. Sayani, Saya Sone
    • 2009
  77. A Practical Guide to Distributed Scrum

    • Elizabeth Woodward, Steffan Surdek, Matthew Ganis
    • 2010
  78. Principles of Software Development Leadership: Applying Project Management Principles to Agile Software Development

    • Ken Whitaker
    • 2009
  79. Patterns of Agile Practice Adoption

    • Amr Elssamadisy
    • 2007
  80. Innovation Games: Creating Breakthrough Products Through Collaborative Play

    • Luke Hohmann
    • 2006
  81. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results

    • David J. Anderson
    • 2003
    • アジャイルソフトウェアマネジメント

    • アジャイルソフトウェアマネジメント

      著者／訳者：David J. Anderson

      出版社：日刊工業新聞社( 2006-03 )

      定価：￥ 4,410

      Amazon価格：￥ 4,410

      単行本 ( 385 ページ )

      ISBN-10 : 4526056162

      ISBN-13 : 9784526056161

  82. Project Management the Agile Way: Making It Work in the Enterprise

    • John C. Goodpasture
    • 2009
  83. The Software Project Manager’s Bridge to Agility

    • Michele Sliger, Stacia Broderick
    • 2008
  84. Business Agility: Sustainable Prosperity in a Relentlessly Competitive World

    • Michael H. Hugos
    • 2009
  85. The Enterprise Unified Process: Extending the Rational Unified Process

    • Scott W. Ambler, John Nalbone, Michael J. Vizdos
    • 2005
    • エンタープライズ統一プロセス

    • エンタープライズ統一プロセス (Object Oriented SELECTION)

      著者／訳者：John Nalbone Michael J. Vizdos 藤井 拓

      出版社：翔泳社( 2006-07-11 )

      定価：￥ 4,725

      Amazon価格：￥ 4,725

      大型本 ( 400 ページ )

      ISBN-10 : 4798109347

      ISBN-13 : 9784798109343

  86. Kanban and Scrum – Making the Most of Both

    • Henrik Kniberg, Mattias Skarin
    • 2010
  87. Agile Software Development: Best Practices for Large Software Development Projects

    • Thomas Stober, Uwe Hansmann
    • 2009
  88. Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing

    • Gojko Adzic
    • 2009
  89. Software Endgames: Eliminating Defects, Controlling Change, And The Countdown To On-time Delivery

    • Robert Galen
    • 2004
  90. Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process

  91. Agile Software Development Ecosystems

  92. Software by Numbers: Low-Risk, High-Return Development

    • Mark Denne, Jane Cleland-Huang
    • 2003
  93. Scrumban – Essays on Kanban Systems for Lean Software Development

    • Corey Ladas
    • 2008
  94. The Enterprise and Scrum

    • Ken Schwaber
    • 2007
  95. Test-Driven Development: A Practical Guide

    • David Astels
    • 2003
  96. Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed

    • Mario E. Moreira
    • 2009
  97. Testing Extreme Programming

    • Lisa Crispin, Tip House
    • 2002
  98. Patterns for Effective Use Cases

    • Steve Adolph, Paul Bramble
    • 2002
  99. Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development

    • Bruce Powel Douglass
    • 2009
  100. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems

    • Jim Highsmith
    • 1999
[Trac][Agile]Agilo日本語版Trac 0.11.7に対応しました add Hatena Bookmark
2010/08/14 18:43:47 Agile・生産性向上, Trac none Comments

Sourceforge.jpで公開しているAgilo日本語版ですが、Trac 0.11.6およびTrac 0.11.7でインストールに失敗する件について対応を行ないました。

入手は以下から。
http://sourceforge.jp/projects/shibuya-trac/wiki/plugins/Agilo_ja

なお、インストール後にプロダクトバックログ画面で、UnicodeDecodeErrorが表示される場合は、http://www.ryuzee.com/contents/blog/941を参照して、sitecustomize.pyを作成してください。

Agiloって何という方は以下のスライドを参照ください。

TracでAgileプロジェクトを可視化する方法

 

日記 PHP オープンソース インストールマニアックス IIS Trac MySQL Perl Linux Agile・生産性向上 wordpress フリーソフト 自宅サーバ 書評 ブックマーク phpMyFaq TraM Plugin 早起き Delphi apache CakePHP Firefox Ruby eclipse セキュリティ プラグイン アジャイル mojavi Subversion Ajax/Web2.0 SQLServer Zope サーバ フレームワーク phpBB 仮想化 PostgreSQL OpenVZ scuttle CMS 文字化け 自宅 翻訳・日本語化 ApacheDS LDAP Excel 生産性向上 CodeIgniter XAMPP hacks taskfreak 修正 言語ファイル Ajax SBM ダウンロード HTML::FillInForm mod_security 情報共有


ads

読まなきゃモグリ

Recent Posts

最近のコメント

あわせて読みたいブログパーツ