なぜ 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 を設定してみます。コーディングルールにして壁に貼ったりもします。
チームでのレビューなので、レビューアとレビューイの役割は固定していません。一回のレビューセッションの中で、レビューアとレビューイが何回も入れ替わります。以前、コードを書かない立場で参加してたら、次のスプリントで実装タスクをもらったことがあります :)
- まとめ
レビューを全員集まってやると、その間の実装は止まりますし、みんな疲れるので、結構コストはかかっています。ただ、よい設計感覚を共有するとか、コード全体をみんなが理解できるようになるとか、コードのスタイルがそろってくるとか、いろいろなメリットがあります。
スキルが低いので厳格なコーディングルールを適用しようとか、ネーミングルールを統一しようとかやるより、プロジェクトの早い時期にしょっちゅうレビューをやるのが有効だと思っています。
以上、ちょっとでもご参考になれば。ツッコミ、コメントをお待ちしております。
Coderetreat ファシリテーターガイド
Coderetreat へようこそ
Coderetreat は、一日中集中して練習するイベントです。ソフトウェア開発と設計の基礎に重点を置いています。開発者を仕事を片付けなければならないというプレッシャーから開放して、集中して練習する機会を提供することで、非常にスキルの向上に有効なことが示されています。モジュール設計、オブジェクト指向設計の基本原則を練習することで、将来にわたって変更コストを小さくするコードを書くスキルを改善できます。
Coderetreatにはファシリテーターが必ず必要です。ファシリテーターの責務は、一日の概要を説明すること(私の解説ビデオを参考にしてください)、セッション中にペアをガイドすること、セッション間の振り返りと、終わりの会をリードすること。このページでは、一日の概要スケジュールと、効果的なファシリテーションのコツを説明します。ブログにも coderetreat のファシリテーションについて書いたのでご参考に。
構造
Coderetreat は、長時間テストされた確立されたフォーマットで、練習に集中するために最適化されていいます。
問題: コンウェイのライフゲーム
セッションの長さ: 45分
開催時間: 午前８時３０分から午後５時か６時まで
ペアプログラミングは必須。ペアプログラミングにおける知識の伝搬が練習には必要であるから。
テスト駆動開発(TDD)を推奨
セッションが終わる毎に、ペアは組み替える
セッションが終わる毎に、作成したソースコードを削除する。ブランチに入れたり、バックアップしたりせずに、後を濁さずきれいに削除する
一日のすごし方
coderetreat は、５ないし６セッションで構成されます。おのおののセッションでは、以前のセッションで得た知見を生かしてコードの作成を行います。午前のセッションは、問題ドメインの理解すること、既存の慣習の打破すること、自身による発見をめざすことに、集中します。午後のセッションでは、ちょっと背伸びをして、抽象化、モジュール化設計、テスト駆動開発のスキルと知識の獲得を目指しましょう。
ほとんどのグループは、ソフトウエア開発に置ける基本、モジュールか設計、シンプルなデザインの４つのルールに集中すべきです。一日を、それらのコンセプトの練習に費やしましょう。
一日のラフなスケジュール
8 - 8.45am : 到着、コーヒや朝食など
8.45 - 9am : 趣旨説明、概要説明、問題ドメインの説明
9 - 9.45am : セッション #1
9.45 - 10am : ふりかえり、休憩
10 - 10.45am : セッション #2
10.45 - 11am : ふりかえり、休憩
11 - 11.45am : セッション #3
11.45 - 12pm : ふりかえり、休憩
12 - 1.30pm : 昼食、ディスカッション
1.30 - 2.15pm : セッション #4
2.15 - 2.30pm : ふりかえり、休憩
2.30 - 3.15pm : セッション #5
3.15 - 3.30pm : ふりかえり、休憩
3.30 - 4.15pm : セッション #6
4.15 - 4.30pm : ふりかえり、休憩
4.30 - 5pm : 最後のふりかえり
セッション毎のトピックの例
経験を積んで、ペアの観察に慣れてきたらファシリテーターは、この例に限らずいろいろなこと試せるようになるでしょう。最初の数回は、以下の例をガイドとしてください。
Sessions 1
ペアは、問題ドメインの感覚をつかむ。コンウェイのライフゲームを全員が知っている訳ではないので、このセッションはまずは問題を理解するために使わせてよい。最初のセッションの後に、コードを削除するというアイデアについてディスカッションしてもよい。抵抗する人もいるだろうが、ルールであることをやさしく説明すること。
Session 2
問題を表す適切なデータ構造についてディスカッションしよう。セルを保持するのに、配列を使うのが正しいだろうか？primitive obsession のアイデアについて説明する。
Session 3
チームに、ちょっと背伸びをするよう促してもよい。ブーリアンのフラグより、ポリモルフィリズムを使った方がいいかどうかについて議論しよう。primitive obsession を避けるようさらに促すこと。抽象化についても重点を置いて探求する。
Lunch / 昼食
昼食時間は十分にとること。参加者は、自己紹介して、午前中に経験についてディスカッションできる機会とする。
Session 4, 5, 6
午後のセッションでは、チームに自ら制約を課してコードを書くことを伝える。
以下に制約の例を示す。どの制約を課すかは、個々のチームの経験による
- if 文を使わない
- ループを使わない
- メソッドを小さくする(５行以下、１行？)
- 言語のプリミティブを使わない
- 本来の意味での TDD
さいごに
最後に全員集合してふりかえりを行うのが重要です。普通の方法は、全員集合して全員に３つの質問を尋ねる方法です。グループの人数にもよりますが、時間を区切る必要があるかもしれません。20-30人もいると、結構時間がかかりますよ。
３つの質問
- 今日、何か学んだことは？
- 今日、何かびっくりしたことは？
- 明日以降、何か今までとやり方を変えることは？
どんな言語でも
coderetreatで提示し、練習するアイデアは、どんなオブジェクト指向言語でも適用可能です。つきつめると、coderetreatは、複数言語でやるべきという意見もあります。coderetreatは新しい言語を学ぶための日ではありませんが、参加者が慣れていない言語で coderetreat をやってみるのは全く問題ありません。ただ、ペアの片方が開発環境が準備しておく必要があることは、ファシリテーターは強調しておかなければなりません。４５分はとても短いので、開発環境をセットアップしているとあっという間に時間がなくなってしまいます。
