BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ Productivity に関するすべてのコンテンツ

  • JustCode Q3 - キーストロークを削減して生産性を向上

    JustCode Q3は、頻繁に使用するタスクを自動化することにより開発者のコーディング量を最小化し、生産性を向上させる。

  • 生産性を向上する Visual Studio 2012 Power Tools

    Microsoft は先日 Power Tools for Visual Studio 2012 をリリースした。3つの機能を新たに加えて,開発者の生産性を向上する。

  • コミュニケーションパターンの精密科学

    MITのAlex "Sandy" Pentland教授は、Harvard Business Reviewのインタビューで、チーム生産性のコンテキストにおける、計量社会学のバッジを使用した彼の実験について語った。彼の研究は、あなたとあなたのチームメンバーが仕事でもっと効率的になり、もっと満足できるようになる、最適なコミュニケーションパターンを明らかにするのに役立つ可能性がある。

  • アジャイルチームで割り込みを扱う7つのオプション

    割り込みはどのチームでも扱わなければならないものであり、扱い方が適切でなければ、納品する能力に不利益をもたらす可能性がある。Agile Adviceブログの最近の投稿で、スクラムや繰り返されるアジャイルアプローチを使っている場合に、チームがどのように割り込みに対処するかについて考慮すべき7つのオプションについて、Mishkin Berteig氏が述べている。

  • ハイパフォーマンスなチームを実現して維持するには

    アジャイルプラクティスはハイパフォーマンスな自己組織化したチームを育成しなくてはならない。チームが正しい問題を解決するよう、ハイパフォーマンスが価値を届けることに等価であることが重要だ。また、ハイパフォーマンスなチームが活躍できる環境づくりも重要であり、これにはマネジメントレベルでの検討と行動が必要になる。ハイパフォーマンスなチームの実現について、私たちは3人のコメンテータの視点について調査した。

  • VelocityによってAgileは死んでしまうのか?

    チームによって完遂され、完遂するまでにかかった時間で分割される仕事の尺度であるVelocityは、チームの生産性を管理するためやチーム間の比較の尺度として用いられるようになっている。Jim Highsmith氏、Mark Levison氏、そしてScott Ambler氏は生産性の尺度としてのVelocityの間違った使い方に関して議論する。

  • アジャイル界隈ではシンプルなツールが好まれる

    アジャイルでは必ずしもツールの利用を必須・推奨しているわけではない。理想的���は、インデックスカードに書かれた要件を使ってコマンドラインインターフェイスでも開発はできるだろう。しかし、この数年、さまざまなツールが現れて、アジャイル開発の成功を促進している。最近、Migan氏とGaia氏はアジャイル界隈におけるツールの利用調査を実施した

  • 「邪魔をしない」ことを要望するチームメンバ

    多くの開発者は、孤立して作業をしたがるが、それは多少の時間であり、決して常時というわけではない。XPでは、「洞穴と共通の部屋(Caves and Commons)」と呼ばれる部屋の配置を推奨している。共通のエリアは、浸透性のあるコミュニケーションを最大化するように構成されている。洞窟は、個人的なメール、電話、クイック・スパイクなどを行うための孤立を推進することを意味する。ところが、チームメンバが、このような孤立した状態での作業を過度に要望することがある。

  • コンテキストスイッチ対策が必要だって?じゃあ邪魔されよう

    コンテキストスイッチとは、あるタスクから別のタスクへと、焦点や注意を比較的短時間で切り替えることだと定義される。これはチームメンバとその人が取り組んでいるプロジェクトにとって、有害であると広く考えられている。Charles Miller氏はAtlassian社で使っていたコンテキストスイッチに対処する方法について述べた。

  • アジャイルが「チームの5つの機能障害」に取り組む

    ITマネージメント・ソリューションの大手プロバイダにおける部長である、Tathagat Varma氏は、アジャイルの生産性改善がチームワークの改善に繋がるのではないか、と思った。彼は、アジャイルの価値と実践をPatrick Lencioniのビジネス物語「チームの5つの機能障害」と対比させて、分析している。

  • 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氏は、最大の生産性はコミュニケーション、コードの読み取り可能性およびデバッグ可能性が改善されることにより、もたらされると考えている。

BT