タグ

関連タグで絞り込む (2)

タグの絞り込みを解除

scrumとScrumに関するderbyのブックマーク (5)

  • 第10回 TFSUG に参加しました - GeekFactory

    7月13日 第10回 TFSUG:ざっくりわかるScrum and Team Foundation Server #tfsug(東京都) 19:00-21:00 日マイクロソフト品川社 「ざっくりわかる SCRUM AND TEAM FOUNDATION SERVER」 講師は @ryuzee さんです。スライドに書いてないトークを中心にメモしたので公開します。後でスライドも公開されるそうです。 アジャイルの適用領域 ビジネスが速くなった! 新しいことにチャレンジする必要が出てきた! 不確実性に対応する ウォーターフォールの適用領域 対象のドメインが変化しない やったことのある領域 アジャイルの考え方 スコープとリソースを総量規制する。 優先順位は状況によって変わる。 優先度はアンチパターン。優先順位にする。 無駄なものを作ってはいけない。 頻繁に確認と調整を行うので、無駄なものを作ら

    第10回 TFSUG に参加しました - GeekFactory
    derby
    derby 2012/07/20
  • アジャイルの概念を取り入れたCMMI - プログラマの思索

    隆史さんが、アジャイルの概念を取り入れたCMMIの記事を公開されていたのでメモ。 ラフなメモ書き。 【元ネタ】 徹底検証! CMMIはアジャイルの改善にも役立つか?- @IT情報マネジメント CMMI | CMMI Solutions | Translations | CMMI 日語翻訳版 上記の記事を読むと、スクラムを例として、アジャイル開発のワークフローにCMMIの概念をマッピングして整合性を取ろうとしているように思える。 ScrumとCMM/CMMIの親和性については、「スクラム入門-アジャイルプロジェクトマネジメント」の一番最後の付録で既に書かれてる。 「スクラム入門-アジャイルプロジェクトマネジメント」では、ScrumのプラクティスはCMMMIのレベル2、3のKPAをほぼ網羅しており、不足しているKPAは、プラクティスの制度化とソフトウェア外注管理だけだという指摘がある。

    アジャイルの概念を取り入れたCMMI - プログラマの思索
  • スクラムを1枚で説明する資料7選

    アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料) みなさんこんにちは。@ryuzeeです。 スクラムを1枚の絵で説明する資料はいろいろ出回っているので、整理をしてみました。 どれもちょっとずつ内容が異なったりしているので比較してみると面白いです。 是非自分用のものを作ってみると良いのではないでしょうか。 http://www.axosoft.com/ontime/videos/scrum/#scrum-diagramCC-3.0のライセンスで公開されている。ダウンロードは前述のページの下部から可能です。 The War Room - Does your Scrum room have the best Scrum image?Free Intro To Scrum Wall

    スクラムを1枚で説明する資料7選
  • アジャイルリーダーシップと組織改革 ~楽天のアジャイル開発というリアル~

    Developers Summit 2012(デブサミ2012)発表資料です。 レガシーコード、求められる開発生産性。開発現場の課題は、この10年で変化したのでしょうか?一方で、世界は日々変化しており、変化を抱擁しない限り、その変化と現実のギャップは徐々に広がっていきます。このセッションでは、楽天という大きな組織の中で始めたアジャイル開発についてお話させて頂きます。変化に対応できる開発のために導入した『アジャイル』が実際どうだったのか?その導入から他部署への展開で経験したリアルを共有させていただく予定です。Read less

    アジャイルリーダーシップと組織改革 ~楽天のアジャイル開発というリアル~
    derby
    derby 2012/02/17
    しゃべりはバカリズムみたいだった。
  • Scrum ではコードレビューをどうやっているか? - haradakiro's blog

    森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基はチーム全員で集まってやります。最大2時間。それ以上やっても集中力が続かないので。プロジェクタで対象

    Scrum ではコードレビューをどうやっているか? - haradakiro's blog
  • 1