マーフィーの法則でもありますがバンクーバー冬季五輪のニュースを見ていてつくづく思うことが「まさか！」と思うことが起るものだということです。 失敗や事件・事故が起こった時に当事者、関係者を責めることは簡単ですが、その道で選りすぐられて世界の頂…

CMMとアジャイルは全く相いれないものであるという誤解がありますが必ずしもそうではありません。 あまり知られていないことですがスクラムはCMMレベル３のKPAの多くを満たすという事実があります。 書籍「スクラム入門-アジャイルプロジェクトマネジメント…

Agile Japan 2010 の告知がありました。 以下にAgile Japan 2010サイトの紹介文を引用します。 Agile Japan 2010 開催のご案内です。 お陰さまで大盛況だった昨年に引き続き、今年も趣向を凝らしたイベントにするべく、ただいま奔走中です。 今年のテーマは…

「西日本アジャイルプロセス研究会中間報告会」に参加しました。 最も興味深かった話がライトニングトークスのトップを飾った株式会社シンフォーム谷本さんの「目覚めよ！スキルアップ欲」でした。 非常に面白いアイデアなのですが、内容をここに書いてもよ…

誤解を恐れずに書くと、計画駆動に代表される予見指向が強いマネージメントではあらかじめ手段を定めて結果はなるようになるという傾向が強いと思います。 一方でアジャイルに代表される適応指向のマネージメントでは結果を定めて手段はなるようになるという…

ここのところCode Contractsを使ったDbC（Design by Contract）に凝っているのですが、ふとアジャイル契約というものを思いつきました。それでDbCにならってジャムズのアジャイル導入に関する契約を考えてみました。 不変条件： アジャイルマニフェスト 事前…

引き続きCode Contractsを使用した仕様記述と検証についてです。 試しに鶴亀算について仕様記述と検証を行ってみました。 はじめは簡単に考えていたのですが実際にやってみるとなかなか奥が深く思っていたほど簡単ではないことが分かりました。 そしてこの難…

Code Contractsを使用した仕様記述の参考としてジャンケン判定の仕様記述の例をあげておきます。 public enum Gesture { Rock, Scissors, Paper, } public enum Winner { Player1, Player2, Draw, } public class ScissorsPaperRock { public Winner Judge(G…

「Code Contracts（契約）の使いどころ - Jamzzの日々」に引き続きCode Contractsについて書きたいと思います。 ここまでの内容はソフトウェア本来の目的である仕様の実現という視点で品質と生産性を向上させるためにCode Contractsを契約による設計（DbC:De…

一般的によくあることで私自身もそうなのですが、アジャイルについて説明する際に従来の方法を「計画駆動型」とか「予見型」などと言って、それに対してアジャイル型を「適応型」として、それぞれを対比して違いを説明したりします。 これはアジャイルとはど…

「Code ContractsとPex - Jamzzの日々」に引き続いてCode Contracts（契約）の使いどころについて書きたいと思います。 Code Contractsで興味深いと思う点は契約の継承、特にインターフェイスやabstractのクラス（abstractのメソッド）に対する契約を記述で…

マイクロソフトのDevLabsで公開されている.NETにおける設計とテストにおけるテクノロジーであるCode ContractsとPexを使ってみました。 結論から言うとかなり使えそうでひょっとしたら開発スタイルを変え可能性があると思いました。 かなり奥が深そうでまだ…

プログラミング言語についてそれほど明るいわけではありませんがC#やScala、F#等のモダンなプログラミング言語の動向を見ていると、手続き型であるオブジェクト指向パラダイムと宣言型パラダイムの融合が進んできていて、徐々に慎重にであはりますが、さらに…

プロジェクトマネージメントとしてアジャイルの意味を理解する一つの視点としてプロジェクトのコンカレント化という見方があると思います。 説明をわかりやすくするために官僚的に工程がシーケンシャルに実施されるウォーターフォール（ウォーターフォールが…