プロセス: 2007年9月アーカイブ
性能の最後の10パーセントが、コストの3分の1と問題の3分の2をもたらす。
「ワインバーグのシステム変革法」
プロジェクトを制約する意思決定につながる一連の高レベルの交渉が、すべてのプロジェクトに先行している。情報が揃っていてかつ適合的な交渉でなければ、プロジェクトは開始以前から命運が尽きている。
「ワインバーグのシステム変革法」
多くのソフトウェア組織にとって、高品質実現の主要な障害は不十分な要求定義（要件）プロセスである。
「ワインバーグのシステム変革法」
どんな事柄でも不可視になるのを許すな。要件も、設計も、コードも、とくにテストはいけない。予防は治療よりもはるかに容易なのだ。
「ワインバーグのシステム変革法」
統計的プロセス制御は、ソフトウェア制御に適用できないと主張する人々を信用するな。彼らに欠けているのは、そうした制御を適用する正しいレベルととるべき適切な行動である。たとえば、彼らはコードの欠陥を計測するかもしれないが、その情報を設定されたしきい値を満足しない個人を責め苛むために用いるのだ。
「ワインバーグのシステム変革法」
ライフサイクルのできるだけ初期に機能間のトレードオフ、品質、コスト、スケジュール間のトレードオフを理解しようと試みる。
「ソフトウェア プロジェクト管理」
ウォータフォール型のライフサイクルにおいて発生する致命的な問題点は、早い段階でのりスク解消が行われないということです。
「ソフトウェア プロジェクト管理」
いたるところの組織が、CMMのレベルを上げるプレッシャーの元にある。これはダークサイドである。なぜなら、それは、ローリスクの安全な行動へと仕向け、それゆえプロジェクトは利益の少ないものとなる。
「ピープルウエア 第2版」
プロセスは、プロジェクトを行う価値が無ければ、推し進める価値は無い。
「ピープルウエア 第2版」
初期に人数が多すぎると、プロジェクトは重要な設計作業を省略せざるを得ない（全員に仕事を与えるため）。
「デッドライン」
優れたプロジェクトは、デバッグに費やす時間の割合が,はるかに低い。
「デッドライン」
標準的なプロセスの危険な点は、人々が賢明な省略を行う機会を失わせることである。
「デッドライン」
プロジェクトの期間中に二つ以上の手順改良に順応することは、現実には期待できない。複数の技能改良プログラム（たとえば、全般的なCMM等級の引き上げ）は,プログラムを実施しなかった場合に比べ、プロジェクトの完成を遅らせる可能性が非常に強い
「デッドライン」
アーキテクチャでは、決定事項の主要なものについてその理由を明記する必要がある。「いつもこういうふうにしている」という正当化に気をつける。
「コードコンプリート」
困難な状態にあるプロジェクトの回復計画で、ほぼ確実に失敗する計画の1つとして、近道を取ることが挙げられる。プロジェクト回復とは近道を取るのではなく、基本に戻ることなのである。
「ラピッド デベロップメント」
上流工程での作業の時間を惜しんだプロジェクトはたいていの場合、そこから派生する問題のために下流工程で10倍から100倍の時間を割かなければならなくなる。
「ラピッド デベロップメント」
プロジェクトの曖昧な準備に数ヶ月や1年が費やされ、プロジェクトが正式にスタートするときには過酷なスケジュールになっているということもまれではない。
「ラピッド デベロップメント」
一般的なプロジェクトでは時間の約80%が予定外のやり直し作業に費やされている。最小限のやり直し作業を戦略的かつ計画的に行えば、ソフトウエアの品質とプロジェクト全体の生産性を劇的に向上させることができる。
「ソフトウェア プロジェクト サバイバル ガイド」
プロジェクトの上流の作業を効果的に実施していれば、構築段階では大きな問題が発生することもなく作業はぐんぐんはかどるだろう。
「ソフトウェア プロジェクト サバイバル ガイド」
ソフトウエアの変更を求める圧力が強くなればなるほど、変更に対しては慎重に対応することが重要になる。さもないと、プロジェクトは管理不可能な状態に陥ってしまう。
「ソフトウェア プロジェクト サバイバル ガイド」
ソフトウエアの構築作業は非常に詳細なレベルで行う。したがって、この作業で下した何千という判断を後で変更するのは、システム全体のコーディングをやり直すことに等しい。最初の時点で正しい判断をしておかなければ、取り返しのつかないことになるのは明白である。
「ソフトウェア プロジェクト サバイバル ガイド」
ソフトウエアプロジェクトでは、プロジェクトのいたるところで間違いが起きるのは避けられない。プロジェクトが成功するかどうかは、プロジェクトチームがこのような間違いを早く発見して簡単に修正できるような体制を作れるかどうかにかかっている。
「ソフトウェア プロジェクト サバイバル ガイド」
プロジェクトの関係者全員が見積作成手順に同意した後は、見積作成の結果である予算とスケジュールについての無駄な議論を重ねるのを止め、見積作成の基となるデータである機能とリソースについての合理的な話し合いに専心できる。
「ソフトウェア プロジェクト サバイバル ガイド」
ユーザーインターフェイスプロトタイプを実際にソフトウエアを作成するときの基礎として使用してはならない。それは、映画撮影所のステージセットを土台にして本物の家を作るのと同じくらいにばかげたことである。
「ソフトウェア プロジェクト サバイバル ガイド」
プロトタイプはあくまでも「単なるプロトタイプ」に過ぎないことをユーザーに理解させなければならない。ユーザーインターフェイスプロトタイプの作成に伴うリスクの1つは、ユーザーに、プロジェクトの今後の進展に対し非現実的な期待を図らずも抱かせてしまうことである。
「ソフトウェア プロジェクト サバイバル ガイド」
段階別分納は万能薬というわけではない。しかし、分納に伴う負担と分納によって改善される点を天秤にかければ、負担の増大を補って余りあるメリットがある。進捗状況のわかりやすさ、品質判断のしやすさ、柔軟性、見積もりの正確さ、リスクの削減などの点が大きく改善されるからである。
「 ソフトウェア プロジェクト サバイバル ガイド」
平均的な管理者の仕事では、数分ごとに頭を切り替えて別の作業をする必要がある。しかし、平均的なソフトウエア開発者の仕事では、最低でも数時間は同じ作業に集中しつづける必要がある。
「ソフトウェア プロジェクト サバイバル ガイド」
