西村直人のレビュー一覧
-
Posted by ブクログ
特に、プロダクトオーナーとスクラムマスターを兼任するのは絶対にダメだ。プロダクトオーナーは作るものをより良くすることに注力しないといけないので、開発チームに、もっとたくさん作ってほしいとかもっと作りこんでほしいというプレッシャーを無意識のうちにかけてしまうかもしれない。一方で、スクラムマスターは円滑に仕事を進めていきたいので、開発チームが無理している状態を見過ごすわけにはいかない。無理をしている状態が続けば、長期的にうまくいかなくなってしまうからだ。
■完成の定義の一例
・デモ手順の通りに動作する
・publicメソッドのテストコードがある
・調査した内容はWikiにまとめてある
・最新の仕様がWikiにまとめてある
・リポジトリからいつでも最新のデモ可能でテスト済みのソフトウェアが取得できる
スクラムチームを常に良い状態にしておくのがスクラムマスターの役目だ。スクラムチームを観察して、どこがうまくいっていないかを見つけよう。扱いにくいコードの場合でも、どこかに予兆はあったはずだ。
たとえば、その予兆は書いたコードからもわかる。どうみても良いコードではないのに誰も話題にしていないとか、ほかにも、開発チームが残業続きなのにスプリントプランニングでさらに多くの項目をやろうとしていることかもそうだ。こうしたことを見逃さないように工夫をしてみよう。実際、何時まで開発作業をしているかとか、テストコードが増えているかを測る仕組みを自動化しているスクラムチームもあるんだ。こういう仕組みはスクラムマスターが率先して準備しよう。良くない状態の開発チームは、こういうことに割く時間さえ作れないかもしれないからだ。
■リリーススプリント
…スクラムを始めたばかりのスクラムチームが採用することが多い。これは通常のスプリントが終わったあとに、リリースに必要な作業を片づけるための時間を最後にまとめて取るやり方だ。通常のスプリントとは違って、その期間のことをリリーススプリントと呼んでいるだけで、やり方はとくに決まっていない。スクラムイベントも必要なければやらなくていい。
スクラムで大人数による開発はできるのだろうか？作るものの規模が大きければ開発する人の数も多くしたくなるだろうが、スクラムでは開発チームの人数は３～９人の少人数が適切とされている。
■ボクくんがスクラムのプロジェクトを通じて気づいたこと
・ロールは単なる目印
・開発を進めるうえで大切だと思うことは何でも話し合っておく
・スクラムチーム全員がプロダクトバックログについて知っておく
・見積りは推測
・自分たちの作業は自分たちで見積もる
・ベロシティがわかれば、先の見通しが見えてくる
・スプリントプランニングでは確実に終わらせられる計画を作る
・スプリントゴールを守るために毎日検査する
・問題になる前に見つけて対応する
・完成の定義は、スクラムチームで合意する
・タイムボックスに入るようにしていくのが重要
・プロダクトバックログの順序は常に見直しておく
・自分たちの責務について理解しないとうまくいかない
・ベロシティはあくまで目安
・ロールで担当する部分を分けているので、どこに問題があるかわかる
・頻繁に話し合って伝えていくのが一番大事
・スクラムマスターがスクラムチームを良い状態に保つ
・障害に順序をつけてどれを優先的に解決するかを明らかにしておく
・スクラムチームの進む先をいつも明確にするために整理し続ける
・スプリントの準備は開発をうまく進めるうえで不可欠
・実現方法を工夫するのはスクラムチームにとってやりやすい調整の仕方
・全員でさまざまな状況を克服できるようにしておく
・責任を持って取り組んでいくのが大事
・なんでもリリーススプリントに回すのは良くないこと
・スクラムは体験して学んでいくための仕組み -
-
-
-
-
-
-
-
Posted by ブクログ
2023/5/14
■インセプションデッキの10の設問
1.我われはなぜここにいるのか?
何のために自分たちはチームを組むのか。自分たちの顧客は誰なのか。そもそもこのプロジェクトが始まった理由は何なのか。こうしたことを再確認する。
2.エレベーターピッチを作る
30秒以内に2センテンスでプロジェクトをアピールするとしたら、何を伝えるべきだろうか?
3.パッケージデザインを作る
何気なくめくった雑誌のページに、自分たちのプロダクトやサービスの広告が載っているとしたら、それはどんな内容がいいだろうか?それからもっと大事なのは、その広告を見た人は君のプロダクトを買いたくなるだろうか?
4.やらないことリストを作る
プロジェクトで実現したいことというのはかなり明確になっているものだ。それと同じかそれ以上に、やらないこともはっきりさせよう。そしてそれをわかりやすく一覧にするんだ。
5.「ご近所さん」 を探せ
「プロジェクトの関係者」に含まれる範囲というものは、自分たちが思っているよりもずっと広いものだ。そうした「ご近所さん」を招いて、コーヒーでもごちそうしながら自己紹介ぐらいしてもいいんじゃないだろうか。
6.解決案を描く
チーム全員の認識が揃っていることを確認するために、概要レベルのアーキテクチャ設計図を描こう。
7.夜も眠れなくなるような問題は何だろう?
プロジェクトで起きる問題のなかには、考えることすら恐ろしいものだってある。だが、あえてそうした心配事について話し合おう。どうすれば最悪の事態を避けられるだろうか?被害を最小限に食い止める方法はあるだろうか?
8.期間を見極める
どれぐらいの期間が必要なプロジェクトだろうか?3ヶ月? 半年?それとも9ヶ月?
9.何を諦めるのかをはっきりさせる
プロジェクトにはいくつか操作可能な要素がある。期間、スコープ、予算、それから品質。現時点で譲れない要素はどれだろう?譲ることになるのもやむを得ない要素はどれだろう?
10.何がどれだけ必要なのか
期間はどれぐらいかかりそうか?コストは?どんなチームならプロジェクトをやり遂げられるだろうか?
・作ろうとしているものは何なのか、それはなぜ必要なのか。
・このプロジェクトの魅力はどこにあるのか。
・プロジェクトで解決したい課題は何か。
・「ご近所さん」は誰なのか。
・解決策はどんな風になりそうか。
・向きあうことになりそうな課題とリスクは何か。
・プロジェクトの期間はどれぐらいの長さになりそうか。
・柔軟に対応すべきところはどこか。
・(期間や費用は) ざっくり何がどれだけ必要なのか。
＝＝＝
アジャイル開発のお勉強。
・ソフトウェア開発の３つの真実
1.プロジェクトの開始時点にすべての要求を集めることはできない
2.集めたところで、要求はどれも必ずといっていいほど変わる
3.やるべきことはいつだって、与えられた時間と資金よりも多い
・アジャイルプロジェクトの3つの特徴
1.役割分担がはっきりと分かれていない
2.分析、設計、実装、テストといった開発工程がどれも、途切れることなく続く連続的な取り組みになる
3.チームが一丸となって成果責任を果たす
・インセプションデッキの課題一覧
1.我われはなぜここにいるのか？
2.エレベーターピッチを作る
3.パッケージデザインを作る
4.やらないことリストを作る
5.「ご近所さん」を探せ
6.解決案を描く
7.夜も眠れなくなるような問題は何だろう？
8.期間を見極める
9.何を諦めるのかをはっきりさせる
10.何がどれだけ必要なのか
・荒ぶる四天王
・スケジュールは圧縮される
・予算は削減される
・バグのリストは長くなる
・やるべきことは際限なく湧き出てくる
・文書化の難しさ
実際のソフトウェアプロジェクトで、重厚な文書化が要求を捉える手段として本当にうまく機能したことなんて一度もない。顧客は自分たちの欲しいものを手に入れることはほとんどなく、開発チームは求められたものを構築しきれない。
・ユーザーストーリーVS要件定義書と仕様書
無駄がない、正確、必要な分を必要なときに vs 重厚、不正確、最新じゃない
対面でのコミュニケーションを促す vs 憶測や誤った前提を招き寄せる
計画がシンプルになる vs 計画が複雑になる
低コスト、素早い、手軽 vs コストがかさむ、遅い、手間がかかる
最新の情報が反映されている vs 情報が古くなったまま放置される
チームが学習するということを踏まえている vs チームが学習するということを考慮しない
フィードバックを即時反映できる vs フィードバックを即時反映できない
見積り精度の高低を当てにしない vs さも見積り精度が高いかのように取り繕う
チームの協調作業や新しい取り組みを歓迎する vs オープンな協調作業や新しい取り組みを歓迎しない
・アジャイルソフトウェア開発の12の原則
1.顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2.要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
3.動くソフトウェアを、2-3週間から2-3ヶ月という、できるだけ短い時間間隔でリリースします。
4.ビジネス側の人と開発者は、プロジェクトを通して、日々一緒に働かなければなりません。
5.意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6.情報を伝えるもっとも効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることです。
7.動くソフトウェアこそが進捗の最も重要な尺度です。
8.アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
9.技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10.シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11.最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。 -
-