読者です 読者をやめる 読者になる 読者になる

1.21 jigowatts

Great Scott!

アジャイルソフトウェア開発の導入について

概要

アジャイル開発やったことありますか?

simplearchitect.hatenablog.com

私はありません。

ウォーターフォールの問題点は体感してますが、アジャイルだとどうなんだろう?そもそも導入するにはどうしたらいいんだろう?ってことで、実績のある方にそこらへんの話を伺ってきました。

背景

Microsoft製品ガチガチの現場ですね。

導入

段階を踏んでの長期計画としたようです。

まず最初のステップではアジャイルプラクティスのうち朝会や継続的インテグレーションなど、いくつかを選び実践。まずはヤッてみるってことですね。導入しやすいものから選んだのかな。聞きそびれました。

ただし、現実はそう甘くはなく、やれ、契約はどうするだとか責任範囲は、品質の担保はつーことで思っていたようなメリットやパフォーマンスは出なかったらしいです。

そしてこれらの課題をふりかえりより洗い出し、一つずつ潰していったようです。改善ですね。

具体的には以下のようなことを挙げてました。

  • 準委任契約とした
  • Sprintの固定
  • プランニングポーカーによる相対見積もり
  • タスクボードの活用
  • バーンダウンチャートの活用

結果としてスクラムでの純粋なアジャイル開発に切り替えることで生産性、品質の向上、メンバーの自主性アップなどの多くのメリットを得ることができた(意訳)!ということです。

さらに顧客より求められたWBSだけでなく、バーンダウンチャートなどを併用し、顧客にアジャイル開発のメリットを実感してもらうことでシームレスに導入へとスライドしたという話になるほどなと思いました。
アジャイルやりましょうと説得するのではなく、知らず知らずのうちに啓蒙活動を行う。大変だとは思いますがうまいですね。

気になったことを質問してみた

Q.導入時にアジャイルコーチを雇うなどのアプローチは行った?
A.書籍による独学だった。

メンバーで書籍を読み込み、読書会などの勉強会を開いていたようです。なかなか導入が難しいというのであれば、プロを雇って話をしてもらうというアプローチもありかも?

Q.もともとテストコードを書く文化は根付いていた?
A.全くなかった。TDDが課題。

テストコードは後から書いているそうです。やっぱりTDDは一段ハードルが高いのかな。

Q.データベースのテストはどうしてる?
A.プロダクトにおいて重要な個所なので、テスト用データベースを使用しテストを行っている。

テスト手法の本などを読んでいると、時間のかかるテストは悪!みたいな感じで実際どうしたらいいのか悩んでいたんだけど、納得です。プロダクトによって必要であれば(設計で時間のかかるテストは最小限に留めつつ)、実際のデータベースのテストを行えばいい。

Q.最大限に効果を実感したプラクティスは?
A.プランニングポーカー。メンバーの自主性を高めつつ、さらにふりかえりを行うことで効果が絶大。

プランニングポーカーほしい!明日からやる!と思って調べてみたんですが、売ってない!売ってても海外取り寄せ2kとか。お話しを伺ったチームの方は手作りしたようです。

Q.メンバーのアジャイル開発への熱量はどうやってコントロールした?
A.やる気のないやつはドライに対応した。

クビにしたってことですね*1ブルブル


いいことだけではなく、苦労や裏話はまだまだ沢山ありそうだったのでもっと聞き出したかったのですがタイムアップ。
終わりに、ハンズオン形式とかで体験したいと訴えてみました。

今回心底感じたのは、アジャイル開発は一つのツールということ。ただ使える道具は多いほうがいい。アジャイル開発の実績がほしいです。
ただのプログラマとしてはアジャイルいいぞとか、こんな開発手法あるんだけど的なアプローチが結構精一杯ではありますが、まずは個人単位で導入しやすいプラクティスを実践してみようかな。

ひとりプランニングポーカー...(´・ω・`)

*1: ;゚Д゚