とあるSEの適当日記(仮)

その時のプロジェクトで必要になって調べた技術や読んだ書籍についてメモしていく場です。誰かの役にたったらいいなくらいのものです。最近の関心事は、「スクラム」「アジャイル」です。

「スクラム現場ガイド」を3分の1くらいまで読みました。

ども、ひぐちぇです(゜д゜)ノ

最近、ずっと、↓「スクラム現場ガイド」という本を読んでおりまして、今、3分の1くらいまで読み終えたとこです。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

これ、超良書ですよ!いままでで1番ではないかくらい!

30のChapterから成り立っていて、それぞれで具体的なショートストーリー(良い例も悪い例もある)で話題を進め、その後で具体的な解説が書かれています。
物語的や会話で書かれている書籍って読み難いものが多いのですが、これは1ストーリーが短いこともあり、割と読み易いです。

各内容もよくありがちな内容で、とても参考になるものばかりです。

Chapter 1:スクラム:シンプルだが簡単ではない

スプリントという単位で仕事してはいるが、結局、やっていることはウォーターホールと変わらないという話でした。実は、私のプロジェクトでも昔はこんなやり方をしてしまってました。。。ほんと反省。。
この本にもっと早くに出会っていたらなーっと思いましたよ^^;

Chapter 2:仲間と共に旅立つには

新しいスクラムというやり方を導入する際には、周りの人間を納得させ、巻き込んでスタート位置に立たせなければならず、これがとても大変ですよね。って話。

Chapter 3:チームコンサルタントでチームの生産性を最適化する

メインの業務を進めるコアチームとは別に、どのチームにも属さない「傭兵」のような部隊であるチームコンサルタントを立ち上げることで、コアチームの足りないスキルを補間するという話
こういうチームがあるととても助かりますね。。私のチームでは足りないスキルについては一時的に先輩社員の助けを借りてなんとかこなしているのですが、その先輩も別の仕事を抱えている状態なので、いつも聞ける状態というわけではありませんからね。

Chapter 4:ベロシティの測定

見積もりのやり方として、「①過去のデータを使う(同一チームもしくは他チーム)」「②わからないなりに見積もる(憶測する)」「③様子をみる(あとで伝える)」の3つが考えられ、それぞれの利点・欠点をあげており、③こそが最も成功するためには一番良い選択肢であるという事を示す話です。ウォーターフォールなどの見積もりでは①で行われることが多いですよね。スクラムでは③で行われるのがいいんですよね。

Chapter 5:スクラムの役割

役割を兼任して、それをいいことに勝手な事やってメンバーからの信頼を失う。みたいな話。
流石にあんな事はやらないかな。。私のとこのプロジェクトでは、スクラムマスターとメンバーを兼任してる方が1名いますが、スクラムマスターの仕事を優先してもらっており、事実上でメンバーの仕事はほとんど出来てないという状態ですね。私は、「できたらメンバーの仕事もして欲しいですけども、それでも良いです」と言ってます。

Chapter 6:スプリントの長さを決める

スプリントの長さを決定するためのやり方を示しています。我々のチームでは1週間スプリントでやっていますが、はじめのうちは上手く成果があがらず、ストレスを貯めていました。本文でも書かれてましたが慣れていないうちは、2週間とかでやって、慣れてきてから1週間スプリントにしていく方が良さそうです。

Chapter 7:完成を知る

誰に対しても明確な完成の定義をしようという話。
その完成の定義を出し方、整理の仕方、決め方が書かれており、それにより、どこまでが終わっているのかが明確になるという話でした。

Chapter 8:専任スクラムマスターの利点

専任のスクラムマスターを立てるというと、上司からは難色を示されるが、実際、スクラムマスター専任の人が1人いた方がチーム全体としてのパフォーマンスは上がる。という話をグラフで表していました。

Chapter 9:エンジニアリングプラクティスのスクラムにおける重要性

本当にパフォーマンスを出せるチームになるにはエンジニアプラクティスは欠かせないという話です。

私のプロジェクトでは、「テスト駆動開発」や「ペアプログラミング」について、推奨はしていて、やってはいるもののあまり効果として実になってない印象で、私も含めてでしょうが、「どういうときにどんな風にやっていく」というのがしっかり理解してないせいではないかと感じています。これをなんとか強化していきたいという思いがありますね。
もう1つ、「統合と自動化された受入テスト」について、まとめて一括で自動単体テストをやる仕組みはできているのですが、画面遷移のようなテストを自動てきにやれる仕組みはまだできていなくて、それを課題としています。今、別のところで仕組みを考案中のようです。

Chapter 10:チームのコアタイム

メンバーごとに出勤、退勤など仕事をするリズムがバラバラであり、それも当然の事なので、スクラムマスター主導でチームとして集まれる現実的な時間を全員の同意で決めてルール化しておこうという話です。
出退勤の時間以外にもこういったメンバー間の常識の不一致みたいなものはよくありますよね。例えば、「メンバーから頻繁に質問が飛んでくるため自分の仕事に集中できない」とか、「周りがうるさくて集中できない」とか、、こういったときにもメンバー内で話あって、「質問していい時間、悪い時間を決める。」とか、「周りがうるさくて集中できないなら、質問して悪い時間だけはヘッドホンして音楽を聞いていてもOK」とか決めていくのがいいかなって思うのです。


以上、とりあえず、Chapter 1~10までを読んだ感想でしたっと( ˙꒳​˙ )

プライバシーポリシー お問い合わせ