第10章 より効果的なアジャイル : 大規模なプロジェクト
クモが象ぐらい〜必然的に象に近い外観に(後略)(p123)
この例えから始まる導入すき、「たしかに」という感情と、「アジャイルで同じことやったらどうなるんだろう」というワクワクが止まらない
わかるw
アジャイルプラクティス──特にスクラムのおかげで小規模なプロジェクトの成功率がよくなっているために、依然として悪戦苦闘している大規模なプロジェクトに焦点が移ったというわけである。
依然として残る課題っていうことだよね。。。
アジャイルを大規模なプロジェクトにうまく適用できてない(?)理由は、クモはクモのままでは象にはなれないし、象は象のままではクモのようなことはできないという例えをしたら少し分かった気になった
OODA(P125中部)
忘れてたので初出ページを書いておく→p25(第3章)
大規模なプロジェクは少なくとも小規模なプロジェクトと同じくらい継続的なテストの恩恵を受けるが、
typoを発見した!
ほんとだ!w見逃して普通に読んでた
図(p126上部)
これをみるかぎり、人が増えても、事前に行われる作業がジャストインタイムで行われる作業の重要度を上回ることはなさそう。アジャイルの経験主義感を感じた
ブルックスは「作業を完全に分割できるのであれば、ブルックスの法則は必ずしも当てはまらない」と述べている。
当たり前だけど、自分は人月の神話のこの部分からの影響が強い気がする。作業が疎結合になっているのであればうまくいくし、ワークフローでつながっているのであればそれは明確にプロトコル化しないとうまくいかないし、しても大変であることには変わりないっていう。疎結合にできないのはビジネスのせいで、ビジネスを変えられないなら甘んじて受け入れるか、そのビジネスから離れるかだって。いう。
何1つも変更せずにプロジェクトをうまくスケーリングしようというのは虫がよすぎる。
そりゃそうって感じ。だけどそう言ってばかりで変化させるのを試みない人がいそうなのはたしかに予想できる。ふと思ったけど、アジャイルの「変化」って「アジャイル自身」にも適用されるのだろうか。されてそうという感覚。
この辺はScrumはScrum Guideを変更しているからそうしているって言っているかなーくらいの気持ち。全体としてアジャイルコミュニティが変化できている印象はあまりない。
創発的な設計に重点を置くことについても、それぞれの小さなチームがきちんと分割された領域の中で作業を行うのであれば、その領域内ではそのままにしておくことができる。(p130上部)
たしかに…!大事なのは/必要なのは適切な分割だったのかな。この辺思い返してみると、PBIって分割だなあとおもったので、それがもう少し大きな単位になっているだけ…?
キューを使用するところ今日ちょうどTwitterでEIPについて話していたな。。。
文書化(p131上部)
包括的なドキュメントってことになるのだろうか。すると、大規模開発になると、アジャイルの4つの価値はそれぞれの前者の方の比重を上げるってことだったりしない…?顧客との契約交渉の点で違うなあと感じたからこの予想は違ってそう
検査
■コンウェイの法則の観点から、現在のアーキテクチャについて主要なテクニカルリーダーと話し合う。人間組織は技術組織と(そして技術組織は人間組織と)どのように一致しているだろうか。
合致していないがゆえに苦しんでいるのをみかける。大まかには合致しているときでも、もう少し最適にできるといいよねっていうのはいつも議論に上がる。
ほぼ完全に一致している…?もちろん、小さな(5人の)チームだからってのはあるかも
大事すぎる…
■最も大きなプロジェクトの人間組織を見直す。作業はどれくらいきちんと分割されているだろうか。それともモノリシックなままだろうか。人間組織のコミュニケーションパスはどれくらい複雑だろうか。それらはソフトウェアアーキテクチャとどのように関係しているだろうか。
これいままでで一番大きなやつだと、だいたい分割されていたかなぁ。。。使っている技術スタックが古いから大変だったけど、あれはあれでうまくいっていたとおもう。
一番大きいのはバイト先で自分がPLをやっている10人メンバー、PL1人、上長1人のチームだけど、上長のアドバイスでいい感じに分割されている気がする。WBS(Work Brakedown Structure)に基づいている。コミュニケーションパスはかなり単純なように思える。メンバー間は同じタスクでコミュニケーションを取り、メンバーとPL間があり、PLと上長間がある。別タスク間のメンバー同士のコミュニケーションが少ないと書きながらに思ったけど、アーキテクチャ的に(?)それがそのまま反映されていて、結びついておいてほしいところにも分離や乖離があったりしている。
■表10-1にまとめたアジャイルの重点を再確認する。事前の設計作業を増やさなくてもそれらの重点のほとんどを維持するもっと簡単な別の方法はあるだろうか。
使う技術スタックを最初からMSA系に全振りしておくとか。FaaSとNoSQLとみたいな。
マイクロサービス化することとかってどうなんだろう
■大規模なプロジェクトの課題を見直し、要求、アーキテクチャ、構成管理とバージョン管理、QAとテスト、プロジェクト管理、またはプロセスから、協調性の問題がどの程度発生するのかを判断する。
要求やプロジェクト管理のところで、持っている時間でvalueを最大化しない方向になりがちなのでそうすると協調しにくい仕事になっているなーっていうのは常々思う。自分達にはできない理想の固定的なアウトプットとか、仕事のあるべき進め方に対する思い込みが強い。
協調性の問題は構成管理とかアーキテクチャあたりである程度発生している感じがなんとなくして、それ以外はそれなりに大丈夫そうかも…?連携させるべきところは連携させる、情報共有の場を設ける、とか必要かもしれない…
適応
■チーム構造の結合性を弱めるためにアーキテクチャを進化させる計画を立てる。
EIPやりたいし、Apache Camelみたいなものでどんどんやっていきたいんだけど、今ひとつ理解されていないのがつらみ。
結合性は今、逆に弱すぎている感じがしなくもないけど、どうなんだろう。というかそれはチーム内部か…チームが複数あるような大規模プロジェクトではないので何とも言えないが、まずはメンバー間の相互認識合わせとかで、全体感をまとめたドキュメントをいつでも誰でも見れるようにしておこうかなーと思った
■上記の「検査」によって発見された協調性の問題の原因に対処するために、大規模なプロジェクトのアプローチを見直す。
ゆえに、PdMとかに頼りたくなるんだけどそれはPdMになんでも求めすぎているだけなので、やはりチームとしてこういったことを議論できるようにしていくようなテンプレートというかなにかが必要なんだろうな。。。
もっとうまくやる方法ってなんかないかなととりあえず上長に聞いてみたい