アジャイルサムライをスクラム初心者が読んだので要点をまとめた
対象書籍
はじめに
私の状態を一度整理します
元バックエンドで今期からフロントエンド
アジャイル開発初挑戦
DEVメンバーとして参画
この書籍では下記言葉は同一だと考えてください
読んだきっかけ
アジャイル開発の成功確率を向上させるために
定番となるこの書籍を読み、見返せるようにまとめたいと思います
内容
DEVチームとしての大事な視点
大きな問題は小さくする
本当に大事なことに集中して、それ以外のことは忘れる
ちゃんと動くソフトウェアを届ける
フィードバックを求める
必要とあらば進路を変える
成果責任を果たす
※誰もがこの働き方を気にいるわけじゃない（私は好きでした）
３つの真実
プロジェクトの開始時点にすべての要求を集めることはできない
集めたところで要求はどれも必ずといっていいほど変わる
やるべきことはいつだって、与えられた時間と資金よりも多い
アジャイル開発の原則
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
最良のアーキテクチャ・要求・設計は自己組織的なチームから生み出されます。
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します
成果責任と権限移譲
職能横断型チーム
チームメンバーを探すコツ
ゼネラリスト
曖昧な状況に抵抗がない人
これもちょっと難しい
我を張らないチームプレイヤー
なんでもやりたがりなメンバー
誰もが我を張らないと難しい？？
インセプションデッキを作成する
我われはなぜここにいるのか？
エレベータピッチを作る
パッケージデザインを作る
やらないことリストを作る
ご近所さんを探せ
解決案を描く
夜も眠れなくなるような問題はなんだろう？
期間を見極める
何を諦めるのかをはっきりさせる
何がどれだけ必要なのか
荒ぶる四天王
時間
スケジュールは圧縮される
予算
予算は削減される
品質
バグのリストは長くなる
スコープ
やるべきことは際限なく湧き出てくる
文書化の難しさ
ソフトウェアへの要求を表現する手段として文章に頼りすぎる弊害
変化に対処できない
顧客の欲しいものに合わせるのではなく、仕様に合わせて作ることになる
下手な推測や誤った前提を招き寄せる
多くの時間を無駄にする
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすること
見積もり技法
三角測量
代表的なストーリーをいくつか基準として選出して、残りのストーリを基準になるストーリーとの相対サイズで見積もる
プランニングポーカー
ベロシティについて
チームがユーザーストーリーを動くソフトウェアに変換する速度
振り返りについて
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整する
うまくやれたことは？
どうすればもっとうまくやれるか？
デイリースタンドアップで実施すること
昨日やったこと
昨日、世界をどう変えたのか
今日やること
今日は何をぶちかますつもりか
チームの開発速度を下げてしまうことがあればなんでも（困ったこと）
不運にも自分のいく手を阻んでしまったばかりに、あえなく吹き飛ばされる定めとなった難問がどんな末路をたどるのか
アジャイルなソフトウェアエンジニアリングのプラクティス
アジャイルソフトウェア開発宣言
プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、
まとめ
これからイテレーションが始まっていくので
このインプットを参考に変化に適応していこうと思います。
ウォーターフォールと何が違うのか今から楽しみです！
この記事が気に入ったらサポートをしてみませんか？