Ryuzee.com

タイトル通りなのですが、TracのAgile用プラグインのAgiloの翻訳をしています。
Agiloは、agile42が提供するAgileプロジェクト支援用のソフトウェアで、有償バージョンと無償バージョンがあります。無償バージョンは、Apacheライセンスで提供されています。

もうすぐ日本語版を公開できると思うので、とりあえずスクリーンショットをさらしておきます。
TracでAgileをやる場合に、要求とストーリーとタスクの関連付けが難しかったのですが、このプラグインを使うとそのあたりが解決できると思います。

プロダクトバックログとタスクの階層管理

バーンダウンチャート

プロダクトバックログ一覧

スプリント編集

Shibuya-tracつながりで、IBMのAgileセミナー「チーム開発の生産性を高めるプロセスを体感しよう（入門編）」に行ってきた。
内容はScrumの基礎とRational Team Concert(RTC)の紹介。

Scrumについては、@masayang師匠から教えを受け、多数の案件をやってきているので、新たな発見というのはあまり無かったけど、改めて復習にはなった。ただセミナーの内容は純粋Scrumというよりは日本型Scrumと言った方が良いかと思う。ターゲット層がAgile初心者だったようなので「これがAgileというものなんです」と言うと誤解を招く恐れがあるのではないかな。Agileマニフェストを最初に説明しておいた方が良かったと思う。

参考になった点を列挙しておく。

Scrum概説

• WFとAgileの例え。WFは長編映画。あたるかどうかは封を切ってみないと分からない。一方でAgileは連続TVドラマ。視聴者の反応を見ながら変えていく。
• Agileにおけるスプリント毎のリリースは、今日の話では「物理的なリリースというよりは、顧客へのレビューの区切り、という位置づけが大きい」と説明されていた。それであれば、全スプリント完了後に結合テストだとか総合テストだとかをやらなきゃいけない、というのは分からなくもない。しかし実際プロダクションリリースとしてリリースできるモノであるならば機会損失の最小化を目指して早期なリリースをするのはビジネス上は重要だと思うので、その点はプロジェクトの性質によって決めていくのだろう。
• 「旧来組織の管理職は、Agileな組織においてはクラスチェンジせざるを得ない。Scrumマスターかファシリテーターが現実路線。」という点については激しく同意。隣になった人に話したのだが、Agileをやろうとすると組織構成や新入社員の教育プロセス、そして各人の評価プロセスについて再構築が必要だと思う。この点については日本のSIerはまだ答えを出していない。
• 「ストーリーはプロジェクト全行程の絵コンテ」と表現されていたが、ちょっと怖い表現。物理的な画面イメージの登場時期については十分な検討が必要。UIの議論に終始すると危険なのは経験則上間違いないので。
• 講師の方の説明で、ストーリーに「開発ルームの設定」とか「マシンのセットアップ」が入っていた。個人的にはこれはスプリント0のタスクだと思うので突っ込んで聞いてみた。答えとしては、これも顧客にとっては価値がある内容なので入れて良い、とのこと。顧客に価値があるので入れて良いというのは分かる気がするが、その場合プロダクトバックログとしては、「生産性を高く保てる環境を用意する」というストーリーにして、部屋だとかマシンはタスクのような気がする。
• そういう意味で、「バックログやタスクの書き方に正解はない」と話されていたが、正解は無いとしても王道はあるんじゃない？とは思っているんだけどどうなのかな？
• 分かること/分からないことをはっきりさせる。棚上げの禁止
• 必ず何かしらの手戻りがあると思うこと（小さい「どっひゃー」みたいな）

Rational Team Concert

• ユーザーの作成、プロジェクトの作成、プロダクトバックログ、ストーリーの作成、運用まで１時間ちょいで。
• Tracを日々使っている身としては抵抗はあまりない。Trac＋Agiloも簡単だが、RTCもなかなか簡単そう。ちょいとボタンやメニューが多くて最初は戸惑いそうだが。
• ちょっと次の案件で使ってみようかなと思ったり。
• Linuxで動くのかな？

その他

• 研修で、「実践アジャイルプロジェクト管理～スクラムではじめる最強エンタープライズ開発～」の本を頂戴したのだが、丁度前日にオンラインで購入しちまったところだった。家に新品が2冊ある切なさ。顔見知りの人に差し上げますわ
• プロダクトバックログを書くワークショップで、かおるんさんと一緒になったんだけど、以前からやっているように、「誰々がほげほげする。それによってまげまげを得る」みたいな書き方をしていたら、講師の方から、「このチームはやり慣れてますね～」と言われた。入門編にいくのは場違いだっかかもしれん（笑）

一週間以上ブログへのPostが滞っていたのだが、やはり日々の仕事に追われた状況になるとinputしないので、outputできないんだよね。
ということで今日は過去のネタを書くよ。

Webアプリでメールを送信するケースは良くあるんだけど、テストは結構やりづらい。
よくある失敗パターンは下記みたいな感じ。年に数回こういうことするなーって会社でアナウンスされたりする。

• 大量送信のテストで社内ネットワーク止めた
• 携帯キャリア宛てに大量のメール送ってSpam扱いされた
• 自分のメールボックスに大量のテストメールが来て受信に死ぬほど時間がかかる
• 間違って本物の顧客のテストメール送ってしまった
• 送信元アドレスも送信先アドレスもダミーなものを使ってインターネット上にメール投げた

で、こういう失敗って、環境の作り方で十分保護できる。僕のやっているパターンを書いておく。

Radishで開発端末にSMTPを立てて、メール送信はそのSMTPを通す

Radishはフリーでソースが公開されているPOP、SMTP、DNSサーバで、http://homepage2.nifty.com/spw/software/radish/で提供されている。

SMTP設定は以下のような感じ。待ちうけるIPアドレスとアクセス許可ネットワークの設定を行う。

一般設定では「キュー常時処理」にチェックを入れてしまうと、Radishは中継したメールをそのまま外に投げてしまうので、必ずチェックを外す。

これでメールを送信すれば以下のようにRadishのキューにメールが溜まる。ダブルクリックすればそのメールの中身がメールソフトで確認できるので、自分のメールボックスにゴミがたまることもない。

さらに安全のためにsendmailもいじくる

とは言え、うっかりRadishでキューを全部処理してしまったりすると世間様にご迷惑をおかけするので、予めsendmail側で、開発に関係ないドメインにメールを送信しないようにしておくべきだ。

sendmailの場合は、/etc/mail/mailertableに以下のように書くと良い。

その上で、

とし、sendmail.mcで

を有効にして、sendmail.cfを作成し、sendmailを再起動すれば良い。

これによってryuzee.com宛てのメールは192.168.1.50のSMTPにリレーするが、それ以外のドメイン宛てのメールは全部捨てられる。
なお、smtp:のあとのアドレスを[]で囲んだ場合はDNSの逆引きが行われない。

Agileプロジェクトにおける契約についてちょっと私見を整理してみた。

• 期間、費用が固定されていて、製造量が不定になる請負契約は行わない。
• 特に上記のケースで、顧客側が開発側に対して強い力を持っている場合は、顧客の力による押し切り、社内の弱い管理者による承諾と開発チームへの強要といったことが発生しやすい。
• Agileは基本的には準委任の方が良い。請負契約の場合、契約時点で成果物をお互いの齟齬がないように明確にせねばならず、往々にして、その認識の齟齬がプロジェクト混乱の原因になりやすい。
• Agileプロジェクトでどうしても請負契約を締結する必要がある場合は、最低限プロダクトバックログの抽出と、以降の開発スプリントについては契約を分離しよう。
• プロダクトバックログが出来上がればストーリーポイントや優先度の算出が出来るし、スプリント計画も立てられるので、ブレは少なくなる。但し全部のスプリント分を一括して契約するのではなく、スプリント毎の契約に出来るとさらに安心だ。
• 一方で顧客側の立場からすると、なんで開発側はそんなに守りに入っているのよ？と見えなくもない。
• しかし開発側は「顧客の欲しいものは日々変わる」「最初にたてた計画はだいたいあっていない」ということを良く知っているんだよね。
• だからこそ、契約なり提案の時点で、開発側は、「プロジェクトをAgileでやること」「Agileで行うメリット/デメリット」の説明をしておく必要がある。なんとなく不安だから請負契約がイヤだ、というのは筋が通りにくい。
• また、契約の時点でチームの生産力の目安を顧客に伝える必要はあるだろう。請負でない形態にした場合、完成しないけれども金は使った、という状態になり得るわけで、その不安も解消する必要がある。
• 個人的な意見としては、そのプロジェクトの前のプロジェクトのプロダクトバックログ(想定ストーリーポイントと実ストーリーポイント入り。全部でなくても良いので、基準ストーリーポイントになったストーリーといくつか規模の違うストーリーが入っていれば良い)とチームのベロシティを提示してあげることだと思う。それによって顧客はチームの生産力をおおよそ把握できるのではないか。
• 上記に書いたような話はもう提案書に書いてしまおう。表面的な提案が顧客に通って契約交渉を始めてから揉めるよりも、最初から「Agileじゃなきゃやらないよーん」という意思表示も必要。提案が通った後に契約方法で揉めたあげくに押し切られてAgileのつもりだったのに詳細設計書大量に書いたり、成果物保証させられたり、というのを結構経験してきた。もうそんなのやめようよ。

Agileを真剣にやるために会社変えて色々勉強しつつ布教活動なんぞをしているのだが、そんな俺がデスマっちゃったよ(笑)
世の中からデスマーチを無くす、というのを大きい目標にしているのだが、自分でも出来ていない(嘲)

この後同じことを繰り返すと馬鹿なので、まだデスマ中だけど、問題点と反省点を書いておこうと思う。
こういうのは渦中にやっておかないと終わった後だと「大変だけど終わって良かったね」で終わってしまいがちなんだよね。
これを読まれている方は反面教師にしてください。

契約と総生産量の関係性

• 期間と費用が決まっている場合、総生産量には当然上限がある。生産量はチームのベロシティが分かっていれば、ストーリーポイントに換算できるので、開発開始時点で、総生産可能ストーリーポイントについては明示すべきだった。土日出て頑張れ！とか残業して頑張れ！とかいうのはAgileを知らない証拠。
• 上記に関連して、プロダクトバックログにストーリーを追加することが出来るのは、プロダクトオーナーの権利なのだけれども、優先度高としてストーリーを追加したところで、バーター可能なストーリーがなければスプリントへの組み込みが難しいことを明示すべきだった。
• さらに、スプリント完了後に手前のストーリーの仕様を変更した場合も、総生産量制限がある以上、バーターがあることを明示すべきだった。
• こういう話がされないで顧客と契約されることがないようにしておかないといけない。契約書で明記できないなら、提案書なりでパターン化した記述を常に入れた方が良い。前の会社で嵌ったパターンは、契約書や提案書にこの手の話が書いていないために、無尽蔵に仕様変更を受け入れざるを得なくなるパターン。死人も結構でた。

プロダクトバックログの話

• パワーポイントの画面遷移図みたいなものをベースにして仕様を決定していくのはデスマパターンの第一歩(散々認識しているけどね)。とにかく最初に止めるべきだった。
• 画面UIを見ないと仕様が決められないのだとすると、本当に提供したいものは何？というのがプロダクトオーナー側で固まっていない可能性あり。この徴候があった場合はむしろスクラムマスターが、徹底的に顧客にヒアリングして、「誰々はhogehogeできる。それによってfugafuggaを得る」の形で要求を整理しにいくべきだった。画面を見てあっている/間違っている、というレベルよりも、前提は合いやすい。
• 今回はUIの案からバックログを抽出してしまったので、UIでは見えてこないモデルや状態遷移、非機能要件が見えにくく、画面のUIが変わるたびにバックログのストーリーが変わってしまうという問題が起きている。
• UIの議論が先行すると、本当に必要なことが見えにくくなる。というのは何度も言っているが意外と理解されない。

プロダクトオーナー、スクラムマスター、Proxy、体制とか

• 間にProxyな人が挟まるパターンではProxyをやる人にScrumの知識が必要。中途半端に誤解されているパターンは危険。Agileだから早く安くできるんだろ？は聞き飽きる。
• そういう状況であれば、スクラムマスターはProxyを通さないように行動するべきだった。
• Agileでは対面のコミュニケーションを最重要視するのだが、分散Agileで全体的にコミュニケーションが不足。
• スクラムマスターが他の仕事を多数かけもちしているため、後手を踏みやすい。

さ、ガンバろ。この話に関連する話をいくつかあげておこう。

• [システム開発][Agile開発]画面設計とか外部設計とか、もうやめようよ (師匠のサイト)
• [Agile]間違ったAgileへの理解がプロジェクトを迷走させる
• [Agile]スプリント中の実装ストーリーの入れ替え
• [Agile]チームがAgileかどうかをセルフアセスメントする42の質問
• [Agile]再利用可能なAgile契約

スプリントを複数こなしたあとに結合テスト、総合テストと称するものをやる理由がわからん。それをやらなきゃ品質担保できないのだとしたら、スプリントごとにリリース可能にするという原則に反しているんじゃないかね？

個人的な感想だが、最後に結合テスト、総合テストと称するものやらなきゃいけなくなっている理由は以下のような感じかな？

• 会社のプロセスで決められているｗ
• 顧客から求められた
• そもそも設計に失敗していて、複数のオブジェクトの結合度が高すぎるが故に、ユニットテストできない（←僕の予想ではこいつが本命）。従って実はスプリント単位ではリリースできないｗ
• ユニットテスト書く時間が無かったので力技でなんとかしようとしている

ちなみに、重厚長大なテストを行うのに大量のコストをかけるくらいなら、とっととリリースして出てきた問題潰した方が良いケースもあるだろう。これはROIの問題なので、必ず100%のカバレージをなんとしてでも達成しよう！なんてのはあり得ないと思うんだよね。（WF屋の教科書にはパターン網羅とか書いてあるけど・・・）

詳しい人教えてちょーだい。

発表するとやらざるを得ない（笑）ということで、TraMのタイムラインのRSS出力に対応しました。
これによって公開プロジェクトであれば、いちいち各プロジェクトのRSSを登録しなくても、TraMのRSSさえ収集すれば状況が把握できるようになります。
ついでにTraM全体でエラー処理があまくて、Internal Server Errorが出てしまう場合がありましたので、これも修正しています。

TraMの詳細はこちら：http://sourceforge.jp/projects/shibuya-trac/wiki/plugins%2FTraM
レポジトリURL：http://svn.sourceforge.jp/svnroot/shibuya-trac/plugins/TraM/branches/genshi-ja

InfoQ: アジャイル開発を成功に導く26のヒント
http://www.infoq.com/jp/news/2009/10/hints-agile-development
から原文
http://www.pmhut.com/26-hints-for-agile-software-development
を辿っててきとーーーに意訳しておいた。
詳しく知りたい場合は上記の原文をどうぞ。

• 2つめの作業に入る前に1つめの作業を終わらせよう
• ビルドを壊してはいけない
• ルーチンはユースケースの実装で必要になるまでは作ってはいけない。
• ユースケースの実装で必要になるまでは、メンバー変数を追加してはいけない。
• 意思決定することを恐れるな
• 品質を向上させる方法を常に勉強しろ
• 測定しろ、測定しろ、測定しろ
• システムではなく人を中心とした設計をしろ(最終的な目的はシステムを使って人々の仕事が成し遂げられるのを助けることだと理解しろ)
• テストは製品の一部だ
• コードを書く前にテストを書け
• 無駄を省け
• ビルドが壊れたらすぐに対応する土壌をつくれ(壊れたビルドを放置するな)
• 全てのチームメンバーは顧客の要求を理解する必要がある
• 関連する事柄は一緒にしておけ(密接に関連することは同じクラスの中に配置する)
• チェックインの前には常にテストを実行する
• 早い段階での最適化は諸悪の根源だ
• 終了していないコーディングタスクの数は最小限にしろ(同時に複数いじくらない)
• 機能を一般化しすぎない
• 2行で出来ることを3行でやらない
• コードの行数を測定してはならない
• 継続的なリデザインとリファクタリングを行うこと
• 利用していないコードは消す
• 新しい言語を発明しない
• 実装と実装のテストが終わるまでは詳細なユーザーインタフェイスのデザインはしない
• ソフトウェアはプラスチックだ(スペックを変えるよりデザインを変える方が簡単だ)
• 問題の詳細を出力することに時間を使いなさい(例外やエラーに関するメッセージは適当にしない)

日々の仕事の中でなかなか全部できていないのが悔しいところだけど、それでもやらなきゃいけない。

平均4:51。土日も5時くらいに目覚め。もう朝五時は暗いし寒いが、特に起床時間への影響はなし。

 

日記 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 情報共有