BT

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

寄稿

Topics

地域を選ぶ

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

  • よく組織されたチーム:単に生き残るのではなく、成功へと導く支援

    業績の良いチームを編成するには何が必要なのか?Doug Shimp氏およびSamall Hazziez氏によると「よく組織されたチーム」は以下の特徴があるらしい。AgileおよびLeanの原則に従う、フィードバックループがある適応システムを使用、ビジネスの展望にフォーカス、そして熱意があり非常に生産的である。

  • GitHub - RailsベースのGitリポジトリホスティングサービス

    Gitは分散バージョン管理システムである。元々GitはLinux TorvaldsがLinuxカーネルのソースコードを管理するために書かれたものだが、Linux以外のプロジェクトでも採用されている。Ruby界隈ではRubiniusやMerbでの利用が知られており、CapistranoやVlad the DeployerといったデプロイツールもGitに対応している。

  • 形式化されたメトリックスを使わない生産性の向上

    Ron Jeffries氏は実在のチームを観察して得られた知見を元にしたフィクションの物語を書き始めている。最初のストーリー(Kate Oneal: Productivity)は、CTOであるKate O'Nealと、彼女のチームの一つである"Rimshot"を中心として描かれている。Ron Jeffries氏はこのエピソードの中を使用して、形式的なメトリックスを使わない生産性の向上の達成と、メトリックスの測定について説明している。

  • Apple社のマネージャが技術者の助けとなるように"Managing Humans"を執筆

    TinyPlanetの業務執行役員であるStephen van Egmond氏によると、Apple社のシニアマネージャであるMichael Lopp氏が新たな素晴らしい本、"Managing Humans-ソフトウェアエンジニアリングマネージャの辛辣でユーモラスな物語-"を執筆した。

  • 理想的なアーキテクチャが理想的な技術であるとは限らない

    一般的に認められた定義によれば、ソフトウェア設計者の役割は「利害関係者からの入力に基づいたシステムのマクロ面」を定義することである。これは、技術的問題点だけでは設計者を動かすことができないことを示す。設計者は、技術やアーキテクチャ設計の選択にしばしば制約を受ける、異なる利害関係者の要件を念頭に置く必要がある。

  • 「ふりかえり最優先条項」についての議論

    ある夜の夕食のときに、ベテランの実践者たちのグループは、自分たちがチームで「ふりかえり最優先条項」をどのように使用するか(あるいは使用しないか)に関して意見を交換した。

  • 問題を抱えたプロジェクトの舵取り:まず酸素マスクを確保���よ

    Fiona Charles氏によるStickyMindsでの最近の記事は、問題を抱えたプロジェクトの舵取りについて触れている。「前進のための融通の利かないプロセスのための時間ではない」と強調し、プロジェクトを好転させるのに役立つ貴重な洞察を提供している。

  • Review Board - コードレビューをオンラインで

    コードレビューは品質を高め、情報共有とメンターシップの優れた方法となる。 残念なことにこれまではサポートツールの準備に手間がかかったりそもそも準備されなかったせいでコードレビューは後回しにされることが多かった。Review Boardはコードレビューのプロセスをサポートするアプリケーションによってこの状況を変えようとしている。このアプリケーションのいくつかの機能をあげよう。

  • 責任、個人のアジャイル性、その他の親密なコミュニケーションのアイデア

    うまくいっているアジャイルなチームの特徴は、プラクティスではなく主に文化にある。この考えは多く(ほとんどと言ってもいいかもしれない)のアジャイルな分野で当てはまるように思われる。組織的変革の世界で有名になった Christopher Avery 氏は Responsibility という言葉を再定義し、その考え方を人々に伝えるという作業に取り組み、その成果をアジャイルプラクティスに注いでいる。個人のアジャイル性はアジャイル導入のカギなのだろうか?

  • イディオムやパラダイムの選択を通じたインテントの通信

    イディオムやプログラミングの決まりごとを信号として使用して、さらに理解しやすく、表現に富んだものにするのはどうか?これこそまさにReg Braithwaite氏が唱えているもので、構文やパラダイムの選択さえもインテントを通信する手段になり得ると示唆している���

  • 職場を越えたアジャイル

    この業界のわれわれの多くは、作業慣行が自身の家庭生活に影響を与えている-しばしば良い意味で。人によっては、毎日の生活の中でスケジュールを立てたり、優先事項を決めたり、日々の仕事を家族と話し合ったりする際にインデックスカードを使用する。Peter Abilla氏は、彼の子供たちに教えるためにどのようにしてジョブチャート(情報ラジエータの一種)を使用するのかをブログに記した。

  • 成功するコラボレーションには偶然などない

    パートナーシップコーチのMichael Spayd氏は契約社員と正社員は両方ともプロジェクトに取り掛かる際にコンサルタントとしての役割を果たすことができ、またクライアントとコンサルティング系統の契約を発展させていくという提案を記した記事をInfoQに提供した。これは通常の”契約”という用語とは異なる意味を持っている。サービスプロバイダとクライアント間の法的な決まりごとである。彼の"Designed Partnership Contract"は金銭の交換に関するものではなく、”コンサルタント”がコミュニケートし、自身達の価値観と嗜好を大切にするのを可能にする一方、より良いクライアントとのコラボレーションを成すために使用されるものである。

  • 私は自信がない。あなたの聞いたことが、私が言ったと思っていることかどうか。

    コミュニケーションそれ自身は難しくも何ともない、と言わんばかりに、私たちの職場は専門用語であふれている - ビジネスドメイン用語、製品用語、開発者用語など。そのため私たちはそこにコミュニケーションがある、と言われても驚きはしない - しかし私たちは、目をぐるぐる回したりマーフィーの法則を引用したりする代わりに、それを捉え、対処することができているのだろうか?

  • 階層アーキテクチャは開発者と彼らが作るソフトウェアの間にギャップを生むか?

    今日のソフトウェアコミュニティにおける努力の多くは、ソフトウェア開発のプロとビジネスピープルとの間のギャップを解消するための橋渡しを目標としているが、一部のブロガーは問題をすこし異なった視点から見ており、開発者と彼らが作るソフトウェアとの間のギャップを強調している。

  • Article: かんばんボードによるプロジェクトの見える化

    日本におけるプロジェクトファシリテーションのの第一人者である平鍋健児さんが、昨今のアジャイル開発プロジェクトで広く浸透している見える化の手法を見ていきます。その中で、チーム全体がプロジェクトの今の状況を把握し、開発者の自律的な作業を可能にし、協調作業を促進する、三つの視点(とき、こと、ひと)をうまく使うかんばんボードの利用法を提案します。そして最後に、三つの視点によるプロジェクトの見える化を実現している、かんばんボードのソフトウェアによる実装“TRICHORD”を紹介します。

BT