スクラムを利用してプロジェクトを進める際に、最初にやっておくべきことをまとめておく。 もちろん全プロジェクトでこれを全部やらなきゃいけないわけではない。そのあたりはコンテキスト依存ということで。 プロダクトゴールや価値の明確化 これから作るもののビジネス価値や製品ビジョンを明確にする プロダクトバックログの作成 もちろん全部が揃っている必要はないが、優先度が高いストーリーは明確に存在するはず。 バックログ項目の優先順位付け バックログ項目の見積もり バックログ項目の詳細化 個々のスプリントの開始前には優先順位の付け直しや見積もりの変更が行われるので、全てを詳細まで行ってはいけない。あくまで初期の1〜2スプリントが実施できる程度にとどめること。アップフロントでの計画を増やしすぎない。要求は必ず変化する。 おおよそのリリースプランニング ロールの明確化 プロダクトオーナーは誰？、スクラムマスタ
![[Agile]Scrumで開発する際に最初にやるべきこと | Ryuzee.com](https://cdn-ak-scissors.b.st-hatena.com/image/square/e28ac0c06090ef4280af681bdbe7af0aed6391ba/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttp%2Fwww.ryuzee.com%2Fimages%2Ffb.png)
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
■ [ITS][PivotalTracker] Pivotal Tracker 最近、社内でプロジェクトで使う ITS を何にするかねーという話題が空前の大ブームになってて、オレのプロジェクトでは隣の隣に座っているチーフプログラマがオススメしてきた Pivotal Tracker というのを使うことにした。 http://www.pivotaltracker.com チュートリアルを見るとだいたいわかる。 http://www.pivotaltracker.com/learnmore 最初は Trac や Redmine のようないわゆる ITS も候補に挙がっていて、追加で Mantis や Retrospectiva も考えてみたんだけど、どれも"こちら側"でのチケットとリポジトリ管理が主な機能。これらは開発側だけで使うなら問題はないけど、顧客と story や goal の共有するこ
![[ITS][PivotalTracker] Pivotal Tracker, [Life] 一回休み - HsbtDiary(2010-03-12)](https://cdn-ak-scissors.b.st-hatena.com/image/square/8cab6183abe73ade0ce0a24c302ac36ee5c17b43/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fwww.hsbt.org%2Fdiary%2Ftheme%2Fogimage.png)
原文(投稿日：2011/08/30)へのリンク アジャイルを採用したばかりの多くの人々はアジャイルチームにおけるUIやUXデザインの位置に戸惑っている。以前は多くのチームがチームの作業から切り分けようと試みたり、一つ後のスプリントで行おうとしていた。最近、UIやUXをアジャイルチームに迎え入れたり、UXはむしろ先頭に立つべきだと言う議論が高まっている。 CollabNetのLuke Walter氏は一つ後のスプリントでやる事に一票を投じている。 私はしばしば非常に熟練したScrum作業者から、UIデザインは開発の前のスプリントで行うか、またはスプリント外のバックログ・グルーミング/スプリント・プランニングで生成されるべきと推薦されることがあります。2004年からScrumを利用しているデザイナーとして、これにはいつも困っています。システムアーキテクチャ（高レベルのソフトウェアデザイン）はそ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
