タグ

scrumに関するikasam_aのブックマーク (16)

  • Scrum Boot Camp東京を開催しました

    7月30日(土)に品川の日マイクロソフト株式会社様の会場にてScrum Boot Campを実施しました。 前回も書きましたが、Scrum Boot Campとは以下のようなことを目的としたセミナー&ワークショップです。 概要 Scrum(スクラム)は竹内弘高氏、野中郁二郎氏が1986年にハーバードビジネスレビュー誌にて発表した「New New ProductDevelopment Game」を元にしてジェフ・サザーランド氏らが考案したアジャイル開発手法の1つで、近年アジャイルな開発の手法として日国内においても急速に採用事例が増えています。 一方でコーチや経験者の指導のないままに表面的なプラクティスを導入し、結果としてあまりうまくいかないというケースも良く聞くようになりました。 そこで今回はこれからScrumを導入して開発を行うことを検討されている方もしくはトレーニングを受けない(受け

    Scrum Boot Camp東京を開催しました
  • Redmine Backlogsで簡単スクラム!スクラムマスターや開発チームとして使う編

    Scrum Process via Lakeworks in the Wikipedia 前回はプロダクトオーナとしての使い方を調べてみた。今回は、スクラムマスターの使い方をRedmine Backlogs :: Usage Scrum Masterを元に調べてみる。 スプリントバックログは、プロダクトバックログの上からチームのベロシティ分選択していくだけでよく、選び出されたストーリーにポイントを付け、スプリント内でストーリーが消化されるようにチームを支援するのがスクラムマスターの仕事になる。上の図だと全体にかかわるお仕事なのだが、Redmine Backlogsではスプリントバックログやスプリントが、舞台の中心になるのだと思う。 スクラムマスターとして使う ストーリーの調整はプロダクトオーナーともチームとも相談する必要がある。Backlogsではスプリントごとのベロシティも簡単に確認する

    Redmine Backlogsで簡単スクラム!スクラムマスターや開発チームとして使う編
  • スクラムにおけるイベントと出席者

    みなさんこんにちは。@ryuzeeです。 スクラムにおけるイベントはスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブの4つがあります(スプリント自体もイベントですが他のイベントの入れ物なので除外しました)。 また責任としてはプロダクトオーナー、スクラムマスター、開発者、そしてそれ以外のステークホルダーに分けられます。 誰がどのイベントに出席するべきなのかについて、マトリクス化された資料が存在しなかったので、作成してみました。なお、イベントではありませんが、プロダクトバックログリファインメントを参考までに入れました 以下補足です。 プロダクトオーナーのデイリースクラムへの出席出席しません。 デイリースクラムでやるべきことは開発者がスプリントゴールを達成できそうか確認し、必要なら再計画のきっかけにすることです。 開発者がスプリントゴールの達成にリスクが

    スクラムにおけるイベントと出席者
  • Kanban and Scrum - Making the Most of Both

    InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architects. View an example Memorial Day Sale: Save up to 60% on InfoQ Dev Summit Boston (June 24-25)

  • [Agile]Scrumで開発する際に最初にやるべきこと | Ryuzee.com

    スクラムを利用してプロジェクトを進める際に、最初にやっておくべきことをまとめておく。 もちろん全プロジェクトでこれを全部やらなきゃいけないわけではない。そのあたりはコンテキスト依存ということで。 プロダクトゴールや価値の明確化 これから作るもののビジネス価値や製品ビジョンを明確にする プロダクトバックログの作成 もちろん全部が揃っている必要はないが、優先度が高いストーリーは明確に存在するはず。 バックログ項目の優先順位付け バックログ項目の見積もり バックログ項目の詳細化 個々のスプリントの開始前には優先順位の付け直しや見積もりの変更が行われるので、全てを詳細まで行ってはいけない。あくまで初期の1〜2スプリントが実施できる程度にとどめること。アップフロントでの計画を増やしすぎない。要求は必ず変化する。 おおよそのリリースプランニング ロールの明確化 プロダクトオーナーは誰?、スクラムマスタ

    [Agile]Scrumで開発する際に最初にやるべきこと | Ryuzee.com
  • クオリティエンジニアの役割とは「お客様の視点を提供すること」 ~ セールスフォース・ドットコムの作り方(後編)

    クラウド上に構築した企業向けアプリケーションを提供するセールスフォース・ドットコム。同社は千人以上の開発者を抱える開発部門全体でアジャイル開発手法を採用し、サービス開発を行っています。 同社はどのようにしてアジャイル開発手法を採用し、品質を重視した開発を進めているのか。2月17日に行われたデベロッパーズサミット2011で、株式会社セールスフォース・ドットコム CTO 及川喜之氏のセッション「salesforce.comの作り方 どのように世界最大規模のアジャイル開発を実現したか」が行ったセッションの内容を紹介します。 (記事は「大規模アジャイル開発の実態~ セールスフォース・ドットコムの作り方(前編)」の後編です) クオリティエンジニアの役割について 開発においてクオリティエンジニアが果たす役割は結構大きい。スクラムチーム内のコミュニケーションのハブとして積極的に働いている。デベロッパは

    クオリティエンジニアの役割とは「お客様の視点を提供すること」 ~ セールスフォース・ドットコムの作り方(後編)
  • 大規模アジャイル開発の実態~ セールスフォース・ドットコムの作り方(前編)

    クラウド上に構築したアプリケーションをサービスとして提供するセールスフォース・ドットコム。同社は千人以上の開発者を抱える開発部門全体でアジャイル開発手法を採用し、開発を行っています。 アプリケーションのメジャーアップデートは年3回。クラウドで提供しているサービスという性格上、もしもアップデートにバグがあればそれは全ユーザーに対して大きな影響を与える可能性があります。バグがないこと、性能低下を起こさないこと、品質管理はパッケージソフトウェア以上に重要です。 同社はどのようにしてアジャイル開発手法を採用し、品質を重視した開発を進めているのか。2月17日に行われたデベロッパーズサミット2011で、株式会社セールスフォース・ドットコム CTO 及川喜之氏のセッション「salesforce.comの作り方 どのように世界最大規模のアジャイル開発を実現したか」で詳しく紹介されていました。 同社の開発手

    大規模アジャイル開発の実態~ セールスフォース・ドットコムの作り方(前編)
  • スクラムルールチートシート

    はじめるにあたって必須のルール(骨格)フルタイムで参加できるスクラムマスターが決まっていて、スクラムチームのメンバーが仕事できる状態であることスクラムチームは30日以内に動作するソフトウェアのデモをすることに同意していることステークホルダーをデモに招くことできるかぎり早期に実現すべきスクラムの基ルールスクラムマスターは必須や基のルールに従うことを保証することフルタイムのプロダクトオーナー(専門知識と権限を持っている)が決まっていることスクラムマスターとプロダクトオーナーを含む機能横断チーム開発チームのサイズは6プラスマイナス3人プロダクトオーナーは開発チームや他のステークホルダーとともに働くことプロダクトオーナーによってプロダクトバックログの作成、管理がなされること3つの質問によるデイリースクラムミーティング(昨日やったこと、今日やること、障害事項)デイリースクラムを同じ時間に同じ場所

    スクラムルールチートシート
  • プロダクトオーナはスクラムマスタを兼任できるか

    Rustが再評価される:エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...

    プロダクトオーナはスクラムマスタを兼任できるか
  • usablog.jp

    This domain may be for sale!

    usablog.jp
  • Innovation Sprint 2011 野中郁次郎先生の基調講演メモ - mkoszk’s blog

    「Innovation Sprint 2011」 基調講演 野中郁次郎先生の講演メモです。 テープ起こしをしていませんので、間違っているところもあると思いますし、補った言葉が間違っているかもしれません。また、編集の過程で順序が変わってしまったところもあると思います。 会場の風景およびスライドなどは、スクラムの生みの親が語る、スクラムとはなにか? たえず不安定で、自己組織化し、全員が多能工である 〜 Innovation Sprint 2011(前編)の記事に載っています。僕の記事より読みやすいです。 ──────────────────────────────────── 基調講演 「Roots of Scrum」一橋大学 名誉教授 野中 郁次郎 ──────────────────────────────────── 今日は、イノベーションを生み出す組織について話をします。 ドクター・サ

    Innovation Sprint 2011 野中郁次郎先生の基調講演メモ - mkoszk’s blog
  • 10分でスクラム - kawaguti’s diary

    「10分でスクラム」という資料をつくりました。 http://www.slideshare.net/kawaguti/20110118-scrum-10-mins 20110118 scrum 10 minsView more presentations from kawaguti. 「xx分でスクラム」という資料はライフワーク的になってきたので、またかよ、と思っても見逃してください。今回は結構よくできた方だと思うんですけど。 最後の方で、スクラムマスタをチェンジエージェントとして位置づけてみたところが、今回のポイントです。 あなたがもし最初の一人だったら 1. スクラムマスタとして行動する。 2. 優先度をつけている人を見つけ、
 はっきりと優先順位をつけるよう促す。
 (その人がプロダクトオーナーだ) &作業規模をメンバーに聞いてみるよう促す。 3. 各メンバーの毎日の作業を教えてもら

    10分でスクラム - kawaguti’s diary
  • ユーザーストーリービギンズナイト at 第11回すくすくスクラム

    プロトタイピングとユーザビリティテストで「UXデザイン」を練りあげよう! | UXデザイン基礎セミナー 第4回Yoshiki Hayama

    ユーザーストーリービギンズナイト at 第11回すくすくスクラム
  • 【資料公開】バーンダウンチャート虎の巻

    みなさんこんにちは。@ryuzeeです。 2010/12/22に永和システムマネジメントさんで実施したスクラム道.02でバーンダウンチャートについてお話させていただきました。 その際の資料を公開します。 スクラムではバーンダウンチャートを使うことが定義されていますが、バーンダウンチャートもツールなので、それをどう使うか、というのを考える事は非常に大事だよ、ということ、改善に使うべきであるということ、形状等を見ればチームの自己組織化レベルまで推察することができるよ、指標を追加するとさらに色々なことが分かるよ、といった話をしてます。 日ではバーンダウンチャートについてこの話をしている人はまだほとんどいないはずです。 感想を聞かせていただければ幸いです。

    【資料公開】バーンダウンチャート虎の巻
  • TiDD に scrum 混ぜると幸せになれるんじゃない? - Natural Software

    あきぴーさんの記事を読んで、そもそも scrum が組めていればそもそも起こらないんじゃないの?と思ったのでつらつら書いてみる(あきぴーさんも書いているけど) チケット駆動開発のアンチパターン: プログラマの思索 1-1,乱発されたチケット スプリントプランニングでタスク分割をメンバー全員で行う。 よって、チケットはメンバー全員で合意の上で作成されるので、乱発されることはない。 テスト時の不具合にしても、1イテレーション中での数はそれほど多くないと予想できるので、制御できないほどのチケットは作成されないと思われる。 1-2,有効期限切れのチケット・放置されたチケット スプリントプランニングで登録されたチケットは1スプリントですべてクローズされるはず。 残ったチケットはバックログ未完了になるので、振り返りで完了できない理由を明確にしたのち、再度振り分け(登録)される。 よって、放置されるのは

    TiDD に scrum 混ぜると幸せになれるんじゃない? - Natural Software
  • 要求について、今の理解とやってみたこと - Natural Software

    要求について、今の自分の理解とやってみたことをまとめる(今の理解なのでつっこみ大歓迎)。 参考にしたサイトを載せておきます プロダクトバックログについて海外の例も踏まえ考えたこと | Ryuzee.com 特徴(Feature)、粗筋(Story)、脚(Scenario) - サンフランシスコ出羽守手記(masayangの日記 塹壕より Scrum と XP 要求とは 要求とは顧客が欲しいと思っている、ソフトウェアの特徴(Feature)。 顧客から提示された要求を満たすことがソフトウェア開発という仕事のゴールになる。 要求を満たすために 要求を満たすためにバックログ(仕事・注文の蓄積*1)を作成する。 これがプロダクトバックログになる。 プロダクトバックログとは 顧客の要求を満たすための粗筋(Story)の一覧。 ストーリーは 誰が(As a) 何をすると(I want) 何を得る(S

    要求について、今の理解とやってみたこと - Natural Software
  • 1