ハンズオンテクノロジストでありアジャイルコーチでもあるDaniel Markham氏は先週、アジャイルに対して本気でイライラする人がいるのはなぜか、という問いに答えようとして記事を書いた。氏はアジャイルの要求を拒絶するような否定的なメールを定期的に受け取る。10年を超えるアジャイルの実践と産業での幅広い受容の後の今、少し立ち止まってAmr Elssamadisy氏が今年初旬にしたような問いかけをするにはちょうどいいのかもしれない。たいていの場合、成功と失敗の間にあるのは小さな一歩だ。そして、言うまでもないがたいていの場合、成功を評価することは難しい。
下記が氏が見聞きした問題だ。
- 偽の成功ストーリー
- 仕事をしない指導者
- 硬直的な追随者
- "いい気分にさせる"アジャイル
- 魔法の弾丸症候群
- チームの優位性の逆転
- カーゴ・カルトアジャイル
- 質問に対する未返答
- アドバイスの衝突
- 詐欺師
- かけ声倒れ
- 小さな金の星症候群
上記の特徴はこの産業でのアジャイルの問題の一般的なパターンを適切に反映している。また、アジャイルを現在はやりのバズワードに置き換えれば、それにも同じことが言えそうだ。 たいていの場合、こういったことが懐疑論の原因だが、氏は次のように説明する。
アジャイルには定義がありません。 基準となる委員会もありません。試験も、公式教科書も、チェックリストもありません。アジャイルはスクラムと似ていませんが、個人的にはこれは良いことだと思います。アジャイルは反復的で漸進的な開発チームの周りにあるベストプラクティス集です。[アジャイルそのものは]マーケティング用語に過ぎません。
しかし、一般的にはアジャイルチームは普通のチームと比べて幸せで高い生産性をもつという証拠はたくさんある。また、成功の要因についての議論はまだ続いている。氏の考えでは成功するアジャイルチームになるための鍵は実行すること、よく考えること、適用することに関わる。
アジャイルは科学ではなく技巧なのです。本を読んだり講義を受講すれば突然アジャイルになるわけではありません。誰かがピアノを弾いている映像を見たり、ピアノについての本を読んだり、ピアノについての会議に参加するだけではピアノが学べないのと同じです。
予想通り、この記事にはたくさんのコメントがついた。
[Techneilogy] うまくいっていること(アジャイルプログラミングのような)が悪くなる原因のひとつは中間管理職特有の"秘密の公式"です。
[Alan Franzoni] アジャイルは適用されたときにアジャイルになるはずです。ゼロから始めてすべての"アジャイルの技法"をすべて適用するのは難しいです。また、開発者側のアジャイルへの要求はマネージャの意思を超えるでしょう。しかし、その状態でうまくいくのなら、何も変える必要はないのかもしれません。
[Rui Curado] コード生成が実行できる実用的なモデル駆動開発(したがってUML/MDAは使わない)はより良い開発への一歩です。この方法は開発習慣の変更がある程度必要ですが、このような実用的な手法は単なる開発者の手の届く範囲にあります。
[Ben] 私はおもちゃのボールが好きでない人、俳句や"アジャイルな人々"が思いつく"斬新な"アイディアが嫌いな人の気持ちがよくわかります。なぜ嫌いなのかも一文で言えます。すなわち、それがソフトウエア開発に何の関係があるんだ?!、というふうに。思うに、私やたくさんの私のような人々に必要なのは"秘話"や"指導者"や"ストーリー"ではなく、技術であり明確な構造と計測であるということにアジャイルコミュニティが気がつけば、得るものがたくさんあるでしょう。
[Anonymous] 最近私の会社はスクラムへと移行しましたが、こんなお手上げ状態になったのは私のキャリアの中で2回目です。すべてのイテレーションは開発者にとってとてもうんざりするものです。2週間のサイクルで何度も何度も小さなタスクを行うのは開発者というよりコードモンキーになった気分です。[Daniel Markham氏のこの匿名のコメントへの返信] もし私があなた(またはあなたのチームのメンバ)でアジャイルのやり方が自分を強烈に苦しめているのがわかったら、毎日のスタンドアップミーティングの議題にします。それはチームのパフォーマンスの障害物だから、取り除く必要があります。
あなたがアジャイルが普及したと考えるなら、アジャイルに対する懐疑をどのように説得するだろうか。アジャイルは十分に成熟しただろうか。それともまだ真実への覚醒の途中段階だろうか。モバイルアプリケーションやクラウドコンピューティングが支配する世界にも適合するか。それとも私たちの産業は、生産性を新たに獲得するにアジャイルを超える手法を見つける必要があるのか。