Project

General

Profile

スクラム開発実践

導入スライド

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アジリティをいかに価値につなげるか

今メディーバでビジネス構造が変わってきているなと僕でも感じます。
柱であるポータルではより一層、ここを再考する事は、必要なプロセスであると思います。

アジャイルを使うことで「機敏性（アジリティ）」を身につけることができます。
様々な状況変化を受け入れ、そこでいかに価値を出すかにフォーカスするわけです。

本場アメリカではアジャイルじゃないなら投資しないという投資会社があるんですが、
そもそもアジャイルは現場からボトムアップで作られてきたもので、
その価値が評価された事によって、ビジネス要求になったわけです。

スクラムというフレームワークをインストールするだけで良いんでしょうか。
スクラムで仮にも作られた「アジリティ」はビジネスで強力な武器にできます。
この武器を使って価値につなげる事ができれば、ビジネスは必ず成功します！

モジュラリティな目標設計

「私は ポータルチームの方々が アジャイル開発についてスゴい人たちになるのを手助けします」
わたしはこの目的のもとで活動しています。そして頑張ってますｗ伝わってますか？ｗ

じつはこれ、キャシー・シエラという方が作ったテンプレートなんですね。
「私たちは $TYPE_OF_PERSON の方々が $THING についてスゴい人たちになるのを手助けしています」

PVや売上の目標は、どうでしょうか、うまく行ってますか？
この目標を達成するために努力するぞ！とメンバーは言えそうでしょうか。

テンプレートを使ってみましょうか、
「私たちは ポータルTOPにアクセスする方々が 今のリアルな情報についてスゴい人たちになるのを手助けしています」
これは達成するために努力できそうだと思いませんか？ ぼくなら数字よりはやる気が出そうです。
この目的に基づく活動によって、PVや売上が上昇するロジックは、組めそうですか？

データベースはACID（原子性、一貫性、独立性、永続性）を担保する必要があります。
データベースにユーザーエクスペリエンスなんて不必要です。データベースとしての機能が必要です。
全レイヤーで同じ目的や目標を持つというのは、どう考えても「設計ミス」です。
システムの目的達成の為にはモジュール毎に目標を相互変換したり分担してあげる必要があるわけです。

３チームあるなら、それぞれチームの目的を作れそうですね、これはどうでしょうか。
「私たちは W杯特集にアクセスする方々が W杯の情報についてスゴい人たちになるのを手助けしています」
これは良い目的だとは思いますが、少しの期間で不要になりそうですね。

必要のなくなったモジュールは、必要なモジュールに交換して構いません。
スクラムチームには「スゴい人たちになるのを手助けする」為の必要な機能が全てが揃っています。
$TYPE_OF_PERSONと$THINGは何を入れれば上手くPVや売上に繋げれそうですか？

目的のある努力は、評価されやすいし、評価しやすい。更にユーザーも喜びそうです。
これを個人やサービスの目的や目標を考えるきっかけにしていただけましたらありがたいと思います。

チームの生産性を上げるユーザーストーリー

「デフォルト画像の記事を読むユーザーとして、デフォルト画像をより記事内容に関係するものにしたい。なぜなら画像で記事の8割を理解するからだ。」
なんて無茶なユーザーストーリーだ！しかし興味深い

チームに居るアーキテクトが提案します。
「写真素材を持つ企業から画像セットをもらって機械学習で出す方法はどうだ」
ただこの方法は外部との調整があるため、プロダクトオーナーに預けられます。

スプリント内でできるMVPとして以下のタスクに分解されました。
「過去のデフォルト画像の記事を分析して、どういう記事があるかを調査する」
「調査結果を元に５つのデフォルト画像を作成する」
「記事作成時にデフォルト画像を選べるようにする」
機能横断チームなので、全てチーム内で開発が完結します。

スプリントレビューで、運用チームから指摘されます。
「選ぶのが面倒、カテゴリで自動にできないのか」
「関係した画像ではあるが、５つでは足りない」
チームは我慢し「わかりました」とだけ答え、次のレビューで驚かせてやる！と思います。

POは開発チームの活躍の裏で画像提供企業との契約をとりつけつつ、データを集めます。
「デフォルト画像記事のクリックレートが少し上昇している」
「デフォルト画像記事の読まれている時間が少し増えている」
「デフォルト画像記事の離脱率が減少している」
このユーザーストーリーはもっと進めていく価値がありそうだ！

１ヶ月後、チームはまた別のユーザーストーリーに取り掛かります。
「さて、次の無茶なユーザーストーリーは何だ？」

The New New Product Development Game

スクラムの起源、野中教授の論文で重要な部分を抜き出しました。
米国人たちはこれを使ったソフトウェア開発で莫大な利益を得ているわけですね。

組み込まれた不安定：無茶な要求、2階にあげてはしごをはずす
自己組織化チーム：前知識を持たせない、どうやっていいかわからない状態にする
＊自立：自分たちで方針を決める、アイデアを大切に扱う、自分自身で決断できる
＊卓越したゴール：挑戦、インパクトあるミッション、違いを生み出す機会
＊相互交流：必要なスキルが全てある、お互いに学び合う
開発フェーズのオーバーラップ：速く柔軟な開発にフェーズは不要
マルチラーニング：重層学習、総合格闘家になる
最小限の管理：自己管理に任せる、相互監視社会の確立、社員は家族であり同志
組織間の学習：他のプロジェクトに波及させる

The New New Product Development Game - Ikujiro Nonaka

ハイパフォーマンスチームは幸福度が高い

幸せだと、どういう状態だと言えるのか。
自分が上手く能力を発揮している時、
自分の環境をコントロールできている時、
そんな状態なら、幸福度が高いと言えると思います。

幸福度が高いチームは、ベロシティが向上する。
幸福度が低いチームは、プロセスに問題がある。

幸福度を見える化する事でベロシティを向上させプロセスを改善できます。

  • あなたの役割は☆いくつ？
  • あなたのチームは☆いくつ？
  • あなたの会社は☆いくつ？
  • もっと良い感じになるには何があると良い？

スプリントレトロスペクティブで、やってみてもいいかと思います。

チームに提供するゴールの難易度

チームにスーパーエンジニアが集まっていれば、簡単なゴールでは満足できません。
チームにひよっこエンジニアが集まっていれば、複雑なゴールではクリアできません。

これは、ゴルディロックスの原理といいます。

人間は挑戦することが大好き、ただし簡単すぎず、複雑すぎない場合に限る。
そういう時に高いモチベーションをもって、その課題を解決する働きをします。
簡単すぎたり、複雑すぎたら、全然がんばれない。はあ、つまんない。

プロダクトオーナーの提供するゴールは、どのあたりを指し示すべきか。
適切なゴール設定のスプリントを繰り返すとチームが育っていきます。
そうするとより高い、それこそ卓越したゴールを目指せるようになります。

BimodalITを適用する

BimodalITとSoR（Systems of Record）SoE（Systems of Engagement）って聞いたことありますか？
これはGartnerが提唱している１つのアプリケーション内に２つのアーキテクチャを共存させる考え方です。
コンウェイの法則によるとアーキテクチャと組織は同じ形なので、守りと攻めでチームを分けてしまう事を意味します。

守りと攻めで、求められるスキルや品質や機能はまったくもって別です。
SoRは、ニーズを受けて開発する予測可能なアプリケーションを開発します。
SoEは、パートナーと協力して可能性を探る探求的なアプリケーションを開発します。

今、なかなか新しいユーザー体験が出てこない状況に見受けられますので、
このBimodalIT設計をチームに適用するというのは、一つ悪くない方法であると思います。

先程紹介しましたが「仕事で大切なのは責任か夢か」という記事も参考にできます。
予防焦点と促進焦点でグルーピングして、どういう違いがあるかを研究しています。
POにとって、どうしたらチームの力を発揮できるのかは興味深い内容だと思います。

仕事で大切なのは責任か夢か - 今城志保

Googleの完全自動テストがどのように作られていったのか

「テストから見えてくる グーグルのソフトウェア開発」を読んだ人います？
この中で以下のようなロールで、テストの文化を作っていったと記載されています。

☆Software Engineer（SWE）
これまでのエンジニアと同様に、顧客に提供するための製品のコードを書く役割。ドキュメント、データ構造、アーキテクチャなどもこの役割が担当する。と同時に、品質の責任も負う。
☆Software Engineer in Test（SET）
テストのしやすさ（Testability）にフォーカスした役割。デザインレビューをし、品質やリスクをチェック。コードをテストしやすいようにリファクタリングする。ユニットテストや、テストフレームワーク、自動テストも書く。
☆Test Engineer（TE）
TEはSETとは逆の立場で、テストが最優先、開発は2番目と考える役割。ユーザーとして振る舞い、利用シナリオを考え、自動テストのスクリプトを書く。SWEやSETのテストへの取り組みを促進するようにし、結果を分かりやすく伝える。

エンジニアがテストについて学ぶことでSETになる、QAがエンジニアリングを学ぶことでTEになる。
今回のプロジェクトで、SETやTEのようなロールも演じれるようになると、素晴らしいと思います！！