9章から16章までふりかえり
ここに感想とか引用とか書いていくぞー!
短いスプリントの利点が、量よりもスピードってまとめられているのめっちゃわかりみがふかい。常に高速に考えることができるチームがオーバースペックだっていう意見がたまにあるんだけど、自分達がボトルネックにならない保証でもあるのかなって推測するんだけど、いまだに出会ったことがないのだよな。。。
スプリント疲れ。。。ここ数年は3連休がうまくつくられているおかげであんまり感じなくなったなー。
バーティカルスライスでのデリバリーが可能になるような計画を立てる。この計画には、開発チームの設計能力と、バックログリファインメントに対するプロダクトオーナーのアプローチが含まれる。
開発チームの設計能力とプロダクトオーナーのアプローチが含まれるっていうのわかるけど、プロダクトオーナーのテクノロジー理解力とかまで含めるくらいのほうがいいような気はする。
だいぶ内容忘れてしまった気がするので読み直したい。
やっぱりMSAだなぁとは思うようになって来たけど、結構盲信的にそれを唱えてしまっていると認識しているので、MSAのメリットデメリットとか、方法論とかについて本を読んだりしたい。
キューを使用するの基本的に賛成なんだけど、スプリットブレインとかが起きなさそうな範囲でやることが大事で、複雑になった時に誰も何がおきるのかわからないみたいなことになりがちだなーって思っている。でも、DBの次にやばいことになりがちなんだよなー。
https://scrapbox.io/files/629df0f512365a001d011684.png
わかりやすいんだけど、平均的なプロジェクトのやばさよ。。。
大規模になるだけで小規模開発と同じようにただ単にそれをスケールした大規模のままやると崩れてしまう、、、
複数段階のDoDを認める具体的な根拠は存在するが、それらを認めると「完成」が本当の意味での「完成」ではなくなってしまい、それらの定義の隙間に品質の悪さや追加の作業が溜まっていくことになる。複数レベルのDoDはなるべく避けるのが賢明である。
それな!!!
完成の定義にまつわる一般的な問題の例がよい。
DoDがエビデンスではなく活動を説明している
これはアカン。。。が、いろんなところでやられていそう。DoD以外っていうか。
少し理解するのに時間を要した、が、たしかにとなった。完了だとacceptはされてるとは限らないんだよなぁ…他にもこういったところでやられていそうっていう例は思いつかないけれど、気づかないうちに起きていそう…
毎日読み返そうかな?と思うくらいまとまっている。
めっちゃわかる。コンパクトにいいかんじ。。。
実例マッピングが強力で多用している。低いコストで理解の齟齬が起きにくい要求がぽんぽんできる
DoRは大事だよなー。ストーリーではないタスクにDoR定義するの忘れがちなチームが多いので、特に気をつけている
図13-2(p158)
皮肉的で好き。でも確かにそうだなぁと感じた
開発バックログ、プロダクトバックログと、バックログが二つが現状はできており、この章の内容が刺さる。
見積もりはアジャみつの二点見積もりを好んで使っている。それなりに数もこなしてきたが、結構正確。
enPiTでTシャツサイズやっていて、いいなぁとなった。さすがenPiT。
チームが立ち上がってから2ヵ月たったが、リードタイムは一時間に一回くらいになりつつある。ただ、CIの仕組みが弱くてバグもちらほら出ているので、今は多少リードタイムが下がってでもDODを拡張して定義を厳格にしている(もちろん明文化だけではなく、CIに取り込もうとしている)
完全自動化に当たっての障害として、金融庁や取引所、証券会社の承認といった部分はつくづく邪魔だな、と感じる。(なくてはならないステップなのかもしれないけど)あとは、投資助言業に当たるかどうかとか、法律が絡むリリースも結構厄介。。
自動テストの話をチームに持っていくのを忘れていた、持っていこう(覚え直し)
「とにかく前に進んでみよう」となりすぎた結果求められている最終状態が何なのか誰も想像できていない、というカオスな状態になってしまったチームを最近見た
最近リーダーシップについて考えることが多いのだが、アジャイルの文脈でリーダーシップについて語られている本の中で本章は結構わかりやすいし共感できる部分が多いと感じる。エラスティック・リーダーシップもよかった。
読みきれなかったのでちゃんと読みたい(このあと読みます)