ドメインモデルには、完全性と純粋性、そしてアプリケーション性能の3つ全てを同時に満足させることは難しい場合があるという話。
ITエンジニアにとって、修羅場は「憑き物」だ。 誤字ではない。トラブルは付いて回るというより、憑いてくる。 納期直前になって致命的な不具合が発覚したり、システムのバグで業務運用がストップして報道されたりする大炎上から、そのドミノ倒しの発端となる些細なボヤまで、必ず、何かしら起きる。 「全てのタスクが遅滞なく進められ、問題が一切発生せず、完璧なリリースを迎える」なんてプロジェクトは存在しない。あるとするならば、そのプロジェクト自体を疑ったほうがいい。異常系テストをせず、運用フェーズでトラブルが多発するのがオチである(ソースは私)。 しかも、自分のせいではないトラブルがほとんどだ。 原因を紐解いていくと、安請け合いして勝手に納期を短縮する営業担当とか、前年比10%コスト削減という根拠のない押し付けをしてくる発注元とか、仕様書はないくせに変更だけ要求してくる担当とか、「バグにペナルティを課せば品
1. 『プロジェクトマネジメントの基本が全部わかる本』橋本将功 著、翔泳社 2. 『アート・オブ・プロジェクトマネジメント』Scott Berkun 著、村上 雅章 訳、オライリー・ジャパン 3. 『アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣』VenkatSubramaniam,AndyHunt 著、木下史彦,角谷信太郎 監訳、オーム社 4. 『プロジェクトマネジメント知識体系ガイド(PMBOKガイド)第7版+プロジェクトマネジメント標準』PMI 著、PMI日本支部 監訳 問題。次のうち、どちらが重要? 1. 炎上プロジェクトを鎮火する技術 2. プロジェクトを炎上させない技術 修羅場における火消しの技術が1だ。燃え上がって墜落寸前のプロジェクトを制御して、なんとか胴体着陸まで持っていくノウハウである。 一方、プロジェクトを修羅場にさせない技術が2だ。そもそもそんな操縦不
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く