タグ

2009年11月29日のブックマーク (4件)

  • アジャイルプロジェクトの契約に関する私見

    アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料) みなさんこんにちは。@ryuzeeです。 ソフトウェアを構築するときに締結する契約は、大別すると請負契約と準委任契約、そして派遣契約(今回は割愛します)があります。 請負契約は、完成させるべきものを事前に規定し、それを満たすものを納品することで代金が支払われます。 一方で準委任契約は、発注者の代わりに自身の裁量で業務を遂行する契約であり、働いた時間に応じた代金が支払われるのが一般的です。 アジャイル開発では、顧客やユーザーのフィードバックを得て作るものを変えていきます。 つまり事前に詳細なスコープは確定しません。 それにも関わらず請負型の契約を行った場合、事前に決められた「完成させるべきもの」に加えて、フィードバックへの対応

    アジャイルプロジェクトの契約に関する私見
  • 画面設計とか外部設計とか、もうやめようよ - masayang's diary

    昨日は特徴(Feature)、粗筋(Story)、脚(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう? 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え

    画面設計とか外部設計とか、もうやめようよ - masayang's diary
  • Agileでやってるけどデスマったw

    Agileでデスマになったのでそのログです。 この後同じことを繰り返すと馬鹿なので、まだデスマ中だけど、問題点と反省点を書いておこうと思う。 こういうのは渦中にやっておかないと終わった後だと「大変だけど終わって良かったね」で終わってしまいがちなんだよね。 これを読まれている方は反面教師にしてください。 契約と総生産量の関係性 期間と費用が決まっている場合、総生産量には当然上限がある。生産量はチームのベロシティが分かっていれば、ストーリーポイントに換算できるので、開発開始時点で、総生産可能ストーリーポイントについては明示すべきだった。土日出て頑張れ!とか残業して頑張れ!とかいうのはAgileを知らない証拠。 上記に関連して、プロダクトバックログにストーリーを追加することが出来るのは、プロダクトオーナーの権利なのだけれども、優先度高としてストーリーを追加したところで、バーター可能なストーリーが

    Agileでやってるけどデスマったw
  • ウォーターフォールとスクラムとリーンの違い | Ryuzee.com

    みなさんこんにちは。@ryuzeeです。 Agile101より引用の図が分かりやすいので引用・意訳にてご紹介します。 ウォーターフォールプロジェクトの終了直前のデプロイまで、何の価値も実現できないテストを最後に残しているため、最後の最後まで問題の発見が遅れる要求事項が変化しているかもしれないのに、ステークホルダーへの提案をしない計画に大きく依存しているため、(計画に失敗していると)プロジェクトの失敗に結び付きやすいプロジェクトマネージャの力量に依存しているフェーズ分割型ウォーターフォール従来型ウォーターフォールに比べればリスクは少ないよくある問題はボトルネックの発生若干の工程の遅れをテスト工程まで引きづり、結果として最後に想像以上に解決の時間を要することになり、結果プロジェクトの終了時期を守れない見積りは難しいのでオーバーコミットメント(過剰な約束)する可能性があるフェーズでの見積りは他の

    ウォーターフォールとスクラムとリーンの違い | Ryuzee.com