アーカイブ
- 2007.10.25: 考えは大きく、行動は小さく、失敗するなら早く、学習は迅速に
- 2007.10.25: リスクは、それに最もうまく対処できる側が持つべきだ
- 2007.10.25: 全体を測定すべきであり、分解して測定すべきではない
- 2007.10.25: 測定したものしか得ることができない
- 2007.10.25: コストとスケジュールは局所最適化のための計測手段であるということがなかなかわからない
- 2007.10.25: 自動テストスイートは
- 2007.10.25: 設計をテストとして文書化することで
- 2007.10.25: あるモデルが有用かどうかを判断する方法の一つは
- 2007.10.25: どのようなコードにするかについて、日々の決定を行うのはプログラマなのだ
- 2007.10.25: チーフエンジニアの役割は
- 2007.10.25: 人は、自分が置かれた組織の期待にこたえるものだ
- 2007.10.25: モチベーションをくじかせる、最も簡単な方法の一つは
- 2007.10.25: ある環境から別の環境へのプラクティスの移植は、間違いである場合が多い
- 2007.10.25: やる気に重要な要素は計測ではなく、権限委譲（empowerment）であると信じている
- 2007.10.25: スケジュールによって作業を進める（プッシュする）のではなく、顧客のニーズが作業を引っ張る（プルする）ことだ
- 2007.10.25: 賢明な決定を下せる専門知識を備えた人を育てる方が
- 2007.10.25: リスクが高い場合が多く、ミスが大きなコストにつながる
- 2007.10.25: イテレーションは、実現可能な解決の一実証例としてとらえるべきであり
- 2007.10.25: 顧客が自分の欲しいものを正確に知っていることはめったにない
- 2007.10.25: ビジネス価値が最も高い機能を先に提供するため、最優先の機能から先に開発するべきだ
- 2007.10.25: あらゆるアジャイルソフトウェア開発手法にも、あらゆる場面で適用するスタート地点がある
- 2007.10.25: 仕事をするのなら、それは、「直接顧客」のための仕事でなくてはならない
- 2007.10.25: リファクタリングをともなったイテレーション
- 2007.10.25: ソフトウェア開発の思考には二つの流派がある
- 2007.10.25: 可変性は悪であるという考えがソフトウェア開発に入り込んでしまった
- 2007.10.25: 決定を遅らせることには価値がある
- 2007.10.25: ムダとは、顧客が認める価値を、製品に付加しないもの、すべてのことだ
- 2007.10.25: 「プラクティス」は、原則を実行するために、何をするか、である
- 2007.10.25: 製造の最終段階での変更による莫大な損失の回避方法として
- 2007.10.25: ソフトウェア開発は製造ではなく製品開発と似通っている
- 2007.10.25: CMMやPMIを非難するわけではない
- 2007.09.22: 必要なのはツールを増やすことではなく
- 2007.09.22: 設計が解決しなければならない矛盾（パラドックス）がまるっきりないなら
- 2007.09.22: 設計が障害を起こしてしまう環境を三つ考えつかなければ
- 2007.09.22: それは品質の改善ではない
- 2007.09.22: 性能の最後の10パーセントが、コストの3分の1と問題の3分の2をもたらす
- 2007.09.22: 管理者たる読者はそれについて何をすべきか
- 2007.09.22: 「人助けモデル」を銘記せよ
- 2007.09.22: スケジュール延長が遅い時は、必ず少なくとも2週間は無駄になると覚悟したらいい
- 2007.09.22: 士気は、プロジェクトの成功確率についての全メンバーによる総合評価と考えることができる
- 2007.09.22: ほとんどの遅延プロジェクトは
- 2007.09.22: おそらく良い管理者の最大の挑戦と試練は
- 2007.09.22: プロジェクト途中の管理者の仕事の多くは
- 2007.09.22: 計画は、敵の最初の一手までは有効である
- 2007.09.22: 管理レビューは、管理層への輝かしい報告ができないプロジェクトを懲罰する方法として
- 2007.09.22: 問題はしばしば、明確化に対する組織の恐怖に根ざしている
- 2007.09.22: プロジェクトを制約する意思決定につながる一連の高レベルの交渉が
- 2007.09.22: 多くのソフトウェア組織にとって、高品質実現の主要な障害は
- 2007.09.22: どんな事柄でも不可視になるのを許すな
- 2007.09.22: 統計的プロセス制御は、ソフトウェア制御に適用できないと
- 2007.09.22: テストの省略や後工程への遅延を許すな
- 2007.09.22: ソフトウェア工学管理は一連の選択であって
- 2007.09.22: 工学とは、ある環境下でできるだけ多くを獲得するアートであるから
- 2007.09.22: リスクアセスメントはリスク管理ではなく
- 2007.09.22: あまりにも性急に速く、多くの変革を組織に押しつける管理者は
- 2007.09.22: システムは、外部要因を無視しようとはするが
- 2007.09.17: 見積りの議論を、「交渉」ではなく、「問題解決」としてとらえよう
- 2007.09.17: コミットメントは交渉できるが、見積もりを交渉の対象にしてはならない
- 2007.09.17: ごくわずかな可能性しかないプロジェクトの見積りなら
- 2007.09.17: バッファ計画の出発点として、顕在化したリスク（RE)の合計を使おう
- 2007.09.17: 信頼性を95%から99%に向上させたいなら、スケジュールの本体に25%を加えるべきである
- 2007.09.17: 開発者とテスト担当者の構成比は、見積もりよりも計画によって安定する
- 2007.09.17: 計画パラメータの見積りは、あくまでも見積りである
- 2007.09.17: 中規模の業務システムプロジェクト（35,000〜10万LOC）では
- 2007.09.17: スケジュールを長くして、小さなチームでプロジェクトを実行して、コストを減らそう
- 2007.09.17: スケジュールの見込値を25％以上短くしてはならない
- 2007.09.17: 適正な見積もり技法を使えば、規模の見積もりは他の見積もりの基礎となる
- 2007.09.17: 具体的な開発タスクを配分して割り当てる準備ができしだい
- 2007.09.17: まず、規模の見積もりに焦点を合わせよう
- 2007.09.17: 見積りのアウトプットについて議論してはいけない
- 2007.09.17: 複数の見積もりが一致したのに、ビジネスターゲットが一致しなかった場合は
- 2007.09.17: 異なる見積もり技法によって別々の結果が生じるときは
- 2007.09.17: 見積りの焦点は、正確さに合わせるべきで
- 2007.09.17: 新しいプロジェクトを見積もるときは、過去の似たようなプロジェクトと比較して
- 2007.09.17: 最良ケースと最悪ケースの見積もりを作成して
- 2007.09.17: タスクレベルの見積もりを行うときは
- 2007.09.17: タスクレベルの見積もりは、実際に作業に携わる者が見積りを作成しよう
- 2007.09.17: できるだけプロジェクトのデータまたは過去のデータを使用して
- 2007.09.17: できるときはいつでも、まず数えよう
- 2007.09.17: 見積りにとって重要なことは。完璧なまでに正確であることより
- 2007.09.17: 見積りを求められたときは、実際に見積もりを行うのか、ターゲットの達成方法を尋ねられているのかを判断すること
- 2007.09.17: 「見積り」「ターゲット」「コミットメント」はそれぞれ異なるものであると認識しよう
- 2007.09.17: 開発者の見積もりを削ってはいけない。なぜなら、既に十分楽観的すぎるからだ
- 2007.09.16: しかしより大きな問題は、私たちのほとんどが他者との衝突を避けようとする点
- 2007.09.16: こういった状況の難しさは、状況それ自体にあるのではなく
- 2007.09.16: 気をつけるべき最後の点は、結果ありきの調査です
- 2007.09.16: ほとんどの難しい意思決定において、問題となるのは調査やデータの欠如ではありません
- 2007.09.16: 熟考という行為は、意思決定のツールとしては不当に過小評価されています
- 2007.09.16: 設計作業や仕様書作成作業といったものは楽観的な観点に立ったプロセスであるため
- 2007.09.16: 誰かの作業を誉めたい時には
- 2007.09.16: 懸案事項の効果的なマネジメントは
- 2007.09.16: とにかく、さまざまな道を考察し
- 2007.09.16: 技術革新は滅多なことでは起こらない
- 2007.09.16: 何も学ばずに日々を過ごせるほど、人生は長くない
- 2007.09.16: 予算管理はいやでもやらざるをえない
- 2007.09.16: 小さい役はない。あるのは、小さい役者だけ
- 2007.09.16: つまらない報告書の書式変更が、すごいプロジェクトになった
- 2007.09.16: うちの会社がやっていることは２つしかない
- 2007.09.16: 仕事中も何か困ったことが出てきたら、すぐに「15分会議」を招集して
- 2007.09.16: 毎朝8時、チーム全員が集まって最長15分の会議を開く効果は計り知れない
- 2007.09.16: 構えて撃ってから狙え
- 2007.09.16: 成功にも失敗にも等しく報いる。罰するのは怠慢だけだ
- 2007.09.16: プロジェクト管理とは、胸がどきどきわくわくし、鳥肌が立ち
- 2007.09.16: どんな仕事も、すごい仕事にできる！
- 2007.09.16: リスクを最小限に抑え、命令系統を尊重し、上司の顔色をうかがい
- 2007.09.16: 偉大なリーダーなんて必要ない
- 2007.09.16: シリコンバレーはなぜ、かくまで栄えたのか
- 2007.09.16: 問題と争点と行動のいちばん近くにいて
- 2007.09.16: 人は人生の大半を、厚い壁の前で過ごす
- 2007.09.16: 打ちひしがれたときの一番の妙薬は、何かを学ぶことよ
- 2007.09.16: よしよし、うまく行っている。このまま同じことを続けて
- 2007.09.16: 蛸壺の中でじっとしていれば、目は見えなくなり、耳も聞こえなくなる
- 2007.09.16: いつも同じ人と付き合い、いつも同じ雑誌を読み
- 2007.09.16: いつも同じ仲間と昼食を取り、いつも同じ顔ぶれの会議に出席し
- 2007.09.16: 本日の予定表をもう一度じっくりながめてみよう
- 2007.09.16: 改革とはお題目ではない。人々を安全地帯から引っ張り出すことだ
- 2007.09.16: 政治は人生そのもの。全ての人が満足する改革はない
- 2007.09.16: モデルやコンセプトを持て
- 2007.09.16: 待っていれば、事態は悪くなるばかり。戦いを起こせ
- 2007.09.16: 許可を求めるのは、「だめだ」と言ってくれと頼むのと同じ
- 2007.09.16: だれにだって、多少とも変えられるものがある
- 2007.09.15: 要員は成功への鍵である
- 2007.09.15: 優れた管理は優れた技術より重要である
- 2007.09.15: ライフサイクルのできるだけ初期に機能間のトレードオフ
- 2007.09.15: 重大な、あるいは本質的な設計エラーまたはアーキテクチャ上の問題点は
- 2007.09.15: ソフトウエア開発の経済的側面のうち重要な事柄の1つは
- 2007.09.15: ウォータフォール型のライフサイクルにおいて発生する致命的な問題点は
- 2007.09.15: 期限が十分先なら−−例えば半年か１年先なら
- 2007.09.15: ソフトウエアの品質は、プロジェクトの１つの要因であり
- 2007.09.15: デスマーチ・プロジェクトが長期にわたると
- 2007.09.15: 「ヒステリックな楽観主義」とは
- 2007.09.15: ある程度、リスク管理担当者は「誠実な野党」である
- 2007.09.15: 真のボトルネックは、プロジェクト管理の革新なのだ
- 2007.09.15: プロジェクトはどうして一年も遅れるようになるのか？
- 2007.09.15: 成功のためには、プロジェクトに携わる人々の質、及びその組織形態と管理こそが
- 2007.09.15: １日の遅れにもやっきにならなければならない
- 2007.09.15: マイルストーンの決定に関し、関係する規則は一つだけだ
- 2007.09.15: 遅れているソフトウエアプロジェクトへの要員追加は更に遅らせるだけだ
- 2007.09.14: ソフトウエアを不安定にさせることは
- 2007.09.14: マイルストーンをヒットする可能性が6つのコンポーネントそれぞれについて90パーセントである場合
- 2007.09.14: 遅れた後は、何がなんでも次のマイルストーンをヒットしろ
- 2007.09.14: 絶対やっては行けない最悪の愚行は
- 2007.09.14: 遅れは問題ではない。遅れに慌てふためくことが問題なのだ
- 2007.09.14: 遅れを利用して効率的な対応を促進しよう
- 2007.09.14: 遅れはモラルの問題ではない
- 2007.09.14: 開発マネージャの立場として、あなたはたった3つの要素を相手に仕事をする
- 2007.09.14: チームの言動はどんな場合でも分析の対象にするにはあまりに複雑すぎるが
- 2007.09.14: 必死に働くことではなく、必死に頭を働かせることに重点をおくこと
- 2007.09.14: プロジェクトが遅れているとしたら、何かが間違っている
- 2007.09.14: 結局はそれほどの根拠がないはずの最終期限を守りたいがために
- 2007.09.14: 定例会議に注意すること
- 2007.09.14: 予測できたはずの問題で驚くようなはめに陥ってはならない
- 2007.09.14: 毎日、「プロジェクトをあと数ヶ月軌道に乗せておく手助けとして
- 2007.09.14: レビュー・リーダは、プロダクトの出来、不出来に対して責任は取れないし
- 2007.09.14: レビュー結果を無視するときには危険を覚悟せよ
- 2007.09.14: プロダクトの品質が悪くてもよいレビューには報いること
- 2007.09.14: 製作者を評価しないこと
- 2007.09.14: 技術的問題点のみを扱うこと
- 2007.09.14: 標準に忠実であること、さもなければ標準を捨てること
- 2007.09.14: 形式についての議論を避けること
- 2007.09.14: 問題点を提起しても、それを解決しないこと
- 2007.09.14: 肯定と否定の両面から検討すること
- 2007.09.14: レビュー・リーダの仕事は
- 2007.09.13: 客先で発見されたバグは
- 2007.09.13: テスト計画が現実に合わなくなったら
- 2007.09.13: 新しいファイルがリリースされたら
- 2007.09.13: テストで問題になる２つの間違い
- 2007.09.13: ホワイトボックス／ブラックボックスは単純化しすぎていて危険だ
- 2007.09.13: どこにいるのか知らなければ、地図はまったく役に立たない
- 2007.09.13: 欠陥発見にはたくましく創造的であれ
- 2007.09.13: チェック作業でのチェッカの目標は、ユニークな重大欠陥を最大数見つけ出すことである
- 2007.09.13: インスペクション自身は、きわめて不合理な納期をも守れることを保証するものではない
- 2007.09.13: 問題発見には自動化ツールの利用をまず考える
- 2007.09.13: インスペクションはテストを代替するものではない
- 2007.09.13: ウォークスルーは訓練に、レビューはコンセンサス作りに！
- 2007.09.13: 予防は治療に勝る
- 2007.09.13: エラー修正のとき、しばらく設計段階にもどってみよう
- 2007.09.13: 修正が正しいという確率は１００％ではない
- 2007.09.13: エラーの徴候ではなく、エラーそのものをなおそう
- 2007.09.13: １つのバグがあるところには、別のエラーもある可能性が高い
- 2007.09.13: プログラムのある部分でエラーがまだ存在している確率は
- 2007.09.13: エラーは見つからないだろうという仮定のもとにテストの計画を立ててはいけない
- 2007.09.13: プログラムが本当に使い捨てのものでないかぎり
- 2007.09.13: それが意図されたように動くかどうかをみただけでは、半ば成功したにすぎない
- 2007.09.13: テスト・ケースは、正しい予想できる入力条件ばかりでなく
- 2007.09.13: それぞれのテストの結果を完全に検査せよ
- 2007.09.13: プログラマは自分自身のプログラムのテストをしてはならない
- 2007.09.13: テスト・ケースの必須条件は、予想される出力または結果を定義しておくことである
- 2007.09.11: どんな処方にも二つの部分がある
- 2007.09.11: ある方向に動けば、別の方向についてコストが発生する（トレードオフ）
- 2007.09.11: 惨事はありえないと言う考えは、しばしば考えられない惨事を引き起こす
- 2007.09.11: 一見どう見えようとも、それはつねに人の問題である
- 2007.09.11: クリスマスプレゼントに金槌をもらった子供は、何でも叩きたがる
- 2007.09.11: テスト済みのコードの品質を改善する唯一の効果的な方法は
- 2007.09.11: 品質に関する主要な決定要因は
- 2007.09.11: 腕の劣る人を1人、班から外せば
- 2007.09.11: 政治問題には政治的解決策を；技術問題には技術的な解決策を
- 2007.09.11: 許しがたい唯一の怠慢は、過去の失敗から学ぶのを怠ることである
- 2007.09.11: 測定できない事柄を、コントロールするわけには行かない
- 2007.09.11: 多くの会社が犯しやすい間違いは二つある
- 2007.09.11: 目標は夢物語とは違う
- 2007.09.11: 何をすべきか従業員がわかっていないとしたら
- 2007.09.11: コーチは選手に何をして欲しいかを考えると同時に
- 2007.09.11: みんなで力を合わせるということは
- 2007.09.11: 問題解決にはどれくらいのコストがかかるかを考える時には
- 2007.09.10: マネージャーの仕事のうち、やさしいほうは制御と調整に関係する
- 2007.09.10: 管理とは、社員が生産的に気分良く働けるようにする一連の触媒
- 2007.09.10: あなたが完璧な模範を示そうと頑張れば頑張るほど
- 2007.09.10: 適切な人が適切なときに適切な意思決定をするようにしむけることである
- 2007.09.10: 一番下っ端の開発作業者が、日程遅れも品質不良もみな自分たち自身の
- 2007.09.10: たいていのソフトウエア技術者は、予定を達成するために
- 2007.09.10: 切迫感ていうのは終わりのほうで痛切になるのに
- 2007.09.10: 成功指数とは、W・エドワード・デミングのいわゆる「外的動機因子」であり
- 2007.09.10: 短時間だけなら、品質を犠牲にしてスピードを採るのは
- 2007.09.10: 真の作業ミーティングは、ある事柄を一緒に考えるために
- 2007.09.10: 究極の管理上の罪とは
- 2007.09.10: 変化に対する主な反応は、論理的なものでなく
- 2007.09.10: いたるところの組織が、CMMのレベルを上げるプレッシャーの元にある
- 2007.09.10: プロセスは、プロジェクトを行う価値が無ければ
- 2007.09.10: 個々人は技量を求めて努力し、よいスキルを積み重ねるが
- 2007.09.10: 誰も書かなかった生産性要因
- 2007.09.10: 管理者の役割は､人を働かせることにあるのではなく
- 2007.09.09: 批評は、非難や罰としてではなく情報として与えられた方がもっと受け入れやすい
- 2007.09.09: 品質とスケジュール目標のトレードオフが出来ないと感じると
- 2007.09.09: 私たちはソフトウエアの仕事はみな論理的だと考えがちであるが
- 2007.09.09: みなを同等に扱うことはみなを平等に扱うことを意味しない
- 2007.09.09: 個人的な経験だけでは、大規模プロジェクト管理にとっては決して十分ではない
- 2007.09.09: 中間管理職の仕事は「人を育てる」ことである
- 2007.09.09: 多くの専門家は彼らのやることにほとんど成功しているので
- 2007.09.09: フィーディーニの手法
- 2007.09.09: リップ・バン・ウインクルの手法
- 2007.09.09: お粗末な管理は他のどんな要因よりも
- 2007.09.09: レビューは、スケジュール効率を改善し
- 2007.09.09: 官僚制のある定義は
- 2007.09.09: 私がこれまでに観察した危機に対するもっとも危険な反応は
- 2007.09.09: 悪い兵士などいない、いるのは悪い将校だ
- 2007.09.09: Xドルの損失はいつでも財務上の責任がXドルを超える取締役の責任である
- 2007.09.09: 品質さえ気にしなければ、品質以外のどんな要求でも満たすことができる
- 2007.09.09: 慣習的（パターン２）組織のプログラマのほとんどは
- 2007.09.09: 受け取ったものについて少なくとも三つの異なった解釈を思いつかないならば
- 2007.09.09: フィッシュボーン図を展開する活動のほうが出来上がった図よりもずっと重要である
- 2007.09.09: 地図と土地とが一致しないとき、つねに土地を信じよ
- 2007.09.09: 生き残るために、管理者は非難を免れるためのこつを知る必要がある
- 2007.09.09: 過去の実績統計は変革のために用いられるのではなく
- 2007.09.09: 品質を手っ取り早く片づけようとすればするほど
- 2007.09.09: 大切なのは出来事ではない、出来事に対する反応だ
- 2007.09.09: 行動は早めに、かつ少しずつ
- 2007.09.09: 大きなシステムは､小さなシステムと似たようなもので
- 2007.09.09: 他の全ての原因よりもカレンダー時間の切迫が
- 2007.09.08: 無茶なスケジュールを達成するように決められたプロジェクトは
- 2007.09.08: 初期に人数が多すぎると、プロジェクトは重要な設計作業を省略せざるを得ない
- 2007.09.08: 致命的なのは知らないことではない
- 2007.09.08: あなたたちの仲裁をさせてもらえますか
- 2007.09.08: 我々は味方同士である。敵は問題そのものだ
- 2007.09.08: 入出力の完全なリストのない仕様書は、見込みなしである
- 2007.09.08: 仕様書があいまいなのは、システムの利害関係者の間で
- 2007.09.08: 管理者が部下を刺激するために屈辱を使うことは
- 2007.09.08: 管理者の怒りと屈辱は伝染する
- 2007.09.08: プレッシャーや残業を使う本当の理由は
- 2007.09.08: 残業時間を増すのは、生産性を落とす方法である
- 2007.09.08: プレッシャーをかけても思考は早くならない
- 2007.09.08: 優れたプロジェクトは、デバッグに費やす時間の割合が
- 2007.09.08: 標準的なプロセスの危険な点は
- 2007.09.08: プロジェクトの期間中に二つ以上の手順改良に順応することは
- 2007.09.08: 一日を無駄にする方法はいくらでもある
- 2007.09.08: プロジェクトの初期に無駄にする一日も、末期に無駄にする一日も
- 2007.09.08: 新しい仕事を引き受ける意欲のある結束の硬いチームは
- 2007.09.08: チームの結束については必要のない賭けはしない
- 2007.09.08: 失敗した作業は早く打ち切る勇気をもつ
- 2007.09.08: 成功を最大化するより、失敗を抑えることによって
- 2007.09.08: 悪い話が上層部に伝わりやすい経路（匿名制など）を作っておくこと
- 2007.09.08: リスクが現実になる前の初期の兆候を予測せよ
- 2007.09.08: それぞれのリスクの実現する確率と予想コストを評価せよ
- 2007.09.08: 短期的に生産性を高める方法などない
- 2007.09.08: 戦闘が始まるときには、管理者の本当の仕事はもう終わっている
- 2007.09.08: 正しい管理の本質は、適切な人材を雇用し
- 2007.09.07: 一生懸命は余分な、不要な努力である
- 2007.09.07: あなたのコードを変更するのは人間であると言うことを頭に入れておく
- 2007.09.07: たとえはじめはエラーがあなたの責任であるように見えなくても
- 2007.09.07: 当初から品質と信頼性を第一に完了することを目指したソフトウエアプロジェクトでは
- 2007.09.07: メトリクスは不要だと言う意見は
- 2007.09.07: よいコードを再利用することである
- 2007.09.07: 20ないし30%の時間が計画立案、要求仕様、アーキテクチャ設計にかけられている
- 2007.09.07: アーキテクチャでは、決定事項の主要なものについてその理由を明記する必要がある
- 2007.09.07: コンピュータ使用の量が多いことと生産性が低いことには相関があることを示している
- 2007.09.06: すでにやる気のある開発者に対して、さらに圧力をかけると
- 2007.09.06: あらゆる要因の中で、「動機づけ」が最も生産性に大きな影響力を与えることが
- 2007.09.06: スケジュールが遅れることそのものより悪いのはただ1つ
- 2007.09.06: 普通以上の残業を当てにしてはならない
- 2007.09.06: 困難な状態にあるプロジェクトの回復計画で、ほぼ確実に失敗する計画の1つとして
- 2007.09.06: 優良な組織と管理のほうが、技術よりもはるかに重要な成功要因であるように思える
- 2007.09.06: グループの結束力のほうがプロジェクトメンバーの個人の能力または経験よりも、生産性に影響している
- 2007.09.06: 複数の目標を設定すると生産性は急激に低下することがわかっている
- 2007.09.06: 重要なことは２つしかない。1つは顧客、もう一つは製品である
- 2007.09.06: 全てのソフトウエアエラーの約40%は、ストレスが原因であると判明している
- 2007.09.06: 楽観的過ぎるスケジュールは、少しの遅延では終わらない
- 2007.09.06: 0.75または0.80以下のスケジュール圧縮率を実現するのは不可能であると
- 2007.09.06: 実際の最短スケジュールは、最も正確な計画されたスケジュールから生まれる
- 2007.09.06: リスクを除こうとすることが無駄な努力であり、リスクを最小化できるかどうかも不確かなら
- 2007.09.06: 積極的にリスクを攻撃しなければ、リスクのほうが積極的に攻撃してくる
- 2007.09.06: 査閲（レビュー）に費やした1時間ごとに保守を33時間も削減したことがわかり
- 2007.09.06: 過度のスケジュールプレッシャーの下で開発され、リリースされた製品では
- 2007.09.06: 上流工程での作業の時間を惜しんだプロジェクトはたいていの場合
- 2007.09.06: プロジェクトの曖昧な準備に数ヶ月や1年が費やされ
- 2007.09.06: スケジュール上のトラブルが発生すると決まってその計画を放棄してしまう
- 2007.09.06: 「なせばなる」姿勢は真の大惨事にいたる小さなつまづきを積み上げていくことになる
- 2007.09.06: 開発速度を落とすには大きなミスを1つ犯すだけでいいが
- 2007.09.06: ソフトウエアのサイズが増加すると、それ以上の比率で作業が増加するため
- 2007.09.06: もっとも効果的な手法は、開発者自身の潜在能力を引き出すことである
- 2007.09.05: プロジェクト記録の内容を応用しやすい形式に変えておけば
- 2007.09.05: 特にそんなつもりもなく、計画をないがしろにしてしまうことである
- 2007.09.05: プロジェクトの関係者が最初から再見積の必要性を理解していないと
- 2007.09.05: スケジュールの遅れを取り戻せたプロジェクトは殆どなく
- 2007.09.05: 初期の段階でプロジェクトの規模を過小評価したり
- 2007.09.05: プロジェクト チームの全員が、各段階の最後にソフトウエアを出荷可能な状態にすることを
- 2007.09.05: 一般的なプロジェクトでは時間の約80%が予定外のやり直し作業に費やされている
- 2007.09.05: プロジェクトの上流の作業を効果的に実施していれば
- 2007.09.05: ソフトウエアの変更を求める圧力が強くなればなるほど
- 2007.09.05: ソフトウエアの構築作業は非常に詳細なレベルで行う
- 2007.09.05: 過度にコストがかかり信頼性を低くする機能を発見し排除することができるので
- 2007.09.05: 設計の形式化不足でコストがかかることを考えれば
- 2007.09.05: 品質保証作業がプロジェクトの終盤まで後回しにされた場合
- 2007.09.05: プロジェクトのいたるところで間違いが起きるのは避けられない
- 2007.09.05: スケジュールの遅れというリスクを最小限に抑えるには
- 2007.09.05: プロジェクトの関係者全員が見積作成手順に同意した後は
- 2007.09.05: 「完璧」にこだわると「優良」というレベルさえ達成できなくなってしまう
- 2007.09.05: プロジェクトのコストに対する影響が、上流と下流でかなり違うことを考慮すると
- 2007.09.04: アーキテクチャの目標は複雑さを減らすことにあるので
- 2007.09.04: ベータテストで効果をあげるためには多くの調整作業が必要である
- 2007.09.04: テストはソフトウエアシステムの品質レベルを調べる手段であり
- 2007.09.04: 速さと品質のどちらを優先するか
- 2007.09.04: ユーザーインターフェイスプロトタイプを実際にソフトウエアを作成するときの基礎として使用してはならない
- 2007.09.04: プロトタイプはあくまでも「単なるプロトタイプ」に過ぎない
- 2007.09.04: 要件を収集すときに最も困難なのは、ユーザの要望を
- 2007.09.04: 成功する組織は、わずかな負担で大幅なリスク回避ができる方法を
- 2007.09.04: 成功するプロジェクトには隠された部分が無い
- 2007.09.04: 全体像を説明する場合、組み込む機能と同じくらいまたはそれ以上に除外する機能について
- 2007.09.04: 成功するプロジェクトでは、プロジェクトメンバーが積極的に責任を追及する
- 2007.09.04: 変更の管理とは、必要な変更は全て行うが
- 2007.09.04: 段階別分納は万能薬というわけではない
- 2007.09.04: 実際に動作するソフトウエアは、紙にかかれたどのような報告書よりも
- 2007.09.04: プロジェクト全体にわたってユーザーと連携することは
- 2007.09.04: 平均的な管理者の仕事では、数分ごとに頭を切り替えて別の作業をする必要がある
- 2007.09.04: 不可能な目標によって意欲をかき立てられる人もいる
- 2007.09.04: 「管理されたプロジェクト」の逆は「管理されない（自由な）プロジェクト」ではなく
- 2007.09.04: プロジェクトの初期段階には、予算とスケジュールを厳密に設定するか
- 2007.09.04: 成功するプロジェクトチームでは、上流の問題は上流で修正できるような手段を講じている。
- 2007.09.02: プロジェクトの最初の段階で工程に時間と労力を傾注しておけば
