アジャイルプロセス協議会は、日本におけるアジャイルプロセスの普及/推進、情報交換などを目的とした企業等の法人/団体によるコミュニティです。 ソフトウェア開発における最大の課題は、開発期間の短縮化、低コスト化、そして目まぐるしく変化するユーザニーズやビジネスニーズへの柔軟で迅速な対応です。これらを解決する手法として現在、エクストリーム・プログラミング(XP)やScrumを始めとする「アジャイルプロセス」に注目が集まっています。
今回の記事では, プロジェクト管理に特化したアジャイル開発手法であるスクラムの概要を説明します. また, スクラムによる開発が成功する理由を説明するための理論的なバックボーンとして引用されている知識創造プロセスやコンテキストの概要を紹介します. さらに, 20 名程度の中規模開発チームにおいてスクラムを適用し, 開発に成功した事例を紹介し, その中で知識創造プロセスやコンテキストが生まれたのか否かについて考察します. 1. スクラムとは 1.1 スクラムの価値と理論的な基盤 スクラム [1] は, Ken Schwaber と Mike Beedle によって考案されたアジャイル開発手法です. スクラムという開発方法論の名称は, ラグビーのスクラムにちなんで名づけられたそうです. スクラムは、Schwaber らがいくつかの失敗プロジェクトを立て直す経験を通じて生み出されたとされています.
ここでは、PF=Project Facilitation(プロジェクトファシリテーション)について議論しています。 プロジェクトを活性化し、楽しくプロジェクトを成功に導くための、実践的な課題を扱います。 プロジェクトの成功に大切なものはなんでしょうか? 個々人のスキルは重要です。そして、ここで取り上げるのは、集まった個人のスキルを100%以上に発揮させるチーム作りとしての、「プロジェクトファシリテーション(PF)」です。 プロジェクトマネジメント(PM)が重要であることは昨今強く言われています。 PMが「計画達成のマネジメント」に重点を置くのに対してPFは「参加者の協調の場作り」に重点を置いています。PMは、計画の立案と実行、差異に注目した管理が中心で、どちらかと言うと「コマンド・コントロール型」のマネジメントスタイルが背後にあります。これに対してPFは、その場その場の変化に対応し、チーム
ソフトウェア開発ではこれまで、できるだけ「シンプル」に設計・開発することの有効性が繰り返し提言されてきた。ソフトウェアをシンプルにすればするほど、設計は見通しが良くなり、開発は容易になり、メンテナンスも楽になる。 では、開発を<シンプル>にするというのはどういうことなのか? 一体どうすれば<シンプル>になるのか? これらの質問にあなたは即答できるだろうか。実際のところ、頭ではシンプルにすることが良いと分かっていても、現実には実践できていなかったりするのではないだろうか。 そこで本稿では、現実の開発現場でシンプルな設計・開発を行うための1つの手段として、その「考え方のコツ」を考察する。もちろんこのコツを身に付けることは、すべてのソフトウェア開発で役立つものだろうが、特にNAgile(エヌ・アジャイルまたはナジャイル)を実践していくうえでは、ぜひ知っておいてほしい(NAgileについての概要は
ということで、ぼくなりに、TPSと「ソフトウェア開発」のマッピングについて、分かっているものを線で結んでみた。ほとんどはMaryによって知られている。 さらに、TPSクイズを用意しました!:(回答は、フォントを白くしています) Q1:後工程のことを「お客様」とよびます。お客さまが欲しいものを欲しいといったときに欲しいだけ作るのがプル生産。では、前工程は何と呼ばれる? A1:「神様」。前工程がなければ自分たちは何も作れない。 解説: 同じ流れの中にある、両隣の工程をリスペクトすること。言葉にこれが表れている。 Q1:後工程から生産指示が来ない場合、前工程はどうする? A1:掃除する(5S)。それでも指示が来なければ、後工程へ行って手伝う。これを「応受援」という。 解説: 掃除、というのは、ソフトウェアで言うなら、「今週の作業が終わっても、次週の作業をやってはならない。時間があまったらリファク
「実践UML―パターンによる統一プロセスガイド 」や「初めてのアジャイル開発 ~スクラム、XP、UP、Evoで学ぶ反復型開発の進め方~」の著者として有名な、Craig Larman 氏と、日本でスクラムマスターのコースを開催した Bas Vodde 氏と、名古屋のトヨタ見学に行ってきました。前回は、Mary/Tom Poppendieck と同行して元町工場を見学しましたが、今回は堤工場を見学しました。 見学後、黒岩惠先生と落ち合って、TPS、リーン、ソフトウェア開発の話を長時間しました。やはり生産方式としては明文化され、確立されているTPSですが、はっきりとトヨタの製品開発の方法論としてはまとまって形式化されているものは見つからず、さらにプラクティスとプリンシプルの調査が必要です。 TPSは生産方式ですから、そのまま開発に使えるわけではありません。しかし、その原則はソフトウェア開発に活か
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く