├── LICENSE ├── README.md ├── daily_scrum.md ├── product_manager.md ├── rhythm.md ├── sprints_planning.md ├── theory_arming.md └── troubleshooting.md /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2015 Yoshitaka Kawashima 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | 23 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ["ふつうの受託開発"](http://www.slideshare.net/kawasima/ss-15118922)の運営マニュアルです。 2 | 3 | ## ふつうの受託開発とは 4 | 5 | 受託開発に向いていないと言われることの多いアジャイル開発ですが、うまくやればふつうにできます。 6 | 7 | - チームのサイズは、3～7名程度の想定です。 8 | - タスクの実行は必ずペアで行います。 9 | - これはペアプロを強制するのではなく、相談・品質チェック・完了チェックを必ずペアでおこなうための目的です。 10 | - 難易度の高いものや初モノは、ペアプロで取り組みます。 11 | - プロジェクトは[プロダクトマネージャ](./product_manager.md)とチーム(スクラムマスター含む)から構成されます。 12 | 13 | - [全体の計画](./sprints_planning.md)を立てます。 14 | - [手順](./rhythm.md)にしたがい、プロジェクトを進めます。 15 | - [うまくいかない場合](./troubleshooting.md) 16 | -------------------------------------------------------------------------------- /daily_scrum.md: -------------------------------------------------------------------------------- 1 | # 朝会 2 | 3 | 参加者: チームメンバ 4 | 5 | 1. 朝の挨拶をします　「おはようございます。」 6 | ＼ おはようございます ／ 7 | 1. 前回作業の進捗状況を報告する。 8 | 1. ストーリーが閉じられるかどうかを確認し、クローズする 9 | 1. ペア割りを決める。 10 | - 基本は2人、余る場合は3人ペアにする 11 | 1. タスクをペアに割り振る。 12 | - 2人ペアは5h、3人ペアは7.5h分割り振る 13 | 1. スプリントのTをふりかえる。 14 | 1. 修正済みチケットを持っている人と件数を確認する。 15 | 1. リスク一覧/課題一覧について以下を確認する 16 | - 期日 17 | - 進捗 18 | - 課題になるリスクはないか 19 | 1. 進捗エスカレーションを挙げるべきか判断する。 20 | - 黄色信号：スプリント期間の50%経過時 21 | - 赤信号：スプリント期間の80%経過時 22 | 1. イベントがあるか確認する。 23 | 1. 他に伝達事項があるかどうか確認する。 24 | 1. 朝会終了の挨拶をします　「今日も張り切ってまいりましょう。」 25 | ＼ よろしくお願いします ／ 26 | 27 | -------------------------------------------------------------------------------- /product_manager.md: -------------------------------------------------------------------------------- 1 | # プロダクトマネージャ 2 | 3 | ## 役割 4 | 5 | プロダクトオーナーは、プロダクトマネージャ+αの役割をもつといわれています。受託開発の場合、ステレオタイプなプロダクトオーナーの役割を受託側におくことが難しいので、あえてプロダクトマネージャと呼ぶことにします。 6 | 7 | 工程に区切られた内側でイテレーション開発をおこなうと、セーフティーリードが必要なので、スケジューリングしてみると、たいていの場合顧客との合意事項がある前に、ストーリーの実装をすすめなきゃいけないことになると思います。 8 | このとき、先行して作るものが無駄にならないよう、ホットスポットを見つけ出し、OCPの原則を保って設計しチームに実装させる役割がプロダクトマネージャです。 9 | 10 | 11 | -------------------------------------------------------------------------------- /rhythm.md: -------------------------------------------------------------------------------- 1 | # スプリントの運営 2 | 3 | 1スプリントのやりかたを定義します。 4 | 5 | ## 前提条件 6 | 7 | - バックログ/かんばんのツールとして、redmine_backlogsを使う前提です。 8 | - 登場人物はプロダクトマネージャ、チームメンバ(スクラムマスター含む)です。 9 | - gitでソースコード管理されている前提です。 10 | 11 | ## スプリントワークフロー 12 | 13 | 1. [スプリント計画ミーティング](#sprint-planning-meeting)を行います。 14 | 1. 今回のSprintでリリースするモジュールバージョンを明確にします。また、依存ライブラリ等でバージョン固定が必要なものがあれば洗い出し、固定依頼等を行います。 15 | 1. 必要に応じてSCM上でブランチを切ります。 16 | 1. [日々の作業](#daily-activities)を行います。 17 | 1. ストーリー開始時、必要に応じてフィーチャーブランチを切ります。 18 | 1. 作成したモジュールをマージし、バージョン固定/リリースを行います。 19 | 1. [スプリントレビュー](#sprint-review)を行います。 20 | 21 | ## スプリント計画ミーティング 22 | 23 | ### 事前準備 24 | 25 | 1. 前々回のスプリントをクローズします。 26 | 1. 新たなスプリントを作り、クローズできなかった前ストーリーを新スプリントに移動します。 27 | - ストーリはただ移動させるのではなく、実態を表すストーリとして作り直してください。 28 | - その過程に置いて、新しいストーリが発生することもあります。 29 | - Ex:残った確認タスクは【Sprint○○の確認】というストーリを作り、そこに移動させるとか。 30 | 31 | ### 第1部 32 | 33 | 参加者: プロダクトマネージャ、チームメンバ 34 | 35 | 1. 新スプリントの期限をオーナに聞き入力します。 36 | 1. スクラムマスターは今回のスプリントで実施するストーリーポイントを宣言します。基本的には前回スプリントの実績と同じにします。 37 | 1. プロダクトマネージャはバックログからストーリーを選択し、スプリントバックログに入れます。 38 | 1. バックログで見積もりされていないストーリーがあればストーリーポイントの見積もりをします。 39 | 1. プランニングポーカーカードを用意します。(最低限 0.5,1,2,3,5,8,13 のポイント分用意してください) 40 | 1. スクラムマスターは基準ストーリーを決めます。(ストーリーポイント=5 くらいのものがよい) 41 | 1. プロダクトマネージャがストーリーの説明をします。実装のイメージをチームメンバがハッキリと持てるまで討論してください。 42 | 1. スクラムマスターの「せーの」の掛け声で、チームメンバは基準ストーリーと比較したストーリーポイントのカードを出します。 43 | 1. バラついた場合は、一番大きい人、小さい人の意見を聞き、再度出しなおします。 44 | - バラつきが少ない場合は、スクラムマスターのひと声で決めちゃってもよいです。 45 | 1. 大体みんなの見積もりが揃ったらバックログにストーリーポイントを記入します。 46 | 1. おつかれさまでした。 47 | 48 | ### 第2部 49 | 50 | 参加者: チームメンバ 51 | 52 | 1. 各ストーリ毎の責任者を決めます。 53 | 1. 各ストーリ毎に、仕様とチェックリストをあげます。 54 | 1. 各ストーリーに対し、スプリントレビューでデモする内容を決めます。 55 | 1. ストーリ責任者がスプリントバックログのストーリーについて、チェックリストを基に、これが全部できればストーリー完了と言えるまでタスクをあげます。(約15分) 56 | 1. タスクが出揃ったら、挙がったタスクに不備はないかを確認して、タスクに時間の見積もりを記入します。 57 | - タスクは必ず1日で終わるサイズにしてください。 58 | - ふつうのSIの現場で、経験則上5時間程度が残業なしの場合に、1理想日を現実時間に変換したものになります。 59 | - したがって、1つのタスクが5時間を超える場合には、タスクを分割します。 60 | 1. 時間の見積もりができない、大きく影響を与えるようなものは、時間見積もりにバッファを積むのではなく、impedimentsにタスクを上げます。 61 | 1. 見積もり合計時間を見て、スプリント内で終われせることが可能か判断します。(危なそうであれば、プロダクトマネージャと相談します。 62 | 1. おつかれさまでした。 63 | 64 | ## 日々の作業 65 | 66 | 1. [朝会](./daily_scrum.md)をします。 67 | 1. かんばんを開き、朝会で今日やると宣言したタスクを「Doing」に移します。 68 | 1. IDEを起動します。 69 | 1. 各PJをSCMから最新化します。 70 | 1. チーム内の前日のコミット内容を確認します。(気になったらコメントを入れる) 71 | 1. ペアで話し合い、分担や一緒にやるところを決め、タスクにとりかかります。 72 | 1. タスク完了したら、「Done」に移します。 73 | 1. 帰る前に「Doing」のタスクが残っていれば、作業時間・残時間を更新し「ToDo」に戻します。 74 | -「Doing」レーンに残したまま帰らないようにしてください。 75 | 1. おつかれさまでした 76 | 77 | ## スプリントレビュー 78 | 79 | 参加者: プロダクトマネージャ、チームメンバ 80 | 81 | ### 事前準備 82 | 83 | - デモを行う画面と、バックログ・かんばんを表示しておきます。 84 | - パワポを作る場合は、カンバンとそのカンバンの説明を必ず明記します。 85 | - KPT用にポストイット（人数*3枚程度）とボードを用意します。タイマーがあると良い。 86 | 87 | ### レビュー 88 | 89 | 1. 「それではただ今より【Sprint名】のレビュー会を開始します。」 90 | 1. ストーリー別にデモをします。 91 | 1. 「レビューを行います。何か意見があればお願いします。」 92 | 1. コードレビューを行います。 93 | - ここのコードレビューの意味は、実装中に気になっていたことや悩んだけどこうしてみた的なことを相談する場です。 94 | - ここで上がった意見は、代表者が議事録として記録します。意見が出尽くしたようなら次へ進みます。 95 | 1. 議事録を読み上げます。「【議事録担当者】さん議事録の読み上げをお願いします。」 96 | 97 | ### ふりかえり 98 | 99 | 1. 開始の挨拶をする。「それではただ今より【Sprint名】のふりかえりを開始します。」 100 | 1. KPTによるふりかえりを行います。 101 | 1. 前回SprintのTを共有します。 102 | 1. ちゃんとTryができたかどうか、ふりかえりをします。 103 | 1. まずはKeepとProblemを出し合います。「KPTを行います。まずはKとPのみ出してください。時間は【５分程度】分です。」 104 | 1. 順番にKeepとProblemを発表する。ボードにポストイットを貼ります。 105 | - Problem vs. us の感じを出すために、全員イスから立ち、ボードを囲むようにします。 106 | - この際に、他者から自分の意見と似た意見が出たら、そのポストイットに自分のポストイットも重ねて貼ります(ビンゴ的なノリ)。 107 | - Problemから話始めると雰囲気が暗くなるので、必ずKeepから発表してください。 108 | 1. KeepとProblemの中で、Tryに繋げられるものを選びます。(3つ程度) 109 | 1. その他連絡事項がないか確認します。 110 | 1. おつかれさまでした。 111 | 112 | ### 事後作業 113 | 114 | - 議事録担当者は、挙がった意見をバックログや不具合に追加します。 115 | - プロジェクトのWikiにTryを追記します。 116 | 117 | -------------------------------------------------------------------------------- /sprints_planning.md: -------------------------------------------------------------------------------- 1 | # スプリント全体計画 2 | 3 | プロジェクト全体のスプリント計画を立てます。 4 | 5 | 1. プロジェクトの終了日から逆算して2週間ずつタイムボックスを作ります。 6 | - 祝休日が間に挟まる場合、最低でも8営業日は確保するように調整します。 7 | - スプリントの開始曜日は固定した方が、リズムが生まれるので好ましいです。 8 | - スプリントの開始曜日は、下記観点から月曜日は避けてください。 9 | - 土日をはさみウォームアップに時間がかかる。 10 | - 日本はハピマンがあるので、曜日固定が崩れやすい。 11 | 1. プロダクトバックログを作ります。 12 | 1. 機能要求をもとにストーリーをあげます。 13 | - ストーリーは体言止めにはせず、「～できるようにする」とか「～を組み込む」のように書くと一覧の視認性は落ちますが、頭に入ってきやすくなるのでオススメです。 14 | 1. ストーリーの概算ストーリーポイントを見積もります。 15 | - 1つのストーリーが13ポイントより大きくなりそうな場合は、ストーリーを分割します。 16 | 1. ストーリーの依存関係を考慮し、優先順位を決めその順に並び替えます。 17 | 18 | 1. スプリントバックログを作ります。 19 | 1. チームのベロシティ(1スプリントで何ストーリーポイント消化するか)を決めます。 20 | - チームが未成熟(初めて組むメンバー)の場合は、初期スプリントではベロシティが低く、徐々にベロシティが向上することが予想されるので、それを考慮してスプリント毎のベロシティを決めてください。 21 | 1. スプリント毎のベロシティに収まるように、プロダクトバックログからスプリントバックログに移していきます。 22 | 23 | 1. マスタスケジュールとの整合性を確認します。 24 | - 受託開発においては、社内のチーム外の人によるレビューやお客様レビューがマイルストーンとして置かれています。 25 | - それらの1スプリント以上前に、ストーリーが完了しているようになっていることを確認します。 26 | - マスタスケジュールに決められたマイルストーンからセーフティーリードを保って、開発をすすめることが成功の鍵です。 27 | - セーフティーリードが取れない場合は、始めるのが遅かったか、実現不可能なスケジュールかのどちらかです。 28 | -------------------------------------------------------------------------------- /theory_arming.md: -------------------------------------------------------------------------------- 1 | アジャイル、ウォーターフォールの二元論でなく、QCDSにとってよいと思われる選択をそれぞれの要素でやる。それがふつうの受託開発である。 2 | 3 | - スケジューリング (マクロ) 4 | - 全体の見積もりはどちらにせよ必要。 5 | - 計画が小さいほど、考慮漏れや手戻りは減る。 6 | - 新規で作るプロジェクトは、スコープを確定させてからスタートしないと、決まった期間と予算でビジネスで使えるものができる保証がなくなるので、従来と同じ要件定義はやる。 7 | - 要件定義で全体のストーリを書き、以降タイムボックスで運営する。 8 | - スケジューリング (ミクロ) 9 | - タイムボックスの遅れは、徐々に伝播していって遅れが常態化すると、バッファを直ぐに食い潰す事態になる。遅れを止める一番大きな単位がタイムボックスであり、ここを死守することが生命線であるという価値観をチームで共有しておく。 10 | - そのためストーリーはタイムボックスのはじめに、タスクに分割し、タスクも見積りがぶれないよう5h以内で実行可能な粒度にする。 11 | - 仕様の決定・承認 12 | - 要件定義は完了してから、詳細の仕様(従来の外部設計での成果物相当)をタイムボックスで実装するストーリー分は、その前に決めて、承認が必要ならばとっておく。スプリント計画MTGをもって承認行為という合意形成が出来るならば、そうした方がよい。 13 | - テスト 14 | - 違いは無い 15 | - タイムボックスによる開発はそれだけオーバーヘッドが大きいので、まとめてやるよりコストはかかる。 16 | - しかし、テストしてないものの上に、次のストーリー実装を積み重ねていくと、そこで開発が止まる・手戻ることが発生することが多々あるので、タイムボックスの中である程度のテスト(従来の機能単体テスト相当)は実施しておく。 17 | - タイムボックスを重ねた結果として、自動テストでは検出できていないデグレードが混入している可能性があるので、一番最後にテスト用のタイムボックスを設ける。 18 | - ドキュメンテーション 19 | - 違いはない 20 | - タイムボックスの中でプログラム・ドキュメンテーションを同時にやるので、その中での順序は問わない。ドキュメンテーションを後回しにできると、その分、プログラミングしてて気づく設計誤りに起因してドキュメントを修正するという手戻りは減る。 21 | - スパイク 22 | - 難易度の高い機能や初めてのパターンは、できるだけ早くフィジビリティをとるようにスケジューリングする。 23 | - ペアプログラミング 24 | - ペアプログラミングの効果は、ペアのスキル、機能の難易度によって大きなブレ幅があるので、常時ペアで作業しなさいという制約はつけない。 25 | - 各タスクの進め方として、第3者の目をいつ通すかという話にする。 26 | - これは早ければ早いほど良いので、タスクの完了条件をペアのレビューを通すこと、とする。 27 | - したがって、ペアの組み方は、アプレンティス同士にならないように注意する。すなわちチーム全体のスキルは、特段のハイスキルを要求しないが、アプレンティスが過半数を超えるチーム構成は不可能である。 28 | - スクラムマスター 29 | - 開発チームのメンバーが開発の専念できればできるほど、生産性が高い。これを真とする。 30 | - チームと外界の境界を作るのは、プロセスによらず重要。 31 | - 工程のEntry/Exit 32 | - その工程でやるべきタスクを全部終えたか? 課題は残ってないか、残っているとしたら解消の見込みは立っているのか、を棚卸しするのが工程の審査である。 33 | - タイムボックス進行の場合、スプリント計画MTG/スプリントレビューでやっていくのがよい。 34 | - この審査のための重厚長大な資料作りはしないようにはじめに合意しておく。ふだん使いのツールですべて賄えるようにしておく。 35 | - 予算のとり方 36 | - 新規プロジェクトの場合、予算を決めずにスタートすることは開発プロセスがどうであろうが賢いやり方ではない。 37 | - エンハンス開発は数人月の枠の中で、出来ることをやる、というノリになりがちだが、投下するコストに対する成果の目標は当然ながら立てるであろう。 38 | - 契約 39 | - 開発プロセスを縛るものではない。 40 | - ただし、要件定義をこの開発プロセスを適用する工程に内包しないようにはすること。 41 | - 体制 42 | - チームビルディングにかかるコストは高く、プロジェクト毎に新しい体制を用意し、開発の山に合わせて要員を逐次投入するのは避けれるなら避けたほうが良い。 43 | - 体制の山谷をできるだけ少なくし、同じメンバーのチームでできるだけ長く仕事をした方が、生産性が高い。 44 | 45 | -------------------------------------------------------------------------------- /troubleshooting.md: -------------------------------------------------------------------------------- 1 | # こんなときには… 2 | 3 | ## スプリント内でストーリが終わりきらない 4 | 5 | スクラムではチームの自律を促すので、計画に無理があったということで、次のスプリントのベロシティを下げがちです。 6 | 明らかにチームの実力が足りない場合はやむを得ませんが、こういう事象が起こるたびに、安直にベロシティを下げるのはチームの生産性を必要以上に落とすことにつながります。 7 | 8 | 例えば以下の点を見なおして、次スプリントでベロシティの向上につながるかどうか試行してみてください。 9 | 10 | - ストーリの終了条件が適切であるか? 11 | - お決まりのパターンでないタスクを単独作業でやってハマっている、なんてことがないか? 12 | - タスクに落ちていない"xxの準備作業"みたいなものが無いか? 13 | - Impedimentsが溜まりすぎて心的負担が大きくないか? 14 | 15 | そして、プロダクトマネージャは自ら率先してコードを書きチームを救うことを躊躇うべきではありません。他人に作らせてレビューに終始するよりも、自らペアプロした方が生産性高いのではないですか? 16 | 17 | 18 | ## ストーリに足りないタスクがみつかった 19 | 20 | 「これやらないと終わりとは言えないし…」 21 | 個別判断せず、プロダクトマネージャにエスカレーションしてください。 22 | 23 | 以下の選択肢がありえます。 24 | 25 | - タスクをいれかえ、そのスプリントの中で実装する。 26 | - プロダクトバックログとしてあげ、後のスプリントで実装する。 27 | - そもそも足りないという認識自体が杞憂である。 28 | 29 | --------------------------------------------------------------------------------