BT

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

寄稿

Topics

地域を選ぶ

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

  • アジャイルを導入する方法

    トップダウンでアジャイルが導入されるのは、企業ではよくあることだ。しかし、その他の方法もある。ステルスでアジャイルを導入する方法や、継続的改善チームを使う方法、限定的にアジャイルの方法を取り入れて、ゆっくりと進め始める方法がある。

  • プロダクションオーナはスプリントのレトロスペクティブに積極的に参加するべきだ

    Roman Pichler氏が,プロダクトオーナがスプリントのレトロスペクティブに参加することによる,開発チームとのコラボレーション向上について,自身の見解を述べている。

  • Bol.comのDevOpsへの道

    DevOpsDays Amsterdam 2014の初日,オンラインストアのbol.comは,DevOpsへの道程における同社の経験について報告した。成功の鍵となったのは完全な自動化,慎重なチーム構築,そして組織全体に浸透したアジャイル思考だ。RunDesk, Puppet, Hira, Nagiousなどのツールを駆使することでbol.comでは,完全に自動化された方法で,作業環境全体の構築と監視を2時間以内に可能としている。

  • 力と影響について

    DevOpsDays AmsterdamでMark Coleman氏が、企業文化の変化はあるひとりの人間が他人に影響を与えることで始まる、と主張した。氏によれば、Charles Handy氏の力と影響についての著作が組織の動きと、その変化のさせ方についての理解を助けてくれる。Charles Handy氏は著書で力の源泉を6つ挙げている。

  • 匿名振り返りの効力

    Hiren Doshi氏はPractice Agile Software Developmentのブログ記事に匿名振り返りについて書いている。チームのフィードバックを最大化する方法だ。

  • "Readyの定義”を使う

    ユーザストーリの完成と製品の提供準備完了をチェックする手段として,多くのチームが"Doneの定義(Definition of Done)"を使用している。しかし,プロダクトオーナから受け取るユーザストーリについてはどうだろう?ユーザストーリの品質をチェックするために,チームが利用できる手段が"Readyの定義(Definition of Ready)"だ。

  • アジャイルにマネージャと職務階級は必要か?

    アジャイルを採用している組織は職務階級を廃止すべきだ,マネージャを一掃すべきだ,といった意見をしばしば耳にする。マネージャや職務階級の存在がチームの自己組織化を阻害する考えられているのだ。

  • David Mole, Sandy Mamoli両氏に聞く - Trade MeにおけるSpotifyのスクワッドモデル導入について

    アジャイルコーチのDavid Mole氏とSandy Mamoli氏は先日,ウェリントンのアジャイルミートアップグループで,ニュージーランド最大のオンライン企業であるTrade Meでの成功体験について講演した。彼らはSpotify型のスクワッドモデル(Squad Model)をTrade Meに導入すべく,チームの自己形成(Self Formation)とビッグバン方式のマイグレーションを行ったのだ。その動機と経験を理解するため,我々は彼らの話を聞いた。

  • アジャイルガバナンスの人的要因

    Anko Tijman氏が言うには、信頼とは関係への投資に関する意思決定だ。アジャイルのガバナンスは信頼の上に成立しなければならない。アムステムダムで開催されたAgile Governanceカンファレンスで、Anko Tijman氏はbeing in control through people factorsと題したプレゼンを行った。

  • どのようにScrumをスケールするか

    大きな組織はScrumをチームを超えた大きさに適用したいと考えている。この記事では、Scrumを拡大適用して組織全体にアジャイルを導入するための方法についていくつかの例を紹介する。

  • リリースプランニングのためのアジャイルな見積もり

    優先度付けや製品のリリース計画のためにアジャイルチームやプロダクトオーナーは見積もりを行う。見積もり、さまざまなレベルでさまざなな方法で行われる。

  • チームの改善のためにベロシティを計測することへの懸念

    アジャイルチームは自分たちのスプリントごとのベロシティを計測する。そうすることで彼らは、計画をたて、進捗をトラッキングし、プロダクトオーナーにプロダクトのリリースプランを作るための手がかりを与えることができるようになる。チームは、自らを改善したいときに、ベロシティのデータを利用できるのだろうか? 何人かの著者がベロシティについて書いており、チームの生産性を高めることを目的としてベロシティを計測することについての懸念を伝えている。

  • 2つのDoDによる開発プロセスの改善

    DoD(Definition of Done)を理想と現状という2つのバージョンに分離しようというアイデアがある。目的とするのは,成熟度および品質の面でのDoDの拡大だ。物理的なボード上で実行する以外に,Jiraのようなアジャイルツールで実践することもできる。

  • アジャイルチームを互いに連携し協同させるためにスクラム・オブ・スクラムを使うこと

    スクラム・オブ・スクラムは、複数のチームが関係しているときにデイリー・スタンドアップ・ミーティングをスケールするために用いられる。その目的は、���ーム間で協同し作業を連携するアジャイルチームを支えることだ。何人かの執筆者が、スクラム・オブ・スクラムを用いた経験をもとに、それに対する見解を述べている。

  • Mike Cohn氏、スプリントレビューにおける未完成の作業について語る

    Mike Cohn氏は、完成していないプロダクトバックログアイテムをスプリントレビューミーティングで披露することも時には価値があるといい、その理由について語っている。

BT