WBS は、作業分解構造ではないのよ。
ちょっと大人数で行うプロジェクトに参加したことがある人なら、WBS (ワークブレークダウンストラクチャー) を目にしたことがあるだろう。
日本語だと作業分解構成と説明されることが多い。Work(作業) Breakdown(分解) Structure(構造) というわけだ。日本語の説明では、そういう説明が主流のようだ。
でも、WBS の Work は実は作業ではない。
WBS を定義した標準の最新版MIL-STD-881Cを見てみると、"A product-oriented family tree composed of hardware, software, services, data, and facilities." 「WBS の定義は、ハードウェア、ソフトウェア、サービス、データ、設備などからなる成果物指向の分解ツリーである。」
ここでいう Work は、成果物のことだ。Workbench (ワークベンチ)、Workshop(ワークショップ)、WIP(ワークインプログレス)で使われるのと同じ意味で、作業の対象となるモノのことだ。WBS の性質をいちばん的確に表しているのは、"Plan Outcomes, Not Actions" 「成果を計画せよ、作業を計画するな」である。
WBS を作業計画に使うと何が起こるかを検討してみよう。例題は、例によってキャンプで作るカレーライスである。
作業ベースで WBS を作成すると、一番上の項目はこんなふうになるだろう。
- カレールーを作る
- 飯盒でご飯を炊く
成果物ベースで WBS を作ると、こうなる
- 温かいカレールー
- 温かいご飯
キャンプでの作業であるから、とうぜん失敗することもある。カレールーは失敗することはあんまりないだろうが、ご飯は焦げたり、生煮えだったり、いろいろ失敗する。
失敗したとき WBS をつかって、どう挽回できるだろうか。作業ベースでつくってしまうと、「ご飯を炊くのは４０分遅れですが挽回できます」しかない。成果物ベースの場合は、サトウのごはんという挽回策がある :)
WBS を使ったプロジェクトが、おいしいカレーを食べられることを祈る。
なぜ Coderetreat に参加するのか。
プログラムを書くのを仕事としていると、締め切りとは無縁でいるわけにはいきません。
もうちょっとコードを書き換えたい、不要なコードを消したい、ちょっと設計を変えたい、いろいろなことを思ったとしても、締め切りがあるのでまずは動くコードを書いてしまいます。そのたびに、ちょっとだけコードの品質が下がっていきます。ちょっとだけ。
・これくらいのコードなら、まああとでメンテできるから大丈夫
・この設計はまだちゃんと動くか確認できていないから、まだ実システムに使うのは早い
・ここは OX を使った方がよさそうだけれど、実際に使ったことはないから、いつまでかかるかわからない。
そんなことを言い訳にしながら、実際のコードはだんだん汚くなっていきます。コードの汚さにもだんだん慣れてきて、そのうち汚さにも気付かなくなっていきます。
Coderetreat は、朝から晩まで45分のペアプロセッションを６回も繰り返します。しかも毎回ペアが変わります。ペア持っているスキルは毎回変わりますし、そもそも同じ言語を使えるかどうかもわかりません。問題は毎回コンウェイのライフゲームですから、だんだん問題に対する理解は深まっていきます。
Coderetreat は、課題を終わらせることが目標ではありません。よいコードを書き、よい設計をすることが目標です。始めてペアを組む相手と、よいコード、よい設計とは何かを話し合いながら、実装しつつ試してみましょう。ファシリテーターがちょっとお手伝いをします。コードを動くようにできないこともあれば、結果としてひどいコードになることもあります。でも、問題ありません。４５分のセッションが終わってしまったら、コードは削除されてしまいますから。
締め切りのある現場に戻ったとき、ちょっとだけ品質を下がるのを避けられる、ちょっとだけコードを良く出来る、ちょっとだけ速くできるようになる。そうなれば、仕事のコードもちょっとだけ良くなっていくでしょう。あ、ペアプロもきっと、ちょっと上手になっていますね。
あ、Coderetreat には必ずおいしい昼食がついています。そちらもお楽しみに。
2012/12/8 は、Global Day of Coderetreat が開催されます。いまのところ150を超える場所で開催される予定です。
View GDCR2012 in a larger map
Deep Agile People で考えていたこと
一週間ちょい経過したので、Agile Japan 2012 で参加させていただいた Deep Agile People について、何を考えて話していたかを、ちょっとメモを残しておこうと思います。
細谷さん、森崎さんに、企画からコメントからいろいろと助けて頂きました。あれがなかったら、単なる酔っ払いトークだった気がするので、大変ありがたかったです。DevLove HangerFlight のときのビデオを提供頂いた富田さん、あのオープニングを編集頂いた(あ)さん、ありがとうございました。
あの場に参加頂いた皆さんに感謝します。ぜひ今度は本当にビール入りでやりましょう。
- 方法論者ではなく実践者でありたい
Scrum や XP などの方法を、枠組みとして定義する人々はものすごい苦労をしてまとめています。いろいろな状況に対応できるように、改善や推敲を重ね、ようやくできるようなひとかたまりのやり方のかたまりになります。すばらしいと思います。
ただ、その方法論を実際に使おうとする場合は、方法論者のまねをしてもうまくいきません。
自身で気をつけているのは、自分でその方法論の弱点を説明できない、もっと単刀直入に言ってしまえば、自分でその方法論を dis れないうちは、その方法論は使わない、ということです。もちろん、その弱点は方法論を適用する状況、現場によりますから、その弱点を現場と切り離して議論することはやりません。簡単に空中戦になっちゃいますからね。
方法論やプロセスをあらたに導入しようとする場合は、もしそれがなかったら何が起こるか？どうやったらこの方法論の利益を破壊できるか？を考えるとよいと思っています。もちろん個々のプラクティスでも。
- 書いていないことには意味がある
Scrum や XP みたいな方法やフレームワークもそうですし、DDD の方法自体や、それで書かれたドメインモデルにもいえることなのですが、そこに書いていないことは、重要な意味があります。
Scrum には技術プラクティスは書いてありませんが、技術を軽視しているわけではありません。Scrum の場合は、元々 SmallTalk の技術方法論が含まれていたのですが、あるとき技術プラクティスは除去するという判断がなされて、今の形になっています。XP にも、もっとマネジメントのプラクティスが含まれていたはずです。ドメインモデルには、ドメインモデルをつかってなにかをよりよくしたいと考えているモデラーの視点は含まれることはありません。
そこに書いていないことは、作成者が利用者を信頼して、自分で考えて欲しいということを願った場所です。その成果をよりよく使ってもらうために。批判があっても、あえて除いたところ。そこで自分で考えることを外してしまったら、どんな方法論もモデルもうまく使えないでしょう。
利用者を信頼せず、考えてもらいもしなかった方法論がどうなったか、ここで批判するのはやめておきます。
どうもありがとうございました。何かの役立てていただけたら良いのですが。コメント、ご意見、ご批判はいつでもどうぞ。お待ちしております。
さて、続きはいつやろう？＞川端さん、牛尾さん
Jenkins 蛙本
Jenkins 蛙本の献本をいただきました。ありがとうございます。
チケット管理システム大決戦でご一緒した、@ikeike443 さんのご厚意です。
ちょうど第二回大阪Jenkins勉強会で、翻訳者の玉川さんとご一緒だったので、非常にタイムリーでした。
チーム用にも予約していたので、まもなくそちらも届くかな。
他の書評にある通り初心者向けの本ではありません。インストールや設定手順も説明はあるのですが、第5章のビルドジョブのセットアップあたりから、いきなり実践編に突入します。著者も翻訳者も、だいぶ Jenkins を使い込んでいそうです。
自分では第10章の高度なビルドと第11章の分散ビルドが参考になりました。パラメータ化ビルドやマルチ構成ビルドジョブは、現在一緒に仕事をしているチームがいつも苦しんでいる課題を解決するのに役立ちそうです。
第12章の自動化デプロイメントと継続的デリバリの章も短いですが適切にまとまっています。第12章を読んでから第10章、第11章に戻れば、なぜそのような高度なビルドを行おうとしているかが理解できるのではと思います。さらに知りたくなったら来月発売の継続的デリバリーを読むと良いですね。
お約束ですが、ツールがチームの生産性を高めるわけではありません。チームの継続的な改善努力があって、その上でツールを使うことが非常に強力な助っ人になるということです。チーム開発では、チームが単一の作業成果物に対して協力して作業を行うことが重要です。それを思い出させ、そうなっていることを確認するために Jenkins はとても有効ですし、その Jenkins を使いこなすのにこの本はとても有用です。
付録Bのプラグインの開発は、@ikeike443 さんが書かれているのですが、Jenkins が動く仕組みがうかがい知れて楽しいです。Trac はほぼプラグインなしで使っていますが、Jenkins はいろいろプラグインを使って使うことになるかなと思います。
P.S. XFD などでチームに「見えなくできない化」を進めている身としては、Remote Access API の使用例などがもうちょっとあると嬉しかったかな。
Arduino で Jenkins の XFD を作る
というお題で、第二回大阪Jenkins勉強会でデモをしてきました。
Arduino jenkins
View more presentations from Kiro Harada.
Jenkins がせっせとビルドしてエラーを報告してくれるのは助かるのですけれど、やっぱり忙しくなると見に行かなくなってしまうのですよね。パトランプなどの実体のあるデバイスを置いておくのは、やっぱり有効です。
タスクボードやバーンダウンチャートは、まずは紙！という感覚とも近いのかもしれません。
Arduino のデジタル８番ピンを、リレーの制御に使っています。
今回利用したArudino やリレーなどは、Strawberry Linux で入手できます。
はじめての場合は、Arduino はじめようキットなどのブレットボードとセットになったものが良いかと思います。
まずは、LED の点滅などで Jenkins の状態を確認できることができてから、リレーを接続して、いろいろなデバイスをつないでみると良いでしょう。AC100V を使うときや、大電流が流れるランプなどを制御するときは、感電に注意して、必ずヒューズやポリスイッチを使ってください。
面白い XFD ができたら、ぜひシェアしてください。
Enjoy Making.
P.S.
Aruduino で、こんなのも作れます。楽しいですよ。
デイリースクラムで ScrumMaster がやるべきこと
デイリースクラムのやり方は、いろいろなところに書いてあるし、チームによっていろいろ工夫をしていると思うので、ここでは書かない。
Scrum Guide にも書いていないけれど、ScrumMaster が絶対にやるべき重要なことがある。
メンバーの顔色を確認することだ。メンバーの体調を計測することだ。それだけでも、ScrumMaster がフルタイムの役割である十分な理由がある。
メンバーの体調は、常に気を配っていないと気付くことはできない。デイリースクラムの３つの質問に気を遣うと同時に、ScrumMaster はメンバーの体調についても十分注意を払う必要がある。
どうも風邪薬や栄養剤のCMのおかげで、体調が悪くても会社にいくべき、のような風潮がある。でも、この時期、インフルエンザのメンバーを一日出社させてしまったら、そのスプリントは終わりだ。チームが全滅するだろうし、他のチームにも迷惑をかける。
熱っぽくて、咳き込んでいるようなメンバーが出たら、まず帰らせて休ませよう。
ある建築会社の PM の方から、「メンバーにけが人を出したらPM失格」と言われたことがある。ScrumMaster は PM ではないけれど、この部分の責務は一緒だ。
もちろん、自身の体調管理にも気をつけて。
Scrum ではコードレビューをどうやっているか？
森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。
レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。
- レビューのやり方
基本はチーム全員で集まってやります。最大２時間。それ以上やっても集中力が続かないので。プロジェクタで対象のコードを映しながらやります。PO も来てもらうといいですね。
対象のソースコードは、とくに実装上に不安があるところをチームメンバーの自己申告で。場合によっては、メトリクスを取得して McCabe 循環複雑度が大きいところをやったりします。
＃はじめにテストを実行して赤くならないこと確認してから始めます。
レビューは、コードを書く元になった PBI を確認してから、読み手がそのコードを説明します。とくにどういう意図でそのようなコードになったのかを説明してもらいます。
メンバーは説明を聞きながらコードを追ってコメントします。重要なのはコードから、説明された意図が読み取れるかですね。説明を聞きながらスムースにコードを追えるかどうか。コードをうまく追えないときは、なんか変なことになっていますね。あと、障害とか改善が必要であるというコメント以外に、うまく書けている、このあたりの実装が格好いいとか、ポジティブなコメントもします。
ディスカッションの上、バグであるとか、改善の必要があることがわかったら、ソースコードにコメントとして書き込みます。
バグの場合
// FIXME: CR日付 コメント
改善が必要な場合
// TODO: CR日付 コメント
レビューが終了したら、テストを実行してコードを壊してないことを確認してから、リポジトリにコミットしておきます。書きませんでしたが、次回レビューをやるときには、前回のレビューコメントがどうなっているかを確認します。
- レビューで気をつけていること
森崎先生の講演でも強調されていましたけれど、レビューは書いた人を責めるためではなく、障害を後工程に残さないこと、そして設計を改善するためにやります。だから、コメントがあくまでもコードに対するもので、人に対してでないことは十分注意する必要があります。ScrumMaster の出番。
ちょっとやっていて面白いと思われるプラクティスは、初めてのバグ、障害を出した人はほめられる、というところですね。「うわ、このバグ超絶技巧！」とかね。テストで検出するのが難しいバグが早めに見つかるのは、後の仕事が楽になる良い兆候ですから。超絶バグが出てきたら、同様のバグがないか、PBI 単位でのレビューが終わってから確認します。
以前のレビューで指摘されたのと同じバグを出すと、「ダサい」という評価が待っています。３回目だと、朝会の遅刻と同じくらいのペナルティですね。おやつ基金か飲み会基金に罰金なことが多いです。３回目という評価をもらうと、だいたい次のふりかえりで、４回目をやらないような Try を設定してみます。コーディングルールにして壁に貼ったりもします。
チームでのレビューなので、レビューアとレビューイの役割は固定していません。一回のレビューセッションの中で、レビューアとレビューイが何回も入れ替わります。以前、コードを書かない立場で参加してたら、次のスプリントで実装タスクをもらったことがあります :)
- まとめ
レビューを全員集まってやると、その間の実装は止まりますし、みんな疲れるので、結構コストはかかっています。ただ、よい設計感覚を共有するとか、コード全体をみんなが理解できるようになるとか、コードのスタイルがそろってくるとか、いろいろなメリットがあります。
スキルが低いので厳格なコーディングルールを適用しようとか、ネーミングルールを統一しようとかやるより、プロジェクトの早い時期にしょっちゅうレビューをやるのが有効だと思っています。
以上、ちょっとでもご参考になれば。ツッコミ、コメントをお待ちしております。
