タグ

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

  • スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみた

    みなさんこんにちは。@ryuzeeです。 以前書いたスクラムマスターを雇う時に聞いてみるとよい38個の質問という記事に対して、自分も答えてみましたので、以下で紹介します。 なお、既に38個答えた勇者がいるのでこちらも併せて読んでみるとよいと思います。 「スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答えた@katzchang/回答-スクラムマスターを雇う時に聞いてみるとよい38個の質問それでは、行ってみましょう。 スクラムマスターの役割についてアジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか?スクラムマスターの関与の度合いはチームの力量や規律の有無、外部との関係性などによって変わります。 チームが自分で解決できない大きな問題をかかえていたり、チームとして機能していなかった

    スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみた
  • スクラムイベントに出席しない優秀で不可欠な(?)エンジニアをどう扱うか

    みなさんこんにちは。@ryuzeeです。 スクラムマスター用のロールプレイのお題をTwitterに書いたら、多くの方から「自分ならこうする」という案を頂いたので共有します。 今回のお題は、以下のものです。 あなたならどうするシリーズw 『あるメンバーはデイリースクラムの時間に出社せず、ほかのイベントでも内職したり別のミーティングでどこかに行ってしまうことがしばしばです。一方で技術的には非常に優秀で、現在の速度で開発する上では不可欠な存在です。スクラムマスターとしてどうしますか?』 — Ryutaro YOSHIBA (@ryuzee) January 1, 2019その他のお題はこちらにあるので、チームで自由に遊んでみてください。 あらかじめ言っておきますが、どの対応が正解というのはありません。 これは、あくまでロールプレイなので、色々なオプションを考えておいて、実際にそのような状況に遭遇

    スクラムイベントに出席しない優秀で不可欠な(?)エンジニアをどう扱うか
  • スプリントレビューの進め方

    1. スプリントレビューの目的まず最初にスプリントレビューの目的を再確認しておきましょう。 スクラムガイドの2020年版では、スプリントレビューを以下のように定義しています。 スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することである。 スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗について話し合う。 スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、自分たちの環境で何が変化したかについてレビューする。 この情報に基づいて、参加者は次にやるべきことに協力して取り組む。 新たな機会に見合うようにプロダクトバックログを調整することもある。 スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする。 ざっくりまとめる

    スプリントレビューの進め方
  • スクラムマスターの仕事にはどんなものがあるか

    みなさんこんにちは。@ryuzeeです。 スクラムのトレーニングをしている中でよく質問を受ける項目の1つに、スクラムマスターはどんなことをすればよいのか?というものがあります。 答えを一言で表すなら、「スクラムがうまく回るようにする」なのですが、実際にどんな仕事をするのか簡単にご紹介したいと思います。 なお雑多なリストなので網羅性はありません。 スクラムマスターの仕事の一例スクラムのフレームワークをうまく回せるように支援するスクラムチームにスクラムの価値やフレームワークを理解してもらうステークホルダーにスクラムの価値やフレームワークを理解してもらうスクラムチームが持続可能なペースで進められるように支援するスクラムチームが集中を維持できるように支援するスクラムチームが透明性を維持できるように支援するスクラムチームが規律を守れるように支援するスクラムチーム内外のお互いの協力を促すスクラムチーム

    スクラムマスターの仕事にはどんなものがあるか
  • リリーススプリントとはなにか

    みなさんこんにちは。@ryuzeeです。 実際のプロジェクトやプロダクトでスクラムを利用している場合、リリースの前に「リリーススプリント」と呼ばれる期間を設けて、残作業を行うことがあります。 これが何なのかについて見ていきたいと思います。 なお、リリーススプリントは、スクラムガイドなどで定められているスクラムの要素ではありません。 あくまで、現実世界でリリースをしようとした場合に行うことがある、というくらいに理解してください(ベストプラクティスではありません)。 基的な考え方まずは基的な考え方を整理しておきましょう。 スクラムでは毎スプリントごとに「リリース判断可能」な成果物を作りますリリース判断可能とは、必ずしもリリース可能であるとは限りませんただしリリース可能になっていれば、ビジネスの要請に応じていつでも状況に対応できるようになりますつまり**「リリース判断可能」な基準と「リリース

    リリーススプリントとはなにか
  • スクラムにおける技術的スパイクの進め方

    みなさんこんにちは。@ryuzeeです。 スクラムでは、スプリントに投入するプロダクトバックログアイテムはReady(準備ができている)である必要があります (Readyとはどんな状態なのかについては以前に詳しく説明したので、そちらを参照してください)。 Readyにしておくことによって、成果の量が安定しプロダクトオーナーやステークホルダーにとっては予測精度が向上していきます。 Readyにする活動は単に受け入れ基準を用意したり、プロダクトバックログの内容を精緻化したり、並べ替えたりするだけではありません。 スプリント内でプロダクトバックログアイテムが完成する可能性を上げるために必要な活動すべてが含まれます。 そしてその中の1つが技術的な調査です。 スプリントでプロダクトバックログアイテムに着手してから実現方法を調べたり、技術的な制約によって大幅な方針転換したりするのでは遅い上に予測性が低

    スクラムにおける技術的スパイクの進め方
  • Impediments(障害事項)への対応

    みなさんこんにちは。@ryuzeeです。 Impediment(障害事項・妨害事項)について、海外で良い記事がいくつかあったのでご紹介しましょう。 Recognizing ImpedimentsThe biggest impedimentImpedimentとはスクラムでよく使う単語で、プロジェクトを進めていく上での障害や妨害になる事項のことです。 人的なもの、プロダクトに関するものなど全てを含みます。 例えば以下のようなものが一例になります。 未完了なままの作業情報の不足繰り返しの作業待ち依存先の欠如割り込みバグ官僚主義間違った、もしくは不明瞭なコミュニケーション意思決定がなされない間違った推定時間がたりないパーツがないよく知らない新しい技術 などなど、ほかにもたくさんあります。 当然のことながら、これらの障害事項を把握することは大事ですし、日々の活動の中で優先順位をつけて改善していかな

    Impediments(障害事項)への対応
  • ベロシティに対する誤解 | Ryuzee.com

    みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 ストーリーポイントとは?まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』(Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29)の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。 ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような

    ベロシティに対する誤解 | Ryuzee.com
  • スクラムの導入状況のサマリー (The State of Scrum Report 2017)

    みなさんこんにちは。@ryuzeeです。 スクラムの導入状況Scrum Allianceが調査を行ったThe State of Scrum Reportの2017年版が公開されていますので、サマリーを見ていきましょう。 なお、レポートはこちらから無料でダウンロードできます。 調査の概要2016年秋に実施。回答者はScrum Allianceのメンバー2000人以上から回答。なおメンバーになれるのは、認定スクラムマスターや認定スクラムプロダクトオーナー等のコースを受講した人であるため、回答者の属性はスクラムの知識がある人に偏っていることを前提として認識しておく必要があります。 回答者は76カ国、15以上の産業にまたがっており、40%がIT関連の仕事、26%がソフトウェア開発に携わっているそうです。 質問内容は全部で44個から構成されており、アンケート回答者の属性・スクラムの導入状況・スクラム

    スクラムの導入状況のサマリー (The State of Scrum Report 2017)
    eternal-shining
    eternal-shining 2017/08/05
    世界を見てもぶつかる悩みは同じなんだなと。 国別比率も知りたいな。アメリカ国内は導入率が高い印象があるので、そんな中でもどれくらい苦労してるのか。逆に省いた時の他の国の導入状況とか。
  • スプリントでのプロダクトバックログ項目着手の方法

    みなさんこんにちは。@ryuzeeです。 スプリント中に対象のプロダクトバックログアイテムにどのように取り組んでいくか、というのは意外とよく質問を受けるので、ここで整理しておきたいと思います。 話を分かりやすくするために、スクラムボードを見ながら考えていきます。 アンチパターン1:プロダクトバックログアイテムごとに担当を決める まず最初に避けるべきなのは、プロダクトバックログアイテム単位で担当を決めてしまうやり方です。スクラムでは誰かが開発チームのメンバーに対して作業を割り当てることはしませんが、割り当てているかどうかに関係なく、開発チームのメンバーが「特定のプロダクトバックログアイテムにサインアップして、そこを全部担当する」というのも避けるべきです。 このやり方をした場合には、次のような問題が発生します。 開発チームのメンバーは自分がサインアップしたプロダクトバックログアイテムの完成ばか

    スプリントでのプロダクトバックログ項目着手の方法
  • スクラムで依存関係を取り扱う方法

    みなさんこんにちは。@ryuzeeです。 コーチングをしていてよく聞かれる質問の1つに、チーム間をまたがる依存関係の管理をどうするか、というものがあります。 これの回答となる素晴らしい記事がTHE QUIET AGILISTというサイトで公開されていました。 著者のRick Cusolitoさんに記事の翻訳と公開を快諾いただきましたので、以下で紹介いたします。 元記事はこちらです。http://www.quietagilist.com/blog/2014/10/16/handling-external-dependencies-in-scrum スクラムの依存関係を扱う3つの実績のある方法 開発チームは機能横断的(クロスファンクショナル)である。インクリメントを作成するスキルをチームとしてすべて備えている。- K. Schwaber and J. Sutherland、スクラムガイド、

    スクラムで依存関係を取り扱う方法
  • あなたのチームのスクラムマスターがうまく作用しない7つの理由

    みなさんこんにちは。@ryuzeeです。 7 Reasons Your Scrum Master May Be Underperforming より抜粋・意訳でご紹介します。 うまくいかないスクラムマスターのパターンは以下にあがっている以外にもたくさんありますが、個人的には、スクラムマスターがチームのファシリテーション役や問題の解決役にならずに、指示出し役になってしまっているケースが良くないケースだと思います。 往々にしてそういう場合はスクラムマスターがチームのメンバーよりも社内の役職上立場が上だったりもします。 スクラムで開発する場合、スクラムのロールの帽子をかぶる人は、少なくともプロジェクトの中では役職の帽子は脱いだほうが良いだろうと思います。 チームで偉大で効果的なスクラムマスターを持つために何を必要とするだろうか? スクラムマスターは私が思うにスクラムチームの中で最も誤解されている

    あなたのチームのスクラムマスターがうまく作用しない7つの理由
  • プロダクトバックログ項目はReadyなものだけスプリントに投入するべきという話

    みなさんこんにちは。@ryuzeeです。 プロダクトバックログはスクラムにおける生命線の1つです。 プロダクトバックログが良くないとプロダクトの価値がでなかったり、そもそもスクラムチームとして安定したデリバリーを行えません。 プロダクトバックログでよく起こる問題プロダクトバックログを管理する上でみなさんがよく知っているのは、並び替えをする、という点ですが、これだけではまったく不十分です。 単に並び替えだけをしたプロダクトバックログで、スプリントを始めてしまうと以下のようなことが起こります。 選択したプロダクトバックログアイテムの中身に対してプロダクトオーナーと開発チームの理解が違ってしまうそのためスプリントを開始した後に頻繁にプロダクトオーナーと会話をする必要が出てきてしまい、場合によっては来の要求が別のものであることが判明するもしくは色々会話をしていたら、当初の想定以上に規模が大きいこ

    プロダクトバックログ項目はReadyなものだけスプリントに投入するべきという話
  • オープンソースの全文検索エンジンFessを試してみた

    みなさんこんにちは。@ryuzeeです。 このWebサイト、昔はWordpressを使っていたのですが、体やプラグインのメンテナンスを頻繁にやらなきゃいけなくて面倒なのと性能面などで辛くなって、その後Ruby製の静的サイトジェネレータであるMiddlemanに変更し、その後ビルドの遅さに耐えられなくなってGo言語で作られているHugoに置き換わっています。 静的コンテンツになればAmazon S3などで運用できるので非常に楽なのですが、一方でサイト内を検索したい場合は別の解決策の用意が必要になります。Googleの検索を埋め込んでももちろん良いのですが、調査の一環として、今回はオープンソースの全文検索エンジンFessを試してみました。 Fessの特徴公式サイトで詳細に紹介されていますが、主な特徴として以下のようなものが挙げられます。 5分で簡単に構築可能Apache ライセンスJava

    オープンソースの全文検索エンジンFessを試してみた
  • 人を集めたからといってすぐ機能するわけじゃないという話 | Ryuzee.com

    日々採用や組織がうまく動くように苦労しているみなさんこんにちは。@ryuzeeです。 ひとりで色々な物事を完結できればこんな楽なことはないのですが、特にシステム開発においてそのような規模のものは多くなく、たいていの場合複数人を集めてプロジェクトを遂行することになります。特に案件ベースで体制を作るシステムインテグレーターなんかを思い浮かべて頂くとわかりやすいかもしれません。 さて、そうやって集められた「人たち」はいきなりうまく機能して、プロジェクトのゴールに邁進できるようになるのでしょうか?というと残念ながら答えはノーです。 以下の図は、心理学者のタックマンが提唱する「タックマンモデル」と呼ばれるチーム(集団)の進化形態をあらわしたものです。 これによると、チームは以下のようなステップを経て変遷していきます。 形成期とりあえず人が集められた段階でお互いのことを知らない。なぜ集められたのか、自

    人を集めたからといってすぐ機能するわけじゃないという話 | Ryuzee.com
    eternal-shining
    eternal-shining 2016/01/21
    いいまとめ。多分みんな気付いてて、だからこそ”チームビルディング”などという言葉があるのでしょうが、明確な言葉を使ってこういうのを予め理解できていると落ち着いて対処出来ますよね。
  • スキルマップ作成のすすめ

    チームでの開発って大変だけど楽しいと思ってるみなさんこんにちは。@ryuzeeです。 チームは共通の目標に向かって日々の仕事に取り組んでいくことになりますが、そのためにはメンバーそれぞれが必要なスキルをもっている必要があります。このスキルを見える化するテクニックの1つとしておすすめなのが、スキルマップです。 作り方は簡単で以下の図のように横軸に必要なスキルを、縦軸にチームメンバーの名前を入れます。それぞれのマスでは、その人のスキル度合いを表す印を入れていきます。ここでは、★:エース、◎:得意、○:一人でできる、△:助けがあればできる、空欄:できない、・:今後習得したい、というようにしていますが、この記号はチームで好きに決めて構いません。 このスキルマップの効用と運用について見ていきましょう。 効果:スキルの見える化長い間同じチームで働いていれば、誰が何をできるのかはだんだん分かっていきます

    スキルマップ作成のすすめ
  • プロジェクトが失敗する10の兆候

    今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス

    プロジェクトが失敗する10の兆候
    eternal-shining
    eternal-shining 2016/01/04
    年始早々目の覚める記事。 失敗する話だけでなく、対策もあって前向き。そして、気付いてて声をあげないあなたも同罪ってのも納得。...
  • Agile関連記事総まとめ

    著作 SCRUM BOOT CAMP THE BOOK 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎 出版社:翔泳社( 2013-02-13 ) 定価:¥ 2,520 スクラム初心者に向けて基的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。 CakePHPで学ぶ継続的インテグレーション 著者/訳者:渡辺 一宏 吉羽 龍太郎 岸田 健一郎 穴澤 康裕 出版社:インプレス( 2014-09-19 ) 定価:¥ 4,320 Webアプリケーション開発における継続的インテグレーションについて、CakePHPのサンプルをベースにして、その概要から使用ツール解説、導入方法、メンテナンスまでを解説 Chef実践入門 ~コードによる

    Agile関連記事総まとめ
  • ドキュメントレビューをする際の10のポイント | Ryuzee.com

    みなさんこんにちは。@ryuzeeです。 重厚長大なドキュメントは、動かなかったり嘘が書いてあったり現実と異なっていたり、その上肝心なこと書いてなかったりということで辛いことが多いのが現状です。 今回とある筋からドキュメントをレビューする際のポイントを教えて欲しい、という依頼を受けたので書いてみます。 なお、個人的には、ドキュメントレビューよりソースレビューの方が重要だと思っています。 とはいえドキュメントレビューで肝心なのは、 ドキュメントレビューをするなら、その投資に見合う何を得るのか?を決めておく必要がある当にそのドキュメントは必要か?をよく考える(会社のルールだから!というのは理由にはなっていない)だと思います。 レビューのポイント1. 体裁をレビューするのではなく、中身をレビューするひどい現場だと、文書のインデントやフォントのサイズ、誤字脱字ばかりを重箱の隅をつつくようにチェッ

    ドキュメントレビューをする際の10のポイント | Ryuzee.com
  • 1