海と山が好き

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

スプリントで終わらなかったストーリーのポイントはベロシティに入れるべきか？

スクラム

ユーザーストーリーを活用しているチームは多い。

ユーザーストーリーの形式はシンプルに「背景」と「実現したい状態」を表現していて非常に認識齟齬を減らしてくれる良いツールです。

逆に、「やる事」だけが書かれているようなユーザーストーリーは注意が必要です。

（往々にして何故やるのかわからないからやった内容に後からイチャモンが付く。）

で、ユーザーストーリーに対して見積もりとしてストーリーポイントを付与するチームも多い。

相対見積もりによって効率よくプロダクトバックログ全体のボリュームを見通すのにちょうどいい。

また、バックログを消化するスピード（ベロシティ）にもちょうど良い指標にされている。

ところで、「スプリントで終わらなかったストーリーは、終わった分だけ割合でベロシティに計上していいですか？」って聞かれることがよくある。かなりある。

結論から言うと、計上しなくていい。ということを勧めている。

① 理由として、計上すると、終わらなかったことに対する責任をチームが持てなくなる。

終わらなかったけどベロシティとしてチームの成果に見えてるぞ、と。

となると計画に積んだのに終わらなかったことを振り返る気にもならない。

結果、ふりかえりで改善のフォーカスが当たらず、チームのパフォーマンスは上がらない。

② さらに、積まなくてもどうせベロシティ計算するときに薄まるから気にしなくていい、ということもつたえる。

3スプリントでベロシティ見積もるとして、それぞれ未完了があったとしたら、次のスプリントで完了したときに、次スプリントで計上されるから。

もちろん次スプリントでも（考えたくないが）未完了は発生するが、3スプリント間で相殺するので、影響は 1/3 になる。

そこまでいったら経験上ベロシティとしては誤差だから気にしなくていい。

③ いちいち気にするだけ時間の無駄だ。

ってあたりをチームに話してみて、計上したい？って聞くといい。

仕事をしたのにベロシティという目に見える形に影響出来ないのは辛いが、ベロシティは成果を評価するためのツールではないので気にしない方がいい。

チームには、終わらなかったことから何を学んだか？んじゃ次はどうしたいか？を考える方に情熱を使ってもらおう。

ちなみに、仕掛かりのままの仕事が多いと、とても生産性が落ちる。

たくさんの仕事をスプリントに積んで食い散らかすより、食べ残しが無いようにしてみると、意外とベロシティは上がる。

（色々着手しないことでサイクルタイムを減らす圧力がかけやすいから当たり前だけど）

始めることをやめて、終わらせることを始める

っていうカンバンの原則を活用すると良いかも。

カンバン仕事術

カンバン仕事術

ふりかえりはチームのためのもの

アジャイル スクラム

職業柄色々なプロダクトのスクラムチームを見ることがある。

で、いくつかのチームで共通する、形骸化したふりかえりのあるあるパターンの１つ。

個人のふりかえり → 個人の反省 → 個人の改善になってるパターン。

「風邪を引いて作業が進まなかった」→「体調管理に気をつける」

みたいなやつ。

作業が進まなかったのは チームの問題 なので個人の問題のままに改善しようとしているならスクラムマスターを何とかした方がいい。

第一、個人のふりかえりと改善なんてスプリント終わりまで待たずに毎日やってくれていい。

スクラムガイドを見ると、

https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。

(中略)

スプリントレトロスペクティブには、以下の目的がある。

• 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。

• うまくいった項目や今後の改善が必要な項目を特定・整理する。

• スクラムチームの作業の改善実施計画を作成する。

スクラムマスターは、次のスプリントが効果的で楽しいものになるように、開発チームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらう。

チームのやり方を見直して、改善するのがレトロスペクティブの目的。

これを忘れるといつまでもチームとしての能力は大して上がらない。多分絶対に。

こうなるチームの特徴の１つが、ストーリーを人にアサインするアンチパターンがある。

Ryuzee さんのブログに詳しいので詳細はそちらを。

www.ryuzee.com

このスタイルで作業を進めると、「レビュー待ちです」「あとはマージだけです」みたいな会話をレビューでよく聞く。いや終わってないからそれ。

そもそも スクラム なんて読んで字のごとくラグビーの話じゃないですか。

どこの世界に各自1個ずつボール持ってヨーイドンするラグビーがあるんです？

というわけでスクラムのレトロスペクティブにおいて、個人のふりかえりにはあまり興味はない。敬意はある。くらい言わないと伝わらない気がしている。

うまくいったやり方をチームでどうすると継続できるか？をシェアして考えて掘り下げて身にしていくサイクルにしないとだ。

なお、やると決めたら、チケット切って次のスプリントの一番上に置くことをお勧めします。

そうすれば改善が進まないんですなんてこともないですし。欲張らずに１つでもいいです。やらないよりは。

計画ってなんだろう

アジャイル

計画ってなんだ？

仕事だけでなくスポーツでも教育でも必ず耳にする 「計画」 という言葉

アジャイルと計画って言葉は密接に関係していると思う。

密接ではあるが表裏では無いのがミソ。

とりあえずググると、、

計画（けいかく、英語: plan）とは、何らかのものごとを行うために、方法や手順を考え、企てること。また、そうして考え企てた内容のこと。

計画とは、何かのものごとを行うために、あらかじめ、その方法、手順などを考えること（この場合「計画する」などと述語、動詞的に用いる）、およびそうして考えた方法や手順のことである。

ブリタニカ国際百科事典によると、計画とは、将来 実現しようとする目標（目的）と、この目標（目的）に到達するための主要な手段や段階とを組み合わせたもの、とのことである。

だそうだ。

要は 「目標」 と 「実現方法」で構成されている。

大抵の場合、実現方法（実行計画）を無視して突撃すると上手くいかないか、多大なコストを支払う羽目になる。

ちょっとずつやってるから大丈夫！と思っても夏休みの宿題が終わるかは分からないからだ。

だからママは聞く。 「夏休みの宿題終わるの？」と。

「算数の15ページ目だよ！」と言われるとツライ。

ママにとって気になるのは終わるかどうかであって何をやってるかどうかでは無いのだ。

って話は進捗管理の話なので今回は置いといて…

「計画」 が立てにくい状況にはアジャイルが効くと言われている。

１つは、「目標」が不確実・不安定な場合があるから。

  • 後になったらもう要らない、というもの

  • とりあえず言ってみたけどそんなに重要じゃないこと

  • その時は必要だと思っていなかったけど、後になって必要になったもの

とか。

そういう状況では「目標」に向けて計画を立てたとしても、目標そのものが目指すべきものでないので、悲惨な結果になる。

だから、間違いなく必要、というところは達成したいので、精緻に計画を立てる。

逆に、多分必要かも〜レベルの内容であれば、そのうち目標として明確になったらやる、と言った程度で、粗く見積もる程度にしておく。有名なのがストーリーポイントとか、T シャツのサイズとか。

やるかどうかもわからんものに計画を立てるのはただの無駄だ。

どうせ作っている間に陳腐化したり、新しいものが必要だと気づくので、先の詳細は先に考えるのが良い。You ain't gonna need it だ。

逆に、ウォーターフォールなんかで要求定義をするということは、

「これを作ります」という宣言の裏で、
「これ以外は作りません」という宣言をしているのと同じなのだ。

IT のプロセスの問題の不都合をビジネス側に押し付けるのは、流石に傲慢では？という感がある。

もう一つ、「実現方法」が不確実・不安定な場合がある

わかりきった、枯れきった技術でやるのと、新技術や出たばかりの OSS なんかでやるのとでは、同じことをやるのにもリスクが全然違ってくる。

ある程度試行錯誤して泥沼にハマって進まないといけない。

こんな場面で実現可能な「実現方法」を計画として建てろと言われてもアホなだけだ。

全く未知の場合は、ある程度ジャブを打って Shure な状態にしてから着手したりする。

スクラムで言えば「技術的スパイク」とかいうやつがそれに当たるか。

（以下、例えがすごく怒られるやつ）

要は、幼馴染とご飯に行くのと、街中で出会った女の子とご飯に行くのでは途中のプロセスは全然事前に読めないし、ある程度試行錯誤が必要なのと同じだ。

前者であれば、いつ何食べに行こうぜ、って誘えば来るな、って計画が立つけど、

後者であれば、何が好きか？何が嫌いか？そもそも初めまして、、、とか色々やらないといけないし、具体邸に何をやるかは計画できない。

ある程度の「構え」的なものを持っておいて、柔軟に対応するしかない。

そして当たるものを試行錯誤するために、頻繁に手を替え品を替えてご飯に誘うしかない。

そう、ナンパとはアジャイルなのだ

（以上、すごく怒られるやつ）

というわけで、不確実な目標や手段を必要とする場合には、試行錯誤のサイクルが勝負につながるので、アジャイルなやり方が性に合っている、ということになる。

（というか、計画駆動を選んだ時点でほぼ ”負け” になる。）

そのやり方で、本当に意味のあるものを作れますかね？勝てますかね？っていうは、開発手法を考える上で、必ず考えておきたい。

アジャイルなので計画はありません

アジャイル

アジャイルなので計画はありません

たまにそんなセリフを聞きます。

アジャイルなのでコミットしません

これもよく聞く

そんな話

アジャイルって計画しないの？

必要ならするでしょう。

必要ないならムダだからやらないでしょうね。

たとえば、みんなが大好きな スクラム

チームはスプリントの達成に向けて全力を尽くすことをコミットします。

そのために必要なだけ計画を立てるし、設計もします。

作るか分からないものに計画を立てたり設計するのはムダになる場合が多々ありますが、

作ると決めたものに向けて計画と設計することは全くムダではないです。

長期の見通しは、荒い粒度で見積もりますね。

よく Planning Onion なんて言いますが。

先のことはわからないからムダを抑えて見通しレベルにしますね。

だってどうせ今の時点でのスコープなんて将来変わるし。

そのときにまた見通しを持ち直せばいいんです。

スコープを変えない？それが約束できるならアジャイルにする意味があまりないかもしれませんね。

（How の不確実性を捌くには、結局重要ですけどね）

-—

アジャイルは計画が立たない状況に非常に有効だが、

無計画の言い訳にも使われやすいので気をつけましょう

アジャイルはドキュメントを作らないのか

スクラム アジャイル

アジャイルってドキュメント作らないんでしょ？

いきなりこれを聞かれたら悲しい。

どんな辛い過去やトラウマがあるのかと。

しかしいまだにこういう認識の人は多い。

「だってアジャイルマニフェストにそんな感じのこと書いてなかった？」

もはやここにアジャイルがドキュメントに懸念している問題が顕在化している気がする。

だってそもそもその ”アジャイルマニフェスト” ってドキュメントじゃん。

ドキュメント上でドキュメントはダメ！とか言ってたらヤバい人でしょう。

そんな筈はないし誤解なので大丈夫。

アジャイルマニフェストではどう書かれているのか？

agilemanifesto.org

すなわち、左記のことがらに価値があることを認めながらも、

私たちは右記のことがらにより価値をおく。

とある。

左記には「包括的なドキュメント」

右記には「動くソフトウェア」

が置かれている。

なので、そもそもの誤解なのだが、ドキュメントがいらない、なんて書かれていない。

曲解したエンジニアや誰かが、アジャイルだからドキュメントはない、っていう事象に遭遇してしまったのかもしれない。

ところで包括的なドキュメントよりも、動くソフトウェアに価値があるとみなすのは、リーズナブルだと思う。

基本設計書だのプロジェクト管理計画書だの課題管理プロセス定義書だのが存在したところでビジネス的になんのお金にもならない。

最終的に動くコードが必要で、包括的なドキュメントを作っているコストがあるならよりビジネス価値を生み出すコードに投資した方がいい。

というのが、原理の一つ。

もう一つ、ドキュメントが危険な場面がある。

これは直接言及されていないが、アジャイルマニフェストの背後にある原則の一つがヒントになる。

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

報を伝えるもっとも効率的で効果的な方法は

フェイス・トゥ・フェイスで話をすることです。

ドキュメントという言葉が使われていないが、比較対象に「ドキュメントによる情報伝達」あることはなんとなくわかる。

F2F で話すことが最も情報を効率よく伝えるのは当たり前すぎるほど当たり前なのだが、世の中にはいまだに完璧なドキュメンテーションができていないからだ、と考える人も多い。

そんなシンプルな時代は終わっている。少なくともソフトウェアの世界では。

ドキュメントに記載された文言は、受け手次第で解釈はいくらでも変わってしまう。

そのドキュメントが作られた背景や経緯を共有していないのに、ドキュメントという文字面から意味や意図を理解することは非常に難しい。

っていうか人間は文字くらいは読めるので、自分の理解のまま理解してしまうのだ。

つまりはなんでも自分流にコンパイルできてしまうのだ。意図した振る舞いじゃなくても。これは怖い。

ソシュールが一般言語学講義の中で説いたシニフィエとシニフィアンの関係性に近いのかもしれない。

シニフィアンとシニフィエ - Wikipedia

冒頭にある通り、アジャイルマニフェストというシンプルな文章の例で言っても、受け手によっていくらでも曲解・誤解されてしまい、正しく伝えることはできない。

多分、アジャイルマニフェストを考えた場にいて、その場で文言が生み出された家庭にいた人間以外には正確に理解するのは難しいだろうな、という気はする。

人に伝えるなら、ドキュメントではなく会話を。 ドキュメントはあくまで補助。

文字列と音声情報のファイル容量の違いを見てもわかる通り、映像の情報量は非常に大きく、会話という相互コミュニケーションはドキュメントには決してできない情報補完力があるからだ。

ただし、現在から未来へ情報を伝えるには、ドキュメントは非常に有効だ。

なぜそうしたのか、コメントでも Redmine のチケットでも書き残しておくと非常に有用だ。

伊達に古代エジプトから生き残っているソリューションなだけある。

書き手の意図したことの 1/3 も伝わらない。

人が直接教える方がよっぽど効率的だ。

そんなことを確定申告サイトの UI と戦いながら思うのである。