スクラム入門
スクラムの意味にはいろいろある。英語のスペルを見るとscramとscrumの２つがある。
scramは原子炉緊急停止のこと。
scrumは
など色々な意味があるので、会話の場や文脈に注意。
さて、本題は「ソフトウェア開発手法」としてのスクラムなのだが、有益な情報源がすでにあるので読んでまとめてみた。
参考情報
下記の記事がすぐ読めて分かりやすくてよい。
アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。
引用元：
開発チームを改善するためのスクラムTips（8）：5分で分かる、「スクラム」の基本まとめ (1/2) - ＠IT
読んでみての感想・まとめ
実は必要に迫られて同じようなことを既にやっていたりする。スクラムの良い点は、やっていることややり方、登場する概念などに名前をつけてノウハウとしてまとめられていることだ。また、チームで共有すべき状況を他のメンバーに見えるよう工夫している点も特徴と思う。これにより、チームでの仕事の仕方をより大きな組織内で共有できたりもしないだろうかと期待したりする。
用語整理
- プロダクト・バックログ・・・機能や技術改善要素を優先度付きで書いたもの。思い出しやすいよう、誰（ユーザー）あるいは何のためにそれを実現するのか記述する。仕様変更が生じたときに影響を分析するのにも用いる。
- スプリント・バックログ・・・プロダクト・バックログからスプリント期間（１〜４週間）の分を抜き出したチームのタスクリスト。１つのスプリントはチームとして期間内に作業完了できると宣言できるものとする。
- タスクボード・・・バックログの状況を短時間で共有するためのもの。ふせん紙に書いたバックログを壁面上の ToDo (未着手), InProgress (作業中), InReview (レビュー中), Done (完了) の各領域に貼り付けたもの。
- デイリー・スクラム（朝会）・・・昨日やったこと、今日やること、障害を15分程度で話し、タスクボードを最新化する。個々の詳細には触れず、共有するだけにとどめ、必要なら別途場を設ける。
- チーム主体・・・リーダーやマネージャに責任・管理が集中するのではなく、合議制でセルフマネジメントしていく。3〜10人で1チームが推奨される規模。一人1分話してもデイリー・スクラムの中に収まる。
- プロダクト・オーナー・・・プロダクト・バックログの作成と優先順位付けと意思決定の最終責任を負う。
- スクラム・マスター・・・チームを健全に保つメンター。すなわち、うまくいっているか、困っていることはないか、確認し、チームの集中を保つ。
- 権限委譲あるいはサーバント・リーダーシップ・・・リーダーというチームを引っ張る単一責任者はいない。権限はメンバーに委譲される。それにより自ら進んで考え、責任を持って行動するメンバーによって自律的なチームが構成される。
スクラムの価値
スクラムをしていく中で、これら上記のような状況に気付き、課題を発見し、自ら定義するきっかけとなることにスクラムの価値がある。
もしあなたの属する組織をサーバント・リーダーシップ型のマネジメントに変えるなら、まずチーム自身が実績を上げ、信頼を高めていく必要があります。
また、情報共有の方法を変えたり、部署間の仕事の受け渡し方法を改善するなど、多くの努力と時間がかかる可能性もあります。しかし、誰かが始めなければいつまでたっても改善しない、ということも事実です。1つ1つ相談し、できるところから解決していきましょう。
５分じゃ終わらなかった。。。
8/18（月）21:15-22:20
