hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

みんなでアジャイル

チームの新卒氏が読んでたので一緒に読んでみた。
アジャイルのプロセス自体がアジャイルで、なんのためにアジャイルをやるのか?とか、地に足のついた理解をしないと活用できないのだな、と思った。
こうするのがアジャイル!だからやりましょう!では、なんで?となったり、そうすればアジャイルで、成功が約束されているのね、では着いていきます、ということでは、うまくいかない。
何をやりたくて、だからこういう開発プロセスをやっていて、やってみたらこういう状況になったので、こういうことのためにここを変えよう、という議論ができるようになって、ようやく採用できる手法だと思う。


最近、自分たちは、自分たちがアジャイルなのかそうでないのかって話をしがちなのだけど、そのとっかかりがなくて、話が噛み合っていなかった。
この本の後半にはテンプレートが用意されているので、ためしに埋めていって、こういう理解でやってる?という話はしてみてもよいかもしれない。
そういう認識合わせとか、チームビルディングの時間を無視して、開発フローだけ決める、ということはやっぱりできないのであろう。


「このフレームワークはただ実施すればよいというものではありません」みたいな、理解から実践までのアクションが難しいフレームワークを大きなチームに一気に導入するのは難しいので、アジャイルサムライで紹介されていることくらいをやってみよう、というのはありな気がする。
こっちのほうがまだやることが定まっていて、プロセス自体の不確実性が低くて、とりあえずやって体験してみても悪いことはなさそう。