|
巷で流行りのアジャイル。取り入れてみたいけれども不安がいっぱい、取り入れてはみたもののうまく行かない、そんなことを考えてはいませんか？
正しいアジャイルって何でしょう。ここでは、みなさんのそんな質問にお応えします。
アジャイル勘違い集(2014年版)
|
|
|
|
| Q. |
アジャイルって、やる気さえあれば誰でもできるんですよね！
|
| A. |
やる気さえあればできるというのは、ある意味では正しいのですが、盲目にそう信じてしまうと痛い目を見ることになるでしょう。
アジャイルな手法は、変化に対応したり、コミュニケーションをとったり、改善を模索したりという行動を要求します。
そうした行動が苦手な人や嫌いな人は、アジャイル手法が苦痛になってしまうかもしれません。
さらにそういう人はアジャイル手法に対して意識的・無意識的に抵抗して、チーム全体の足を引っ張ることさえあります。
アジャイルに向いた人もいれば、重厚な方法論に向いた人もいます。向き不向きを考えてメンバーを集めるか、
メンバーが固定しているプロジェクトではそのメンバーに向いたやり方を考えたりしましょう。それがプロジェクト成功の早道です。
|
|
| ▲ページTOPへ |
| Q. |
アジャイルって、デキる人・優秀な人・ベテランにしかできないんじゃないの？
|
| A. |
デキる人ならアジャイルができるとは限りません。Q1.にあるように、技術スキルではなく行動の仕方で、アジャイルに向く向かないが変わります。
私見ですが、「あの人にプログラム任せると完璧なんだよね」とか「Webサービスのことならなんでも知ってるよ」と言われるような、
技術力の高い熟練者には、アジャイルに向かない人が多いようです。作業範囲を個人で厳密に区切ったり、手順をキチッと決めて作業したり、
自分の作業を邪魔されるのを嫌ったりするためではないかと思います。
また、技術的には未熟でもアジャイルのやり方になじめれば、プロジェクトの中で飛躍的に成長するチャンスがあります。
アジャイルなプロジェクトでは、いろいろな作業を担当したり、人の技から学んだり、間違いを指摘されたりするチャンスが豊富にあります。
決められた作業だけをやるよりもはるかに早く成長して、プロジェクトの戦力となれる可能性が大きいのです。
|
|
| ▲ページTOPへ |
| Q. |
アジャイルプロセスはドキュメントを書かないと聞きました。そんなプロセスは不安で採用できませんよ。
|
| A. |
「アジャイルプロセスはドキュメントを書かない」と最初に言ったのは誰なのでしょうか。正直、迷惑してます。
もちろんアジャイルプロセスでもドキュメントは書きます。ただ優先順位が異なるだけです。
『アジャイルソフトウェア開発宣言』にもあるように「完全なドキュメントよりも、動くソフトウェア」を相対的に重視するだけです。
最小限の文書化で最大限の効果を狙う、必要にして十分なドキュメント。そうしたドキュメントは一朝一夕に書けるものではありません。
むしろアジャイルプロセスのほうが、ドキュメント作成の難易度は高いともいえます。
「コードがドキュメントだ」とうそぶくことは簡単ですが、「ドキュメントであるかのようなコード」「ドキュメントが不要なコード」を書くのはとても難しいです。
また、コードだけでは「なぜこの設計にしたのか」「なぜ他の設計にしなかったのか」という設計判断の根拠が残せません。
アジャイルプロセスはコードを重視するプロセスではあっても、偏重するプロセスではありません。
コードとドキュメントの間でバランスを取ってこそのアジャイルプロセスなのです。
|
|
| ▲ページTOPへ |
| Q. |
メンバー間でコミュニケーションがうまく行われていないように感じています。これではいけないと思い、メンバーを呑み会に誘うようにしています。
毎回ほとんど全員が参加してくれて、その場は楽しく過ごすのですが、次の朝になるとまた以前と変わらない雰囲気です。なにか、アドバイスをください。
|
| A. |
日本には昔から「呑みにけーしょん」という言葉があるように、コミュニケーションの改善の場を、
呑み会のようなインフォーマルな場(職場外、就業時間外)に設けることがよく行われていました。
しかし、コミュニケーションの基本は「信頼」です。呑み会の場で、自己開示を行ったり、相手に関心を示したりするのも大事ですが、
まずはフォーマルな場での解決を考えるべきでしょう。
また、状況を改善するためには、相手を変えるのではなく自分が変わるという意識が重要です。
普段から、「約束は守る」「人の話を最後まで聞く」「大事なことは即座に報告する」などを心がけるようにしましょう。
|
|
| ▲ページTOPへ |
| Q. |
XPの「シンプル」を実践し、表記法などを使った設計に時間をかけずにプログラミングに注力しました。
すると、ソフトウェアの複雑さが増大し、手がつけられなくなりました。どうしたらいいですか？
|
| A. |
「シンプル」は過剰なアーキテクチャ重視を批判していますが、「設計をまったく行わない」のではありません。
「UMLを使ったモデリングだけが設計だ」と狭義に考えずに、TDDとリファクタリングを使った「設計」を採用して、
ソフトウェアの複雑さに対応してはいかかでしょうか。
TDDとリファクタリングは、モデル→コードといった演繹中心に良いソフトウェア構造を振舞いを導きだす代わりに、
試行錯誤によって段階的に導き出すアプローチを提案しています。
プログラミング前に、UMLやその他の手法を用いたモデリングセッションを設けてはいかがでしょうか。
ただし、1週間以上一人でモデリングツールをちょこちょこ触っているようなことは避けてください。
顧客価値をもたらさない自己満足を満たすためや知的権力を誇示するためにパターンを採用していないか注意してください。
まずは、半日ぐらいの時間でホワイトボードや付箋といった道具を使ったグループディスカッションがお勧めです。
|
|
| ▲ページTOPへ |
| Q. |
アジャイルで開発していますが、うまくいきません。どうすればうまく行くのでしょうか？
|
| A. |
あなたが用いているのはアジャイルではなく、アジャイルプロセスではありませんか？
アジャイルプロセスとは、XPやスクラムに代表される「アジャイルな開発を実践するために、重要なプラクティスを定義し、まとめたもの」です。
このアジャイルプロセスを忠実に実践しているだけでは、ソフトウエア開発はうまく行きません。
優れたプラクティスを忠実に実践すれば効果を生むこともありますが、その価値と原則を知らなければ、本来の力を発揮することはできません。
アジャイルとは、ソフトウエア開発に対する、心の持ちようや、取り組む態度をあらわした言葉です。
アジャイルプロセスによる開発を成功させるためには、アジャイル提唱者達が宣言した4つの価値とそこから導き出された12の原則を常に心に留め置く必要があります。
|
|
| ▲ページTOPへ |
| Q. |
プラクティスを実践すればアジャイル開発をやっていると言えるんですよね？今日も上司にアジャイルのプラクティスの重要性を訴えてきましたよ！！
|
| A. |
確かに、プラクティスは具体的な実践項目であり、導入のスタートラインになるでしょう。しかしプラクティスを実践することがゴールではありません。
プラクティスは必ず「原則」に基づいて実施されます。原則は「価値」を、妥当であるかどうかの判断基準としています。
まずプラクティスから始めてください。そして次に、あなたの環境に合わせてプラクティスをカスタマイズしてください。
その時に、「原則」に則っているか、「価値」に合っているのかを考えてみてください。
もっと簡単に言えば「なぜ、そのプラクティスを実践するのか」を深く考えてみてください。
プラクティスについて深く考え、その背景にある「原則」「価値」そして「理由」が見えた時、あなたはプラクティスの真の価値に気付いたことになります。
|
|
| ▲ページTOPへ |
| Q. |
いつでも仕様変更できると思って、アジャイル開発を始めました。なのに、仕様変更がある度に激務になります。
仕様変更に機敏に対応できることがアジャイル開発ではなかったですか？
|
| A. |
アジャイル開発だからといって、むやみに仕様の変更を受け入れてはいないでしょうか？そもそも、それは本当に仕様"変更"ですか？
ユーザにも理解してもらい、必要な機能のみを組み込みましょう。変更反映のタイミングも重要です。
各イテレーションでリリースした製品をユーザに評価してもらい、その結果を次のイテレーションで反映するようにしましょう。
また、テストは正しく行えていますか。テストは仕様を現します。テストファーストであれば、仕様変更と思われがちな"仕様の誤認"を防ぐことができます。
すべての機能に対するテストが記述されていれば、安全なリファクタリングも可能になります。
ソースコードをシンプルで美しくすることで、コードの可読性が高まり、仕様変更を受け入れやすくなるでしょう。
|
|
| ▲ページTOPへ |
| Q. |
アジャイル開発を行えば品質が高まるなら、テスターは必要ないのではないですか？
|
| A. |
結論から言うと品質保証のためのテスト行程、およびテスターは必要です。
アジャイル開発、特にテストを重視するプロセスを実施する場合には、テストがみっちりと行われるためテスターは必要ないのではないかと言う方がいます。
しかし、品質保証のためのテストと開発促進のためのテストは異なります。
非機能用件に関してはお客さまは素人です。そしてプログラマもまた、非機能用件に関しては不十分な知識しか持っていないこともあります。
たとえプログラマーがテスターを兼任することになっても、品質保証の視点からのテストを行う必要があるでしょう。
アジャイル開発が対象にしているテストは開発促進のためのテストであって、品質保証のためのテストではありません。
|
|
| ▲ページTOPへ |
| Q. |
リファクタリングしたら、いままで動いていたものが壊れてしまいました。
やはり、「動いているものには触るな」のアドバイスに従ったほうがいいと思うのですが。
|
| A. |
壊れてしまうようでは「リファクタリング」とは呼べません。テストファーストやTDDと組み合わせて、
動作を確認をしながら安全にリファクタリングを行いましょう。また、リファクタリングツールを使って、作業を機械に任せましょう。
もし誤っても、バージョン管理ツールで動いている状態に戻せるようにします。ペアプロやコードレビューと組み合わせて、安全にリファクタリングを行いましょう。
|
|
| ▲ページTOPへ |
| Q. |
ペアプログラミングでナビゲータになると、手持ち無沙汰で眠くなります。なにか良い方法はありませんか？
|
| A. |
ペアプログラミングは、ドライバーとナビゲータの双方が知力を合わせてプログラミングを行います。
ナビゲータは、ドライバーといっしょにプログラムを考えてください。そして、たくさんアイデアを出してください。
分かりにくいコードをドライバーが書いたときは、すぐに説明を求めましょう。
そうすれば手持ち無沙汰にならずに、とてもエキサイティングな時間をすごせると思いますよ。
そういえば、ペアプロがらみでこんな勘違いな話を聞いたのを思い出しました。
ナビゲータがプログラムを考え、ドライバーは打ち込むだけ。ドライバーをしている間は、プログラムを考えてはいけない。
どうやら、ラリーのドライバーとナビゲータのメタファを使っているようです。
ドライバーは、どこに向かうかはナビゲータの指示に絶対服従しなくてはならないと思っていたようです。ちょっと、玄人レベルの勘違いですかね。
|
|
| ▲ページTOPへ |
