BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ 顧客要求 に関するすべてのコンテンツ

  • アジャイル,DevOps,自社製品の社内利用

    DBmaestro共同創設者でCTOのYaniv Yehuda氏にインタビューした。彼らがアジャイル開発をどのように実行し,DevOpsを利用しているのか,継続的デリバリや困難だと言われるアジャイルプラクティスをどのように実践しているのか,さらにはアジャイルやDevOpsプラクティスを使うことによって,どのようなメリットを得られているのだろうか。

  • 振る舞い駆動開発入門

    振る舞い駆動開発(BDD/Behavior-Driven Development)は,開発対象に対する開発者の理解と,要件によって生じる技術的課題に対するビジネス側の理解とのギャップを克服するために有効だ。その理由は,2つのグループ間のコミュニケーション促進にある - Alistair Stead,Konstantin Kudryashov両氏は,BDDの初心者向けガイドの中で,このように説明している。

  • PMIがBusiness Analysis CertificationとPractice Guideをローンチ

    先日のProject Management Institute Global Congressで,Business Analysis Practice Guideが発表された。今年11月にローンチされた,PMI-PBA(Professional in BusinessAnalysis)を補完するものだ。InfoQではBusiness Analysis and Requirements Program Managerを務めるDave Bieg氏に,今回のPractice Guideと認証について話を聞いた。

  • 定量的かつ正確にソフトウエアの価値を定義する

    製品の本当の要件は必要な機能や提供されるべきユーザストーリーではない。顧客が製品を買うことで得られるパフォーマンスの向上の可能性が本当の要件だ、とMatteo Vaccari氏は言う。XP Days Benelux 2014カンファレンスで、氏はAntonio Carpentieri氏とともに、顧客が必要な価値を定義することについてワークショップを開催した。

  • 企業のマインドフルネスと状況把握

    プロセスから無駄を排除するには、ジャストインタイムで提供できる流れが必要だ。そして、人間の知性によって構築されたプロセスの問題に対処するための、企業でのマインドフルネスや状況把握が必要になる。ますます多くの企業が流通の概念を導入して必要なときに必要なものを開発し、在庫を抱えるのを回避しようとしている。このような企業に必要なのは“自動化”、つまりマインドフルネスと状況把握だ。

  • 自動車システムのためのアジャイルテスティング

    アジャイルテスティング(Agile Testing)は,自動車システムのソフトウェア開発に応用することができる。アジャイル手法を自動車に適用するには,Automotive SPICE-Vモデルをアジャイルに適用することが必要だ。アジャイルとSPICEを組み合わせた成果として,Xavier Martin氏は,QA&Test 2014カンファレンスでのプレゼンテーションで,"集中的な自動テストとクライアントのデモンストレーションが,よりよい製品を生み出し,顧客満足を向上するのに役立っています",と述べている。

  • アジャイルでユースケースを利用する - ユースケース2.0,スライシング,ラミネーティング

    アジャイルソフトウェア開発を使って製品をインクリメンタルに開発し提供する場合,要件項目はプロダクトバックログに収集,整理される。ここで使用される要件定義テクニックはユースケースだ。アジャイルの製品要件管理でユースケースを利用するテクニックには,ユースケース2.0やスライシング,ラミネーティングなどがある。

  • Gojko Adzic氏のユーザストーリー改善についての新著

    優れたユーザストーリーはソフトウエアの提供を改善するだろうか。Gojko Adzic氏はチームのユーザストーリーの管理の仕方を小さく変化させることで最終的な成果に大きく影響を与えることができると言う。1月中に関心がある人が5000人集まったら執筆するという。

  • アジャイルにおけるドキュメント:いつどれくらい書くべきか

    アジャイルソフトウェア開発マニフェストは「包括的なドキュメントよりも動くソフトウェア」に価値を置いている。そうだとすると、どんな種類のドキュメントが、いつどれだけ必要なのだろうか?

  • 振る舞い駆動開発(BDD) - コラボレーションによる価値創造

    ソフトウェアプロジェクトの目的はステークホルダに価値を提供することだ,BDD(Behavior-Driven Development,振る舞い駆動開発)は,そのためにデザインされた – ウォーターフォールからアジャイルプロセスへの移行に取り組むソフトウェア開発者のViktor Farcic氏は,自身のBDDに対する見方を述べた4つのブログ記事の冒頭でこう説明している。

  • カンバンで需要と能力のバランスをとる

    カンバンを使うことで、組織は実施中の作業を把握し、需要と能力のバランスがとれるプルシステムを確立できる。まずは実際の能力がどの程度あるかを見極め、その能力の流れを可視化することだ。InfoQはFlorian Eisenberg氏にインタビューし、どのように需要と能力のバランスをとるかについて話を聞いた。

  • プロダクトオーナーの役割を拡大するには

    スクラムのプロダクトオーナーの役割はビジネスと開発の橋渡しをすることだ。複雑な商品を持ち多くの決定をする必要がある大きな組織では、プロダクトオーナーの役割をひとりで担うのは現実的ではない。このような場合、何らかの方法でプロダクトオーナーの役割をスケールアウトしなければならない。InfoQはTimo Punkka氏にインタビューを行い、プロダクトオーナーの役割、リーンポートフィリオマネジメント、顧客との協業について話を聞いた。

  • ウォーターフォールからアジャイルへの移行によるムダの削減

    組織がアジャイルを採用するのは,変化への対処を可能にするためだ。アジャイルは開発チームにとって,顧客ニーズを満足する製品を提供する上で有効な手段であると同時に,必要のない(使用されない)機能を含まない製品を提供する手段でもある。リーンソフトウェア開発は言う:ユーザに価値を提供しないものは,すべてムダとみなされると。ならばウォーターフォールからアジャイルへのソフトウェア開発の移行は,開発組織のムダ削減に役に立つのだろうか?

  • アジャイル手法は個人の作業にも適用可能か

    アジャイルへの移行は,チーム全体,プロジェクト,あるいは組織単位で行うのが普通である。アジャイルはチームを主体とするアプローチだからだ。ところが,個人でアジャイルプラクティスの利用を始めたり,ワン・パーソン・チームとしてアジャイルを実践しているプロフェッショナルが存在するのだ。どうすれば個人でアジャイルを採用できるのだろう,そして,どのようなメリットがあるのだろう?

  • アジャイルの柔軟性 : 短所か長所か

    “計画に従うのではなく変化に対応する”ことは実践では役に立たないアジャイルの強みなのだろうか。例えば、過度の柔軟性を期待する顧客と変化を管理しなければならないプロジェクトの難しさはどうだろう。アジャイルは期待される効果を発揮できないのだろうか。それとも、チームや組織がアジャイルを導入する方法に問題があるのだろうか。

BT