InfoQ ホームページ Delivering Value に関するすべてのコンテンツ
-
実験と価値提供のバランスをとる
リーンスタートアップの実験は顧客について学び、どのような機能に価値があるのかを判別する手助けをしてくれる。しかし、価値は製品を作り、実際に顧客に届けることで生まれるものだ。実験とデリバリのバランスを上手くとる必要がある。
-
-
あれから10年、いまアジャイルが熱い。アジャイルサムライ他流試合レポート
2011年9月18日、アジャイルに熱いサムライ達が東京に集結した。「アジャイルサムライ 他流試合」というイベントに参加するためである。「アジャイルサムライ」はJonathan Rasmusson氏によって執筆されたアジャイルの解説書である。発売以降、日本の技術者の心を掴み続け、各地で読書会が開かれている。そして、その読書会の参加者達が一同に集まるイベントがこの「他流試合」だった。
-
プレゼンテーション: 最悪でないアプリケーションをつくる
驚きと喜びをもたらすアプリケーションを開発することは、明確に話したり定量化するのが難しい靄の中のゴールのように思われる。しかし、InfoQに投稿された最新のプレゼンテーションの中で、DeliciousライブラリやTap Tap Revenge、Obama氏の2008年のiPhoneアプリケーションなどに取り組んだソフトウェア開発者であるMike Lee氏は、よりよいアプリケーションを構築するためのアルゴリズムを提案した。
-
プロダクトオーナーにバックログを優先順位付けさせる方法
スクラムは優先順位付けされたプロダクトバックログがあることで最も効果的に機能する。バックログを優先順位付けするのはプロダクトオーナーの役割なのだが、プロダクトオーナーが優先順位付けの価値を理解していないためにバックログを優先順位付けしないとき、あなたには何ができるのだろうか？
-
アジャイルアーキテクチャ - 矛盾? それとも賢明なパートナーシップ?
アジャイル技術とアーキテクチャに関する考え方の間にある意見の相違について、数多くの解説者たちが話題にしている。 この投稿は、Big Up Front Design (BDUF) と You Aint Gonna Need It (YAGNI)の考え方の間にある緊張状態を調べ、2つのアプローチが好意的なやり方で実際に協力できる方法を探る。
-
アジャイルと"ユーザ中心設計"の調和
UX のスペシャ��ストである Anthony Colfelt 氏がアジャイルについて，それが単独では不完全なものであることを論証するとともに，ユーザ中心設計のアジャイルへの統合の可能性とあるべき姿に関して，詳細かつ興味深い検証を行う。
-
-
継続的デプロイのプラクティス
継続的デプロイは、リーン開発の"仕掛排除"運動で最近注目されている。多くの人が、これについて興味を持ち、価値のある目標を見出している一方、これが実際どのように達成されたかをなかなか可視化できていない。Ash Maurya氏は会社で起こった自身の経験を説明することで、このギャップを埋めようとしている。
-
ビジネス価値を見積もる
従来のアジャイル開発では優先順位をつけるとき、ビジネス価値の低いユーザストーリーよりもビジネス価値の高いユーザストーリーを優先して実装する。このやり方はシンプルだが、うまく実装できるかどうかはビジネス価値を評価する仕組みがあるかどうかにかかっている。Pascal Van Cauwenberghe 氏は最近、ビジネス価値を定義する方法について説明している。この方法は"ビジネス価値モデリング"と呼ばれ、役に立つかもしれない。
-
リファクタリングかリライトか？
リファクタリングやリライトの目的は、コードの可読性、構造、明確さを改善することでシステムの健全さを改善する点にある。クリーンなコードはメンテナンスもエンハンスも楽だろう。しかし、多くの状況下にて、アジャイルチームはリファクタリングとリライトのどちらを行うかで厳しい選択を迫られる。
-
フォレスターがビジネス向けリーンに関する無料の調査報告を公開
フォレスターリサーチは来週のビジネス・テクノロジフォーラムに先んじて、アナリストによる調査報告”リーン、新たなるビジネス・テクノロジ規範”を無料で公開した。リーンをビジネス全体の規範として管理者向けに書かれており、ITへの影響にも触れている。”価値の創造と柔軟性の増加を忘れて、無駄の排除に没頭してはいけない”との注意もある。
-
価値とベロシティ、そしてバリューベロシティの比較
多くのアジャイルチームでは'価値'とチームの'ベロシティ'は正比例すると、暗黙的に前提している。幾つかのケースにおいては本当にそう見られる。しかしながら、多くの場合はチームのベロシティが本当に価値を提供できたかはほとんど示されない。
-
ベロシティは何のため？
最近、ScrumDevelopment Yahoo!グループでは、ベロシティの活用と誤用に関して様々な議論がなされている。ベロシティを生産性の基準として使うべきだろうか？イテレーション計画のために使うべきだろうか？もっと長期のリリース計画にはどうだろうか？
-
立ち止まってリファクタリングをする？
いつリファクタリングをするべきなのだろうか？単純に技術的負債（"technical debt"）を返済しなければならない時もあり、そこでは立ち止まってリファクタリングをするべきなのか。そうではなくて、ユーザストーリーに関わっている時だけしかリファクタリングするべきではないのか。どちらのアドバイスが正しいのだろうか？あるいは、もしかしたら第３の選択肢が存在するのだろうか？