InfoQ ホームページ PM に関するすべてのコンテンツ
-
-
ThoughtWorks Technology RadarについてRebecca Parsons氏が語る
1月、ThoughtWorksは最新のTechnology Radarで、同社が追跡しているソフトウエア開発のエコシステムの動向を発表した。1)プロダクション環境での警告システムとリカバリ、2)プライバシとビッグデータの緊張関係、3)JavaScriptのエコシステム、4)物理と仮想の環境の境界の曖昧化、の4つが今年の大きなテーマだ。
-
ThoughtWorksが継続的デリバリツールGoをオープンソース化
ThoughtWorksが継続的デリバリ(Continuous Delivery,CD)であるGoをオープンソースにした。このツールはCruiseControlを起源にしており、開発プロセス全体をカバーするパイプラインプロセスを提供する。つまり、継続的統合、テスト、デプロイメントだ。
-
-
アジャイルでユースケースを利用する - ユースケース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” カンファレンスでのセッションでは，企業におけるアジャイルのスケーリング実践経験が参加者によって発表された。
-
英国における巨大アジャイルプロジェクト失敗の原因調査結果
英国監査局の報告およびリークされたユニバーサル・クレジット事業の内部調査は、この事業の失敗の原因は、リーダシップと実践の貧弱さにあると非難している。ユニバーサル・クレジット事業は、英国雇用年金局のもとで開発されつつあるもので、何百万人もの英国の受給申請者に対する給付金支払い業務を統合するものである。このプロジェクトは、アジャイル手法を使って管理されていたが、その実施は失敗した。
-
ウォーターフォールからアジャイルへの移行によるムダの削減
組織がアジャイルを採用するのは，変化への対処を可能にするためだ。アジャイルは開発チームにとって，顧客ニーズを満足する製品を提供する上で有効な手段であると同時に，必要のない(使用されない)機能を含まない製品を提供する手段でもある。リーンソフトウェア開発は言う：ユーザに価値を提供しないものは，すべてムダとみなされると。ならばウォーターフォールからアジャイルへのソフトウェア開発の移行は，開発組織のムダ削減に役に立つのだろうか？