エンタープライズ領域にリーンスタートアップの手法を導入する
どの製品を作るのか、既存製品にどんな機能を追加するのか決定するのは難しい。リーンスタートアップの手法は顧客のニーズを理解し、ニーズにあった製品とサービスの周囲に持続可能なビジネスを構築することを手助けする。企業がより革新的で競争的になるには、どのようにしてリーンスタートアップの手法を導入すればいいのか。 James Donelan氏はdo lean startup principles have a place in the enterprise?と題したブログ記事で、リーンスタートアップの概略を説明している。 リーンスタートアップは、要約すれば、新しいビジネスモデルや製品を立ち上げるときに、検証された学習、実験と頻繁なリリースをベースするということです。こうすることで顧客からの価値あるフィードバックを測定し獲得することができるのです。言い換えれば、すばやくビルドし、頻繁にリリースし、計測
アジャイルのレトロスペクティブはなぜ難しいのか？
レトロスペクティブ（ふりかえり）は，チームの作業方法を見直して修正することによって，自らの作業を改善するものだ。より多くの価値をユーザに提供する手段として，アジャイルの重要な手法のひとつに数えられることも多い。しかし時には，レトロスペクティブを行うのが難しく思われることもある。変更すべき対象がチームメンバのコントロール範囲外にあると感じられたり，改善の余地がないように思われたり，適切なアクションの定義が難しく感じたられりすると，アクションの定義よりも先に不満が口をつき始める。そうなるとレトロスペクティブがつまらない，単なる時間の浪費だと感じられてしまうのだ。このような問題に対処して，より有意義なレトロスペクティブを行う方法を見つけるには，どうすればよいのだろう？ Keith McMillan氏のブログ記事 agile concept of the week: retrospective に
Pragmatic Daveに質問: アジャイルよりも敏捷性
今月前半、アジャイル宣言の共著者であるDave Thomas と Martin Fowlerの2人が GOTOデンマークの一連の会議でパネルディスカッションに参加した。パネルは“アジャイル宣言のやり直し”を中心としていた。これはDaveの最近のブログ記事、『アジャイルは死んだ (敏捷性万歳)』から着想を得たものである。この記事は3月に公開されて以来、興味深いディベートやディスカッションを生み出してきた。 本 Q&A は、Pragmatic Daveとして広く知られているDaveが自身の考えを説明するものである。テーマは、当パネルディスカッション、彼のブログ記事、そして、アジャイルについてあまり重点を置かず、敏捷性の実際的な適用に重点を置くべき時だと彼が信じるようになった理由についてである。 InfoQ: ごく最近までアジャイル関連のイベントに参加してこなかったのはなぜでしょうか？ それは元
InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ
図1 かんばんとプル生産方式 図1は、かんばんシステムの抽象的なモデルです。図1で示されているのは、上流と下流の2つのプロセスであり、上流プロセスが下流プロセスに部品を供給しています。最終的な顧客に製品を供給するために、プロセスは部品を生産し、その部品を下流に流し込まなければなりません。しかし、多すぎてはいけません。過剰生産は最悪のムダだと考えられます。そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます。(または、「スーパーマーケット」3 - 大野耐一氏 がアメリカのスーパーマーケットに行った時にかんばんの最初の考えを手に入れました。そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や
人員を増やさず，より多くのソフトウェアを提供するには
ソフトウェア製品やサービスに対するニーズの増加に伴って，企業の開発能力を向上させるための方法が求められている。多くの企業が選択するのは，人員の追加によるスケールアップだ。このアプローチに対して一部の人々が疑問を持ち，人員を増やすことなく，より多くのソフトウェアを提供する方法を提案している。 Robert Martin氏は"Horders of Novices (初心者の集団)"というブログ記事で，少数の専門家チームによるソフトウェア開発を提案する。 これ以上，初心者を増やす必要があるのですか？ 大して能力のない連中をさらに投入したところで，優れたソフトウェアが早く開発できるものでしょうか？ ソフトウェアの問題は，本当にマンパワーだけの問題なのですか？ コーディングはレンガ工事と同じなのですか？ 左官工の数が多ければ多くのレンガを積めるように，コーダが多数いれば，コードも多く書けるでしょう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルは”再び"死んだ
Dave Farley氏，継続的デリバリの基本原理について語る
InfoQ: かんばんとスクラム - 共に最大限に活用する