BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ PM に関するすべてのコンテンツ

  • ソフトウェアアーキテクチャに関する新刊

    ソフトウェアアーキテクチャはソフトウェア技術者にとって重要なトピックのひとつである。ソフトウェア開発プロジェクトの失敗の大部分が不適切な設計を原因とするものだからだ。だからアーキテクチャ上の問題の理論と実際について学ぶのは重要なことだ。最近出版された,あるいは近々出版予定の興味深い新書が大いに役立つだろう。

  • アジャイルのリーダーたちがPMIのアジャイル認証について議論する

    スクラムの共同発案者Ken Schwaber氏はPMIがアジャイル認証プログラムを定めたことを歓迎し、最近自らの考えを投稿した。

  • PMI Agile Certificationパイロットが開始

    新しいPMI-Agile Certified Practitioner (PMI-ACP)称号を最初に得たいと考える、新しもの好きの人は 5月23日から始まるPMI Agile Certificationパイロットに応募できる。このパイロットに選ばれた人は PMI-ACPの認定を得るためにアジャイルの基礎について、選択形式のテストに受かる必要がある。

  • Visual Studio vNextは、さらなる機敏さとDevOpsの統合を提供する

    マイクロソフトは、TechEd North America 2011で、プロジェクトのプランニングからステークホルダーフィードバックの収集、開発者への運用フィードバックの提供などのアジャイルツールに加えて、VC++のアーキテクチャダイアグラムと単体テストといった次期バージョンのVisual Studio新しい機能を紹介した。

  • アジャイルテストの描写

    アジャイルコミュニティの何人かのメンバが、ユーザストーリーテストやテーマ全体に関するテストをどう表現するか、いくつかの方式を提案している。

  • ユーザーストーリーを分割する方法

    アジャイル技法が十分に機能するようにユーザーストーリーを細分化することは、ほとんどの新しいアジャイルチームにとって困難である。アジャイルコミュニティのメンバーが、いくつかの記事を通してユーザーストーリーを効果的に分割する方法についてのガイダンスを提供している。

  • 収縮の価値

    ITとアジャイルの熱狂的な支持者のひとりであるMike Burrows氏はKanbandevグループである議論を始めた。このグループはコミュニティを展開/収縮パターンの探索に連れ出している。氏の始めた議論はInfoQの他の記事で紹介した。その記事では要求を細かく砕いて展開する方が、砕いたものを再度まとめることよりも価値があると考える実践者たちの見方を紹介した。しかし、多くの人がこのパターンは両方とも便利だと思っている。

  • まとめ直し(collapse) の価値

    アジャイル手法では,機能を小さなユーザストーリに分解(“展開”)することを推奨している。しかし,コードが完成した後は,これらを元の機能にまとめ直すべきなのか,それとも全体を1つのユニットとして扱う方がよいのだろうか? まとめ直し(collapse) に利点があるとすれば,それはどのようなものだろう?

  • PMIのAgile認証パイロットが5月に開始

    PMIカンファレンスでのアジャイル セッションの増加にともなって、PMIがアジャイルを受け入れるのではないか、という憶測がかなりあった。PMI は、遂に 独自のアジャイル 認証をアナウンスした。

  • アジャイル契約

    ほとんどのソフトウェア契約は,固定的なスコープ/コスト/スケジュールという,ウォーターフォール方式のアプローチを念頭において書かれています。 この記事では,アジャイルソフトウェアプロジェクトの契約を記述する方法についてのアドバイスを提供します。以下、RSS feed / longer summary (max 400 chars)です。 従来のウォーターフォールモデル手法,すなわち要件を定義し,サプライヤが価格を提示して,両者が法的拘束力を伴う契約書にサインする,というやり方は,企業が何かを購入する場合にはとても都合のよいものです。しかしこの方法で記述された契約書には,アジャイルアプローチを使った開発に必要な自由がほとんどありません。この記事では,サプライヤと顧客がアジャイル開発の契約を締結するために利用可能な,4つの異なったモデルを検証しています。

  • リーンやアジャイルの契約書の書き方

    アジャイルやリーンのプロジェクトは従来のプロジェクトとは違う。ではこれらのプロジェクトの契約はリーンやアジャイルの概念をサポートしているだろうか。それとも邪魔になっているか。この記事ではリーンやアジャイルプロジェクトの効率的な契約書の書き方についていくつかのヒントを紹介する。

  • ThoughtWorksによる最新技術動向の概括

    ThoughtWorksは2011年1月版 (PDF)のTechnology Radarを発表した。これは現在のソフトウエア技術の動向を簡潔にまとめた文書だ。

  • Agile 2011で実際の顧客から聞く

    Agile 2011での「顧客と一緒に働く」ステージは、アジャイルチームの顧客から話や報告を求めている。このステージは、顧客のコミュニティとアジャイル開発チームとの関わりを研究する。非技術的な機能と同様に、アジャイル開発チームそのものにも焦点を当てている。この記事では、ステージの企画者が質問に答え、実際の顧客に訴える。

  • スクラムにユースケースは使えるか?

    スクラムでは一般的に,要件はユーザストーリーで表される。ではユースケースの使用も認められるだろうか? 認められるとすれば,どのような状況で用いるべきだろうか?

  • どんなアジャイル指標が報告されるべきか?

    よい測定はよい管理を後押しする。では、マネジメントがアジャイルソフトウェア開発プロセスをもっとも支援できるようにするには、どんな指標がマネージメントの流れに沿って打ち上げられるべきなのだろうか?

BT