「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ
このInfoQの記事において、平鍋健児氏は、日本の製造業者と共に学んだことを適用する。多くのアジャイルチームはバリューストリームの一部だけを最適化するが、平鍋氏は、リーン生産のかんばんによる視覚的なトラッキングシステムから学んだことを適応させるシンプルな方法を提案する。このかんばんシステムは、多くの企業でプロセスを見える化し、よりよいコミュニケーションとプロセスの改善をもたらすものだ。
InfoQ
InfoQ
トピック・タグ別の表示
補完実践に関するすべてのコンテンツ
補完実践に関する最新コンテンツ
補完実践に関するNews
個人の生産性
Tony Wong氏(プロジェクトマネジメントのブラックベルト)は個人の生産性にとって実践的なポイントをいくつか挙げている。この記事では、これらをいかにソフトウェア開発に適用するかを考え、彼のリストと他のリストを比べる。
バリューストリームマッピングはソフトウェア開発でも有効か？
バリューストリームマッピングはリーン(lean)生産技法のひとつであり，製品やサービスを消費者に届けるのに必要な，材料と情報の流れを分析するために使用される。製造業において Toyota が実施に成功したこのプロセスが，ソフトウェア開発においても適用されている。ソフトウェア開発は製造業と同じ道をたどるのだろうか？
アジャイルの"ルール"を"ガイドライン"に変えられるか？
一般的にルールとは，ある行動に関して定義された基準のことをいう。ルールには従わねばならない。法律の非公式な呼び方が "ルール" である，と言い換えてもよいだろう。これに対してガイドラインとは，決められた手順に従うことによって，特定のプロセスを合理化する目的のものだ。定義上は，ガイドラインは義務ではない。アジャイルチームはルールを語るべきだろうか，それともガイドラインで十分なのだろうか？
ふりかえりについてのふりかえり
組織内のどのチームもアジャイルを用いていて、それぞれ局所的な改善を実装するので手一杯だった場合、正式に｢IT｣ないし「システム開発」と呼ばれるようなより大きな組織では何が起こるのだろうか？これについて巨大なアジャイルプログラムを抱えるコーチが、自分たちの立てた戦略を共有した。これはより大きな組織が全体の動向を把握し、そこから学ぶことで利益を得られるように作られている。Paulo Caroli氏はこれを「ふりかえりについてのふりかえり」と呼んでいる。
補完実践に関するArticle
アジャイルなプロジェクトにおけるアナリストの役割
多くのアジャイルソフトウェア開発プラクティスの文献にあるものと、アジャイルチームが実際に直面するものにはギャップがある。このギャップを埋めるべく、その役割と価値を担い、状況を変えていくことが、アジャイルなプロジェクトにおけるアナリストの役割だ。この記事では、ありがちな状況として、開発チーム寄りではなく業務寄りになるような場合でも、ビジネスアナリストはアジャイルなチームワークと実用的な連携を行うことができる、ということを主張していく。
短いイテレーションの事例
Valtech Technologies社のアジャイルコーチであるDave Nicolette氏は、短いイテレーションは長いものよりも良いのかという質問に、取り組んでいる。Dave氏は、短いイテレーションは、変更に対しより素早く対応し、より多く問題を発見し、修正する機会があることをデモしている。また、短いイテレーションがバーンアウトや他の問題を招きかねない懸念材料についても対処している。
AgileEVM: 製品ライフサイクル全体で費用対効果を計測する
AgileEVMは、出来高管理の指標を使用した基準計画と比較し、コスト、スケジュール及びスコープの実際の値を計測する伝統的なプロジェクト管理手法を適応したプロジェクト管理手法です。
３つのM - リーンの３要素
リーン主義をソフトウェア開発に適用することについての議論では、主にムダ（無駄：Muda）なものを特定して排除することに関心が向けられてきました。リーン思考は同様に、ムリ（無理：Muri）とムラ（ばらつき：Mura）を削除することも目指しています。ムダ、ムリ、ムラは「３つのM」と呼ばれています。