アジャイルプラクティス

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

不勉強にて、つい最近まで「プラクティス」という言葉の意味を知りませんでした。（中学生英語レベルの「練習」という意味なら当然知っていましたが）結構一般的な言葉ですよね、すみません。
前回の「初めてのアジャイル開発」と合わせて購入した本です。私の場合、実践的に取り組むまでは「初めての〜〜」よりはもう少し具体的な行動に落とし込んだ内容が必要だと感じていましたので合わせて読む事にしていたのです。諸々の理由でわかりやすい形でアジャイルに取り組める環境ではないので、小さい単位で取り組める行動が記載されているこの本は重宝しています。

構成

ひたすらプラクティスとその効果についてまとめている構成になっています。悪魔の声としてそのプラクティスに関連したアンチパターンも合わせて説明しているので、実践するメリットがわかりやすい所も特徴です。
章だては以下の通りです。各プラクティスがグルーピングされて説明されているので、自分の職場で実践できる部分から読んでも良いかと思います。

1. アジャイルについて
2. アジャイルの初心
3. アジャイルさを育む
4. ユーザが求めるものを提供する
5. アジャイルなフィードバック
6. アジャイルなコーディング
7. アジャイルなデバッグ
8. アジャイルなコラボレーション

特に心に残ったプラクティス

• 非難してもバグは直りません
• 応急処置は泥沼を招く
• 正しい事をしましょう
• 技術の変化についていきましょう
• あなた自身とチームのレベルを引き上げましょう
• なぜ？と問い続けなさい
• 優れた設計は地図です。少しずつ発展させるのです
• うまくいく最もシンプルな解法を考えなさい
• まともな設計は積極的にコードを書くプログラマから生まれます
• メンターになりましょう
• みんなに知らせましょう

基本的に行動原理なので、全て非常にシンプルです。ただし、出来ているかどうかは別問題です。
ただ、こうやって振り返って見ると、私が重点的に取り組んで行きたいことが心に残っています。繰り返すことが重要なんでしょうね、子供が物事を覚えるようにやっていくことが近道かもしれません。

開発がアジャイルであること

本文中に以下のような言葉があります。

開発がアジャイルであるという事は、協調性を重んじる環境で、フィードバックに基づいた調整を行い続ける事

ということは、IIDじゃなくともできそうな事はたくさんありそうですね。私の心に残ったプラクティスもIIDにこだわった話ではないものばかりです。私は以前「初めての〜〜」のフィードバックで以下のように書きました。

一番の障壁は自分の部署のマネージャだったりします(苦笑)。

これは明らかに良い訳ですね。IIDでなくとも、個人レベルでも始められることは沢山ありそうです。

話は少しそれますが

なかなか答えがわからないのがプロジェクトが収束するタイミングです。いつまでやれば終わりなのか、と言うのがわからないのです。
私達開発者にとって、アジャイルに開発を進めることは魅力的なのですが、お客さんと私達との間で完了の条件が正しく認識されていないと終わる事ができなくなってしまうのでは？という疑問がわきました。
そもそも開発自体がお客さんの存在なしで進む事はあり得ませんが、お客さんと我々の相互理解と共通目的をちゃんと持つ事が重要だと思います。それを実践する小手先(口先)のテクニックはないのでしょう。基本は信頼関係なのだと思います。それを築くための我々の態度としてこのようなプラクティスがあるのでは？
詳しくは「リーンソフトウェア開発」のフィードバックに譲りますが、そこでも1章取られているにもかかわらず、私は充分に理解が及びませんでした。

最後に

プラクティスは実践して結果を振り返ってみないと身につきません。今はまだ師の教えを知ったばかりの状態なので、言葉を意識しなくても実践できるレベルまで高めないと。そのためには、アジャイルの形だけに拘らないでできることからやっていく必要があります。
まずは、自分のプロジェクトでフィードバックと成長を重点においてチームの活動に取り入れていっています。ふりかえりでの効果測定が楽しみです。
一朝一夕に成るものではないので焦りは禁物ですが、サボらないようにやって行こうとおもいます。