永瀬美穂のレビュー一覧

スクラム開発の全体像を実践を意識して把握できるのでありがたいが、漫画のほうに（あえて描かなくてもいいはずの）残業描写が多いのが気になる

一緒に作業をしつつコーチングをして社内政治にも負けず、環境ができたら立ち去る。これを社内の一メンバーが逆境の中で達成できるとは思えない。
上記が難しく感じるのは、本書が立派なコーチになるための手段の説明を主に書いているからであり、個々のプロセスの目的や必要性の記述が薄いからだろう。
社内政治に勝つの...続きを読むではなく、一つ一つのプロセスの目的を説明した上でお互いにとって利益があることを確認しながら体制を変えていく必要があり、それに伴ってコーチも正当に評価される環境を目指す必要がある。

　特に、プロダクトオーナーとスクラムマスターを兼任するのは絶対にダメだ。プロダクトオーナーは作るものをより良くすることに注力しないといけないので、開発チームに、もっとたくさん作ってほしいとかもっと作りこんでほしいというプレッシャーを無意識のうちにかけてしまうかもしれない。一方で、スクラムマスターは円...続きを読む滑に仕事を進めていきたいので、開発チームが無理している状態を見過ごすわけにはいかない。無理をしている状態が続けば、長期的にうまくいかなくなってしまうからだ。

■完成の定義の一例
・デモ手順の通りに動作する
・publicメソッドのテストコードがある
・調査した内容はWikiにまとめてある
・最新の仕様がWikiにまとめてある
・リポジトリからいつでも最新のデモ可能でテスト済みのソフトウェアが取得できる

　スクラムチームを常に良い状態にしておくのがスクラムマスターの役目だ。スクラムチームを観察して、どこがうまくいっていないかを見つけよう。扱いにくいコードの場合でも、どこかに予兆はあったはずだ。
　たとえば、その予兆は書いたコードからもわかる。どうみても良いコードではないのに誰も話題にしていないとか、ほかにも、開発チームが残業続きなのにスプリントプランニングでさらに多くの項目をやろうとしていることかもそうだ。こうしたことを見逃さないように工夫をしてみよう。実際、何時まで開発作業をしているかとか、テストコードが増えているかを測る仕組みを自動化しているスクラムチームもあるんだ。こういう仕組みはスクラムマスターが率先して準備しよう。良くない状態の開発チームは、こういうことに割く時間さえ作れないかもしれないからだ。
　
■リリーススプリント
　…スクラムを始めたばかりのスクラムチームが採用することが多い。これは通常のスプリントが終わったあとに、リリースに必要な作業を片づけるための時間を最後にまとめて取るやり方だ。通常のスプリントとは違って、その期間のことをリリーススプリントと呼んでいるだけで、やり方はとくに決まっていない。スクラムイベントも必要なければやらなくていい。

　スクラムで大人数による開発はできるのだろうか？作るものの規模が大きければ開発する人の数も多くしたくなるだろうが、スクラムでは開発チームの人数は３～９人の少人数が適切とされている。


■ボクくんがスクラムのプロジェクトを通じて気づいたこと
・ロールは単なる目印
・開発を進めるうえで大切だと思うことは何でも話し合っておく
・スクラムチーム全員がプロダクトバックログについて知っておく
・見積りは推測
・自分たちの作業は自分たちで見積もる
・ベロシティがわかれば、先の見通しが見えてくる
・スプリントプランニングでは確実に終わらせられる計画を作る
・スプリントゴールを守るために毎日検査する
・問題になる前に見つけて対応する
・完成の定義は、スクラムチームで合意する
・タイムボックスに入るようにしていくのが重要
・プロダクトバックログの順序は常に見直しておく
・自分たちの責務について理解しないとうまくいかない
・ベロシティはあくまで目安
・ロールで担当する部分を分けているので、どこに問題があるかわかる
・頻繁に話し合って伝えていくのが一番大事
・スクラムマスターがスクラムチームを良い状態に保つ
・障害に順序をつけてどれを優先的に解決するかを明らかにしておく
・スクラムチームの進む先をいつも明確にするために整理し続ける
・スプリントの準備は開発をうまく進めるうえで不可欠
・実現方法を工夫するのはスクラムチームにとってやりやすい調整の仕方
・全員でさまざまな状況を克服できるようにしておく
・責任を持って取り組んでいくのが大事
・なんでもリリーススプリントに回すのは良くないこと
・スクラムは体験して学んでいくための仕組み

なぜか購入したまま放置していたのか、どこかから出てきた。
実践的という意味では非常によくまとまっている。もう少し早く読めば良かったか。

やや難解。日本語は不自然でないがすんなり入ってきにくい。また日を改めて読み直してみる。
“いまどき”の組織編成のあり方として明確な指針を示していると感じる。将来に通用するかは分からないが、いまはこれがベストだろう。
事前の知識を必要としていて解説が平易でないところも多いうえ、組織を編成する責任者とか...続きを読む所属チームを拡張する一端を担うような人でないと使いどころが無さそう。組織のビジョンをこの書籍で共有することは難しい。

アジャイル開発の考え方や運用のコツ、言葉などを一通り学習。未来はすべて決められないことを前提に、しなやかにゴールに到達するチーム運営として、とても参考になる考え方。目的ゴールにワクワクすることが大事、というのは不変。

コンウェイの法則を意識するのは分かった。
4つの最適なチームや3つのインタラクションモードがあることは分かった。
自分のチームがどんな状況で、どうしたら良いか、考えるために良い本だと思う。

漫画でアジャイル活動の説明がされており、初めてアジャイルに取り組む人が一般的な流れを理解するにはとても良い。

実際にスクラムを始めるときに起きそうな失敗談を交えて、漫画でイメージしやすく書いてあるのがよかった。初めてスクラム触れる人が軽く目を通すとイメージしやすい気がする。特にdevチームの人に読んでもらいたいかも。

みんなで学び合う文化を作る。
この本に早めに出会えればよかったなー、そうすると前職でもっと違う施策をとってだと思う。こういう文化を一から作り、改善が実感できていくのは楽しいだろうなー。

エースを作らず、皆で必要な無駄を取り入れて成長する
ペアプロ、デイリースタンドアップミーティングなどなど
二重投...続きを読む資が実は最短で低コスト、というマインドと自負を持つべきですね。

あと、ルールと計画に厳格なマネージャーではなく、恐怖によらない説明責任のもと、皆で改善して将来の計画を作っていこう、という雰囲気を作るチーム作りが大事と痛感。
これを肝に命じて、自分の仕事を見直していこう。だから、今の会社はマネージャーとは言わない。

　読み終わって、うちの会社と比べてみる。
　う～ん、このやり方は絶対楽しいけれども、うちの会社には合わないだろうなぁ。

　ソフトウェア開発会社なのに、二人一組で一つのパソコンを使い、
　オープンスペースのオフィスは、机をつなげればチームの増減に対応できる。
　タスクはすべて無駄なく管理されて、ちょ...続きを読むっとこれもやってよ、なんて仕事も発生しない。

　理想の働き方とは。