AgileTourOsaka2010に参加してきました。
まとめは他の理解の高い方々にお任せして、今日知ったこと・思ったことを書きます。
【知ったこと】
- 欧米と日本で同じ方法でAgile開発を実現できない。
派遣法など法律による縛りや、粘り強く極める、器用であることなど民族性の違いから、欧米で成功した事 例をそのまま適用すること自体が難しいパターンや、適用自体が難しいパターンがある。だから、欧米で成功した方法をそのまま日本に適用しても成功するとは限らない。育った環境が違うから...
- 自分たちで方法を探し、創りださなければならない。
自分たちの会社や現場の環境によっても、制約がある。上司・ユーザの合意のとれる部分/とれない部分、適用しやすい/しにくいプラクティスがある。結局は自分たちに合うようにXPなりScrumなりに手を加える必要がある。借り物ではダメってこと。
- 段階を踏んで適用していく
いきなり「Agile開発！」とするのではなく、BTSで不具合とチケットを一元管理することから始めたり、テスト駆動から適用したり、など。いきなり導入は開発者も管理者も拒否反応・不適合を招く。そもそも欧米諸国もウォーターフォールからイテレーティブ、アジャイルと段階踏んできたんだし。薬も少しずつ飲まないと一気に飲んだら毒になる。
【自分の現場に対して思ったこと】
まだアジャイル開発のフィールドに立つのは難しい。今の現場ではアジャイル開発を適用するのは難しいと思う（課題がたくさんある）。
- 割り込み作業が多過ぎ、スプリントの間に開発に集中させることができない。
- テスト駆動開発の価値を理解してもらえない。（目の前の工数が増大するため）
- 簡単な自動化よりも「苦労する」ことが大事であると勘違いしているところがある。
- 新しいものを採用してみることに拒否反応が見られる。
- 「顧客への価値」って何？を再度考える必要あり。設計書も大事、でもユーザが欲しいのは動くもの。
など。
愚痴になってしまうので、ひとつだけ書こ。まずこれだけ始めませんか？と言いたい。
※ここからはAgileTourOsaka2010は関係ないです。私個人の思うところ。
テストコード、自動テストの価値
既存のレガシーコードから独立した新しい機能作るときは、テストコード作成しよう...
テストコード作るには工数がかかるかもしれないけど、いろんな効果がある。
- 開発者にコードの理解を促す(製造時の勘違いバグ、考慮漏れによる後工程で発見されるバグを軽減)
- リファクタリング時の保険になる(Code and Prayでなくなる)
- テスト実行は人を介さないため、結果は正確(疲れて不正確になったりしない)
- リグレッションを防ぐ(Code and Prayでなくなる)
- 自動ビルドの価値が高まる(CIが機能し始める)
本当はリファクタリングの重要性も理解して欲しいんだけど、そこまで贅沢言わない。
結局、Agileがどうとかより、テストコードにだけこだわってる気がするけど、説得してこれ適用できるいい方法ないかなぁ...
