無料ブログはココログ

« [#agile] 「リーン開発の現場」を読んで その1 - 引き取り的な仕組み - | トップページ | [#agile #TiDD] 「リーン開発の現場」を読んで その3 - チケット駆動開発にあてはめる - »

[#agile] 「リーン開発の現場」を読んで その2 - パイプラインとスケールアップ -

前の記事では、リーンソフトウェア開発とTPSの関係を書きましたが、今回は「リーン開発の現場」にでてくるプロセスのパターンを中心にリーンを説明したいと思います。

プロセスのパターンはcsh的なスクリプトでモデル化して説明します(いまどきならbashでしょうけど、4.2BSD世代な人なのと、cshの方がわかり易いだろうとの判断です)。

ウォーターフォール、スクラム、リーン

ウォーターフォールというのは、各工程ごとに成果物を完成させて作業を進めます。

A < IN > x
B < x > y
C < y >  OUT

このようにすると、aの途中に間違いがあって、それがOUTを確認している最中に見つかると、Aを修正して初めからやり直さないと行けません。

このような手戻りはムダですので、XPやスクラムでは全体をいくつかに分けて、順番に実行します。

for each i ( in1 in2 in3 in4)
     abc >> OUT
end

バックアップをとっておけば、途中で問題が見つかった際にそこだけやり直せますし、繰り返し期間ごとに集中と休息のリズムを感じる事ができます。

しかし、システム的に考えると起動終了のオーバーヘッドが大きいですし、多能工が必要になり、処理量の増大方法にも限界がありそうです。そこで、リーン開発では

A | B | C

のようにパイプラインで並行処理をします。このようにすると、起動終了のオーバーヘッドがなくなり、A,B,Cは専門性を活かせます。出力は随時確認できますが、

CTRL-Z

で処理を一時停止したり

CTRL-C

で中断したくなるでしょう。そのためにはA,B,Cの協調が必要なので、ミーティングが行われます。

スケールさせる

パイプラインで処理をする場合にはいくつかの方法があります。簡単なのは

A | B| C | D| E

とパイプライン処理を増やす方法です。多段になりすぎて管理しにくい場合、

A | BC | DE

のBCやDEを別のスクリプトにして階層構造を実現します(階層構造は繰り返し処理でも実現できますね)。

これらは全体のスループットをあげていませんので、並列性を高めたい場合もあるでしょう。

A & B

cshだと中間ファイルをつくらないと入力を2分岐できませんが、カンバンボードでは必要なところで並列度をあげる事ができます。

WIP制限

並列度が高いとうまく処理できない場合もあるでしょう。いったんまとめて、優先度順に処理します。

(A & B) | C | D

具体例ではこんな感じですね(cshではjob番号が邪魔しますし、bashでは面白くないですが、、)。

( echo "aaa\nbbb\nccc" &  echo "AAA\nBBB\nCCC" ) | sort | cat -n | pr

括弧で出力が一つにまとめられ、sortで優先順位に並べられ、cat -n で番号が付けられます。

この処理では、処理間のパイプラインに小さいバッファがあり、処理が可能な分が引き取られています。

また、sortの後では、優先度の順に処理され、優先度の低いものは後で処理されます。

sortとcatは1行ずつの処理であり、同時処理(仕掛り)数を制限しています。これはマルチタスクを避けて、後続の処理に負担をかけないWIP制限になっています。

最後のprはページ単位の出力です。今週のリリース予定、来週のリリース予定など、機能を一定の単位に区切ってリリースします(11/7追記)。

考えるプロセス

プロセスプログラミングの提唱者であるオスター・ワイルの有名な言葉「 ソフトウェアプロセスもまたプログラムである」を感じていただけたでしょうか?このようにプロセスは色々と工夫できます。

CMMの普及に大きく貢献し、後に形骸化の危険性を説かれた故坂本氏は、開発標準をわざと薄く作られたそうです。そして開発者達にどのように実践すべきかを考えるように言われていたそうです。

ソフトウェア開発は複雑で難しい作業です。リーン開発はその開発を可視化するもののあまり単純化しません。どちらかと言うと、複雑で難しい処理の優先度や並列度を良く考えて、より最適に開発できるようにします。

そのようなプロセスは一度に実現できるものではありません。開発に関わる人たちで、工夫しながら一つずつ積み上げて実現していくものです。

最前線からのメッセージ

「リーン開発の現場」には上に挙げたようなプロセスの構成要素が示されています。プロジェクトが進むにつれ、工夫によってカンバンボードは成長し、洗練していきます。

カンバンボードはプロジェクトを見える化するだけでなく、プロジェクトの関係者達の成長も示しています。

翻訳者のお一人である藤原さんのスライドにもそのような様子を見る事ができます。

書籍では、より大規模で階層的な開発の様子が描かれています。それは、著者のヘンリック氏が最前線で戦いながら「俺たちはこうやったぜ、次は君たちの番だ!」と言っているようです。

次の記事ではチケット駆動開発でリーン開発の実現方法を考えてみる予定です。

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


« [#agile] 「リーン開発の現場」を読んで その1 - 引き取り的な仕組み - | トップページ | [#agile #TiDD] 「リーン開発の現場」を読んで その3 - チケット駆動開発にあてはめる - »

私のアジャイル」カテゴリの記事

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

« [#agile] 「リーン開発の現場」を読んで その1 - 引き取り的な仕組み - | トップページ | [#agile #TiDD] 「リーン開発の現場」を読んで その3 - チケット駆動開発にあてはめる - »