InfoQ ホームページ PM に関するすべてのコンテンツ
-
-
アジャイルでユースケースを利用する - ユースケース2.0，スライシング，ラミネーティング
アジャイルソフトウェア開発を使って製品をインクリメンタルに開発し提供する場合，要件項目はプロダクトバックログに収集，整理される。ここで使用される要件定義テクニックはユースケースだ。アジャイルの製品要件管理でユースケースを利用するテクニックには，ユースケース2.0やスライシング，ラミネーティングなどがある。
-
Gojko Adzic氏のユーザストーリー改善についての新著
優れたユーザストーリーはソフトウエアの提供を改善するだろうか。Gojko Adzic氏はチームのユーザストーリーの管理の仕方を小さく変化させることで最終的な成果に大きく影響を与えることができると言う。1月中に関心がある人が5000人集まったら執筆するという。
-
アジャイルにおけるドキュメント：いつどれくらい書くべきか
アジャイルソフトウェア開発マニフェストは「包括的なドキュメントよりも動くソフトウェア」に価値を置いている。そうだとすると、どんな種類のドキュメントが、いつどれだけ必要なのだろうか？
-
振る舞い駆動開発(BDD) - コラボレーションによる価値創造
ソフトウェアプロジェクトの目的はステークホルダに価値を提供することだ，BDD(Behavior-Driven Development，振る舞い駆動開発)は，そのためにデザインされた – ウォーターフォールからアジャイルプロセスへの移行に取り組むソフトウェア開発者のViktor Farcic氏は，自身のBDDに対する見方を述べた４つのブログ記事の冒頭でこう説明している。
-
カンバンで需要と能力のバランスをとる
カンバンを使うことで、組織は実施中の作業を把握し、需要と能力のバランスがとれるプルシステムを確立できる。まずは実際の能力がどの程度あるかを見極め、その能力の流れを可視化することだ。InfoQはFlorian Eisenberg氏にインタビューし、どのように需要と能力のバランスをとるかについて話を聞いた。
-
スプリント計画ゲーム "Rocket to Mars"
"ほとんどのチームとそのプロダクトオーナは，より多くのストーリポイントを達成することがチームの唯一の責務だと信じています。しかしこれは，チームとプロダクトオーナの関係を完全に誤解したものだ，と私たちは考えます。" こう語るのはDamien Thouvenin氏とPierrick Revol氏だ。氏らはストーリの創出や問題の調査，技術的負債の削減，およびそれらを���レーニングするための時間的投資を題材としたスプリント計画ゲームを実施した。
-
プロジェクトはすべてやめるべきか？
XP Days Beneluxカンファレンスで行った"Kill all projects"と題するセッションの中で，Paul Kuijten氏は，すべてのプロジェクトを廃止することを提案した。InfoQでは氏にインタビューして，アジャイルにとって価値のあるプロジェクト管理や製品開発の資金について話を聞いた。
-
プロダクトオーナーの役割を拡大するには
スクラムのプロダクトオーナーの役割はビジネスと開発の橋渡しをすることだ。複雑な商品を持ち多くの決定をする必要がある大きな組織では、プロダクトオーナーの役割をひとりで担うのは現実的ではない。このような場合、何らかの方法でプロダクトオーナーの役割をスケールアウトしなければならない。InfoQはTimo Punkka氏にインタビューを行い、プロダクトオーナーの役割、リーンポートフィリオマネジメント、顧客との協業について話を聞いた。
-
企業におけるアジャイルスケーリングのプラクティス
組織規模でアジャイルを採用している企業は，時としてアジャイルプラクティスの適用範囲を拡大する必要に迫られる。"Agile Methods in the Finance Sector and Complex Environment” カンファレンスでのセッションでは，企業におけるアジャイルのスケーリング実践経験が参加者によって発表された。
-
英国における巨大アジャイルプロジェクト失敗の原因調査結果
英国監査局の報告およびリークされたユニバーサル・クレジット事業の内部調査は、この事業の失敗の原因は、リーダシップと実践の貧弱さにあると非難している。ユニバーサル・クレジット事業は、英国雇用年金局のもとで開発されつつあるもので、何百万人もの英国の受給申請者に対する給付金支払い業務を統合するものである。このプロジェクトは、アジャイル手法を使って管理されていたが、その実施は失敗した。
-
ウォーターフォールからアジャイルへの移行によるムダの削減
組織がアジャイルを採用するのは，変化への対処を可能にするためだ。アジャイルは開発チームにとって，顧客ニーズを満足する製品を提供する上で有効な手段であると同時に，必要のない(使用されない)機能を含まない製品を提供する手段でもある。リーンソフトウェア開発は言う：ユーザに価値を提供しないものは，すべてムダとみなされると。ならばウォーターフォールからアジャイルへのソフトウェア開発の移行は，開発組織のムダ削減に役に立つのだろうか？
-
ThoughtworksのTechnology Radarから見る最新技術トレンド
Thoughtworks社が最近公開したTechnology Radarの最新記事は、『Infrastructure as Code』（コードによるインフラ管理）を可能にする技術、『境界のない企業』、実績あるプラクティスのあらゆる場面への適用、そして軽量なアナリティクスを目玉としている。
-
InformITがDorset Houseの書籍を電子書籍で出版
Pearson EducationのIT出版部門であるInformITはDorset Houseとパートナーシップをむすび、電子書籍のフォーマットでDorset Houseの書籍を出版する。InfoQの読者は2013年10月末までこの電子書籍を25%割引で購入できる。
-
アジャイル手法は個人の作業にも適用可能か
アジャイルへの移行は，チーム全体，プロジェクト，あるいは組織単位で行うのが普通である。アジャイルはチームを主体とするアプローチだからだ。ところが，個人でアジャイルプラクティスの利用を始めたり，ワン・パーソン・チームとしてアジャイルを実践しているプロフェッショナルが存在するのだ。どうすれば個人でアジャイルを採用できるのだろう，そして，どのようなメリットがあるのだろう？