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

Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

「「チケット駆動開発とメトリクス」の感想」の感想

【公開】第10回 RxTstudy/第57回 SEA関西プロセス分科会「チケット駆動開発とメトリクス」の感想 #RxTstudy: プログラマの思索 をさささっと読んだ。簡単な感想もさささっと書く。

当勉強会の告知のタイトルを見たときには、さらっと流してしまったが、
チケット駆動開発とメトリクス」とは、非常に奥深く、意義のある取り組みだと思った。

特にこのページの考察内容がとても具体的でよく伝わる内容だから、だと思う。

チケットをきっかけにその都度で駆動するものについては、これまでいろいろ語られているが、
それらをつなぎあわせて何が描けるか、というところまで、いよいよ話は進んでいるのだ。

以下、共感なので抜粋。

【2-2】しかし、WF型開発はメトリクスを使いにくいと思っている。

テスト工程やリリース前の工程でメトリクスを採取したいと思っても、
普通は障害が多発するために、メンバーもリーダーも忙しすぎてメトリクスを収集しにくい。
また、プロジェクト完了時にメトリクスを採取して、チームにフィードバックしたとしても、
チームは解散してしまうので、そのノウハウをチームとして学習することができない。

つまり、せっかく採取したメトリクスをチームの学習やチームの成長に生かせないのだ。

本来は、障害分析や設計レビュー、課題の傾向分析などから、
そのプロジェクトの知見、そのシステムのノウハウをチームは学習して、どんどん改善すべきなのだ。

しかし、普通は、
要件定義と設計工程は元請、開発・単体テスト工程は下請けのように、
メトリクスを採取する対象のメンバーが違うために、そのメトリクスをチームの成長に使いづらい弱点がある。

日本のSIでWF型開発を標準プロセスとして持っている企業は多いし、
品質保証のためのメトリクスの知見も持っているのにも関わらず、
そのメトリクスのフィードバックが開発チームの学習に生かされていないのではないか、と思っている。

開発途中に生かされないこともそうだし、以降のプロジェクトにも生かされない。
まるで知見がその場その場で蒸発して抜けだしていっているようだ。

「開発中で改善ができないいのなら、せめて次からのプロジェクトではなんとかしよう」と、
個人的に振り返ったり、方法を考えたりしていたが、
次の開発でもまた同じことの繰り返し、、、である。本当にぜんぜん改善できていない。
だから、「「次からは」というやり方が間違っているのだよ」と、このプログは言っている。
気付いた時に手を出さなければ、手を打たねばならないのだろう。
どうもWFは何から何まで流してしまいやすいものだ。