タグ

ブックマーク / www.ryuzee.com (32)

  • 【資料公開】プロダクトバックログ Deep Dive

    みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 今年もスクラム実践者の祭典であるRegional Scrum Gathering Tokyoが、2022年1月5日〜7日までの3日間開催されました。 このイベントで「プロダクトバックログ Deep Dive」というタイトルで発表しましたので、資料を公開します。 スクラムガイドでも、プロダクトバックログという単語の登場回数は非常に多く、それだけ重要だということが分かります。 一方で網羅的にまとまっている資料が日語ではあまり存在しなさそうなので、今回用意してみました。 内容については、過去にこのブログで説明している箇所も多数ありますが、1箇所にまとめたことに意義があるということでご了承ください。 みなさんのお役に立てば幸いです。 内容に関するご意見やフィードバックは、T

    【資料公開】プロダクトバックログ Deep Dive
  • 【資料公開】マネジメント向けアジャイル開発概要

    みなさんこんにちは。@ryuzeeです。 2020年1月20日にとある企業の経営レベルの方向けにアジャイル開発の概要について説明した際の資料を公開します。 自社で経営者の方やマネージャーの方にアジャイル開発がなぜ必要なのかを説明する際の参考になれば幸いです。 (スライドはこちらからもご覧いただけます:https://slide.meguro.ryuzee.com/slides/101) 資料は、なぜ今アジャイルが必要なのかという点をまず理解していただけるようにコンテキストのすり合わせに主眼を置いています。 経営者やマネージャーの方にとってはスクラムの具体的なやり方といった手法部分はあまり関係なく、それによって組織がどういう影響を受けるのか、組織としてどんな取り組みをすべきなのかが分かることが重要なためです。 単一チームや小さなプロダクトでアジャイル開発をするのと、組織的にそれをスケールし

    【資料公開】マネジメント向けアジャイル開発概要
  • 【書籍発売のお知らせ】レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

    著者/訳者:David Scott Bernstein、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士出版社:オライリージャパン発売日:2019-09-18単行(ソフトカバー):300ページISBN-13:9784873118864ASIN:4873118867 書は、David Scott Bernstein氏の『Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software』の全訳です。 著者のDavidはMicrosoftやIBMを含むさまざまな企業での開発経験をバックグラウンドに持つ、特にアジャイル開発における開発者向けの教育に情熱を注いでいる独立のトレーナー/コンサルタントです。 日にも、2019年のDevOpsDays Tokyoでの基調講演やScrum Allianc

    【書籍発売のお知らせ】レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
    yujiorama
    yujiorama 2019/08/10
    Beyond Legacy Code の翻訳
  • スプリント1を始める前にどんな準備をするか

    みなさんこんにちは。@ryuzeeです。 スクラムでスプリント1を開始する前にどんな準備をしておくと良いかについては、Regional Scrum Gathering Tokyo 2018で話をしたのですが、改めて文章化してみました。 なお、かなり長いので関係なさそうなところは適宜読み飛ばしてください。 1. はじめに1.1 この記事の目的スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。 つまりプロダクトバックとスクラムチームが存在するところがスタート地点になっています。言い換えるとそれらがないとスプリントが開始できません。 稿では、実際にスクラムでスプリントを開始する前にどんな準備を行うと良いのかを考察してい

    スプリント1を始める前にどんな準備をするか
  • これからプロダクトオーナーになる人へ

    みなさんこんにちは。@ryuzeeです。 これからスクラムで初めてプロダクトオーナーをやる方に向けてのポエムです。 何はともあれ時間を確保しようプロダクトオーナーは非常に忙しい役割です。片手間でできる仕事ではありません。 例えば、プロダクトオーナーが開発チームのために週1日しか開発チームと一緒の時間をすごせず、後はメールやSlackなどのオンラインツールで非同期かつ遅延のあるコミュニケーションを取る場合を考えてみましょう。そこで起こるのは、開発のリードタイムの増加と手戻りの増加です。細かい確認をすべてオンラインでやることはできないので、開発チームは想像で物事を進めてしまい、後で認識の違いが分かり使った時間を無駄にするか、次回対面で話せるまで結論を先送りにするかのいずれかになります。 プロダクトオーナーは、プロダクトにつき1人です。サポート役をつけることはできますが、最終意思決定者が1人とい

    これからプロダクトオーナーになる人へ
  • スクラムを1枚で説明する資料7選(2019年版)

    みなさんこんにちは。@ryuzeeです。 スクラムの全体像を表す絵は多数出回っています。コーチングやトレーニングを生業にしている人であればだいたい何度も作ったことがあるのではないかと思います。 今日はスクラムの全体像を表す絵のうち、比較的新しいものをいくつか集めてみたので紹介します。 見出しの行か画像をクリックすると、それぞれオリジナルを公開しているページにアクセスできます。 The Scrum Framework Poster | Scrum.org ケン・シュエイバーが設立したScrum.orgのサイトで公開されているもの極めてシンプルなので汎用性は高い一方で、スクラムマスター、プロダクトオーナー、開発チームの記述がでてこないなど、要素がすべて網羅されているわけではないことに注意が必要Visual AGILExicon Essential Scrumの著者Ken Rubin氏作のもの。

    スクラムを1枚で説明する資料7選(2019年版)
  • アジャイル開発やスクラムのトレーニングでよく聞かれる質問とその答え (1)

    みなさんこんにちは。@ryuzeeです。 弊社ではアジャイル開発、スクラムのトレーニングを提供しているのですが、トレーニング中には多くの質問をいただきます。 今日はよくある質問とその答えについていくつかご紹介したいと思います。 好評そうだったら続編も書く予定です。 ■アジャイル開発において、ドキュメント作成の一般的な指針を教えてくださいどのようなドキュメントがいつ、どの粒度で必要なのかはプロダクトやプロジェクトに依存します。 プロダクトやプロジェクトにはそれぞれ固有の品質基準があり、それはアジャイルやウォーターフォールといった方法論の違いによって変わるものでもありません。 したがってプロジェクト冒頭でプロダクトオーナーやステークホルダー(品質管理部門や顧客など)と「なんのために」「どのようなドキュメントが」「どのような記述レベルで」「いつまでに必要なのか」を決定してください。 誰も使う予定

    アジャイル開発やスクラムのトレーニングでよく聞かれる質問とその答え (1)
  • スクラムで開発チームが自由な取り組みをするには?

    みなさんこんにちは。@ryuzeeです。 スプリントをずっと回していると、「いつもスプリントに追われている気がする」「一回立ち止まってゆっくり考えたい」「情報共有ができていない気がするので整理したい」「技術検証をもっとやりたい」「勉強時間をとりたい」といった話を聞くことがあります。 それに対して、どのように対処していくべきか考えてみましょう。 考えられる対応策はいくつもあるので、まずはそれを列挙します(ダメなものも混ざっています) 複数回スプリントを実施したら、1回分のスプリントでは開発チームは好きに活動する(✕)スプリントとスプリントの間に休憩を入れる(✕)フィーチャー開発以外の取り組みを行うスプリントを必要に応じて用意する(△)スプリントのキャパシティを見直して、開発チームが持続可能なペースで働けるようにする(◎)それぞれを順番に見ていきましょう。 複数回スプリントを実施したら、1回分

    スクラムで開発チームが自由な取り組みをするには?
  • 【資料公開】強いチームの作り方 | Ryuzee.com

    2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。

    【資料公開】強いチームの作り方 | Ryuzee.com
  • vagrant-lxcで軽量仮想環境を手に入れる

    Vagrantは標準ではVirtualBoxを仮想環境として利用しますが、とにかく遅いのが難点です。 Test-Kitchenを使ってChefのCookbookのテストをしたり、これらを継続的インテグレーションしようとしたときにこの遅さはたまりません。いくつか手段はあってお金持ちの皆様であれば、大富豪アプローチということで、仮想マシンを動かす母艦にXeon E5-2697 v2を積んだ高性能マシンを使ったりもできるのですが、普通に考えれば、VirtualBoxよりも軽量な仮想環境を使うのが有力なアプローチです。 今回はLXCを使って軽量な仮想環境を手に入れる方法を紹介します。 LXCのインストールLXC自体の説明はこの辺とかこの辺を参照ください。 インストール対象の母艦はUbuntu 12.04 LTSです。 sudo apt-get install lxc sudoの設定変更sudoのバ

    vagrant-lxcで軽量仮想環境を手に入れる
  • 翻訳 アジャイル関連書籍ベスト100(2012年度版)

    来年1月に行われるScrum Regional Gathering Tokyo 2013で基調講演をしていただく予定のJurgen Appelo氏による2012年度版のアジャイル関連書籍ベスト100に邦訳書籍の情報を加えました。書籍選びの参考までに。 なお、リストに入っていて年新たに訳されたは、リーンスタートアップ、Clean Coder(@kdmsnrさん翻訳)、継続的デリバリー(和智さん、高木さん翻訳)、アジャイルゲーム開発(@ebacky_jaさん翻訳)、アジャイルソフトウェアエンジニアリング(@tomohnさん監訳)だと思われます。Specification by Exampleとかは是非訳されると良いですねー。Management3.0は進んでいるという噂があるとかないとか。 それからJurgen氏といえば、How to Change the Worldという組織に関する短

    翻訳 アジャイル関連書籍ベスト100(2012年度版)
    yujiorama
    yujiorama 2013/01/03
    長いw
  • 【資料公開】Doneの定義虎の巻

    10月28日に日オラクルさんで行われたスクラム道EXPOに登壇しましたので資料をさらしておきます。 登壇時間が20分ということで非常に駆け足でDoneの定義について話をしました。 大事だと思うことは最後にまとめておきましたが、これについて補足しておきます。 プロジェクト開始時点で決める完成の定義の内容によってプロジェクトの所要期間や見積りは影響を受けます。たとえばプロダクトバックログアイテムの完成の定義でテスト対象ブラウザを定義することを考えてください。Mac上のChromeだけでテストする場合と、IE、Firefox、Chrome、Safari、OperaでテストしてさらにWindows7Windows8とMacとUbuntuでテストする場合とでは、タスクの見積り時間も異なります。 必然的にスプリントで完了するプロダクトバックログアイテムの量も異なります。 この合意がないままに進める

    【資料公開】Doneの定義虎の巻
  • ざっくりわかるScrum and Team Foundation Server

    2012年7月13日に行われたTFSUGに登壇しましたので、その際の資料を公開します。 今回はScrumやTFSのことをあまり知らない方向けにざっくり全体像を理解していただくことを目的としたものになっているので、既に色々な取り組みをしている人には物足りなかったかもしれませんがご容赦いただければと思います。(TFSについていうと、僕の役目はツールの機能紹介をすることではなく、思想を理解していただくヒントを与えられるようにすることだと思うので、具体的なデモとかが見たい方はながさわさんにお願いすると良いです) 個人的には、いままで色々なところでScrumの説明をしていた際と説明の仕方や順番を完全に変えたり、理解促進のための新たなワークショップを追加してそれがまずまず機能したようだったので、それが分かったのが成果です。プロセスを自分の手で絵で書いてみるというアプローチは理解促進や現状把握に非常に役

    ざっくりわかるScrum and Team Foundation Server
  • フィードバックループについての分かりやすい資料

    みなさんこんにちは。@ryuzeeです。 アジャイルな開発における重要な要素として、「フィードバックのループ」があります。 このループによって日々のプロセスや行動や品質が改善されていくことになります。 また小さな問題を無視してしまって後になってから大きな問題になることを防げますし、作り過ぎの無駄も防げます。 以下の図は、VersionOne社が公開しているフィードバックループに関するポスターで、全体像を非常にわかりやすく示しているので紹介します。 © VersionOne 以下項目を説明します。 継続的なフィードバックTDD常時ビルドリファクタリング常時結合人と人との協調他にはペアプロぐラミングなども該当します。 1日単位でのフィードバックデイリースタンドアップミーティング受入テストの実行 (※1 夜間等に全自動テストを実行するイメージ)僕のところでは受け入れテストに限らず、Subvers

    フィードバックループについての分かりやすい資料
    yujiorama
    yujiorama 2012/07/12
  • スクラムに関する無料の日本語資料のまとめ | Ryuzee.com

    みなさんこんにちは。@ryuzeeです。 スクラムを学習するにあたって参考になる【無料】の資料を以下にあげておきます。 僕がコーチングする際は上2つの資料については事前に読んでもらった上で、トレーニングを実施したりしてます。 スクラムガイドスクラムの父であるジェフ・サザーランド氏とケン・シュエイバー氏が書いた公式のルールブック。 これを読まないでスクラムをやるのはマズイです。 http://www.scrumguides.org/日語版は、多くのの翻訳をされている角さんが訳されてます塹壕よりScrumとXP昨年開催したScrum Gathering Tokyoで基調講演をされたヘンリック・クニベルグ氏によるScrumとXPの実践事例。 どういう問題がおきてどう改善したかも分かる。 http://www.infoq.com/jp/minibooks/scrum-xp-from-the-t

    スクラムに関する無料の日本語資料のまとめ | Ryuzee.com
  • プロダクトバックログにおけるよくある質問と答え | Ryuzee.com

    みなさんこんにちは。@ryuzeeです。 スクラム道FullBoostで出ていた質問と議論で若干うずうずするところがあったので、好き勝手に答えてみます。 なお、回答はあくまでコーチとしての勝手な見解であり、全てのコンテキストに有効な絶対解では決してありません。 そもそも自分達のおかれたコンテキストを踏まえた上で、どうやったらもっとうまくいくのかを考え続け改善していけばよいのです。 「パーキンソンの法則」を「ストーリーポイント」で防ぐ事はできるのか?パーキンソンの法則とは、「ある資源に対する需要は、その資源が入手可能な量まで膨張する」という法則で、開発にあてはめれば、確保した時間は、それを使い潰すまでつ使ってしまう、ということになる。 この症状をストーリーポイントによって解消できるか、という質問に対しては、答えはNoだ。 それは以下の理由だ。 ストーリーポイントは単なるポイントであり、なんら

    プロダクトバックログにおけるよくある質問と答え | Ryuzee.com
  • 自己組織化やTimeboxを理解する簡単なワークショップ

    An Agile Game - Management by Walking Aroundより。以下に紹介するワークショップは認定スクラムマスター研修などでもよく行われるもので、自分の会社でも簡単にできるので是非やってみていただきたい。 コーチやトレーナーやスクラムマスターがチームを教育するための簡単なゲームを紹介しよう。このゲームは時間もかからず簡単な体を使うもので、単純なルールやタイムボックスによって自己組織化された環境がつくられる様を示している。自己組織化された環境はリスクを軽減し、エンゲージメントやスピードや柔軟性を向上させる。 概要と事前準備所要時間:感想や報告を含めて10分〜15分対象人数:10人〜50人準備:テーブルや椅子等の物が置かれている十分に広い部屋、部屋の中にゲームの参加者が十分動けるだけのエリアの境界線を引くためのマスキングテープ。そしてタイマーラウンド1のやり方参加

    自己組織化やTimeboxを理解する簡単なワークショップ
  • スクラムがうまくいっている兆候

    みなさんこんにちは。@ryuzeeです。 昨日Twitter上で@yujioramaさんから「これは成功すると思えたスクラム導入の兆しとか読んでみたいです!」という要望を頂いたので個人的な見解を書いてみたいと思います。 なお、僕は基的に、技術力とかツールの話以前の話としてチームの態度や周りとの協調関係を重視しているので、主にそういう観点が多いことを念頭においておいてください。 プロダクトオーナープロダクトオーナーが明確なプロダクトバックログアイテムを書いている自分が書いたプロダクトバックログアイテムに責任をもっている。開発チームがプロダクトプロダクトバックログアイテムの中身についてプロダクトオーナーに確認できる開発チームが必要なときにはいつでもプロダクトオーナーにコンタクトできるプロダクトオーナーが開発チームのそばにいるプロダクトオーナーと開発チームが敵対関係でなく会話しているプロダクト

    スクラムがうまくいっている兆候
  • プロダクトバックログ項目の明確化の必要性 | Ryuzee.com

    みなさんこんにちは。@ryuzeeです。 プロダクトバックログ項目からタスクにうまく分割できないので、あればそのコツが知りたいと@riskriskさんからリクエストを頂いたので解説したいと思います。 まずは以下の図を見てください。 これはスクラムにおいて、プロダクトバックログからスプリントバックログへの流れを会議体とともに示したものです(パワーポイント版はこちら)。 実はほぼこの中に全て答えがあります。 まずプロダクトバックログ項目(ストーリーなど)からタスクにうまく落とせない場合は、以下のようなことが原因として考えられます。 そもそもなんのためにそのプロダクトバックログ項目があるのか分からないプロダクトバックログ項目の内容が曖昧または抽象的すぎて、作るべきものが分からない。または人によって著しく成果物のイメージが異なるプロダクトバックログ項目に受け入れ条件がないため、何ができたらそのバッ

    プロダクトバックログ項目の明確化の必要性 | Ryuzee.com
  • 開発をより良くしたい人が読んでおくべき10冊

    アジャイルな開発の導入支援の現場や色々な勉強会でよく「どんなを読んだら良いですか」と聞かれたりします。 何のためにを読んで勉強するかは人それぞれですし、自分のおかれたコンテキストでどのが役にたつかは分からないですが、以下にあげたは個人的に強くオススメできるです。人に聞くのも大事だし自分で試行錯誤するのも大事だけど、を読んで体系的に学んだり先人の知恵を学ぶことは続けたほうが良い。 プロダクティブ・プログラマ -プログラマのための生産性向上術どうやったら自分自身の生産性を高くすることができるのか。PCの使いこなしから始まり、自動化やバージョン管理等にも触れている プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)著者/訳者:Neal Ford、島田 浩二 (監訳)、夏目 大出版社:オライリージャパン発売日:2009-04-27単行

    開発をより良くしたい人が読んでおくべき10冊
    yujiorama
    yujiorama 2012/03/11
    10冊って上限決めて、毎年メンテナンスするとかしたほうがいいのかもしれないと思ったくらい、最近の本が増えてるなー