BT

InfoQ ホームページ カルチャー&手法 に関するすべてのコンテンツ

  • 子どもの創造的活動のための環境としてのScratchおよびRasberryPiの可能性

    MITの Mitchel ResnickがScratchというヴィジュアルプログラミング環境を開発した。Scratchは,子どもたちの遊びを観察することから得られた「想像,作成,遊び,共有,振り返り, 想像…」というCreative Learning Spiralを支援する.そのため,動画共有サイトによく似た作品共有サイトhttp://scratch.mit.edu/ が用意され、世界中の子どもたちが協働して作業する環境として機能している。

  • プロジェクトインセプション - 協力体制を作るミーティングの方法

    プロジェクトを始める前にチームの協力体制を築くことは、効率的、効果的であるために最も重要なことです。チーム全体で強い忠誠心を持ちながら意思の疎通を図ることは、たくさんのEメールやドキュメント、会議電話よりも、チームで協力体制を保つためにずっと効果的です。この記事では、大きくなったチームで協力体制を築くために、1日インセプションミーティングを実施する方法を説明します。

  • カンバンはどのように動作するか

    ソフトウエア開発や継続的改善を管理するシンプルで効率的な方法として、カンバンにますます関心が集まっています。しかし、カンバンとはどのように動作するのでしょう。この記事では、待ち行列理論を使って、カンバンを深く掘り下げます。また、ケーススタディを通じて、カンバンの基本的な概念と示唆に富んだアイディアを明らかにします。

  • 自己組織化チームはなぜ必要か?

    私たちの世界では変化は日常であり,"ビジネス的アジリティ"が求められます。組織を運営する上で,古い地図はもはや役に立ちません。体系的思考に基づいた,新たな地図が必要です。優れた自己組織化チームについてのシリーズ記事の第2回目では,自己組織化チームが必要な理由について論じます。

  • 効果的なテストの文化を創る

    誰しも開発したソフトウエアに自信を持ちたいと思っています。テストが重要なのはわかっているのですが、さまざまなテスト方法を学習するときの障害を克服した上で、自分たちの仕事に自信を持つことを妨げているのは何なのでしょうか。

  • ソフトウェア開発プロセスから無駄を省くための7つの方法

    約2年間、ソフトウエアベンダでリーンソフトウエア開発を実践し、段階的に7つの大きな変化を生み出すことでR&D部門のソフトウェア開発プロセスから無駄を削除しました。

  • 自己組織化チームとは何か?

    自己組織化チームとは何か,どうすれば効果的にサポートできるか,といった情報はあまり多くはありません。今回の記事では,自己組織化チームについて学ぶシリーズの最初として,自己組織化チームとは何かを探求します。

  • 「Ameba流Scrum」を浸透させるために私たちが実践したこと

    現在、コミュニティサービスだけでも40以上のサービスが提供されている、サイバーエージェントの「Ameba」サービス群。ネットユーザーの嗜好をとらえたサービスを短期間で次々とリリースできる秘訣は、各開発チームが導入し実践するScrum開発手法にある。ScrumはAmebaにおいてどのように浸透していったのか。同社アメーバ事業本部 サービス部門 コミュニティ事業部の大﨑浩崇氏に推進の過程やコツを聞いた。

  • かんばんはただの常識か?

    私たちは、製品開発について考える時に、経験則の概念がどれほど強力かを見てきました。アジャイルマニフェストは、個々のアジャイルプロセスとプラクティスを使って、経験則をまとめたものだと考えられます。このかんばんシンキングモデルは、注目すべき重要な分野を含む5つのかんばんの経験則と、改善に関する3つの影響が含まれています。

  • 技術的負債を管理する

    技術的負債は、出来るだけすぐに返済すべき悪いことだと広く考えられていますが、うまく管理すれば、短期間の利益と長期間の生産性のバランスをとる戦略となります。この記事では、プロジェクトが技術的負債を返済できるさまざまな方法と、返済したほうがよいか、負債を転換するか、利息だけを支払うかを決めるために、熟考しなければならないことを説明します。

  • かんばん方式を実践する

    Lean KanbanカンファレンスにおいてInfoQはArne Roock博士に,かんばん方式がチームに相応しいツールであるかを知るにはどうすればよいか,キックオフはどうすればよいのか,などを質問しました。それに対して博士は,いくつかの規範的なアドバイスをしてくれました。

  • アジャイルにおけるソフトウェアアーキテクチャ図とNoUML

    開発中のソフトウェアアーキテクチャを理解することは,カオスを避け,協調的なコード所有を促進する上で重要なことです。しかしアジリティを競い合う中,特にUMLを捨てて "ボックスとライン" による図に乗り換えたチームの多くが,その実践に苦慮しています。迅速な行動には良好なコミュニケーションが不可欠ですが,これをBDUF(Big Design Up Front)とUMLなしで行うにはどうすればよいのでしょう?

BT

あなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。

Eメールを変更すると確認のメールが配信されます。

会社名:
役職:
組織規模:
国:
都道府県:
新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。