BT

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

寄稿

Topics

地域を選ぶ

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

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

    アジャイルでは必ずしもツールの利用を必須・推奨しているわけではない。理想的には、インデックスカードに書かれた要件を使ってコマンドラインインターフェイスでも開発はできるだろう。しかし、この数年、さまざまなツールが現れて、アジャイル開発の成功を促進している。最近、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氏は、最大の生産性はコミュニケーション、コードの読み取り可能性およびデバッグ可能性が改善されることにより、もたらされると考えている。

  • コンピュータを無視して集中しよう

    アジャイルを実践している人たちは、プロジェクトやチームで「コンテキストスイッチング」が起きた場合の、生産性への悪影響が分かるようになった。同じアイデアを毎日の仕事や個人の対話のレベルでどの程度まで適用し、そしてマイクロレベルのマルチタスキングの問題を避けるために何が出来るのだろうか?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氏はプログラム構造の観点から、柔軟性対生産性の矛盾があることを強調している。

BT