BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ 継続的な改善 に関するすべてのコンテンツ

  • 世界的に有名なオーケストラがスクラムに似た手法を採用

    スクラムチームには指名されたチームリーダーがいない。チームは自己管理することが望まれる。同様に、世界的に有名なオーケストラは、チームでリーダーシップを共有して決定を行うというプロセスを支持し、指揮者の役割を完全に省いた。その過程で、スクラムチームが利益を享受できるような連携方法とレッスンを身につけた。

  • 個人のふりかえり -- あなたの「ウェットウェア」を進化させよ

    先日のAndy Hunt氏のインタビューは、達人プログラマからアジャイルな開発、そして彼の最新の関心である実践的なウェットウェアまで、彼の変化について話している。人がどのように学習し改善するかを理解するということは、アジャイラーの道具箱を補強する重要な要素だ。

  • チームで新しい習慣を身につける報酬は?

    チームが新しい習慣を身に着けようとして、なかなかうまくいかないときがある。習慣とは、ユニットテストを書く、コンパイラの警告をなくす、ビルドを壊さない、などのことだ。どうしたら、チームにこうした習慣を植え付けることができるだろうか?Clint Shankはメンバーを移行させるために、あるゲームをデザインした。

  • TDDへの見解:品質は思索と熟考から得られる。バグの抑制からではない。

    Michael氏はユニット・テスト、インテグレーション・テスト、TDDそしてクリーン・ルーム・ソフトウェア開発について言及し、コードの品質というのは思索と熟考から得られるのであってバグの抑制から得られるのではないと結論付けている。

  • レトロスペクティブ(ふりかえり)の失敗とその回避方法

    アジャイルのレトロスペクティブ(ふりかえり)について書いた文章の多くは、どのようにそれらを実行し、どのような形式を使用できるかに関する基礎に重点を置いている。

  • Article: レトロスペクティブのプライムディレクティブに対する問い

    この記事の始まりは、知的で思慮深い人たちの魅力的なグループが食事会を終えて話をしているところです。話はレトロスペクティブ(振り返り)プロセスの要であるプライムディレクティブ(最初の指示)に及んでいます。

  • あなたは本当に、他の言語を学ぶべきなのか?

    ブロガーのGustavo Duarteは、新しいプログラミング言語を学習するのはしばしば時間の無駄である、と言う呪いの言葉を吐いた。彼は最初、自分の投稿に"新しい言語は有害だと思われる"と言う、Dijkstaがgotoについて述べた古典的な文章を文字った題名を付けていた。

  • バリューストリームの妨げとなるもの

    スクラムでは「より生産的であろうとすることを妨げる何らかのもの」を障害として定義している。チームができるだけ継続的に、障害を取り除く手段を確立することを、スクラムでははっきりと重視している。Joe Little 氏は、障害のスコープについて、「組織が価値を提供することを妨げる何らかのもの」とした方がよいのではないか、と提案している。

  • Article: 高い生産性を生み出すソフトウェア開発の秘伝

    何について学ぶのか?お互いのこと、テクノロジ、ドメイン、顧客など、すべてについてである。速く学習するチームは成功する。チームのパフォーマンスを妨げる目に見えない「学習ボトルネック」について詳しく知りたいのなら続けて読んでほしい。

  • レトロスペクティブの第一(忘れられた?)ルール:やり遂げること

    非常に経験の浅いアジャイルチームでさえ、「Retrospective」という言葉を明確に理解している。しかし、悲しいことに、チームが実際に最後までやり遂げるような改善をおこなうために使用されないと、レトロスペクティブは無駄な努力になる可能性があることが、多くの場合見落とされている。 Gordon Pask Awardの受賞歴のあるJim Shore氏が、レトロスペクティブを最大限に活用する方法についてアドバイスをし、アジャイルハートビートでのアクティビティーの究極の場所を教えている。

  • ビジネスバリューを理解する

    最近、Joe Little氏は、もっともよく利用されるが同時に広く誤解されてもいる、アジャイルのコアとなる概念「ビジネスバリュー」に関する自分の考えを投稿した。

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

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

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

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

  • Article: 3つのM - リーンの3要素

    リーン主義をソフトウェア開発に適用することについての議論では、主にムダ(無駄:Muda)なものを特定して排除することに関心が向けられてきました。リーン思考は同様に、ムリ(無理:Muri)とムラ(ばらつき:Mura)を削除することも目指しています。

  • ベッドタイムユーザストーリー: カウボーイとおとぎ話

    「ソフトウェアエコノミストで国際的なコンサルタント」を自称するDavid Longstreet氏が、昨年、アジャイルソフトウェア開発はおとぎ話で、ただ「カウボーイ」開発を正当化しようとしているだけだと主張する論文を発表した。

BT