プロダクトバックログリファインメントはいつ何をするのか
みなさんこんにちは。@ryuzeeです。 プロダクトバックログリファインメントのやり方について立て続けに聞かれることがあったのでまとめておきます。長文ですが参考になれば幸いです。 まずはスクラムガイド2020を確認しておきましょう。該当する箇所は3箇所です。 スプリントでの説明（9ページ） スプリントでは、（中略） プロダクトバックログを必要に応じてリファインメントする。 スプリントプランニングのトピック2での説明（10ページ） 開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。 スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。 それによって、チームの理解と自信が高まる。 プロダクトバックログでの説明（13ページ） 1スプリント内でスクラムチームが完成できるプロダクトバッ
基礎からわかる内製化
みなさんこんにちは。@ryuzeeです。 2022年7月6-7日のGoogle Cloud 内製化 Dayの1日目で光栄にも特別講演をさせていただきました。 資料については、イベントページにすでに掲載されていますのでご案内します（このページにアクセスして、「公開資料」の下にある「特別講演」をクリックしてください）。 なぜ内製か？ 今の世の中はソフトウェアが企業の競争力の源泉になっていますが、そこで必要なのは、「素早く」「頻繁に」「安定的に」価値を届けること、つまり安定した「価値のフロー」の実現です。 ソフトウェアの構築は知的労働であり、実際の作り手はチームです（マネージャーや管理者、経営者ではありません）。 したがって、企業としては、安定した「価値のフロー」を実現できるチームを手にいれる必要があります。 安定したフローを実現するためには、専任が必要です。複数のプロダクトやプロジェクトを同時
【資料公開】レガシーコードからの脱却
みなさんこんにちは。@ryuzeeです。 2019年10月4日に行われたAWS DevDayの「レガシーコードからの脱却」のセッション資料を公開します。 内容は、9月に発売になった同名書籍『レガシーコードからの脱却』の全体像と一部のプラクティスの紹介という形になっています。 時間の関係で紹介できたのはごく一部の内容になっていますので、スライドを見て内容に興味をお持ち頂いた方はぜひ書籍をお読み頂ければと思います。 なお、現在Amazonの在庫が高額な値付けの転売商品？だけになってしまっているので、オライリーの直販か電子書籍(PDF、epub)をご利用ください。 45分という短い時間の中で何をお話するかは結構迷いました。本書はレガシーコードを「どうやって直すか」ではなく「どうやって作らないようにするか」に軸足を置いていて、そのためのプラクティスとして以下の9つを提唱しています。 やり方より先に
誰がプロダクトオーナーをやるとよいのか？
みなさんこんにちは。@ryuzeeです。 最近立て続けにプロダクトオーナーを誰がやるとよいのか聞かれることがあったので、パターンとメリット・デメリットを整理しておきます。 なお、組織のサイズや業種、扱っているプロダクトによっても変わってくるので、考え方のロジックとして読んでいただければと思います。 プロダクトオーナーとは？まず最初に前提として、プロダクトオーナーの責任ややるべきことをスクラムガイド（2017）で確認しましょう。 5ページ：プロダクトオーナー プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。 (中略) プロダクトオーナーは1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映する
チームパフォーマンスモデルとは？
みなさんこんにちは。@ryuzeeです。 人が集まっただけでは機能するチームにならない、というのはみなさんご存知のとおりです。 そしてチームの形成過程をあわらすモデルの1つとして有名なものに「タックマンモデル」があります（こちらを参照）。 今日はもう1つ別のモデルとしてDrexlerとSibbetが提唱している「チームパフォーマンスモデル」を紹介します。 タックマンモデルでは、チームの形成過程は形成期・混乱期・統一期・機能期・解散期の5段階（初期は4段階）で構成されていましたが、このチームパフォーマンスモデルでは、以下の7段階で構成されます。 オリエンテーション信頼の醸成ゴールの明確化コミットメント実行ハイパフォーマンスリニューアルこれらのステージは前半上から下に向います（形成段階）が、この段階では、徐々に制約を感じるようになっていきます。一方で後半に下から上にあがっていく（持続段階）につ
人を集めたからといってすぐ機能するわけじゃないという話 | Ryuzee.com
日々採用や組織がうまく動くように苦労しているみなさんこんにちは。@ryuzeeです。 ひとりで色々な物事を完結できればこんな楽なことはないのですが、特にシステム開発においてそのような規模のものは多くなく、たいていの場合複数人を集めてプロジェクトを遂行することになります。特に案件ベースで体制を作るシステムインテグレーターなんかを思い浮かべて頂くとわかりやすいかもしれません。 さて、そうやって集められた「人たち」はいきなりうまく機能して、プロジェクトのゴールに邁進できるようになるのでしょうか？というと残念ながら答えはノーです。 以下の図は、心理学者のタックマンが提唱する「タックマンモデル」と呼ばれるチーム(集団)の進化形態をあらわしたものです。 これによると、チームは以下のようなステップを経て変遷していきます。 形成期とりあえず人が集められた段階でお互いのことを知らない。なぜ集められたのか、自
Ryuzee.com
AgileコーチングAgile開発については多くの誤解があり、また経験の無いチームが自力で行うのは難易度が高いものです。当方ではオンサイトでAgile開発での企画〜開発まで全工程を支援します。例えばプロジェクト立ち上げに際しての集合研修、ふりかえりや計画ミーティングのファシリテーションなど。 DevOps実践支援DevOpsには組織とツールの2つの要素があります。サイロ型の組織構造のDevOps型組織への転換(組織デザイン、採用プロセス、評価プロセス)、ツールによるデプロイ・プロビジョニング・運用・監視の自動化など幅広い側面で支援します。チームづくりのトレーニングも提供しています。 Cloud Architecting支援ビジネスの成長やシステムの利用状況に柔軟に対応できるのがクラウドの特性ですが、一方でシステムアーキテクチャがレガシーであればそのメリットを享受できません。本支援ではマイク
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。
Electronでデスクトップアプリを簡単構築
全国5000人のエンジニアをやめて寿司職人になろうと思っているみなさんこんばんは。 前回までスライド共有用のアプリケーションを趣味(リハビリ)で作っていたのですが、折角なのでデスクトップクライアントも作ってみました。 構築にはElectronを使ったのですが、結構簡単にできたので記録としてまとめておきます。 Electronって何？GitHubが開発するクロスプラットフォームで動作するアプリケーションを開発するためのフレームワーク。コードの記述はHTML5とNode.js。その範囲であれば既存のWeb開発技術が使いまわせる。例えばjQueryとかAngularなんかを使うのも可能Chromeブラウザのオープンソース版のChroniumのエンジンを内蔵例えばAtom・Visual Studio Code・Slackクライアントや、日本だとKobitoあたりがメジャー作り方あちこちに記事があが
オープンソースのTrelloクローン Libreboard | Ryuzee.com
Trelloは、https://www.trello.com で提供されているオンラインのタスク管理サービスで、利用している人も多いと思います。僕自身も以前書いたSCRUM BOOT CAMP THE BOOKの執筆の進捗管理や、Regional Scrum Gathering Tokyoのタスク管理などで使っていました。 このTrelloのオープンソース版のクローンが登場したので紹介します。 LibreboardLibreboardは、こちらで開発が進められているオープンソースソフトウェアでMITライセンスで提供されています。2014年の頭に開発が始まり、最初の開発ペースは早くありませんでしたが、昨年末くらいから急激に開発速度が上がってきているようです。 技術的には、NodejsのフレームワークであるMeteor(メテオ)を利用しています。 Meteorの詳細については以下を参照すると良
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】カイゼンの基本
【資料公開】カンバンのキホン
【資料公開】強いチームの作り方(デブサミ2016版)