ふりかえり実践会「スクラムガイドを読み解いてみよう」第7回

「スクラムガイドを読み解いてみよう」第7回 に参加しました。

今回の範囲は、スクラムガイド 2017年11月の P.9(スプリントプランニング)からP.10(スプリントゴールの手前)でした。1時間で1ページのペースでした。

発言・コメントなど

網羅的ではありません。

スプリントプランニング

  • 何時間くらい?

    • 1週間で4時間使ったことあります
    • 分業されてると時間がかかる
  • スプリントプランニングでは、以下の質問に答える。

    • 誰が答えるのか?
    • > Sprint Planning answers the following:
    • 原文は上記なので、スプリングプランニングの結果決まるという感じなので、誰がというのはない

トピック 1:スプリントで何ができるか?

  • 横文字が多くて、頭に入ってこない
  • スプリントゴール大事だけと、依然としてはっきりしない

トピック 2:選択した作業をどのように成し遂げるか?

  • 作業に分解は全部やるのか?
    • スクラムガイド的には不要(「開発チームがスプリントの最初の数日間で行う作業については、スプリントプランニングで作業に分解する」)
    • https://www.ryuzee.com/contents/blog/7101 不要
    • 全部分解したい
    • プランニングの時間内で作業分解できない場合は、そのチームのスキルでは、どうせスプリント中に完了できないので全部はやらない

疑問

スプリントプランニングのトピック2での「作業に分解」は、スクラムガイド的には明らかに、スプリント中のすべての作業を分解する必要はないです。

開発チームがスプリントの最初の数日間で行う作業については、スプリントプランニングで作業に分解する

と明記されてますから。

しかし、作業に分解して作業時間を見積もらないと、スプリント中に本当に終わるかわからないというか、見積もりの確度が下がってしまうように思います。

全作業項目を見積もらずに、スプリント中にほんとうにできるかどうかをどのように判断しているのか?という疑問が生じました。

とはいえ、スプリントプランニングですべての作業を分解しておくというのは、ウォーターフォール脳な気もしました。

参考

Tags: scrum

ふりかえり実践会「スクラムガイドを読み解いてみよう」第6回

「スクラムガイドを読み解いてみよう」第6回 に参加しました。

今回の範囲は、スクラムガイド 2017年11月の P.8(スクラムイベント)〜P.9(スプリントの中止)でした。 1時間で1ページちょいのペースでした。

気づき・感想など

スクラムイベント

スクラムで規定されたイベントは規則性を作り出し、スクラムで定義されていないミーティングの必要性を最小化する。

スプリント以外のスクラムイベントは、何かを検査・適応するための公式な機会である(スプリントはその他のイベントの入れ物である)。

規則性、定義されていないミーティングを最小化する、検査と適応、このあたりがスクラムイベントの意義かなと。

スプリントの時間が余ったらどうするか?追加で何かするのはよくないんじゃないか?という話が出ました。

スプリント

スプリントでは、 - 品質目標を下げない

ここは私はいわゆるQCDのQは下げないということと漠然に考えていました。しかし、そもそも品質を下げるという選択肢はソフトウェア開発(アジャイル開発)では通常ないため、何故、わざわざ書いてあるのかよくわかりません。

スプリント中に品質目標を下げてゴールを達成しようとするということがよく起こったのでしょうかね?

スプリントは 1か月以内のプロジェクトと考えることができる。

プロジェクトであればゴールというものがあるでしょうということかと。

スプリントゴールとは何か?という難しい問題の参考URL。

スプリントの中止

スプリントゴールが古くなった場合は、スプリントを中止することになるだろう。会社の方向性や市場・技術の状況が変化すると、スプリントゴールは古くなってしまう。

スプリントは中止されることがありえます。

GO TO キャンペーンみたいなものが降ってきたら、スプリントを中止して対応のためのスプリントをするんじゃないかという話が出ました。

次回

Tags: scrum

ふりかえり実践会「スクラムガイドを読み解いてみよう」第5回

「スクラムガイドを読み解いてみよう」第5回 に参加しました。

今回の範囲は、スクラムガイド 2017年11月の P.7(スクラムマスター)でした。 1時間で1ページのペースでした。

議論のログは、#ふりかえり実践会「スクラムガイドを読み解いてみよう」第5回のまとめ - アジャイルって、なんだ にかなり丁寧にまとめられています。

スクラムガイドとは?

スクラムガイドは、スクラムの開発者である Ken Schwaber と Jeff Sutherland によるスクラム公式ガイドです。スクラムのルールが記載されています。

以下からダウンロードできます。

スクラムのルールブックなので、原理主義的にはスクラムガイドに従っていればスクラムを実践していると言えます。逆に、スクラムガイドに従っていない場合はスクラムっぽい開発、なんちゃってスクラムと言えます。

スクラムガイドは最低限のルールなどが抽象的に簡潔に記述されているため、最初はかなり読みづらい、理解しづらいです。

具体的なやり方は記載されていないため、いきなり一人で読むことはハードルが高いです。今回のような読書会などに参加すると理解の助けになるかも知れません。

以下、個人的な気づき、感想です。引用はスクラムガイドから。

感想など

スクラムマスター

スクラムマスターは、スクラムチームとやり取りをするとき に役に立つこと/立たないことをスクラムチームの外部の人たちに理解してもらう。

The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t.

スクラムチームの外部の人とのやりとりがスクラムマスターの重要な仕事になりますね。

スクラムマスターはプロダクトオーナーを支援する

スクラムチームの全員がゴール、スコープ、プロダクトのドメインを可能な限り理解できるように する。

Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;

さらっと書いてありますが、実際にやるのはなかなか難しいです。

価値を最大化するためのプロダクトバックログの調整方法をプロダクトオーナーに把握してもらう。

Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;

これは私はPBIの並び替えのことだと理解しています。 ROIを最大化するように並び替える。

実際にどうROIを推定するかは、そんなに簡単ではないですが。

スクラムマスターは開発チームを支援する

スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチする。

Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

スクラムが完全に適用・理解されている組織環境というのは、ほとんどなさそうです。

スクラムマスターは組織を支援する

組織へのスクラムの導入方法を計画する。

Planning Scrum implementations within the organization;

スクラムマスターはスクラムチーム内の役割ですが、スクラムチームよりも前にスクラムマスターが存在することが前提となっているように読めます。

スクラムが導入されていない組織ではスクラムチームはまだ存在しませんが、スクラムマスターはそのような組織でもスクラムの導入を指導したり、計画を支援するということですから。

その他の話題

スクラムガイドにはありませんが、スクラムマスターのチェックリストというものが、いくつか作成されているようです。

こういうチェックリストを見ると、自分ができていないことを探す参考になります。

次回

参考

Tags: scrum