InfoQ ホームページ Productivity に関するすべてのコンテンツ
-
コンテキストスイッチ対策が必要だって？じゃあ邪魔されよう
コンテキストスイッチとは、あるタスクから別のタスクへと、焦点や注意を比較的短時間で切り替えることだと定義される。これはチームメンバとその人が取り組んでいるプロジェクトにとって、有害であると広く考えられている。Charles Miller氏はAtlassian社で使っていたコンテキストスイッチに対処する方法について述べた。
-
アジャイルが「チームの５つの機能障害」に取り組む
ITマネージメント・ソリューションの大手プロバイダにおける部長である、Tathagat Varma氏は、アジャイルの生産性改善がチームワークの改善に繋がるのではないか、と思った。彼は、アジャイルの価値と実践をPatrick Lencioniのビジネス物語「チームの５つの機能障害」と対比させて、分析している。
-
Kent Beck氏、ごく短期のプロジェクトではテストを省略することを提案
Kent Beck氏は、ごく短期のプロジェクトにおいて、実行可能なコンセプトがあるかどうか判断するときには、すばやく軌道に乗せるために自動テストをあまり（あるいはまったく）やらなくても構わないと提案している。これはTDDを取り巻く従来の見解に反するものだ。
-
なぜTDDとペアプログラミングで生産量が増えるのか
テスト駆動開発」と「ペアプログラミング」は、アジャイルプラクティスで最も広く知られているものの2つであるが、まだそれほど多くのアジャイルチームによって実践されてはいない。たいていその理由として、TDDやペアプログラミングなどのプラクティスを取り入れるには「忙しすぎる」点が挙げられるだろう。要するに、これは高いコード品質を得ようと努力することが生産性を低下させることを示唆している。Mike Hill氏は、この論理がなぜ重大な誤りであるか説明している。
-
5人はチームの最適なサイズか？
最大の生産性のための最適なチームのサイズに関して、たくさんの議論や討論が行われている。大半のアジャイリストは、大きなチームに比べて小さなチームは機能的で生産性が高いという意見に同意しているが、最適なチームのサイズを定義することは依然として難題である。
-
「結合テストはでたらめだ」- J.B.Rainsberger氏による連載の紹介
著名なアジャイリストでテスト駆動開発のエキスパートでもあるJ.B.Rainsberger氏（J.B. Rainsberger）が始めたブログでの連載では、「結合テストはでたらめだ」という考えさせられる見解になぜ氏が行き着いたかの説明がなされている。
-
ボトルネックの制約がある中での改善への視点
My Framework is More Productive than Your Frameworkの中で、Ken DeLong氏はソフトウェアプロジェクトをさらに生産的にするアプローチについて検証している。���レームワーク、言語およびプロジェクト管理ツールに関する宣伝にもかかわらず、これらはボトルネックにならない傾向にある。Ken氏は、最大の生産性はコミュニケーション、コードの読み取り可能性およびデバッグ可能性が改善されることにより、もたらされると考えている。
-
コンピュータを無視して集中しよう
アジャイルを実践している人たちは、プロジェクトやチームで「コンテキストスイッチング」が起きた場合の、生産性への悪影響が分かるようになった。同じアイデアを毎日の仕事や個人の対話のレベルでどの程度まで適用し、そしてマイクロレベルのマルチタスキングの問題を避けるために何が出来るのだろうか？Phil Gerbyshak氏がアドバイスをしている。
-
アジャイルの生産性をドルで測る
以前Scott Ambler氏は、加速度を利用してアジャイルチームの生産性を測る方法に関する記事を投稿した。最近、彼は引き続き別の記事を投稿したが、そこではアジャイルの生産性と加速度に関係のある、いくつかのよくある質問（FAQ）に答えている。
-
「良いデザイン」とは?
ソフトウェアプロジェクトが成功する上で(および、実のところソフトウェア職に携わる上でも)、要となるのは良いデザインであるということは、今さら言うまでもない。「良いデザイン」が何を意味するのかを定義することは、一連の終わりのない討論、論文、話し合い、議論などで、長い間大々的に取り上げられてきた。これも新しいことではない。J.B.Rainsberger氏およびScott Bellware氏が真の定義がなされるまでフォローすると役立つアドバイスを提供している。
-
チームの腐ったリンゴを扱う
ここ数日間、Scrum Development Yahoo Groupでチームの1人の「働きが少ない」場合に何をするかについてとても活発な議論がなされている。Rotten apple in Scrum team(スクラムチームの腐ったリンゴ) の130以上のレスポンスの中で、最初の質問へのアドバイスから、チームのやる気や誰がそれを管理するかという話、個人を計測する昔からの論争、チームが本当に「チーム」であるかどうか見分けることなどへ議論が及んだ。
-
ふりかえりを改善するための秘訣
「Agile Retrospectives: Making Good Teams Great（邦訳：アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き）」の共著者であるEsther Derby氏は先ごろ、ふりかえりを改善するためのテクニックについて書いた。
-
コードの構築に、OOPは最適?
パワーおよび柔軟性を提供するプログラミング言語が、近ごろ勢いをつけている。しかしながら、Johnatan Tang氏はプログラム構造の観点から、柔軟性対生産性の矛盾があることを強調している。
-
インフラがアジャイルソフトウェアチームを楽にする
アジャイルマニフェストは「プロセスとツールよりも個人と相互作用」を尊重する。しかしながら、ツールとプロセスをうまく混ぜ合わせるとアジャイルチームの成功の触媒の役割を果たすことがよく起こる。アジャイルの導入が増え、多くのチームが分散環境で働くという事実の中で、適切なインフラを持つことがアジャイルチームの成功の重要な要因となっている。
-