InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ
図1 かんばんとプル生産方式 図1は、かんばんシステムの抽象的なモデルです。図1で示されているのは、上流と下流の2つのプロセスであり、上流プロセスが下流プロセスに部品を供給しています。最終的な顧客に製品を供給するために、プロセスは部品を生産し、その部品を下流に流し込まなければなりません。しかし、多すぎてはいけません。過剰生産は最悪のムダだと考えられます。そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます。(または、「スーパーマーケット」3 - 大野耐一氏 がアメリカのスーパーマーケットに行った時にかんばんの最初の考えを手に入れました。そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や
それは説明責任の問題 - rabbit2goのブログ
ソフトウェア開発者の仕事は、もちろん納期通りに要求されたソフトウェアを開発することだけど、それだけではない。成果物に対する説明責任も伴うはずだ。 どのようなアーキテクチャ、デザインパターンを採用しているのか？ モジュール構成、クラス構成はどうなっているのか？ 何をどのようにテストすれば良いのか？ 性能面、機能面でのボトルネックはどこか？ どのような障害が発生したのか？ 次の派生開発時に改善すべき問題は何か？ 通常、これらの情報は仕様書などの資料として残したり、申し送り事項という形で整理されるはずだ。もちろん、ソースコードを読めば分かるようなことはどうでも良くて、そのコードの背景にある設計思想とか、大量のコードの中に埋もれがちな考え方、役立った開発資料などの情報の方がずっと重要な意味を持っていたりする。こんな情報こそ整理しておく価値があると思う。 しかしながら、開発が終わって一安心するのか、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
