日頃、スクラム開発は単なるバズワードであって手法ばかりに注目が行って有体に言ってコンサルの飯のタネとしか思ってない。 重要なのは不確定要素を可能な限り取り除いたうえで振り返りという形でイテレーションの終わりに自分たちが組織としてどのようにふるまえたかを客観的に評価する健康診断という強制的なイベントを実施して、代謝が機能するような体制づくりのことだと思う。
それゆえ、イテレーションを1か月とか長い期間とってしまうと不確定要素の相対量が増え、振り返りも難しくなるので1~2週間が望ましいと個人的には思っていて、たぶんそれが世のなかの一部エンジニアの皮をかぶった謎の存在も含めた現実を直視することが苦手なソフトウェア開発の苦労や困難の実情を知らない人間たちにとっては「開発スピードがあがるんだ！！！」みたいな的外れな幻想を抱かせてしまうのだろうと思っている。
で、そんなことを常に考えていてむしゃくしゃすることがないことはないんだけど medium.com の記事を読んで前半の Sprint に対する筆者の洞察は私と全く同じで、首肯のしすぎで頸椎が疲労骨折した。
ただし、後半の XGH なるものは極端すぎてほとんど賛同できなかった。というより、ものすごい優秀なエンジニアでないと成立しないという感想を持った。
どのようなものかは原文を参照してもらうこととして、以下が直感的な理由。
- 優先順位とかなくて必要な時に必要な価値が届けられればよい
- PO に当たるような役割はなく、要求はエンジニアが完璧に理解している前提
- 問題が発生したら局所的な対応か、作り直しをする
- テストは書かない
- それゆえリファクタリングが存在しない
- 他人の書いたコードに介入しない
一方、共感できる部分が特にない。
要はこの記事、差分を各担当者の責務としてメンテしろという話であってチーム運用の話ではないとしか思えないし、品質の話を一切してないんだけど皮肉として述べてるんだろうか。一筆書きで過不足なく動くときは動くものを作る(開発スピードについては言及なし)ということを目指しているよう思える。
チームメンバーにこの記事の感想を出してもらうことで価値観のすり合わせはできるかもしれないとは思ったけど、今のところ私には XGH は無理という結論が出ている。
