このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
2011/06/24にスクラム道バーストに参加してきました。申し込みを忘れていたのですが、当日行けそうに無かった方のご好意で代わりに参加してきました。@ledsunさんありがとう。 内容は過去のスクラム道の再演とトピックに対する議論の場でした。詳しい内容は他の方の素晴らしいレポートがあるのでそちらをご参照くださいw 選手ってなに?ってことが良くわからないまま選手として参加してしまいましたが、壇上に上ってもそんなに緊張しないものですね。変なこと言っても殴られたりしないので、このような形式があったらどんどん選手として名乗りをあげるといいと思います。 スクラム道バーストで「doneの定義を拡大/縮小することの是非」がトピックに上がりました。思い返すとストーリーのdoneの定義なのかタスクのdoneの定義なのかがあやふやだったので、それぞれ検討しました。 結論としては、拡大するにしろ縮小するにしろ
寝ようと思ったけど、これを動かしていてテンションが上がった。 Redmine0.9.0でサックリ動くバックログプラグイン(Backlog Plugin)。 http://github.com/relaxdiego/backlogs スクラムでは、全体的な要求(作業より要件に近い?)を集めたプロダクトバックログ。イテレーションで実行するタスクまで落とし込んだリリースバックログ。リリースバックログをさらに細かく切ったスプリントバックログというものが登場する(参考:スクラム(開発手法) by Wikipedia)。 Redmineでこれを何とかしたかったのだが、今のところ、Backlogプロジェクトを作って、そこからチケットを移動して何とかしようと思っていた。 でも、もっと良い方法で、Redmineのプロジェクトごとのバックログを管理できないかなーとおもったたら、見つけたのがこのプラグイン。 ま
スクラム提唱者から学ぶ、チームの不幸を減らすたった2つの方法:スクラム提唱者が教える、チームの不幸を減らす方法(1/2 ページ) スクラム提唱者のジェフ・サザーランド氏を講師に招いた、日本初の「スクラムアライアンス認定プロダクトオーナー研修 レポート」レポート。チームも顧客も不幸な状態をなくす方法は実にシンプルだ。 2011年はアジャイル実践者にとって歴史的な年となった デスマーチ続きでリリースは遅延、チームはプレッシャーを受けてマネージャはてんてこ舞い、顧客も不幸……そんな状態を良い方向に転換する方法はたった2つである――「スクラム」提唱者の1人である、ジェフ・サザーランド氏の言葉です。 1月11日と12日、サザーランド氏による日本初のスクラムアライアンス認定プロダクトオーナー研修(Certified Scrum Product Owner 研修、以下CSPO研修)が開催されました。翌日
イテレーション バックログ ブックを使用して、各イテレーション (スプリントとも呼ばれます) の作業の進行状況を計画および追跡できます。 このブックでは、タスクに定義されている見積もりと残りの工数に基づいて、チームの最大利用可能時間およびバーンダウンを計算します。 既定のブックには、作業の計画、チームの最大利用可能時間の計算、およびイテレーションのバーンダウンの視覚化に使用できる 5 種類のワークシートが用意されています。 別のイテレーションをサポートするため、必要に応じて追加のブックを作成できます。 注意 イテレーション バックログ ブックは、チーム プロジェクトの SharePoint 製品をホストするサーバーに保存されます。 チーム プロジェクトでプロジェクト ポータルが有効になっていない場合、ブックにアクセスできません。 詳細については、「チーム プロジェクト ポータルおよびプロセ
製品計画ブックを使用すると、ユーザー ストーリーのバックログおよび開発を管理し、チームの速度を判断し、複数のイテレーション (スプリントとも呼ばれます) 間で作業負荷を分散させることができます。 イテレーションを計画するには、プロジェクトに実装するストーリーについて、確認、順位付け、優先度付け、およびポイントの割り当てを行います。 作業負荷を分散させるには、各ストーリーを固有のイテレーションに割り当てて、すべてのイテレーションで割り当てられたストーリー ポイントの数が概ね等しくなるように割り当てを調整します。 注意 製品計画ブックは、チーム プロジェクトの SharePoint 製品をホストするサーバーに保存されます。 チーム プロジェクトでプロジェクト ポータルが有効になっていない場合、ブックにアクセスできません。 詳細については、「チーム プロジェクト ポータルおよびプロセス ガイダン
原文(投稿日:2009/09/22)へのリンク スプリント計画にストーリーポイントと作業時間のどちらを用いるかについて,決着の付かない議論が長く続いている。どちらの陣営も,自分たちのアプローチが相手より優れているとする根拠をいくつも持っているようなのだ。Mike Cohn 氏が ユーザストーリーをタスクに分割して,それを元に時間見積を行う方法を好んで使用すれば,それに対して Jeff Sutherland 氏が 氏自身が関わった最高のチームでストーリーポイントを使ってバーンダウンを行った例をあげる。他にも多くのアジャイリストたちが,自らの好む方法とその理由について意見を表明している。 Mike Cohn 氏はスプリント計画でストーリーポイントを使用することを好んでいない。ストーリーポイントがどちらかと言えば長期的な測定基準であって,短期作業には向かないと考えているからだ。彼の意見では, シ
Copyright (C) 1995-2008 Nikkei Business Publications, Inc. All rights reserved. このページに掲載されている記事・写真・図表などの無断転載を禁じます。著作権は日経BP社,またはその情報提供者に帰属します。 掲載している情報は,記事執筆時点のものです。
今週は、野中郁次郎氏とジェフ・サザーランド氏というアジャイル開発手法「スクラム」の生みの親2人が基調講演を行った歴史的イベント「Innovation Sprint 2011」のレポートを2本公開し、たくさんの方に記事を読んでもらうことができました。 スクラムの生みの親が語る、スクラムとはなにか? たえず不安定で、自己組織化し、全員が多能工である ~ Innovation Sprint 2011(前編) 重要なテクノロジーは10名以下のチームで作られた ~ Innovation Sprint 2011(後編) この記事きっかけに「スクラム」に興味を持ったという読者もおられたようで、そんな方のために(かどうかは分かりませんが:-)、「Innovation Sprint 2011」の実行委員長だった川口恭伸氏が「10分でスクラム」というスライドを公開しました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く