大きくて、重くて、厳密さを追求して失敗した事業。
<この項は書きかけです。順次追記します。>
OS、言語、通信規約
OSといsて大きすぎて複雑すぎたという伝説のMultics
rattydave/alpine-multics
https://hub.docker.com/r/rattydave/alpine-multics
言語として、大きすぎて複雑すぎたという伝説のPL/１
通信規約として、大きすぎて複雑すぎたOSI
それらに対して、管理方法として、大きすぎて複雑すぎたというPnbokは、最近小さくなったらしい。
https://www.pmi.org/pmbok-guide-standards/foundational/pmbok
改善の方法としても、大きすぎ、複雑すぎたCMMIを削ぎ落としたのが Scrumという認識。
つまり、ソースコードのない管理系はいくらでも削ぎ落とせるが、
ソースコードのあるOS、言語、通信規約は、そう簡単に削ぎ落とせないというのが経験則か。
考え方、枠組み
考え方、枠組み、方向性には、いいところがあっても、
統計や確率に基づいて選択するのではなく、
細かい整合性にこだわると失敗する。
CMMIは、最適化を目指している道具だから、統計、確率はあたりまえのはずなのに、
低い水準から議論すると間違うという典型。
水準５から考えれば、現実を描写する統計や、成功する確率に投機するとう姿勢があればよい。
その意味では、CMMIはMulics, OSIとは違うかもしれない。使い方で無駄をしなければ。
p.s.
SCRUMとか、C言語規格とか、小さくて、軽くいものでも、同じ無駄可能。
現実の課題とかを見ずに厳密な定義をしようとすると道を踏み外すかも。
SCRUMであれば、現実に使っている道具、自動化、参加している人の能力など。
C言語規格であれば、CPUの仕様、実際に書いているコードの分布、書き手の能力など。
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20190412
ver. 0.04 URL追記 20230302
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.