アジャイル開発のバッドパターン

podchastを聴いていたら、アジャイルでもなんでもバッドパターンはあまり書かれないみたいな話があったので、俺が遭遇したバッドパターンを書いておく。

speakerdeck.com
podcastでこの人の話聞くとホントどうかしているわこの人って思う(褒めてる)。


ちなみにそのとき俺がやっていたのは、データレイク基盤実装のプロジェクトで、連携元との結合部のフレームワークを作っていた。

毎日チーム朝会をやっていたので、スクラム型になるのかな？ そのときに俺が思っていたことをメモしておく。

チーム間での認識齟齬と技術不足で足並みがそろわない

根本的な原因はとにかくここ。

とにかくチーム間、チーム内の連携が取れておらず、 +チーム間で個別で話し合ったことが共有されない +チーム間で話し合った内容と結果が違う、それに気づけない +チーム間の細かい状況がブラックボックス
実装だけの話ではなく、そもそもこのプロジェクト自体の根本的な問題もここのような気がする。

チーム間で個別で話し合ったことが共有されない

当人同士の秘密になってしまうやつ。
チーム間で個別で話した内容が共有されず、話した当人の個人チャットや会話で完結してしまうのでなぜそうなったのか当人しかわからない。

当人しかわからないことが正だと周りは認識して作業を進めていくので、ずれが大きくなる。

実際あったのは中のpropaty設定の実装が異なるときに、「個別でチャットしたときに認識合わせたんですけど、向こう忘れてしまったのかな」みたいな。

それってチャットの中で完結してよかったの？
相手方チームと自分が他チームと共有しなくてよかったの？


短いスパンで小さく作っていくというアジャイルの特性上、スピード感もって作業するというのは正しい動きだと思っている。

ただ自分の作業タイミングと相手の作業タイミングは必ずしも一致しない。

なので相手が振り返られるようにしてあげるというのは意識してやらないと、認識のずれがおきてしまうんじゃないかなあと。


俺は手間だけど必ずみんなの目につくところに書くようにしていて、ウォーターフォール型でも開発手法関係なく認識はあわないし、認識あっていてもダメ押しておいたほうが幸せになれるという今までの経験から。
口頭で話して実際に文字や絵で伝えると、実は認識ずれているパターンもあるので。

チーム間で話し合った内容と結果が違う、それに気づけない

技術的な都合による修正が勝手に行われているやつ。

この時も当然最初にこういうルールにしましょうね、なミーティングをやっていたんだけど、いざ実装し始めると技術的に難しいという面がある。

そのときに勝手にやってしまうということが大きく実装内容が乖離するきっかけになったと思う。

具体例としては、既存のOSSを使って今回のプロジェクトのフレームワークを作ろうとしていたんだけど、OSS側の理解度からOSS全く使用しないチームがではじめてきて同じフレームワークなのに全く違うものが完成してしまった。

めちゃめちゃ素振りして理解した人に質問したらよかったのに、しなかったばっかりに発生した事象。

逆にめちゃくちゃ素振りしていた人も知ってますアピールをしてなかったので、確認できなかったというのもある。

チーム間の細かい状況がブラックボックス

なんかよくわからないけどなにかやってるやつ。

同じフレームワーク作ろうねって言っているのに、始まるとチームごとの独自文化が形成されてしまっているパターン。

互いに知っているのは各チームごとの大きいスケジュールで、実装のものすごい詳細な観点までは見れていない。

独自文化が形成されるのは、なんというか仕方のないことではあると思っている。経験上、独自文化形成しちゃうし。
それをどう回避するって横断的に立つようにすることを心掛けるしかない。

俺はプロジェクトで他チーム間横断していることが多いので、経験上あれ？って思うことも多いんだけど、まあそういうもんかで握りつぶすところもあって後々あれって思ったところで揉めるパターンが多いような気がする。

互いに気軽にどんな感じなのかちらっとソース眺めたり、雑談で話しやすい関係性であったり、そういう小さいレベルで防げるやつなのかもしれない。

修正タイミングが結合テスト中でデグレ障害が頻発

この話の一番やばいところ。修正タイミングがすごい悪かった。

そもそも発見が結合テストがスタートする前の作業的には谷から山に差し掛かろうかというところ。
設計見直しから入らざるを得ないものの、もう日程的に修正するタイミングがほぼない。
だがやるしかない、な逃げられない状態で修正したからかテストユニットを回してなかったとかで、結合テストで開発起因のバグが出て地獄。

また設計見直しでリファクタリングもってなったけど、ここ修正する意味ある？みたいなのもあった。
リファクタリングでこれ実装難易度が高いし期間的に難しくない？てかそもそもそれやって誰が幸せになるんだろう。みたいなやつ。


技術的負債はなくならないのでどこかでつぶさなきゃいけないけど、タイミングと粒度を見誤ると技術的負債から生まれた新しい負債につぶされる。

早めに負債に気付けることが重要だけど、突然の死！を迎えるまで気づかないのも事実だよなあと。
上記の細かい気付きをやっていけば防げていたのかもしれない。

俺が感じたこと

俺が思ったのは実際、開発手法がどうこうってあまり関係ないんだよなあってこと。

絵なり文字なりで事前に認識をしっかり合わせて足並みそろえたり、状況はしっかり共有したり、雑談で進捗どうですかな話をしとくとか、ごくごく当たり前のことで詰まっていた気がする。