InfoQ ホームページ 補完実践 に関するすべてのコンテンツ
ニュース
RSSフィード-
よりアクセスしやすいソフトウェアシステムを開発するための十戒
ハイブリッドワークプレイスへの急速な移行は、デジタルコンテンツ消費の加速も意味する。オンラインはグローバルに手が届くことを意味するが、さまざまな種類の障壁のために、世界の人口の一部はオンラインにアクセスできない。Julien Dubois氏はDevoxx UKの基調講演で、ソフトウェアをよりアクセスしやすくするための一連のベストプラクティスと設計原則を示した。
-
個人の生産性
Tony Wong氏(プロジェクトマネジメントのブラックベルト)は個人の生産性にとって実践的なポイントをいくつか挙げている。この記事では、これらをいかにソフトウェア開発に適用するかを考え、彼のリストと他のリストを比べる。
-
バリューストリームマッピングはソフトウェア開発でも有効か？
バリューストリームマッピングはリーン(lean)生産技法のひとつであり，製品やサービスを消費者に届けるのに必要な，材料と情報の流れを分析するために使用される。製造業において Toyota が実施に成功したこのプロセスが，ソフトウェア開発においても適用されている。ソフトウェア開発は製造業と同じ道をたどるのだろうか？
-
アジャイルの"ルール"を"ガイドライン"に変えられるか？
一般的にルールとは，ある行動に関して定義された基準のことをいう。ルールには従わねばならない。法律の非公式な呼び方が "ルール" である，と言い換えてもよいだろう。これに対してガイドラインとは，決められた手順に従うことによって，特定のプロセスを合理化する目的のものだ。定義上は，ガイドラインは義務ではない。アジャイルチームはルールを語るべきだろうか，それともガイドラインで十分なのだろうか？
-
ふりかえりについてのふりかえり
組織内のどのチームもアジャイルを用いていて、それぞれ局所的な改善を実装するので手一杯だった場合、正式に｢IT｣ないし「システム開発」と呼ばれるようなより大きな組織では何が起こるのだろうか？これについて巨大なアジャイルプログラムを抱えるコーチが、自分たちの立てた戦略を共有した。これはより大きな組織が全体の動向を把握し、そこから学ぶことで利益を得られるように作られている。Paulo Caroli氏はこれを「ふりかえりについてのふりかえり」と呼んでいる。
-
ビジネス価値を基準に(バックログの)優先順位を付ける
ビジネス価値を基準に(バックログの)優先順位を付ける。Luke Hohmann氏は、バックログのどの項目から検討を始めるべきかについて定量的な判断を下す方法を述べている。
-
アジャイルの採用に関する感��的な障害
Amr Elssamadisy氏 (『Agile Adoption Patterns: A Roadmap to Organizational Success』の著者) はAgile2008でアジャイルの採用における非技術的な障壁をテーマにセッションを行った。彼は「年を重ねるにつれて、もっともややこしい問題は技術ではなく人の問題であることに気づいたんだ」と言った。
-
アジャイルプロジェクトにおけるトレーサビリティ・マトリックス
形式ばったトレーサビリティ・マトリックスは、しばしばアジャイルコミュニティから強い反応を引き起こしている。Agile Testingグループでの激しい議論の中で、Jorge Argus氏はアジャイルプロジェクトにおけるトレーサビリティ・マトリックスの必要性に関する興味深いスレッドを立てた。
-
Article: AgileEVM: 製品ライフサイクル全体で費用対効果を計測する
AgileEVMは、出来高管理の指標を使用した基準計画と比較し、コスト、スケジュール及びスコープの実際の値を計測する伝統的なプロジェクト管理手法を適応したプロジェクト管理手法です。
-
よく組織されたチーム：単に生き残るのではなく、成功へと導く支援
業績の良いチームを編成するには何が必要なのか？Doug Shimp氏およびSamall Hazziez氏によると「よく組織されたチーム」は以下の特徴があるらしい。AgileおよびLeanの原則に従う、フィードバックループがある適応システムを使用、ビジネスの展望にフォーカス、そして熱意があり非常に生産的である。
-
デザインやコードの良いレビュー、悪いレビュー、そして酷いレビュー
デザインとコードレビューに関する興味深い記事でKirk Knoernschild氏は、レビューを行うということは、ソフトウェアの品質を改善することを約束し、基準の順守を保証し、そして価値ある開発者の教育ツールとなると述べている。しかしながら、レビューの実施方法にその効果は左右される。レビューは、ある組織ではソフトウェア開発工程で本当に意味のあるものであるかもしれないが、その一方で別の組織では形式的なお役所仕事の一部となってしまっているかも知れない。
-
Article: ３つのM - リーンの３要素
リーン主義をソフトウェア開発に適用することについての議論では、主にムダ（無駄：Muda）なものを特定して排除することに関心が向けられてきました。リーン思考は同様に、ムリ（無理：Muri）とムラ（ばらつき：Mura）を削除することも目指しています。
-
成功するコラボレーションには偶然などない
パートナーシップコーチのMichael Spayd氏は契約社員と正社員は両方ともプロジェクトに取り掛かる際にコンサルタントとしての役割を果たすことができ、またクライアントとコンサルティング系統の契約を発展させていくという提案を記した記事をInfoQに提供した。これは通常の”契約”という用語とは異なる意味を持っている。サービスプロバイダとクライアント間の法的な決まりごとである。彼の"Designed Partnership Contract"は金銭の交換に関するものではなく、”コンサルタント”がコミュニケートし、自身達の価値観と嗜好を大切にするのを可能にする一方、より良いクライアントとのコラボレーションを成すために使用されるものである。
-
私は自信がない。あなたの聞いたことが、私が言ったと思っていることかどうか。
コミュニケーションそれ自身は難しくも何ともない、と言わんばかりに、私たちの職場は専門用語であふれている - ビジネスドメイン用語、製品用語、開発者用語など。そのため私たちはそこにコミュニケーションがある、と言われても驚きはしない - しかし私たちは、目をぐるぐる回したりマーフィーの法則を引用したりする代わりに、それを捉え、対処することができているのだろうか？