アジャイルなプロジェクトにおけるアナリストの役割
多くのアジャイルソフトウェア開発プラクティスの文献にあるものと、アジャイルチームが実際に直面するものにはギャップがある。このギャップを埋めるべく、その役割と価値を担い、状況を変えていくことが、アジャイルなプロジェクトにおけるアナリストの役割だ。この記事では、ありがちな状況として、開発チーム寄りではなく業務寄りになるような場合でも、ビジネスアナリストはアジャイルなチームワークと実用的な連携を行うことができる、ということを主張していく。
InfoQ
InfoQ
エディタ毎の記事の表示
全ての 近藤 修平 - (株)永和システムマネジメントに関するすべてのコンテンツ
近藤 修平 - (株)永和システムマネジメントが書いた最新の記事
メタプログラミングを使ってRubyにプロパティを追加する
Werner Schuster氏が、簡単な例を示しながら、Javaのようなプロパティをメタプログラミングを使ってRubyに追加する方法を示します。
近藤 修平 - (株)永和システムマネジメントが書いたNews
スクラム導入時の課題
新しいソフトウェア開発手法を導入することは、「変化を受け入れたがらない」といったものから「誤った導入方法」ようなものまで幅広く、いくつもの失敗へと繋がる課題がある。Cesario Ramo氏とEelco Gravendeel氏は、アジャイルジャーナルの連載記事の中で、スクラムで仕事をしている時であったり、さまざまな組織にスクラムを導入した時に気付いた課題について語っている。
スクラムにおける変更要求の運用
変更管理というのは、昔ながらのプロジェクトマネジメントで使われる変更を運用するための手法だ。昔ながらのプロジェクトの変更管理は典型的に、変更内容の詳細、プロジェクトへの影響、リスク、代替案などの属性を持った変更要求の詳細を書き込むことで成り立っている。
Brain Marick氏「アジャイルマニフェストに足りないもの」
Brain Marick氏は、Agile Development Practicesカンファレンスの基調講演の中で、アジャイルマニフェストに足りていない価値について説明した。氏によれば、アジャイルマニフェストは本来マーケティング用の文章であって、アジャイルが日の目を見るように、ビジネスとして成立させるという目的があったと言う。
James Shore氏「アジャイルの衰退と凋落」
James Shore氏はアジャイルは衰退していくと断じている。多くのチームが、長期間にわたって高品質なソフトウェアを生産するために必要とされる技術的なプラクティスを適用することなく、「スプリント」と朝会だけ行っていることを例に挙げている。
「スプリント」は適切な呼び方ではない？
アジャイル開発における最も根本的な概念の1つとしてあげられるのは「反復」しながら仕事をすすめるということだろう。繰り返し暫定的なマイルストンを設定しながら、繰り返し改良されたバージョンの製品を納品することで、プロジェクトを運営していくのである。アジャイルな手法では、このやり方を何かに喩えた名前を付けている。有名なもので言えば、XPの「イテレーション」であり、スクラムの「スプリント」である。
Martin Fowler氏が語る陥りがちなスクラムの落とし穴を避ける方法
InfoQチャイナのJacky Li氏は、ThoughtWorks社のAgileChinaカンファレンス中にMartin Fowler氏と会談した。このインタビューは、Martin Fowler氏がスクラムの認定試験と、アジャイルの未来について語ってくれたものだ。
ビジネス価値を基準に(バックログの)優先順位を付ける
ビジネス価値を基準に(バックログの)優先順位を付ける。Luke Hohmann氏は、バックログのどの項目から検討を始めるべきかについて定量的な判断を下す方法を述べている。
誠実さはアジャイルにとって価値と言えるか?
Declan Whelan氏は示唆に富むブログを書いている。その記事では、Mishkin Berteig氏から学んだという思想に言及し、成功するアジャイルチームには(暗黙の)原則として、「誠実さ」があるという。
アジャイル開発における失敗事例
アジャイル開発者は成功体験を語るのは好きだが、失敗についてはなかなか口を開こうとしない。Robin Dymond氏はそこに切り込み、「あるスクラムプロジェクトの失敗」という記事を書いた。