Project

General

Profile

スクラム開発実践

導入スライド

チケットへのサインについて

ユーザーストーリーは、新しいユーザー体験について記載されています。
ユーザーストーリーは、スプリントプランニングで話し合いながらタスクに分解します。

デイリースクラムで、分解されたタスクの最も上のものをそれぞれ1つ取りサインをして実施します。
タスクが終わったら、Doneに移動させ、次の最も上のタスクを取りサインをして実施します。
翌日のデイリースクラムでは、ゴールのために完了させたタスクが何かを話して共有します。

陥りがちな問題は、みんながバラバラのユーザーストーリーをやってしまうという事です。
1つのユーザーストーリーのタスクを、みんなで一気に片付けるようにします。
つまり、タスク間の依存関係を排除していく努力が必要です。

スプリントレトロスペクティブの効果的な活用方法について

スプリント振り返りでKPTなどでProblemの抽出などをします。
これってどういうPloblemを抽出して、どうTryしていくか、なかなか悩ましいと思いますね。

ここで抽出すべきProblemとは、ProcessにおけるProblemを指します。
効率的に仕事ができない問題を抽出するMTGになります。
出てきたProblemを投票制で、次回スプリントでTryするかを決めましょう!!

スプリント毎に1個のTryを実施していく事がおすすめです。
今スプリントでどのTryをするのか、これを決めて、実施していきましょう!!
効果がなければやめて、効果があれば続ければいいという事です。

プランニングポーカーについて

プランニングポーカーは、今までの人月計算から比べると大変精度が高い見積もり方法です。

わかりやすいストーリーのポイントを軸に、フィボナッチ数を提示します。
出た数が4つの値以上にまたがっている時(1,2,3,5など)選んだ根拠を説明します。
そしてまたやって、連続する3つの数の範囲に収まったら、合計して平均を出します。
平行線となって3回つづいたら、最大と最小を除外して、平均の値を使います。

議論やすり合わせは一切必要ない上に、コンセンサスを取る必要もありません。

スプリントのバッファーについて

スプリント内でどうしてもやらねばならぬ仕事が割り込んでくる場合があります。
そうすると、ベロシティが単純に比較する事ができなくなって、正しい改善が困難になります。

スプリント内でだいたいどれぐらいの割込みが発生するかをストーリーポイントを見積もってバッファとしてバックログに挿入します。
そのバッファは、使用しなくても良いですし、使用するなら、デイリースクラムで説明して使用できます。
こうする事でベロシティを正しく評価する事ができるようになります。

なお、ストーリーポイントに、作業バッファを含めるのはおすすめしません。
ストーリーポイントは工数のように何時間かかるから何ポイントのようにするのではなく、
基準となるユーザーストーリーから相対的に大きい小さいで評価するポイントであり、
後からこれは5相当だったな、となったら次回の見積もりの時に活かせばいいです。

重要なのは、見積もりにそんなに時間をかけてもムダって事です。

スプリントプランニングではスプリントレビュー時に何が見せれるかについて話し合いゴールを決めます。
そのためユーザーストーリー毎の受け入れ条件やタスク分割という部分にフォーカスしていきたい所です。

チーム分割によるコミュニケーション増大

チームとチームのコミュニケーションが大変になっているかもしれません。
今までは、1つのチームだったわけですから、分割したら、そりゃ大変になりますよね!

これはSpotifyの例ですが「分隊の依存関係」という項目が参考になります。
http://lean-trenches.com/scaling-agile-at-spotify-ja/

「分隊の依存関係」についてSpotifyは何をゴールにして、どう取り組んでいるのか、
そこに注目して読み込むことで、理解を深めることができます。

チーム分割によるコミュニケーション不全

スクラムで重要なのは、スクラムチームの独立と自己組織化です。
チームが他のチームに依存せず独立しており、そのプロダクトのすべての権限を持つという事です。
よって、疎遠になるというのは正しい結果といえるのです。

ただ疎遠になってしまった事が正しいとは言え、その方はもっと別の物が見えてるかもしれません。
なぜ「疎遠になってしまったのを危惧」したのか、これはぜひ深掘りしてほしいと思いました。
チームは独立したが、それ以外の独立してない部分についての問題提起であるんじゃないかと思います。

また、尾野さんはサイロ化の危惧をしていました。これも重要なポイントです。
サイロ化というのは、ナレッジが共有されず閉じてしまう事を指します。
ナレッジが共有されなかった時に、ナレッジを取得する必要が発生します。
しっかり共有していれば必要のなかったプロセスですので、これは無駄ですね。
しかし情報を共有しすぎていたらコミュニケーションコストが増大し、これも無駄です。
「どの情報を共有するべきで、どの情報をチーム内に留めるべきなのか」
それがサイロ化という課題の投げかけに対して、我々がするべき解答です。

アジャイルは、プロセスだけでなく組織や製品にも適応していく事が望まれます。

インセプションデッキは誰のもの?

インセプションデッキは、則る事で無駄なコミュニケーションを避けることができるツールです。
これは、チームのインターフェース仕様と言っても間違いではありませんので、
絶対正しく、間違いがあってはなりませんね。これが正しい物か確証は得られていますか?

インセプションデッキはPOがベースを作り、POとチームが意見を出し合いながら完成させます。
このインセプションデッキは全くなってない、などとうんちくを垂れるMTGです。
そして、その後POがインセプションデッキをステークホルダーと合意を取ります。
そうする事で、インセプションデッキの正しさを証明するわけですね。

そのおかげで、最小限のマネジメントで、最大のアウトプットが出せるようになるという事です。
スクラムの独立性や自己組織化にとって、必要不可欠なツールです。

プロセスに責任を持つスクラムマスターはその旗振りをしなければなりません。
あるとないでどれだけベロシティに影響するか、とても興味深い実験になりそうですね!

ユーザーストーリーの分割

ちょっとPOのユーザーストーリーが大きすぎるってときありますね。
スプリントに入らない、そんなの絶対おかしいよ!INVESTじゃないよ!

1.簡潔なユーザーストーリーである
プロダクトバックログリファインメントで1スプリントに収まるレベルに分割します。
分割する時のコツは、「追加機能」「削除機能」のように分割するという事です。
「テーブル設計」「検証」のように分割してしまうと、並列実行できませんね。
スクラムチームのCPUはマルチコアですから、並列実行可能、スレッドセーフを心がけます。

2.複雑なユーザーストーリーである
MVPで作って、スプリントレビューでPOやステークホルダーの反応を見てみましょう。
まずかったら、どうまずいか聞いて、作り直します。作って評価、作って評価。そして完成!
アルファ版、ベータ版、RC1、RC2、RC3、そのように作っていくイメージです。

3.どうしても分割できない
並列性がどうしても確保できないアトミックな処理があります。
重要なのはチームで協力してスプリントゴールを達成する事なので、
そのようなユーザーストーリーは、ペアプロやモブプロなどの手法が有効です。
品質が上がりますし、自分に無い新たなスキルを身に付ける機会になります。

アジャイルなドキュメントとは何か

情報を伝えるもっとも効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることです。
情報を伝えるために、ドキュメントを書く必要はありません。対話が一番必要なものです。
これは「アジャイル宣言の背後にある原則」の一つであり、アジャイルの重要な考え方です。

さらにアジャイルではウォーターフォールで必要だったドキュメントは全て不必要になります。
これはアジャイルにとって不必要という意味で、成果物にドキュメントがある場合などは別です。

なぜか、それは包括的なドキュメントよりも動くソフトウェアを価値とする宣言があるからです。
かと言って、まったく書かないわけではありませんね。「動くソフトウェア」の為なら書きます。

では具体的にどうすればいいのか、ユーザーストーリーにしてしまうという案はどうでしょうか。
ユーザーストーリーには「誰のために」「何を」「なぜ」の要素がありますから考えてみます。
それをチームにストーリーポイントで見積もってもらい、優先順位を立ててみましょう。
POとしてはドキュメントを保守するコストも含めたROIも忘れてはならないポイントでしょう。
そうするとウォーターフォールで必要なドキュメントは、大体のPJで不要になると思います。

ここに面白い調査結果があります、アジャイルと言っても必要なドキュメントを書かないわけではないんですね。
http://www.ambysoft.com/surveys/modelingDocumentation2008.html