レゴスクラムに参加してきました
良い体験をしてきたので、まとめます。
経緯
スクラムを初めて実践することになった私は、実践事例を聞いてみたり、本を読んでみたりして計画を立てようとしたのですが、具体的な作業イメージが出来ず不安な状態にありました。
そんなときに偶然DoorKeeperのレコメンドに表示されたこのイベントの内容や参加者のブログを見て、具体的な作業をイメージできるようになれそうだと思い参加することにしました。
参加した感想
プロダクトが出来るにつれて、チームの成長も感じられて、複雑な問題が単純な問題に近づく感じを体験できました。スプリントを繰り返す度に担当タスクに各自のアプローチ、複数人なら分業して取り組んでいてとても楽しかったです。
何回かスプリントを繰り返すとプロダクトの形が見えてくるので、ユーザーストーリーの優先順位が変わって新しいプロダクトバックログアイテムが現れても、どう実現すればいいのかイメージができるようになりました。
スクラムの楽しい体験を通して、アジャイル実践手法をどう活用していくべきか、今後の指針を得ました。
フレームワークに「はめる」のではなく、「活用する」という考え方に変えられたのはよかったです。
具体的に良かった・学んだ事
- アジャイル（概念）とスクラム（実践）の違いを理解できた。（アジャイルとは傘である）
- 単純（Simple）な問題が次々に投入されるチームにはカンバンを利用が効果的である、ということを知った。
- カンバン / タスクボード をスクラムで利用すると効果的であるが、もともとは独立したタスク整理手法である、ということを知った。
- 日常の仕事は分解すれば事前にゴールを計画できる Complicated な問題が実は多い、ということを知った。
- Complex な問題はどこから取り組めば良いか分からず、ゴールを事前に計画できないので進捗率が意味をなさない問題を指す、という意味が分かった。（The Stacey Graph）
- スクラムを適用すると効果が上がる条件を明確に出来た。（Complicated と Complex）
- スクラムに限らずアジャイルで使われる実践手法は 、プロジェクトに一貫して適用するというよりも構成する仕事に適用するものだと、考え方を見直せたこと。（スクラムに当てはめるのではなく、スクラムを仕事の一部に組み込む）
- 野菜を切って、そばと炒めて、盛り付ける－といった直線的に計画を立てる癖が身に付いているため、食べたら感想をフィードバックして次の焼きそばを作る－というループする癖をつけることが大切。（Inspect and Adapt で「最高に美味しい焼きそばの作り方」を考える）
- 複雑なソフトウェアは小さいモノから作る。（焼きそばとソフトウェアは違う）
- 技術的な役割は当然のように全うしながら、チームの知恵や経験も少しずつ作り込んでいく。（Management の役割）
- 不安定な状態を作り、自律、成長、交流といった自己組織化を促す。（指示をせずにチームをどう作るか）
- 作る対象が Complex ならば、作る人もそれに応じて変わる。（コンウェイの法則）
- スクラムマスターはどのように作るかの責任者。テックリードのロールだが、指示は避ける。
- プロダクトオーナーは何を作るかの責任者。スクラムチームとステークホルダーの両者に目を向ける。プロダクトバックログでチームに意向を示す。
- 価値は顧客が決める。頑張って良いものを作っても仕方ない。だからフィードバックを早く貰うことが大事。（Customer Definition Value）
- 自動車業界のチーフエンジニアのように What と How 両方を出来る人は少ない。だからプロダクトオーナーとスクラムマスターがいる（プロダクトとプロセスの境界）
- 見える化（Transparency 作って貰うが指示をしない秘訣）
- スクラムマスターがメンバーの成長を願い意図的に指示するなどマネジメントをすることも時には（状況によっては）必要。（最終的にチームが自律すればいい）
- プロダクトオーナーには圧倒的当事者意識が必要。
- 収支にも責任を持つ。（ただし一つの受託開発型で組むスクラムは少し違うと思う）
- パートナーとスクラムを組むときはそれぞれの想いのすりあわせが大切。
- 大規模で計画が難しいからアジャイルをするのは違うのでは？（本当は Complecated なだけかもしれない）
- 新製品開発など反復的に開発が出来、もし上手くいかなければ中断する判断も出来るプロジェクトには、アジャイルが良く合う。
- プロダクトバックログの表現にはユーザーストーリーが多いが、実はユースケースシナリオ、仕様書、何でも良い。
- ユーザーストーリーは、3行で書くといい。（1行目：属性、ペルソナ、2行目：欲しいもの、3行目：理由）
- 必要なことを理由にしないこと。開発者のやる気が下がる。（ユーザーストーリー）
- ユーザーストーリーの見積は相対値で並べる。（プランニングポーカー）
- 1スプリントで対応可能な見積予測値を立てて、優先順位の高いプロダクトバックログアイテムを取り出す。（スプリント計画／スプリントレビュー）
- 初めてのスクラムでは、1スプリント目は代替失敗することが分かった。（予測値通りには行かないからレビューとレトロで見直す）
- プロダクトバックログをタスク化したらカンバンに張り出す。（スプリント計画）
- 見積もりできない、困ったときはプロダクトオーナーを呼びつける。大抵のプロダクトオーナーは他のタスクで忙しいので。
- 自分が何をやるかは自分で決める。（サインアップ）
- スプリントバックログの作り方は、プロダクトのタスクを分解すること。
- 見える化、流れの管理、WIP制限（カンバン3原則）
- Development のタスクが Test に移れないのなら、早くタスクを流す為に みんなで Test のタスクを手伝う等、どうすべきか考えることが大事。（流れの管理）
- 一度に取りかかれる数は決まっている。その中でタスクをこなす方法を考えることが大事。（WIP制限）
- テストコードの量は開発者が自信を持って納品できる量。
- メンバー評価をチーム評価にすると、手を抜く人が出るかも知れないので注意。
- 納期が決まっている（ゴールまでのやるべき事が決まっている）場合に、スクラムを取り入れるのは、やるべき事が終わらない可能性があるので注意する。
- スクラムの基本はスコープを分けること。
- 「こんな出来のモノを見せて良いのかな？」と思っても大抵は問題ないので、見せてフィードバックを得ること。
- スクラムは、プロセス（人）の成長とプロダクトの成長の相互作用で成り立つ。（スクラムを体験して、なるほどなと思った）
- DB設計など後回しにしたことで惨事に至るタスクは先に済ませるべき。（Railsを進められた。何でだろう？）
- 共通ライブラリなど、必要になったときに作ればいい。
- アジャイルをやったからといって納期は早まらない。早まるときはスコープを絞ったときだ。（そりゃそうだ）
- ウォーターフォールだからといって品質があがるとは限らない。品質の上げ方は取り組み方に依存する。アジャイルに開発しても同じ。アジャイルだからといって設計書を作らない訳でもないのだ。フレームワークにはめようとせず、その利用目的を考えよう。
- スプリントレビューではプロダクトオーナーがプロダクトバックログアイテムを読み上げる。作った人はそのデモを通してプロダクトオーナーからフィードバックしてもらう。受け入れなら実績にその見積値を記録し、継続なら実績は０とする。
- こなれた付箋の千切り方を学べたこと。（笑）
解消できた悩み
- スプリント計画のやり方は？
- プロダクトバックログアイテムの書き方は？
- 見積ってどうやるの？（見積ってプロダクトバックログに対してするんだ）
- DBを設計するタイミングはいつ？
- 共通ライブラリを準備するタイミングは？
- プロジェクト収支を管理する人は誰？
- アジャイル＝早いって本当なのかな？
- プロダクトオーナーって誰がなるといいの？
- アジャイルの本質は、チームビルディングって本当？
- スクラムをやる目的って何だっけ？
