InfoQ ホームページ マネジメント に関するすべてのコンテンツ
-
Adobe が Hadoop のための Puppet レシピをリリース
Adobe は先日，Hadoop/HBase デプロイメントを自動化するための Puppet レシピをコミュニティ向けにリリースした。InfoQ では PuppetLabs の創設者である Luke Kanies 氏に，その目的について詳しく聞いた。
-
ビジュアルリスクマネジメント
プロジェクト規模に関係なく、リスクとその緩和戦略を把握できているとき、ステークホルダは心強く感じるものだ。アジャイルは情報発信器の利用を強く推進している。その情報発信器の考え方に基づき、アジャイリストはリスクのトラッキングと緩和を容易に行える様々なビジュアルなリスク表現法を考案した。
-
FAI: Linuxのインストール、管理、カスタマイズを自動化する
FAI (Fully Automatic Installation) は、Linuxシステムを手動でインストール、カスタマイズ、管理するという退屈な反復作業から逃れるための非対話型システムだ。最近では、数台の単一システムのセットアップから数千台ものシステムからなる大規模なインフラやクラスタのセットアップまで、chroot環境や仮想マシンおよび物理マシンを管理するのに使われている。
-
Puppet: Rubyベースのサーバ管理自動化スイート
Reductive Labsのチームは先日、Unix、Linuxサーバのシステム管理を自動で行うための、Ruby製オープンソースツールPuppet 0.25.2のリリースを発表した。今回はバグフィックスリリースであり、123のチケットが解決された他、メモリ使用量の削減や、エラーレポート、スレッディング、ロック競合の改善などが行われている(後者はシステムハングの原因だったようだ)。
-
アジャイルはマイクロマネジメント
マイクロマネジメントは通常、あまり良い意味で使われない。このマネジメント方法は、マネージャが部下や社員の近くで仕事について細部まで指示する方法だ。普通、アジャイル開発とマイクロマネジメントは正反対の手法と考えられがちだか、表面上の違い以上に強く関連している。
-
よいアジャイルなメトリクスとは何か?
適切でアジャイルな計測とは何だろうか?もし伝統的な計測方法である、アーンドバリュー、労働時間、コード行数、テストによるコードカバレッジがアジャイルなプロジェクトにはあまり適さないのであれば、どういう方法があるのだろうか?よりよいアジャイルなメトリクスを選ぶ上で助けとなる、私たちが決められるルールは何だろうか?
-
自己組織化を導くことは、オーケストラを指揮するようなものか？
伝統的なマネジメントモデルは、自己組織化を妨げることなくどうやってア���ャイルチームをサポートするのかということについて、リーダに教えてはくれない。音楽の演奏と「オーケストラの指揮」に喩えられることも多いが、それが適切であると誰もが合意している訳ではない。「指揮者」モデルは優れたプラクティスなのか、それともアンチパターンなのか？TEDトークにおいて指揮者のItay Talman氏が示したのは、これは指揮者が何をしていると考えるかによるということだった。
-
アジャイルの本質的な要素
アジャイルを成功させるためには、どのスキルが開発者に必要か、またどのプラクティスが組織に適用できるか、多くの議論が行われてきた。しかし、アジャイルを成功させるために本当に欠かすことのできない重要な心はなんだろうか。Mark Schumann氏はアジャイルの"本質的な要素"としてアジャイルの基底的なテクニックではなく、正確にいえば<em>アジャイルの考え方と管理を共に位置づける事を提唱する。
-
SOAのマネージメント戦略
Mike Kavis氏が、SOA instituteに書いている記事で、SOAを実装する成功要素として、人、プロセス、技術そしてビジネスの４つを上げている。彼は、よいマネージメント戦略とは、これらの各分野での、重要な成果物を作り上げるロードマップを作り、それを伝達することである、と信じている。
-
ふりかえりについてのふりかえり
組織内のどのチームもアジャイルを用いていて、それぞれ局所的な改善を実装するので手一杯だった場合、正式に｢IT｣ないし「システム開発」と呼ばれるようなより大きな組織では何が起こるのだろうか？これについて巨大なアジャイルプログラムを抱えるコーチが、自分たちの立てた戦略を共有した。これはより��きな組織が全体の動向を把握し、そこから学ぶことで利益を得られるように作られている。Paulo Caroli氏はこれを「ふりかえりについてのふりかえり」と呼んでいる。
-
Lean & Agile をリードする - すべては皆のため
Mary & Tom Poppendieck 両氏は新刊 "Leading Lean Software Development: Results Are Not the Point" を発表した。同書で両氏は Lean/Agile 変換におけるリーダーシップの重要性について調査研究し，変革を求める組織に対して助言を与えている。
-
デマルコ、ソフトウエアエンジニアリングの40年間を振り返る
NATOのソフトウエアエンジニアリング会議から40年経ち、トム・デマルコはソフトウエアエンジニアリングの信念の進化において、自身が支持したメトリクス指向の方法論が、"変革を起こすこと。世界を変えるソフトウエアを作ること。"を目的にする現実の開発現場では、本当は邪魔になっていたのではないかと、振り返った。それとも、彼の当初の助言はやはり有効なのだろうか。彼自身は、"有効ではなかった"と、Software Engineering誌の"時代はやって来て、そして過ぎ去ってしまったのか"と題した記事で書いている。
-
アジャイルへの移行を正当化するコスト
「金を見せてもらえないことには…」――アジャイル・マイグレーションの正当化コストは争点の多い問題である。アジャイル・アプローチのほうが成功しており、より迅速に価値を提供し、より良い品質の製品を製造する。だがそれをいかにして証明するか？この記事ではその測定について説明し、アジャイル・メソッド採用の正当化に寄与する結果を提示する。
-
-
アジャイルのリスク管理
リスク管理は、リスクを判断し、軽減し、監視することに向けて行われる活動だ。多くのアジャイル実践者は、アジャイルプロジェクトのリスク管理のプロセスが従来のプロジェクトとそれほど異なっていないと確信している。