プロジェクトマネジメントのためのパターン言語
https://gyazo.com/d92567056c80904a7f7320ad6c820a1e
4.1.3 : ぐずぐずするな (要件が決まり切らなくても、自信のある箇所については作業をはじめていく) 4.1.10 : 期日までのゆとり (デリバリー期日と開発終了見込みの日の差分 (ゆとり) を最初から追跡しておく。 減少していくようであれば危険) 4.1.11 : 作業の分割 (作業を分割して、優先度の低い部分を遅らせることができるようにする) 4.1.13 : ワークキュー (作業は優先順位付けしたリストにする。 バックログっぽい) 4.1.14 : 非公式の労働計画 (各人に短期間の作業計画を立ててもらう。 プロジェクトマネジャーは一定以上の詳細までは追跡しない) 4.1.15 : 開発エピソード (あらゆる開発に対してグループの活動としてアプローチする) 4.1.16 : 暗黙的な要件 (事業と開発の両方の観点で機能のまとまりを考えるべきで、そのために顧客にもわかるように機能のまとまりに名前を付けて認識できるようにする、ということっぽい。 エピック的な感じかな) 開発者がプロセスをコントロールし、アーキテクトがプロダクトをコントロールする
4.1.18 : 作業が内側に流れる (顧客をはじめとしたステークホルダーから開発者へと作業が流れ込むべきで、マネジャーから作業が流れ出すべきではない) 4.1.19 : プログラミングエピソード (成果物を作り出すための活動を一つのエピソードとして捉えて集中する、というようなこと？？) 4.1.20 : 常に誰かが進捗させる (第一優先のタスクが進められるように、チームの誰かが常に第一優先のタスクをするような状況を作ること。 具体的な方法は状況次第) 託児所 : トレーニングをソフトウェア開発のタスクと分ける 4.1.21 : 一つのタスクに一つのチーム (サブチームを作って突発事態に対応してもらうことで、メインチームが作業を続ける。 もしくはチームを分けることで各チームがそれぞれの第一優先のタスクに集中できるようにする) やらないこと :
要件担当と分析担当を別チームにしたりはしない。 要件担当や分析、設計、開発、デザインといった専門職が混ざったチームを作る
要件チームに対して、行った判断を設計者のために文書化することを求めたりもしない。 要件担当と設計担当は密に連携して主に口頭でコミュニケーションする
4.1.23 : 託児所 (新人教育に人を割り当てることで、他の人は通常の開発に集中できるようにする) 4.1.24 : 雇われアナリスト (技術的なドキュメントを整備するために、必要なドメインをよく知っていて、設計自体には利害関係のないテクニカルライターを雇うべし) 4.1.25 : 作業を中断して問題を取り除く (重要なリソースが提供されないせいでプロセスが止まるようであれば、そのリソースを提供することができるロールの作業を中断してでもプロセスを止めないようにする) 4.1.26 : 手を止めて始めた作業を中断するな (既に何かの手を止めて作業しているのであれば、どうしようもなくなるまでその作業を止めてはならない。 さもないとコンテキスト切り替えのせいで収集できなくなってしまう)