無料ブログはココログ

« 2011年3月 | トップページ | 2011年5月 »

PLUS 針なしホッチキス ペーパークリンチ

ペーパークリンチなるものを買いました。類似品もあるようです。茶屋町のジュンクで売っていたので買いました。これにしたのは、小型のものはとめる際に力が必要だったことと、これなら6枚までとめられるからです(他は4枚まで)。簡単に言うと針のないホッチキスのイメージです。感想は

  • 針の補充が不要なので、いつでも使えるし、止めている最中に作業が止められない
  • そのままシュレッダーにかけられる
  • 穴をあけてしまうので、やり直しができない
  • 上に紙を増やす場合は、別のところを閉じれば目立たない

ちょっとした資料なら6枚までがほとんどなので、それなりに便利です。かさばることと、やり直しができないのが欠点ですが、針の補充がいらないのでさっと使えるのが便利です。

[#TiDD] プロセスプログラミング4 - チケット駆動開発 -

ここまで、プロセスプログラミングの歴史から、プロセスの設計方法と品質特性プロセスのインスタンスを進化させる技術について書いてきました。最後にプロセスプログラミングの開発環境としてのチケット駆動開発について考えてみます。

ソフトウェアの開発環境を考えたなら、パワフルで柔軟性の高い言語やフレームワークといった環境の導入が大切であることがわかると思います。便利なライブラリがそろっていて、思い通りにプログラムできる言語、簡単な設定だけで複雑なプログラミングが不要になるフレームワークがあれば、生産性が高まって楽にソフトウェアが開発できるでしょう。

プロセスプログラミングの歴史で述べたプロセスモデリングの研究の目的にも、プロセスの実行支援やプロセスの自動実行があります。プロセス間の制約や関連のパターンを用意しておき、簡単な定義によって、計画やその変更、実施を支援するものです。

BTSをタスク管理に用いるチケット駆動開発は、プロセスの実行支援や自動実行が特徴です。ウォータフォール開発の改善やアジャイル開発の改善のほか、多くの支援が可能です。

プロセスプログラミングの歴史で述べたように、ウォータフォール開発では、工程間の順序性が高いですが、工程内のタスクはリーダーに任されており、外乱に強い柔軟なタスクを構成することが求められています。チケット駆動開発ではタスクをチケットに記述することで、タスクの進捗管理が容易で、タスクの実施順序の変更時も容易に管理できます(もちろん、順序を容易に変更できるようにタスク分割しなければなりませんが)。

アジャイル開発で必要になるオブジェクトブラウザやトラッカーに相当する機能も、チケット駆動開発は支援しています。様々な視点でオブジェクト(タスクのチケット)をブラウズできますし、変更や議論の履歴が自動的に残ります。また、複数回リリースするアジャイル開発では、リリース後のソースと開発中のソースを2重管理する必要がありますが、チケットのワークフローという制約を簡単に定義することで、プロセスの実行を支援します。

この他にも、チケットのブロッキング関係も制約の定義と支援ですし、チケットの更新時にメールを送信するのもプロセスの自動実行と考えることができます。

このようにプロジェクトを実施することは、インスタンスを進化させるというプロセスプログラミングそのものなのです。プロセスプログラミングの視点で、その環境を用意するならばチケット駆動開発は大いに参考になるでしょう。また、チケット駆動開発の事例を集めることは、プロセスのインスタンスを進化させるノウハウそのものだと思います。

#このようにプロセスプログラミングをベースにすると、サーベイ論文がいくつか書けそうですが、どなたか一緒に書きませんか?

このエントリーをはてなブックマークに追加



[#TiDD] プロセスプログラミング3(改) - ファシリテーション -

プロセスプログラミングの歴史を振り返ると、プロセスのクラスである標準プロセスは発展し、現場のソフトウェア開発に大いに貢献しています。その一方、インスタンスに関しては、プロセス記述の研究が進んだものの、現場への貢献はあまりありません。このため、ソフトウェアプロセスに関する集まりに参加すると、現場での経験が抽象化されないまま、情報交換されています。

もちろん、TSPガイドブック:リーダー編 (IT Architects'Archive)

をはじめとする標準プロセスを実践する本にも多くの情報があります。しかし、それは標準プロセスを前提とするものであり、独立した技術とは言いにくいものです。

これは、一人として同じ人間はおらず、同じ人であっても時と共に成長することによるものです。このため、プロセスのクラスから生成されるインスタンスには同一のものはなく、各インスタンスの差異が大きいことから一般化した議論が難しいからです。

ソフトウェアプロセスの喩として用いられることの多い、料理のレシピでさえも工夫する余地があれば結果は異なります。大阪で行列のできることで有名な「堂島ロール」というロールケーキがあります。このお店は元々堂島ホテルにあり、今も同じレシピを元に「堂島ホテルロール」http://sakaba.cocolog-nifty.com/sakaba/2010/02/post-5c72.html
が作られています。しかし、味は微妙に違います。レシピというプロセスのクラスは同じでも、そのインスタンスが生成されるときに立地や販売戦略、価格などの異なる要素によって人間が最適化するからです。

標準プロセスを定めた場合であっても、テーラリングが行われます。開発対象や諸条件に応じて標準プロセスをカスタマイズして用いるのです。しかし、それは標準プロセスを計画時に変更するものです。計画を実施している間に、開発者のコミュニケーションを良くし、メンバーの能力をどのように高めるか、というプロセスのインスタンスを実践することを目的とした技術ではありません。

そのような中で、プロセスのインスタンスに注目している技術ははプロジェクトファシリテーションです。プロジェクトファシリテーションのお話では、かんばん、バーンダウンチャート、コミットベルなどのツールが注目されがちですが、それはあくまでも支援環境、すなわちプロセスインスタンスの実行環境です。そのような環境を用いた上で、実際のプロジェクトのメンバー構成を考慮して、コミュニケーションやモチベーションを向上するという、インスタンスの技術がファシリテーションの特徴だと思います。

このように、プロセスのクラスとインスタンスを分けて考えると、プロセスのクラスのテーラリングの観点で、個別のプロセスインスタンスを生成するだけでは不十分です。生成したインスタンスをどのように進化させるか、プロセスプログラミングの観点で見直す必要のあると思います。

このエントリーをはてなブックマークに追加



[#TiDD] プロセスプログラミング2 - ウォーターフォールとアジャイル -

プロセスプログラミングの観点でウォーターフォール開発のプロセスとアジャイル開発のプロセスを考えてみます。ソフトウェアプロセスがプログラムであるなら、プログラムと同じように様々な設計方法や品質特性があるはずです。

まず、設計の観点で見てみます。ウォーターフォールは構造化設計や複合設計で言うところのSTS(源泉、変換、吸収)分割と似ています。これはデータフローに基づく機能分割で、モジュールの強度を強く、モジュール間結合度を弱く実現すべきであると言われています。

各工程をモジュールと考えるなら、設計書や仕様書というドキュメントのインタフェースによってモジュールの独立性が保たれています。しかし、ドキュメントで実現される仕様はすべてが一括に実現されることが前提であり、その多くは個々のパラメータを個別に扱えないスタンプ結合になっています。また、各工程の関係を考えるとその順序は絶対であり、順序結合であると考えられます。

このように、ウォーターフォール開発の工程はあまり保守性の良いモジュールではありません。各工程の関連が強く、工程の順番を入れ替えることもできません。その反面、工程内の作業をモジュール化するのはリーダの役目であり、リーダーや支援する環境によってより良いプロセスを実現できる可能性があります。

一方、アジャイル開発におけるイテレーションは、ストーリーまたはタスクの集合を入力とする機能的なモジュールです。実装する対象によって、ある程度の順序性はありますが、基本的にイテレーションは独立であり、さらにはイテレーション内のタスクお多くが独立性の高いものになっています。

このように考えるとアジャイル開発は、オブジェクト指向設計されているようです。開発作業が多くのオブジェクトに分割され、柔軟に組み合わせることができます。その反面、全体を見渡せるオブジェクトブラウザ(かんばん)が必要で、呼び出しシーケンスを明確にしておく(トラッカーの)必要があります。

このようにウォーターフォール開発とアジャイル開発をプロセスプログラミングの観点でみると、その特徴と支援すべきものが見えてきます。そして、そこにチケット駆動開発の有効性が見えるのです。

このエントリーをはてなブックマークに追加



[#TiDD] プロセスプログラミング1 - ソフトウェアプロセスもソフトウェアである -

プロセスプログラミングという言葉をご存知の方は少ないかもしれませんが、4半世紀も前に生まれたこの言葉は、その後のソフトウェア工学を大きく発展させました。すでに死語となった感もあるプロセスプログラミングという言葉ですが、原点回帰すると見えてくるものもあるものです。そこで、プロセスプログラミングの観点で、今あるプロセスの議論を考えてみたいと思います。

ソフトウェアプロセスの議論は1980年代半ばに、ソフトウェアプロセス国際ワークショップ(IWSP)を中心に議論されていました。ハンフリー氏のプロセス成熟度の話や、ベーム氏のスパイラルモデルも議論されていました。見聞きした話では「旅行は想定外のことが楽しいよね」とか「ウォータフォールを繰り返すスパイラルはフラワーモデルと呼んだ方が良い」などという議論もあったようです。

そのような中で最もインパクトのあったのはオスターワイル(Leon J. Osterweil)氏のプロセスプログラミングです。氏の

Software Processes are Software, Too
(ソフトウェアプロセスもソフトウェアである)

という言葉はソフトウェア工学に大きな衝撃を与えました。そして第9回ICSE(ソフトウェア工学交際会議)で発表された論文は、後に最も影響を及ぼした論文として表彰されました。

プロセスプログラミングは2つの流れを生みました。一つはプロセスのインスタンスともいうべき実世界のプロセスのモデリングによって、表現し、伝え、議論し、実行支援や自動実行する、というプロセスモデリングの流れ。もう一つはプロセスのクラスともいえる標準プロセスの流れです。

プロセスモデリングでは、複雑なプロセスをどのように記述するかが注目されました。ソフトウェア開発のプロセスは、予期せぬ事態により、あるプロセスから別のプロセス群が生まれたり、別のプロセスに変質することがあります。このようなプロセスの動的な変化をどのように記述するか、共通例題が作られペトリネットのように図的なものを含めて多くの言語が提案されました。

一方の標準プロセスの流れは、成果物を中心とした標準化から、組織プロセスの成熟度を考慮したものに発展しました。当時はコーディングルールや仕様書の体裁に見られるような成果物の標準化が多く行われていました。そこにソフトウェア工学の技術が組み込まれ、CMM/CMMIのような組織プロセスの成熟度を考慮したものに発展しました。

CMMIの元になったCMMは、段階モデルが特徴ですが、SEPGにプロセスプログラミングの影響を見ることができます。CMMの段階モデルは、開発組織の成熟度ランキングから、ソフトウェア工学の技術を組織の成長すべきと思われた順にならべたものです。そのような組織の標準プロセスを構築し、技術を導入しつつプロセスを改善するのがSEPG(Software Engineering Process Group)です。言うならばプロセスプログラミングと保守によって、標準プロセスを進化させることが仕事です。

このように、プロセスプログラミングはソフトウェア工学の世界に大きな影響を及ぼしました。しかし、その中心はプロセスのクラスともいうべき標準プロセスでした。この歴史を考えると、現在のソフトウェア開発に必要なものが見えてきます。

以降、プロセスプログラミングの観点から、ウォーターフォールとアジャイルファシリテーションチケット駆動開発について考えてみたいと思います。

このエントリーをはてなブックマークに追加


« 2011年3月 | トップページ | 2011年5月 »