)
イテレーション バックログ ブック
イテレーション バックログ ブックを使用して、各イテレーション (スプリントとも呼ばれます) の作業の進行状況を計画および追跡できます。 このブックでは、タスクに定義されている見積もりと残りの工数に基づいて、チームの最大利用可能時間およびバーンダウンを計算します。 既定のブックには、作業の計画、チームの最大利用可能時間の計算、およびイテレーションのバーンダウンの視覚化に使用できる 5 種類のワークシートが用意されています。 別のイテレーションをサポートするため、必要に応じて追加のブックを作成できます。 注意 イテレーション バックログ ブックは、チーム プロジェクトの SharePoint 製品をホストするサーバーに保存されます。 チーム プロジェクトでプロジェクト ポータルが有効になっていない場合、ブックにアクセスできません。 詳細については、「チーム プロジェクト ポータルおよびプロセ
)
製品計画ブック
製品計画ブックを使用すると、ユーザー ストーリーのバックログおよび開発を管理し、チームの速度を判断し、複数のイテレーション (スプリントとも呼ばれます) 間で作業負荷を分散させることができます。 イテレーションを計画するには、プロジェクトに実装するストーリーについて、確認、順位付け、優先度付け、およびポイントの割り当てを行います。 作業負荷を分散させるには、各ストーリーを固有のイテレーションに割り当てて、すべてのイテレーションで割り当てられたストーリー ポイントの数が概ね等しくなるように割り当てを調整します。 注意 製品計画ブックは、チーム プロジェクトの SharePoint 製品をホストするサーバーに保存されます。 チーム プロジェクトでプロジェクト ポータルが有効になっていない場合、ブックにアクセスできません。 詳細については、「チーム プロジェクト ポータルおよびプロセス ガイダン
「10分でスクラム」、アジャイル開発の「スクラム」に興味がわいた方へ
今週は、野中郁次郎氏とジェフ・サザーランド氏というアジャイル開発手法「スクラム」の生みの親2人が基調講演を行った歴史的イベント「Innovation Sprint 2011」のレポートを2本公開し、たくさんの方に記事を読んでもらうことができました。 スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編） 重要なテクノロジーは10名以下のチームで作られた ～ Innovation Sprint 2011（後編） この記事きっかけに「スクラム」に興味を持ったという読者もおられたようで、そんな方のために（かどうかは分かりませんが：-）、「Innovation Sprint 2011」の実行委員長だった川口恭伸氏が「10分でスクラム」というスライドを公開しました。
プロジェクトファシリテーション実践編：ふりかえりガイド
ここでは、PF=Project Facilitation(プロジェクトファシリテーション)について議論しています。 プロジェクトを活性化し、楽しくプロジェクトを成功に導くための、実践的な課題を扱います。 プロジェクトの成功に大切なものはなんでしょうか？ 個々人のスキルは重要です。そして、ここで取り上げるのは、集まった個人のスキルを１００％以上に発揮させるチーム作りとしての、「プロジェクトファシリテーション（PF）」です。 プロジェクトマネジメント（PM）が重要であることは昨今強く言われています。 PMが「計画達成のマネジメント」に重点を置くのに対してPFは「参加者の協調の場作り」に重点を置いています。PMは、計画の立案と実行、差異に注目した管理が中心で、どちらかと言うと「コマンド･コントロール型」のマネジメントスタイルが背後にあります。これに対してPFは、その場その場の変化に対応し、チーム
プロダクトバックログとスプリントバックログの違い～要求マネジメント - プログラマの思索
「成功する要求仕様 失敗する要求仕様」の最後に、要求マネジメントに関するクイックレシピがある。 その方法が、Scrumのプロダクトバックログとスプリントバックログを上手に使い分けるのと同じように思えたのでメモ。 【1】あるシステムを作るために、要件定義をしているとしよう。 その時、「成功する要求仕様 失敗する要求仕様」のクイックレシピによると、以下の手順が必要になる。 1.ブレーンストーミングで要求をまず洗い出す。 要求の実現性は問わない。 要求の優先度や重要度も洗い出す。 2.ブレーンストーミングで洗い出した要求リストから、要求か否かを決定する。 実現できる要求のトリアージを行い、要求の候補を決定する。 但し、この段階では、コストやスケジュールは未決定。 3.リリース計画を作る。 実現可能なスケジュールと予算を作り、リリース計画へ入れる要求を足していく。 但し、作成中のリリース計画では不
ユニケージ開発手法という古臭いが革新的な開発手法によって - Javaの日々
その業務専用のDSLを早く安く作るという手法は確立されたと言っていい。 Common LispによるDSL作成能力は残念ながら否定されてしまったに近い。 ユニケージ開発は、シェルスクリプトと独自コマンド群から成り、 シェルスクリプトはLinux標準のbashを使い、独自コマンド群はそれぞれ 目的にあわせて独自の開発言語を使うという柔軟な手法を提供する。 シェルスクリプトという最高級言語でありながら、独自コマンドによって 詳細な処理の補完と拡張を可能にしている。 シェルスクリプトの最大の欠点は、それが粒度の細かい処理がほぼできない という点と、関数による拡張性を持たないという点だった。 しかし、独自コマンドの作成という使い古された手法によってそれが 解決されてしまったのである。 さらにユニケージ開発手法はもう一つ重要な主張をしていることになる。 それはシステム開発につきもののRDBを不要であ
第5回 BDDとATDD | gihyo.jp
はじめに 本連載では、「透明性」というキーワードで、アジャイル開発について説明しています。前回は、テスト駆動開発(TDD)の持つ、開発を促進する設計作業としての側面にスポットを当てて説明しました。今回は、それらの考えを展開させてみたいと思います。具体的には、振る舞い駆動開発(BDD)と受け入れテスト駆動開発(ATDD)という二つのトピックを、ご紹介します。 テストのレビュー 前回、テスト駆動開発におけるテストを、設計作業であるとする考え方をご紹介してきました。これは、個々のクラスのインターフェース(=振る舞い)を、テストにより明確にしてゆくというものです。結果的に、作られたテストは、実装との乖離を自動的に検出できる設計書となります。 仕様変更やリファクタリングに伴うソフトウェアの改変に際して、バグの混入を自動的に検知できるので、実装と設計の同期が取れるという大きなメリットがあります。 し
ペア・プログラミングの採用を成功させるには
経験上、ペア・プログラミングの採用を成功させる上で唯一最大のステップは、適切なペア用ステーションを用意することです。以下で記述するようなペア用の構成を推奨しますが、状況に応じてカスタマイズする必要があるでしょう。 両者が並んで快適に座れるような平らな机。Nat Pryce氏は円卓の使用でも成功しています。通常、作業者の方へカーブする机は快適な作業条件を実現できないため、避けるべきです。 手ごろに購入できる最速な開発用マシン。ペア用のステーションが個々のマシンより優れているならば、使用する機会も増えます。また、2人につき1台を購入しさえすればよいため、より多くの費用をかけることができます。 デュアルDVI出力付きビデオ・カード。スプリッタも正常に機能しますが、十分ではありません。最大の解像度を得るには、デュアルDVI出力を使用するほうがより適しています。 24インチまたは30インチのモニタを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
)
スプリント計画
スプリント計画：ストーリーポイント VS 作業時間
InfoQ: 体験レポート：ゲームで学ぶアジャイルな反復型開発
