第2章 アジャイルの本当の違いは何か
「アジャイルの本当の違いは何か」のようなタイトルの章を持つアジャイル本のほとんどは、2001年に宣言されたアジャイルマニフェストと、それに関連して20年前に作成されたアジャイル原則の歴史に関する説明をいきなり始めるだろう。
一文目からつよい。。。
アジャイル開発の恩恵は「アジャイル」という魔法の呪文を唱えることでどこからともなく湧き出るものではない
つおい・・・
「アジャイル開発で恩恵を受けるために、決めなくてはいけないことがある」的な話ですよね
アジャイルやるぜーっていっていたら、いつのまにかアジャイルになるみたいな
wwwwwwwwwwww草
アジャイル開発とシーケンシャル開発の比較では、どちらか一方をよいものとし、もう一方をよくないものとする傾向がある。
ほんとこの傾向がある。
ほんとうにそれ。
「アジャイルとは最良の開発プラクティス!」
素人がよくいう
「アジャイル」が不可分な概念で、「すべてを採用するか、まったく採用しないかのどちらかでなければならない」という考えから脱却すれば、アジャイルプラクティスをそれぞれ自由に採用できるようになる。
わりと不毛な「それはアジャイルかアジャイルじゃないか論争」みたいなものを目撃するので、こういう考え方が大事だなと思う。
++
アジャイルコーチ、アジャイルの実践者はバランスが大切って言いながら、グラデーションがあるって言いながら、「それはスクラムではないよね」とか「アジャイルじゃないよね」とか嘲笑する傾向があるのが、ちょっと。。。
わかりみのかまたり
ただ正しいアジャイルをわからずに中途半端なところで止まっているのと、正しいアジャイルを知った上で中途半端なところで止まるのは意味が違いそう。
アジャイルの境界を見誤ると、期待値のずれといった問題につながることがある。
これわかりつつも、問題が目の前で大きく発生したりはしにくいので、問題の予想力みたいなのが問われて、組織におけるテストエンジニアっぽさが必要とされている感がある。
あるいはアジャイルというなら数スプリント回してみて、改めて境界線引き直す、期待値設定し直すのが必要かも
あなたがCレベルの責任者(CxO)である場合組織全体がアジャイルの境界内に含まれている可能性は大いにある
あなたが組織のトップテクニカルリーダーである場合は、技術系の組織全体がアジャイルの境界内に含まれているかもしれない
ファンクション別に別れている(会計、データ基盤、認証基盤)ごとにある開発部の中で、開発チーム単位でアジャイルにはなっていても、XX開発部自体がアジャイルになっていない疑惑
アジャイルの境界に囲まれたバブルはチーム単位
そもそもカウンターパートのプロダクトマネージャーチームが境界を意識してない
納期とプロジェクトが壁の向こうから降ってくる感じ
開発リーダーは会議に参加するけど、メンバーは参加しない
参加しないからメンバーは「アジャイルでやった結果の方が大事」で納期を平気でぶっちぎりがち
当然開発リーダーの評価は死にがち
アジャイルソフトウェア開発とアジャイルでない法規制
アジャイルな営業とアジャイルではないソフトウェア開発
アジャイルソフトウェア開発とアジャイルでない企業顧客
ソフトウェア開発はアジャイルでないパターンは初めてみた
アジャイルソフトウェア開発と「アジャイルでない偉い人のメテオ攻撃」
メテオ攻撃を禁止カードにすべきなのではこのケース
検査
■これまで「アジャイルはオールオアナッシングの命題である」とどれくらい思い込んでいたのかを振り返ってみる。そのことは管理的なプラクティスと技術的なプラクティスの改善方法にどれくらい影響を与えていただろうか。
「うちはアジャイルだから管理しないよ!」的アプローチ(アカン)
境界線ひいて、比較的シーケンシャルよりのところは管理的プラクティス入れたほうがいい的な話かしら
どちらよりでも管理的プラクティスは必要で、改善する方向が違うんじゃないかなっておもう。
たしかに。カンバンとかバックログとかありますからね
■組織内の少なくとも3人のテクニカルリーダーと話をし、彼らにとって「アジャイル」が何を意味するのかを尋ねてみる。具体的にどのような行為を言うのかを尋ねてみる。テクニカルリーダーたちはアジャイルの意味に関してどこまで合意しているだろうか。アジャイルではないものに関して意見が一致しているだろうか。
絶対これは揉めそう。
アジャイル=「生産性向上」的な理解のリーダーが一人はいる
まずリーダーの価値観の調整というかインプット(洗脳かも)が必要
これは明確に一致したことが無いなぁ
ちょうど弊社のSlackで「アジャイルとは業務要件の決め方である」みたいな発言が出ていたりして、(間違ってると言いたいわけではないが)「?」ってなっている。
「それだけではないにしろ、それも大事ですよね」っていうフィードバックをするかなー。もし返信があったら、どのように違うのかと、それがチームにどんな影響を与えるのか詳しく聞いていくかも。
「アジャイルの境界を越えるときは、期待値や定義、インターフェースだけでも最低限決めとけや」って話なのかな
境界はあまり関係ないと思いました。常にじゃないですかね。
もめそう笑
品質とかは特に意識に差がありそう
■非テクニカルリーダーと話をし、彼らにとってアジャイルが何を意味するのかを尋ねてみる。彼らの仕事とあなたのソフトウェアチームの間の境界またはインターフェイスを彼らはどのように捉えているだろうか。
境界がふんわりしていたり、あるいは境界から「プロジェクトと納期」だけが降ってくると、アジャイル境界の内側もアジャイルではなくなってしまう・・・(納期ファースト開発になるので)
そもそも境界の時点で必要なインプットと不足な分はそっちで決めていいよの権限が欲しい
ないなら要件定義を境界上でやらないとReadyにならない
非テクニカルリーダーだから、「彼らがアジャイル開発に期待する期待値」「彼らに要求される決めるべきこと(I/F)」を伝えろって話では
「アジャイルで生産性バリ上げなんでしょ?」「(ふんわりした説明)を何月何日までにヨロ!細かいところは納品前レビューでダメ出しするから!」みたいなチャラいリーダーは許されない的な感じかしら
「毎回、打ち合わせでは、次回の打ち合わせまでにどういう風に変えるか決めましょう。次回にそれを持ってきますんで、大丈夫そうか見てください。良さそうならすぐユーザーに向けて出しちゃいましょう」みたいな話をする。
あまりアジャイルがどうのと言っても意味が無いと思っているので、非テクニカルリーダーが普段の仕事をどうやっているのかに合わせたくなる。
↑ の話は、非テクニカルリーダーがお客さんを想像して書きました。
チームでうまくやっていくぞっていうケースと、受託開発的なケースがあるなーっておもう。
後者の場合だと、ソフトウェアチームの一員にまきこむのを最初のコーチングにすることがおおい。
■表2-1の各項目に照らしてプロジェクトポートフォリオを見直してみる。それぞれの項目について、あなたのプロジェクトを5段階で評価する。1を「完全なシーケンシャル」、5を「完全なアジャイル」とする。
たぶん数字に意味がなくて、数字の意味についてワイワイすることに意味があるやつだこれ
4ぐらい
チームの中では完全なアジャイルに近づけようとする。けど、会社の手続き上、シーケンシャルな流れもあるので、そこはそれなりに乗る。
4くらい
リリースはバッチサイズが大きい
3くらい
ステークホルダーがグローバルのクライアント、グローバルの自社、グローバルの前任者、ローカルの各子会社とあってまぢでシーケンシャルになりがち。なんだけど、ミクロに見るとアジャイルっぽさがある。
適応
■組織内で「アジャイルの境界線」を引くためのデッサンをしてみる。
アジャイルにしていいところとそうでないところで線引きしちゃう(新たに引き直す)という話かしら
うちだと監査が絡むところとそうじゃないところで引きたいという願望がありますね。。。
法律が絡むところで引かれるようなイメージ
■本書の残り部分を読みながら答えるための質問リストを作成する。
これはまだ論ぜられるレベルになく・・・。
あー。これ毎回作ってもいいな。
2回目
現在のアジャイル開発と対比させるとしたら、最も意味をなすのはシーケンシャル開発である。(p9)
以前も少し聞いたんですが、僕が想像していたウォーターフォール開発と呼ばれていたものはシーケンシャル開発なんじゃないだろうか
ウォーターフォール開発は、プランニングの100パーセント、要求獲得の100パーセント、そして設計の100パーセントを事前に試みるものとされていた。(p9)
表 2-1:シーケンシャル開発とアジャイル開発の重点の違い(p10)
よくできたシーケンシャル開発でもプランニングの多くがジャストインタイムで行われる(p10-11)
ジャストインタイムはアジャイルの専売特許みたいな印象があったのでびっくり
"よくできた" が重要ですね
ジャストインタイム
事前に行うプランニングはほんのわずかであり、詳細なプランニングのほとんどはぎりぎりまで行わない(p10)
(表 2-1)
事前の詳細なプランニング
事前の詳細な要求獲得
プランニングと要求獲得の違いがよくわからなかった
プランニング
要求獲得をどうやってやるか、プロジェクトをどうやって進めるかみたいなものも含む
スプリントプランニングのようなものだけじゃない
要求獲得
顧客インタビューやマーケット調査など
事前の設計/アーキテクチャ作業の「一部」について価値を認めることに関しても、モダンなアジャイルは2000年代初期のアジャイル理論よりも進歩している。(p11)
2000年代初期のアジャイル理論は閉鎖的だったのかなという解釈をしました
カウンターカルチャーみたいな
Big Design Up Front (BDUF)
アジャイル開発では、テストは(中略)場合によってはコーディングよりも先に行われる。(p11)
コーディングより先にできるのだろうか、TDDでいう先にテストコードを書くことを言っているのかなという解釈をしました
順調に進むプロジェクトは、アジャイルアプローチとシーケンシャルアプローチのどちらを用いるかに関わらず、管理をきちんと行うことと、顧客とのハイレベルなコラボレーションを重視している。そして、高品質な要求、設計、コーディング、テストに重点的に取り組んでいる。(p12)
まさにこれ、比較して一方を断罪するのではいいプロダクトはうまれないと思うし、誤解を恐れずに極論を言うなら、これができるなら開発手法はなんでもいいと感じました
詳細な計画は、あとで無視されたり、捨てられてしまったりすることがあるからだ。(p13)
大いに共感。プロダクトの開発に限らず、日常の計画も詳細過ぎても結局その通りに行かなくて無視されたりするよなあと…
安全性が最優先のソフトウェアを開発している組織は一般に創発的な設計を採用しない。創発的な設計は経費の節約になるかもしれないが、この場合は安全性に配慮する方が重要である。(p13)
シーケンシャル開発(みたいなウォーターフォール開発)を用いると宣言して用いる場合の理由ってここに1つありそう。安全性を最優先にするならそりゃ大事だよなあと…
頻繁なリリースによって得られるフィードバックは経費の削減につながることがあるが、組織によってはかえって高くつくこともある。
ハッとした。たしかに、アクセスしにくいデバイスに組み込まれるものや法規制上の負担があるものはリリースを繰り返すと、経費としては高くつくこともありそう。それで逆に詳細設計とかにコストかけ過ぎても、リリース回数少ないのにアジャイル的にリリース回数多くした方が安かったりもしそう。リリースコストがどれだけあるかわからないけど…。ただ、正式リリースじゃなくてもプロトタイプリリースを繰り返すのはいいんじゃないかと思いつつ、flakinessも考えないとな…と思いました。
検査
■これまで「アジャイルはオールオアナッシングの命題である」とどれくらい思い込んでいたのかを振り返ってみる。そのことは管理的なプラクティスと技術的なプラクティスの改善方法にどれくらい影響を与えていただろうか。
技術はグラデーションがあるが、管理はオールオアナッシングみたいなところがまだ存在しているなっていう印象がある。管理的なプラクティスの解像度がまだ低いんだろうなって思う。
■組織内の少なくとも3人のテクニカルリーダーと話をし、彼らにとって「アジャイル」が何を意味するのかを尋ねてみる。具体的にどのような行為を言うのかを尋ねてみる。テクニカルリーダーたちはアジャイルの意味に関してどこまで合意しているだろうか。アジャイルではないものに関して意見が一致しているだろうか。
全然違ったけど、それは聞き方とか場の設定によるところもありそう。いい大人なので、その場では合意したことになりそう。
■非テクニカルリーダーと話をし、彼らにとってアジャイルが何を意味するのかを尋ねてみる。彼らの仕事とあなたのソフトウェアチームの間の境界またはインターフェイスを彼らはどのように捉えているだろうか。
短期間での仮説検証プロセスとして捉えていた。境界はまだわかっていなく、とにかく遠いという印象だけがある。
■表2-1の各項目に照らしてプロジェクトポートフォリオを見直してみる。それぞれの項目について、あなたのプロジェクトを5段階で評価する。1を「完全なシーケンシャル」、5を「完全なアジャイル」とする。
3くらい
ステークホルダーがグローバルのクライアント、グローバルの自社、グローバルの前任者、ローカルの各子会社とあってまぢでシーケンシャルになりがち。なんだけど、ミクロに見るとアジャイルっぽさがある。
3.5~4くらい
授業の時はもっとアジャイルに近かったが、「アジャイルだ。」というプラクティスなどはあまりしていないのでこの数値
適応
■組織内で「アジャイルの境界線」を引くためのデッサンをしてみる。
まだできていない
やってみたい
今週末のMTGでやってみたい
そもそも自分たちがアジャイル開発をできているのかが・・・わからない。という理由でアジャイルの境界線は引けないかもしれない。自分たちがアジャイル開発できているなら組織の殆どが境界内にいる。
■本書の残り部分を読みながら答えるための質問リストを作成する。
これからやろうかーって計画を始めているところ
本書のやり方と僕らのプロジェクトのやり方の差分を出すためのものと解釈。やってみたい