InfoQ ホームページ Complex_Systems に関するすべてのコンテンツ
-
大規模システムの保守における技術的負債とチームのモラル
Agile Testing Days 2015において、Thomas Bradford氏はテストがなく大きな技術的負債のあるモノリシックなJavaベースのシステムの保守に関する経験について語った。 InfoQは、システムを保守する上での問題や作りこまれた技術的負債、なぜ別のアプローチをとったのか、どうやってチームのモラルを向上させたのかについて氏にインタビューした。
-
月へ(To the Moon) - 宇宙計画とソフトウェア開発の共通性
Russ Olsen氏がGOTO Berlin 2015カンファレンスで“To the Moon”と題した基調講演を行った。InfoQは氏にインタビューして，期限に間に合わせるためにすべてを同時に実行する方法の問題点，失敗や成功から学ぶということ，ソフトウェア開発において些細なことがいかに命取りになるか，複雑な作業において各詳細に集中して対処するにはどうすればよいか，などを聞いた。
-
リビルドか，リファクタか
ソフトウェアはリビルド(再構築)すべきか，リファクタリングすべきか？Wouter Lagerweji氏とのインタビューから，リファクタリングを困難にしているものは何か，ソフトウェアのリビルドがリファクタリングよりリスクが少ないのか，継続的デリバリがソフトウェアのリビルドに対してどのように好都合なのかを考える。
-
スケールアップのジレンマに対処するには
複数のチームが一緒に仕事をするというのは，時には困難が伴うが，大規模で複雑な製品を開発し提供するために不可欠なことも多い。アジャイルのスケーリングにまつわるジレンマをテーマとした，Agile Adria 2015カンファレンス基調講演の中で，Poppendieck氏は，アジャイルのスケールアップを望む組織にヒントを示してくれた。
-
企業のマインドフルネスと状況把握
プロセスから無駄を排除するには、ジャストインタイムで提供できる流れが必要だ。そして、人間の知性によって構築されたプロセスの問題に対処するための、企業でのマインドフルネスや状況把握が必要になる。ますます多くの企業が流通の概念を導入して必要なときに必要なものを開発し、在庫を抱えるのを回避しようとしている。このような企業に必要なのは“自動化”、つまりマインドフルネスと状況把握だ。
-
複雑度を測定してソフトウェア品質を改善する
ソフトウェア複雑度はソフトウェアの品質とコストの直接的な指標だ。コードの複雑度が高ければ、そのコードの品質は低くなり、それを管理するコストは高くなる。複雑度の測定は、開発とテストのための見積もりや、品質向上と問題防止のためにリファクタリングが必要なところの判断に使うことができる。
-
アジャ��ルでユースケースを利用する - ユースケース2.0，スライシング，ラミネーティング
アジャイルソフトウェア開発を使って製品をインクリメンタルに開発し提供する場合，要件項目はプロダクトバックログに収集，整理される。ここで使用される要件定義テクニックはユースケースだ。アジャイルの製品要件管理でユースケースを利用するテクニックには，ユースケース2.0やスライシング，ラミネーティングなどがある。
-
サウンド・オブ・サイレンス：「理解する」と「聞く」を向上するワークショップ
Agile Tour BrusselsカンファレンスでLuc Taesch氏は「理解すること」と「聞くこと」に関するワークショップを行った。氏はそこで"認知科学"あるいは"神経科学"をITプロフェッショナルに紹介し，思考の中断や感情の処理を支援するためのソリューションを提示した。
-
正しいもの作りのためのシンプルさ
GOTO Amsterdam 2013のhard things made easy（難しいことを簡単に）というトラックにおいて、Russ Miles氏が5つの問いによる正しいもの作りについてライトニングトークした。彼はインパクトマッピングから4つの問い「Why? Who? How? and What?」を引用しつつ、「すべての根拠になっている仮説は何ですか？」という問いを加えた。InfoQでは、シンプルさによる正しいもの作りについて、Russ Miles氏にインタビューした。