スクラム道.02に行けなかった

開発 agile 勉強会

スクラム道.02はバーンダウンチャートについての話でした。

非常に生き行きたかったのですが残念ながら家庭の事情もあり行けませんでした。
参加者の知見を聞くことは出来ませんでしたが、ありがたいことに今回の語り部である@Ryuzeeさんが資料を公開されていますので、「バーンダウンチャートって?」とか「う〜ん、バーンダウンチャートねぇ」という人はご覧になることをお奨めします。

はなてにはエントリ書いてませんでしたが、以前私がShibuya.trac#6で発表した似非バーンダウンチャートの話と対比してみると面白いかと思います。*1


スプリントバーンダウンチャート虎の巻



滝の中でバーンダウン(Shibuya.trac＃6)
View more presentations from Kanu orz.

次回、「スクラム道.03に行けなかった」に続きます(嘘)

*1:私の駄目さ加減が良く分かりますw

クリスマスイブなのでグラス片手に・・・

開発 雑文

PDCAのサイクルが良いモノとするのであり、システム開発におけるプロセスでも実施すべきと考えると・・・

ウォーターフォールはプロジェクト全体もしくは個々の工程でのPDCAの実施となる。行程毎でも全体であってもPDCAの効果が得られるのは進行中のプロジェクトではなく次プロジェクトということになり、結果としてPDCAサイクルの効果は顧客にフィードバックされにくい構造となる。

対してスプリント/イテレーション単位で動くものを作るアジャイルな開発におけるPDCAサイクルは、スプリント/イテレーション単位で実施され次のスプリント/イテレーションでPDCAサイクル実施の効果を得ることが可能になる。

結果としてウォーターフォールについてはPDCAサイクルの効果がプロジェクト進行中に得られにくいため、失敗を最小限にするリスク管理が求められることになる。対してアジャイルな開発プロセスではPDCAサイクルの効果が得られやすいため失敗するリスクを許容し、その失敗を次のスプリント・イテレーションへ生かすという形のプロジェクト管理が可能になる。

ゆえに一部で言われるハイブリットアジャイルという、ウォーターフォールの各工程もしくは特定工程以後をイテレーションで区切り開発することは、アジャイルな開発プロセスにおけるメリットを採り入れているように見えても、その効果は極めて限られたものであり本来の得られるメリットとは程遠いものになる。

しかしウォーターフォールに少しでもアジャイルな開発におけるメリット採り入れようとする試みだと考えると悪くはなく、むしろ過渡期もしくは移行期の形態としてはありだと思うし、その効果を知りアジャイルな開発プロセスへ移行するきっかけとなれば良いのではないだろうか。



でもね・・・軸足がウォーターフォールでアジャイルマニフェストを気にもしない方法を、ハイブリットアジャイルと呼ぶのはどうかと思うんだよね。ハイブリットウォーターフォールなら分かるけど。いくらグラス片手に酔っぱらっているとは言っても酷すぎると思う。*1

*1:参考記事：グラス片手にアジャイル開発連載一覧：CodeZine（コードジン）

TracLightningの2系と3系を同居させてみた(結構適当)

Trac

2010/12/13 追記あり

サンプルプロジェクトのインターフェースがすっかり変わって話題の TracLightning3.0 ですが、今日現在で3.0.3がリリースされてます。
TracLightning3.0 の本質は見た目の変更ではなく、Trac本体のメジャーバージョンアップと増えすぎた同梱プラグインの整理にあります。
では早速移行しようと思ってもTrac本体のメジャーバージョンアップの影響確認と、今までの環境に別途入れたプラグインの調整などが必要になります。

vm立てて疑似環境作ってテストして〜と行きたいところですが Windows だとライセンスの兼ね合いもあったりで簡単ではありません。

そこで既にTracを運用しているサーバにリソースの余裕があったので同居させて検証してみることにしました。
無事、同居出来たので以下にその方法をメモ代わりに書いておきます。
あくまでも検証用なのでサービスで起動せずコマンドプロンプトからの起動ですので、その辺りはご了承を。*1


0.アジェンダ

作業としては

  • 一旦別なPCにインストールして、それをコピーする。
  • Apacheのポートを変更する
  • Hudsonのポートを変更する
  • Pyhton周りのPathが重複しないようにする
  • 今動いてるTracを止めない(←一番重要w)

を念頭に置いて作業をすると目標が達成できます。

1.一旦別なPCにインストールする

これは TracLightning は一部ですが環境変数を操作します。
Trac稼働中サーバに直接インストールすると動かなくなるためにこれを回避します。
インストールする先はドライブ構成が同じマシンが望ましいですが、それが出来ない場合は subst などで仮想ドライブなどを割り当てると良いでしょう。

C:\>c:\subst D: C:\TEST

また当然ですが稼働中の環境と同じパスにしてしまうと後の変更が面倒なので、必ずデフォルトの TracLight ではなく Trac303 などに稼働中のものと異なる path にインストールしましょう。

2.Apacheのポートを変更する

新たにインストールした TracLightning の Apache のポートを変更します。
%TRAC_LIGHT_HOME%\CollabNetSVN\httpd\confにあるhttpd.confを修正します。
53行目辺りに

Listen 80

とある部分を

Listen 8080

のように任意のポートに変更します。(この場合は8080)

Hudson用Proxyポートも変更します。
608行目辺りの

ProxyPass http://127.0.0.1:8010/hudson
ProxyPassReverse http://127.0.0.1:8010/hudson

とある部分を

ProxyPass http://127.0.0.1:8020/hudson
ProxyPassReverse http://127.0.0.1:8020/hudson

のようにして任意のポートに変更します。(このばあいは8020)

3.Hudsonのポートを変更する

%TRAC_LIGHT_HOME%\hudson にある hudson.bat でのポート指定を変更します。

"%JAVA_CMD%" -Duser.home="%TL_PROJECT_HOME%\hudson" -jar hudson.war --prefix=/hudson --ajp13Port=8009 --ajp13ListenAddress=127.0.0.1 --httpListenAddress=127.0.0.1 --httpPort=8010

の "----httpPort=8010" の部分を

"%JAVA_CMD%" -Duser.home="%TL_PROJECT_HOME%\hudson" -jar hudson.war --prefix=/hudson --ajp13Port=8009 --ajp13ListenAddress=127.0.0.1 --httpListenAddress=127.0.0.1 --httpPort=8020

のように、http.confで指定したポート(この場合は8020)に変更します。

4.setenv.batにPYTHONPATHの追加

%TRAC_LIGHT_HOME%\bin にある setenv.bat に PYTHONPATH の設定を追加します。
環境変数を設定するsetenv.batでは PYTHONHOME は指定されていますが、PYTHONPATH の設定がなく既存環境と重複してしまいますので、そのための処置になります。

setenv.bat の最終行に

SET PYTHONPATH=%TRAC_LIGHT_HOME%\python\DLLs\;%TRAC_LIGHT_HOME%\python\Lib;%TRAC_LIGHT_HOME%\python\Lib\plat-win;%TRAC_LIGHT_HOME%\python\Lib\lib-tk;%TRAC_LIGHT_HOME%\python\Lib\site-packages

をして追加して PYTHONPATH の設定を行うようにします。

また最終行に以下を追加します。2010/12/13 追記

set PATH=%PYTHONPATH%;%PATH%

これのPATH指定が無いとコマンドプロンプトでのtrac-admin等の実行に支障が出ます。

5. start.bat の変更

2010/12/13 追記あり
setenv.batと同様にPYTHONPATHの追加とPATHの設定の追加を行います。(5行目あたり)

SET PYTHONPATH=%TRAC_LIGHT_HOME%\python\DLLs\;%TRAC_LIGHT_HOME%\python\Lib;%TRAC_LIGHT_HOME%\python\Lib\plat-win;%TRAC_LIGHT_HOME%\python\Lib\lib-tk;%TRAC_LIGHT_HOME%\python\Lib\site-packages

set PATH=%PYTHONPATH%;%PATH%

またstart.bat で既に TracLightning と言うサービスが起動している場合には、停止後に再起動するようになっています。
同居前提の場合は先に動いている TracLightning を止められては敵いませんので、その部分をコメントアウトします。
9行目の

httpd.exe -n TracLightning -k stop

とある部分を

REM httpd.exe -n TracLightning -k stop

にしてコメントアウトします。


6. ショートカットの変更

同居を前提とするとスタートメニューに含まれるショートカットの名前が重複して分かりにくいので、各ショートの頭に TL3 とでも追加しておくと分かりやすくなります。
スタートメニューにある「サービスのインストール」「サービスのアンインストール」は削除しておいた方が安全だと思います。*2

7. 稼働中の環境へのコピー

インストールした TracLightning のフォルダー丸ごとと、スタートメニューのショートカットを、同居させたいTrac稼働中のサーバにコピーします。

8. 起動

コピーしたショートカットの「コマンドプロンプトから実行」で起動させます。
ブラウザで"http://127.0.0.1:8080/trac/SampleProject"として表示されれば無事完了です。

9. 終わりに

思いのほか簡単に同居出来ました。
プラグインの追加なども、個別のショートカットのコマンドプロンプトを利用することで独立させて行うことが出来るようになりますので、安心して作業することが出来ます。
気をつけるのは同居させたいマシンに直接インストールぜず、ドライブやパスを同居させたい環境に合わせた状態で別PCへインストールすることでしょうか。

TracLightning3.0の世界を是非お楽しみください。*3

質問あればコメント欄でもTwitterででも聞いてくださいな。

*1:不可能ではないはずけど面倒だからw

*2:間違って既存のサービスの書き換えてしまうことを防ぐため

*3:ちなみに2系と3系の同居だけでなく、3系同士や2系同士の同居も同じ手法で可能です。

アジャイラーを責めないで

ネタ

私はアジャイルが嫌いです。
アジャイルは幼稚で　礼儀知らずで　気分屋で
個人との対話と　動くソフトウェア　顧客との協調と　変化への対応を実践している。
甘やかすとつけあがり　放ったらかすと悪のりする
滝だ　ハンコ主義だ　変化しないだと　はっきり口に出して人をはやしたてる無神経さ
私ははっきりいって契約主義です

努力しないことを許さない　予想に基づく行動もしない
手順と形式の深みも　渋みも　何にも持っていない
そのくせ　下から見上げるようなあの態度
火事の時は足でまとい　契約の時は悩みの種　いつも開発の問題児
そんな御荷物みたいな　そんな宅急便みたいな　そんなアジャイルが嫌いだ

私は思うのです　この世の中からアジャイルがなくなってくれたらと
ウォーターフォールだけの世の中ならどんなによいことでしょう
私はアジャイルに関わらないでよかったと胸をなで下ろしています。

私はアジャイルが嫌いだ　ウン！
アジャイルが世の中のために何かしてくれたことがあるでしょうか
いいえ　アジャイルは常に私達　ウォーターフォール実践者の足を引っぱるだけです
身勝ってで　ドキュメントを書かない
テスト駆動開発　ペアプログラミング　コンティニアスインテグレーション
イテレーション　レトロスペクティブ　バーンダウンチャート　リファクタリング
好きなものしかやりたがらない　嫌いな物にはフタをする
滝とは違うと言えばすむと思っている所がズルイ　繰り返しやってみるアジャイラーも嫌いだ。

スクスクとシステムばかり大きくなり　最初の要件からフラフラと変化しやがって
変化への対応が速く　いつも顧客価値を追求する
あの世間体を気にする　その思考がいやだ
あの計算高い　繰り返す手法がいやだ　繰り返しが不愉快だ
何がイキイキだ　何が俊敏だ　何が幸せになる　開発手法だ

そんなアジャイラーのために　私達ウォーターフォール実践者は　何もする必要はありませんよ
第一ウォーターフォール実践者がそうやったところで　ひとりでもお礼を言うアジャイラーがいますか
これだけアジャイラーがいながら　ひとりとして感謝するアジャイラーなんていないでしょう
だったらいいじゃないですか　それならそれで　けっこうだ　ありがとう　ネ
私達ウォーターフォール実践者だけで　逐次的に生きましょう　ネ

アジャイルはきらいだ　アジャイルは大嫌いだ
離せ　俺はウォーターフォール実践者だぞ
誰が何といおうと私はアジャイルが嫌いだ
私は本当にアジャイルが嫌いだ〜〜〜〜〜〜〜〜〜〜

スクラム道に参加しました。

勉強会

スクラム道とは

スクラム道では、毎回、参加者と共に一つのテーマを深く掘り下げて探究し、現場の悩みを少しでも解消する事を目的にしています。
当日は、発表者(スクラム道では読み手と呼んでいます)がその日のテーマについて 30 分ほどお話しして、それを切っ掛けに 1 時間以上みっちりと参加者と共に質疑応答やディカッションを行う形式で進めていきます。

11月1日 スクラム道.01(東京都)

という形式の勉強会です。
今回のテーマは「ふりかえり」ということで、アジャイル実践未満の私でも参加者の皆さんと共有出来ることがあるかなということで参加を申し込んでみました。*1

キーワードは「KPT is harmful」ということで気になったキーワード

  • KTPのKeep/Problem/Tryの維持/問題/挑戦は良くない日本語化で抵抗を減らす
  • 守破離の破のフェーズとしてのKPt(Tryを小さく)/KT(Pを出さない)/KP(無理にTryしない)
  • 状況を絵で表す(細かい外部からのチェックや干渉を避けられる)
  • 各人の気分の並をバイオリズム形式で表してからふりかえる
  • ふりかえりガイドを読む

最後の方に[twitter:@Ryuzee]から自分達の改善のためだけにふりかえりを行うのはどうなのかとという話がありましたが、私自身としてはチームの熟達度合いによって異なるのかなと思ってます。もちろん顧客に対する価値を高めるためにふりかえる行えるチームが理想だとは思います。
しかしコマンドコントロールの中で作業してきたチームにとって「顧客に対する価値提供」を追求するためのふりかえりは、自分たち自身が良くなることを追求することで結果として顧客へより良い価値を提供することが出来ることを実感できるまでは難易度が高いと感じます。
だからといってグラス片手に自身の利益だけを追求するふりかえりやアジャイル擬きは論外だとは思いますが、ふりかえりの結果としてチームメンバーの実感を引き出し、顧客へより良い価値を提供できる方向にしていくのがファシリテーターだったりスクラムマスターの役割なのではないでしょうか。

次回スクラム道のテーマは参加資格があるかどうかは不明ですが、参加するのが楽しみな勉強会が増えました。
喋りすぎて他の人の話す時間と機会を奪ってしまったのを反省しつつ次回を楽しみにしたいと思います。*2
最後になりましたが企画・運営してくれた [twitter:@Ryuzee] [twitter:@nawoto] [twitter:@ebacky_jp] 、そして参加者の皆さん本当に有り難うございました。





補足：最近目にしたふりかえりの資料としてこちらも非常に参考になりました。

「KPTの理論と実践」プロジェクトへの「ふりかえりカイゼン」の導入で学んだこと
View more presentations from esmsec.

*1:最近、勉強会に参加すると「あっプロの人だ！」と言われることがありますが、認定スクラムマスターではありますが実践者でもコーチでもなく導入挑戦者ですからw

*2:喋りすぎは毎度のことだと言われれば、その通りではありますが・・・

また、つまらないモノを作ってしまった・・・

Hudson

という発言を受けてなのかどうなのかは分かりませんが
Hudsonのpersona Plugin使い、今日の修造botの発言200件分を仕込んで

ビルド成功した場合


ビルド失敗した場合

を作ってみました。


よくよく考えてみると大人の事情がありまくりで*1、xml及び画像は公開は出来ませんが、xmlと画像を用意するだけで色々と簡単に作れますので皆さんも色々作ってみては如何でしょうか。

詳しい作り方は本家か Hudson Persona Plugin使ってみた - marsのメモを参照すると分かりやすいと思います。

痛Hudson化するもよし、今日の名言的なものを作っても良し。
アイディア次第で開発現場をなごませることの出来る楽しいプラグインです。

*1:そもそも、このキャプチャーが不味いという話もある