めも帖

「めも帖」代わりにダラダラと書いていったり、めもしたりしているだけです。

SCRUM BOOT CAMP THE BOOK

書評

読むきっかけ

アジャイル開発の本を何冊か読んでいます。 開発プロセスについて、どのようにして進めていけばいいのか？考えることが多いからなのかもしれません。 アジャイル開発に関する本の中で、なにやら実践的な本らしい、と知ったのが「SCRUM BOOT CAMP THE BOOK」です。

読んでみて

まず、読みやすい。そして、途中でマンガ？イラストが出てくるのですが、それがさらに読みやすく、わかりやすくしているように思います。 少し気になったのは、書籍ですから、仕方ないのですけれど、少し理想的な展開をすることになること。あと、もう少し人数の多いチームはどうしたらいいのか？ということです。開発+プロダクトマネージャー+デザイナーなど合わせて、10名以上になると、チームを分けることについても、知りたいと思いました。

ここ最近の話

開発プロセスのことを調べつつ、どうやって実践に持ち込んだらいいんだろう？と考えます。 でも、開発すること自体が、疎かになっているようにも思えて、どうやってバランスをとるべきなんだろう？ということも、読んでいて考えました。

読書メモ

鉄は鉄によってとがれ、人はその友によってとがれる

要求を並び替える

  • バックログ
  • 要求のリスト
    • 要求の優先順位を決められるのは、プロジェクトオーナーだけ
    • プロジェクトオーナー重要！

プロジェクトの責任者はだれ？

  • プロダクトオーナー
    • 結果責任
    • バックログの管理者
    • 並び替えの決定権限
    • プロダクトの価値を最大化
    • 開発チームに相談できるが、干渉はできない

開発チーム

  • 3〜9人
    • 10人開発スピードの低下
    • 部長などは、数に入れていない
    • 最大も気になるけれど、最低が3人というのも気になる。プロジェクトオーナー、作業者と、だれだ？
  • 自己組織化されたチーム

我々は、なぜここにいるのか？

  • プロジェクトの意味、存在

見通しは大切

  • 必要以上に時間をかけない

見積り

  • きちんと作業見積りしたものからの比較で、他の作業を見積もる
  • 適切な基準とは、作業内容がイメージでき、日数も予想がたつもの
  • 基準となる見積もりは、中ぐらいの項目がよい
    • 比較して決める見積もりを、相対見積り、と呼ぶ
  • 相対見積りは、見積りが不確実である、という前提にたつ
  • 相対見積りでは、フィボナッチ数を利用する。基準と比較して大きいものを扱うとき、どんどん大きな数字になる。見積りが不確実である、という事を教えてくれる
  • 見積りは、推測

自分達の作業は、自分達で見積もる

  • 見積りポーカーは、対話

ベロシティをプロジェクトが始まる前に知る方法

  • 過去のベロシティを参考にする
  • 試しに実際にやってみる

終わりの認識を揃える

  • デモ手順
  • 受け入れ基準
  • 完了の定義
  • デモ手順

完了の定義

  • 最新の仕様がwikiに乗ってる
  • テストコードがある
  • リポジトリから最新のデモ可能なソフトウェアが入手可能

全部、耳が痛い。wikiは、チケットと連動して書くようにしている。 テストコードはない（技術的な負債ばかり生んでいる気分に最近なっている）。 バージョン管理、リリース管理ががされていない現状。アジャイルプラクティスでも、「単純な技術的問題」と言われてしまうほどなのに、出来ていない

完了の定義は、チームで合意しないといけない

  • タイムボックスは譲れない
  • タイムボックスは、進捗状況の予測に使う
  • タイムボックスが変わっていたら、予測に使えない

プロダクトバックログ

  • 順番重要
  • 誰でも追加可能
    • 誰でも追加可能が当たり前だと思っていたけれど、現場ごとに違って驚いていたことを思い出した
    • 追加して、優先順位を決めるのはプロダクトオーナーだから、追加されていても、優先順位を下げたらいいだけ

ベロシティ

良いスクラムチームは、ベロシティが安定している 上がり続けても、よくはない

  • 上がらないかも？
  • 安定しない
  • ベロシティを上げるのは、簡単に小細工できる
    • プロジェクトの先が予測出来なくなる

人を増やしても、ベロシティは、すぐには上がらない

  • チームに慣れる
  • プロジェクトに慣れる

「人月の神話」ではないけれど、人を増やすということは慎重にしなくてはいけない 急激な人数の増加や、激しい人の出入りは、コミニュケーションロスを生みやすいし、チームと溶け合うまでに時間がかかるものだと思う

ベロシティをあげるには

  • 作業をやりやすく
    • より速いマシン
    • 割り込みを対策
  • 日々の工夫
    • 日々の工夫が最近足りていない
    • og確認用のツールを作ったけれど、まだまだ気になる点はあるので改良していこう

伝える

  • 開発の意図
  • ユーザーストーリー
    • Redmine のバックログのプラグインが、どうしてストーリーって書いてあるのか、最近になって分かってきた気がする
  • 実現したいことは、先に理解を深める
  • 決めるべき仕様を決める
  • 技術的に、どんな風に実現するか確認

スプリントの準備は、不可欠

準備が出来ていない場合は、スプリント計画ミーティングでも、取り扱わないぐらいに大切

まとめ？

スクラムは、体験して学んでいく仕組み

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK