チケット駆動開発から発生したチームの変化

さかばさんの記事とyusuke-kokuboさんのつぶやきを読んで思ったことをメモ。

【元ネタ】
[#TiDD] チケット駆動開発はプロジェクト成功の3C(Commitment、Communication、Collaboration)を実現する: ソフトウェアさかば

Twitter / yusuke-kokubo: 社内Redmineのチケットに「後で振り返る？:Boolean」というカスタムフィールドを追加した。

僕もRedmine導入前は、Excelで課題管理、タスク管理をやっていたし、Excelのテスト仕様書でテストして、Excelで障害管理もやっていた。
プロジェクトをどう進めればよいか、は自分では見えていたけれど、制御するのは非常に難しかった。

Redmineでチケット駆動開発を運用し始めて、色んな事に気づいた。
単にAgile開発を初めて実際に運用できただけでない。

従来からやっていた朝会や、新しく取り入れたふりかえりがスムーズになじんだ。
朝会でロードマップを見ながら説明するのが、チームにゴールを提示しているのだと気付いた。
ふりかえりで、僕が作ったワークフローに苦情が出て、むしろ開発者が議論しながらワークフローを作り出したこともあった。
ふりかえり後、私が思っていたことは他の人も同じように思っていたんですね、と感想を漏らした若手の女性もいた。
朝会やふりかえりはチーム力を強化してくれる。

定期的なリリースのサイクルが自然にイテレーションのリズムとして、開発チームの速度になった。
チケットを登録して消し込んでいく運用に開発者自身も慣れて、作業を始める前に必ずチケットをToDo代わりに起票するようになった。

開発中に不明な仕様が出たら課題を必ずチケットに登録して、課題の回答を得てソースに反映したらチケットを解決するというワークフローに開発者も慣れたが、管理者自身も今抱える課題が一覧表示できるのは良かった。
たくさん出てきた課題こそがリスクであり、それを解決しなければプロジェクトは前進しないから。

「No Ticket, No Commit!」の運用ルールに開発者自身が慣れると、そのルールに則っていない別チームの開発者に苦情を言うようになった。コミットログに変更理由やチケットNoを書かないと、何故そんな修正をしたのか、分からないので作業に支障が出る、と。
又、コミットログを後で振り返ると、やる気が出てくるみたい。

StatSVNやStatCVSでソースのLOCやコミット数を毎晩Cronで出力して公開したら、特に若手のモチベーションが上がった。
自分は半年間で1万行も書けたのか、とやる気が出てきたみたい。
公開された開発者ごとのLOCは、まさにプロジェクトへの開発者の貢献度を意味するから。

チケット駆動開発で、単に開発やプロジェクト管理の生産性が上がるだけではなく、各人の作業が見える化することによって、コミュニケーションが促進される。
そして、定期的なリズムがあるからこそ、リリース後にチーム独自の運用ルールを見直して、更に改善していこうという雰囲気が生まれる。

チケット駆動開発はチームビルディングも強化してくれるのだ。