海と山が好き

海と山が好きだけど埼玉に住むおっさんが遭遇したアジャイルとかのはなし

スプリントへの割り込みに悩まされた時に考えること

前回の続き

bbbbashiko.hatenadiary.com


割り込む理由/どんな状況か/何を見て判断するか/対処方法

※ここに書いてあること以外にもいっぱいあるはず。

※割り込みが絶対にあってはいけないとは言わないですが、ヒステリックにゼロイチでないといけないということもないと思うので、割り込みが多いなって思ったら気にするくらいで。完璧なんてないので。 ※目安はスプリントゴールがもう無理ってなるかどうか


計画が立てられるほど見通しが良くない

500m先を右に行こうとか見えてない先のことまで考えて運転しても途中でハンドルを切り直す羽目になる。

  • こんな状況
    • スプリント期間で何をやればいいのかを決め打ちできるほど、チームの置かれている状況の見通しが高くない。
    • 必然的に、スプリントを進んできたところで新たな発見・ないしはやらなければいけない仕事に出会い、修正を余儀なくされる。
    • 結果、割り込み誘発される。
    • ウォーターフォールは変化に対応しにくいけど、同じ理由で変化に合わせたサイクルでないスプリントも変化に対応できない。
  • 兆候
    • 割り込みはスプリント後半に発生している
  • 対処
    • スプリント期間を短くする。
    • またはタイムボックスで仕事をすることを諦める(フローで仕事をする。カンバンとか)

規律の乱れ

規律が乱れると地獄が始まる

  • こんな状況
    • PO が開発者(というか規律)に対する甘えを持っている。スプリントの途中で頼めばいいだろう、という発想でいる。
    • 結果としてデリバリーが混乱し、チームの規律を乱すことを許し、プロダクトのアウトプットも低下する。結果として、ROI を最大化するという PO の責務を果たせていない、ということに気付いていない
    • PO は常に一歩先、二歩先を見越して何を解決すべきかを考え続ける必要があるが、受託請負メンタルの PO には難しい。役割名通り、オーナーシップを持っていないとこの辺りのことを考えられない。
  • 兆候
    • 割り込みを追加する際にチームとしてルールや規律を設けていない
    • 開発者は割り込みを受け入れることで、ゴール達成できなくてもしょうがなくない?というコミットメント放棄がバーターとして許されるという甘い罠にハマっているので、スプリントゴールの達成がされない
    • スクラムマスターは見て見ぬふりをしている
  • 対処
    • スクラムマスターを変える
    • 規律として割り込みをどうするのか、チームで話してワーキングアグリーメントを定める

お前の目は節穴か

視力が悪い人は視界が良くても速く走れない

  • こんな状況
    • スプリントのスコープがコロコロ変わる
    • ドメインについてあまり理解していない PO や開発者で構成されている。受託みたいな。
  • 兆候
    • スプリントのいつでも割り込みがある
    • PO はドメインについてあまり詳しくない
    • スプリントレビューで初めてトンチンカンなもの作ってることに気づくことが多い
  • 対処方法
    • ドメインを理解している PO に交代する
    • PO がドメインを理解する訓練をする
    • チームが、言われたものを作ると言う態度から、なぜ作る必要があるのか、を問うように訓練する

    • 視点をソフトウェアを作る、システムを作る、と言う観点から、サービスや業務を作る、といった観点に引き上げる。

      • ユーザーストーリー形式の、”〜〜なぜならば、” の項を明確に書くようにする。ないと何が困るのか、誰が困るのかを理解する
      • 肩越しの視線:ユーザーが使っている場面を見に行く、とかもできるならやる
      • プロダクトバックログアイテムの向こう側にいる実際の人を見るきっかけを作る。映像で実感する。

結局のところ、ドメインの不確実性のためにアジャイルな構えが必要というのは、1だったり3だったりで複合的、というか、相対的なものなのかもしれない。

同じシステムを新人や未経験のチームに任せるということは、相対的にそのドメインがチームから見て不確実性が上がっているように見える、のかもしれない。知らんけど。

なぜ割り込み仕事に悩まされるのか

スプリントへの割り込みに対してどう対処するか。

スクラムをやっていて一番悩まされることが、スプリントへの割り込みどうするか。

基本的には、スクラムマスターが スプリントへの割り込みタスクを防止するように割り込み依頼者に伝える。とある。でもそうはいっても難しいというのをよく聞く。つらい。

 

なぜ割り込みが発生するのか

続きを読む

『別にスクラムは目的ではないので』との向き合い方。

「別にスクラムは目的ではないので」

親の顔よりよく見かけるフレーズ(当社比)

スクラムの規定しているロールやイベントをやらない際に使われる。Scrumbut みたいな。

f:id:Bashiko:20200623171313j:image

もちろんスクラム自体は目的ではないし、してはいけない(と、個人的には思っている)が、スクラムがなぜ機能するのか、を理解せずに、上の言葉を持ち出してねじ曲げる場面を見ると、少し危ないと思っている。

(もっとも、スクラムだけじゃなくて、PMBOKCMMI でもよく聞いたし同様だ)

 

続きを読む

スクラムを個人戦にしてしまう方法

スクラムではチームの成果にフォーカスする。

そのためには、個人で仕事をする形から、チームで仕事をする考え方にシフトしないとけない。

いわゆる Swarming という考え方で、チームが寄ってたかって一つの開発アイテムを進めることを意味している。

逆に、チームでバラバラと仕事を進めるわけではない。

イメージしにくい人は、アメフトの試合で、ボールがフィールド上にいくつあるのか(1つに決まっている)、チームはどのボールに向かっているのか(1つに決まっている)を想像してみるといいと思う。あっちもこっちもボールが転がってたら大変だ。面白そうだけど。


なぜチームで仕事をするのか

続きを読む

なんでもアジャイルなのだ

空前のアジャイルブーム到来(主観)

ここ2、3年? アジャイルブームが来ている、気がする。

 

一方で、アジャイルっていう必要あるんかそれ?っていうモノも見かけるようになってきた。

 

アジャイルアジャイル、みたいな接尾辞がつくのは特にそんな感じのものが多い気がする。

 

 

アジャイルを名乗るな!とかいうわけではなくて、本質を見失うと空回りしかないからよくないんじゃないかなーと思う

 

第一、”それ” を広め ら れ る 側の立場からすると、謎の横文字と出羽守スタイルで殴りかかってくる敵と戦う構図になるので拒否反応しか出ないのではないかなあ。

 

アジャイルってなんだったっけ

ところで、そもそもアジャイルってなんだったっけ、に戻ってくる。

アジャイル開発ではなくてアジャイル

 

みんな大好きアジャイルマニフェストのとおり、価値宣言と原則があって、っていう。

 

アジャイルソフトウェア開発宣言

アジャイル宣言の背後にある原則

 

表現がシンプルすぎて誤解を生みまくる、というか都合の良い解釈をされやすいこれら。

よくわかんないからって調べても、まあまあ怪しい解釈サイトがいっぱい出てきて中々腹落ちしづらいこともあるし、そこでみんないろんな解釈をしてすれ違いが生まれるんだろうなあ(他人事)

 

背景や過程を知らないで文言だけ追っても本来の意図とは違うものを解釈するのは当然起こる。

tree-swing-s-hogh

ので、背景や過程を知っておくのも、アジャイルとは?ってのを理解する上では重要だと思う。

(ユーザーストーリーにおける、so that ~~~ の部分。)

一応、Agile Manifesto のページにはちょっとだけ History ページもあるけどなんでこれ翻訳されておらんのやろ。

agilemanifesto.org

 

読もうね。

 

計画駆動(≒現実軽視)やプロセス重視(≒人間軽視) からの脱却であって、見える化とかチームとか速くデリバリするとかはそのための手段ちゃうんかな

 

アジャイルで部署の枠を超えて新商品発売の開発期間をxx%削減!とか言われても、会社が小さかった頃はアジャイルなんて言わずにそうだったんじゃないの?アジャイルっていう必要あるの?とか思ってしまう(性格悪い)

 

営業部は昔から組織目標の売り上げの達成グラフみたいなのを出すことはずっとやってる。でもアジャイルとは言わないだろう。

営業の現場でも昔から使われている見える化という取り組み(パターン)をアジャイルでも使われている、ってだけで。

土木の現場では毎朝朝会をやっている。でもそれをアジャイルとは言わないだろう。

毎朝現実の進捗に基づいてその日の計画を立てる、予測を立てる、っていうのをアジャイル開発も同じようにやっているだけで。

 

逆にアジャイルは朝会をやります、というのを、脳死でマネしても多分意味はないしそれでアジャイルとか言われてもツライだけだと思う。現場が。

 

とはいえ、

アジャイルとかいうのがなんらかの改善を伴う活動だっていうのは間違いないが、

 

「レビューで手戻りが起きた!」

→ 『よし、改善だ!』

→ 『事前に仕様に間違いがないことを合意して押印してもらうぞ!これで改善できるぞ!アジャイルだ!』

 

ぐらいのことはきっと起きるし起きてる。ツライ。

 

(例えは極端だけど、予実がズレたから1ポイントを1人日にしましょう!みたいなチームは稀によく見る。スクラムマスタークビにしろ)

 

じゃあどうすんのさ

どういう観点で改善進めるのかが肝心な気はしている。

 

ディスカバリーサイクルとデリバリーサイクルの流れをよく見るのが一番効果が高くなる気はしている。

バリューチェーンのどこがボトルネックだったり、サイクルタイムを長くしているのかを調査する。

(やることや観点はパフォーマンスのチューニングと一緒だったりする)

 

視野を狭めると効果がないので注意が必要だったりするし、難しい。

 

開発チームの中でスクラムを回して楽しく開発してても作ったものが本番にデリバリーされてないならそこに目を向けないでスクラムスクラム言ってるのはなんの意味もない。というか浅い。

よっしゃ DevOps や!とか言いながら改善スコープを広げていくしかない。

実は開発サイクルじゃなくて PO が顧客と話してまたは調査して課題発見するまでがボトルネックだったり長くなってるならそっちに手をかけないと意味がない。

一生懸命アプリケーションのチューニングばっかりしてるけど DB のレスポンス遅いのは DBA の仕事だから僕知らない、みたいな。良くないしそっちがパフォーマンスにおいて支配的なら自分のスコープに拘る意味がない。

 

f:id:Bashiko:20200317211947p:image

 

 ------2020/3/17 追記-----------

この辺で雑に書いてたことは全部綺麗に Ryuzee さんのブログに書いてあったから各意味なかったのと思ってるしそっちを参考にした方が1億倍健全ですのでそっちを見てください。

不確実な環境の中で 変化にどう対応すべきか | Ryuzee.com

 ------追記終わり-----

 

アジャイルを広める

とかいう難儀な仕事に就くなら、社内の改善サイクル、改善軸の手助けから始めるのがよさそう。

脳死で大規模プロセスとか導入するのはラクだし成果も見せられるだろうけど結果には繋がらんので。

(さいきょうのサーバーを1台置いたんで、ここでみんなかいはつしてでぷろいしてさーびすしてください!なんて悲劇しか起こらんでしょ)

スケールさせるのはプロセスじゃなくて文化。間違えると人間軽視に走って自己否定になるし。(もちろんプロセスも大事だけど。)

 

----

 

結局『アジャイル』とかいう実体の伴わないラベルは忘れた方が良いのかもしれない。

(AI やりましょう!くらい胡散臭いと思っていい)

 

自分らが顧客に何を提供するかの観点で、じゃあ何の問題を解決しましょうか、の繰り返しの結果、多分アジャイルみたいな何かになっている、はず。たぶん。知らんけど。

一方で、アジャイルっていうのが、どんな課題にどんな解決策で上手いことやってるか、というのは、知っておくと効率が良いし車輪の再発明しなくて済む。かな、って程度で。