スクラムガイド2016を読んでみました 2
実際に何するの?
前回は、大体の登場人物を把握したので、日々何をすべきかってのを纏めてみる。
スクラムを全然知らない人がスクラムガイドをよんでこうだろうなぁって思った内容なので、 間違いがあるかと思いますが、ご了承くださいませ。
まずプロジェクト始まった時にするところから
- PO(お客さんとプロジェクトリーダー)が必要な機能や仕様を洗い出して、何かに登録する。細かく。
- POがその工数を見積もる。その後、メンバーで工数を見積もる。
- ざっくりみんなでガント化する。
- チーム内で、毎日する事、手順、単語、成果物に対する考えとかを共有する。
- スクラムとウォーターフォールの違いを説明する。
一発受注で「ハイ作って」契約だと、こんな感じでやるのが良いのかなと思いました(ので投稿してるときにやってみてます。)
簡単そうですが
ウォーターフォールとか、普通の学生 -> サラリーマンの流れの人の場合、
- 指示を受けてしか作業を出来ない。
- 指示を受けたことの作業しかしない。
の人が多いため、「メンバーで工数を見積もる」すらまともにできませんでした。最初。 なので、こんな感じにしました。
- 最初はこっちで見積もりとガントを作ってしまいます。
- そのあと、見てもらって大丈夫そうか返答をもらいます。
- 1時間毎に目標を立てて、50分間作業、10分振り返り(何で遅れたか or はやかったか)。
- 次に活かそうね!
後で出てくる「スプリント」を決める際の特訓にもなりますね。
あとは、指示待ちが多いので、「なんか詰まってない?」、「それをどうしたいの?」という方向で聞く。 意思を聞く。
多分、はじめは返事が返ってこないと思うし、向こうにお前が決めるもんだろうってイライラされると思うけど、聞く。 仕様については教えるけど、実装方法については自主性を付けてもらわないと困る、だからしかたない。
煙たがられてもいい
そのうち、自分が選択した方法で進めるという事に意味を感じてもらえると思う。
定例を決めて行こう
- スプリントという単位をチームで決める。(ソフト開発なら1週~2週?)
- そのスプリントでどこまでを実装するかをメンバーが決める(POは妥当性だけを確認すればいいかと)
- スプリントが終わったら、コミットできたこと、出来なかったことをみんなで出して、何でそうなったか、対策はあるか?とかを話し合う。
- 次のスプリントのコミットを考える。
簡単そうですが、これがまた思っているようにできない
その週にどこまでを実装できるかを決める。
困りポイント
- 希望でしかない
- 残業前提である
どうしてもガントを守ろうという流れになるので、阻止したい。 最初の見積もり時にこのスケジュールで定時でOKってしたはずなので、19時には帰る流れで出してもらう。
多分、これが現実的にはメンバーからこの条件で出してもらうの難しい(嫌がる)し、昔ながらの上長には怒られると思う。
なもんで、上長には遅れたらスケジュールを延ばせるてもらうとか、そういう手はずをプロジェクト始まる時点で整えておく必要があるかと思います。 自分だけで裏でこっそり球を持っててもいいです。延ばせるようにしておく。
もしくは、即座に後れをキャッチして報告する。今後の見通し込みで。今後このように遅れるので、調整をしてくださいと。
まぁ、頭の固い人相手だと、苦労しますが、出来ないものはできないし、そもそも後でおんなじような報告しないといけないんだし、先にしておいたほうが楽ですよね。多分・・・。
振り返り
困りまポイント
- そもそもの、原因を追究しないで話が終わってしまう。
- 一方的な報告だけになって意味が無い。
そもそもの、原因を追究しないで話が終わってしまう。
前者は、取りあえず「何に」かを追求するしかない。(何で?だとただの知識不足って事になってしまう)
- その詰まりは、俺もしたよ。
- おれ、そのライブラリ作ったけど・・・。まだpushはしてないけどな!
見ないな話が出たりするようになります。きっと。 この時も、その人が「遅れを責められている」みたいに感じるみたいです。
自分でやるっていった範囲が出来なかったので、そう思うのはしかたないですね。 次のスプリントの際に「自分でやるっていった範囲」が身の丈に合う様にセットしてもらうしかないです。それのせいで遅れが出るとしても。
他の人に、「進んでいたらキャッチアップして助けてあげて」と声をかけましょう。 まぁ、最初はいい顔はあまりしませんがw
一方的な報告だけになって意味が無い。
最初に、みんなにやりたい報告に仕方を言いましょう。 そして、意見を聞く時に個人あてで振ってみましょう。 たぶん、うまくいかないですが orz
振っても意見が出ない時に、俺はこう思うんだけど、どうです?って聞くといいかも。
これらの困りポイントが出る原因が
「リーダーから指示がきて、それをやる」 という、命令系統ができてるって認識があるから起きるんだと思います。
フラットにやるんだよ。って伝えるの難しい。
スクラムの運用の手順は
やる内容は簡単なんです。 その中身のクオリティをあげるのが難しいというか、 形骸化してしまっている内容を、しっかりとした目的をもってやるというのが大事。
その為には、
個々にチームの一人であるという認識を持ってもらう必要がある
と思いました。実践してみて。
「集まり」ではなく「チーム」。
次は、もう少し大きいスパンでの振り返りと、まとめとか