タグ

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

  • デイリースクラムのTIPS (2016年版)

    みなさんこんにちは、@ryuzeeです。 今日はデイリースクラムについて、概要や注意点を紹介します。 なお、あくまで一般論であることに注意してください。スクラムの基は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。 1. デイリースクラムの目的 2. デイリースクラムの参加者 3. デイリースクラムのタイムボックス 4. デイリースクラムの事前準備 5. デイリースクラムのファシリテーション・進行 6. デイリースクラムのアンチパターン 1. デイリースクラムの目的 スクラムを利用するとき「フレームワークで決められているから」というだけの理解で進めてはいけません。これは全てのイベントに当てはまります。 スクラムのイベントはすべて、検査と適応が行われるように明確に設計されています。 デイリースクラムの最大の目的は、

    デイリースクラムのTIPS (2016年版)
    bobniku
    bobniku 2024/04/05
  • アジャイル開発がうまくいっていない気がするというチームに確認すべきこと

    みなさんこんにちは。@ryuzeeです。 仕事柄さまざまな会社のいろいろなチームから相談を受けます。 具体的な相談のこともあれば、抽象的な相談のこともあります(内容が具体的になっていればもう解決までそう遠くありません)。 抽象的な相談で多いのは「なんとなくうまくいっていない気がするけど、何を確認したらいいの?」というものです。 今日はこの質問に対して、どう対応しているかを共有したいと思います。 スクラムをベースに書いていますが、スクラムでなくても構いません(その場合は適宜用語を読み替えてください)。 確認ポイント いきなりほぼ結論です。 このような相談を受けたときに、いちばん重要な確認ポイントは 「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらっているか?」 です。この確認をしないうちに「スクラムイベントは全部やっているか?」とか「プロダクトバック

    アジャイル開発がうまくいっていない気がするというチームに確認すべきこと
    bobniku
    bobniku 2024/03/01
  • 【資料公開】目標設定の基本

    みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと

    【資料公開】目標設定の基本
    bobniku
    bobniku 2023/05/10
  • チームの状況を把握するための5つの質問

    みなさんこんにちは。@ryuzeeです。 アジャイルコーチでもスクラムマスターでもエンジニアリングマネージャーでも、新しいチームと一緒に働くことになった場合にまず必要なのが情報収集です。 チームの様子を観察したり、1on1で聞いてみたり、ドキュメントを読んでみたりとさまざまな方法があります。 そこで、今回は直接チームのみんなに話を聞いて情報収集する場合に、5個だけ質問できるとしたら何を聞けばよいか考えてみました。 まず、初期の段階では、単に開発プロセスがうまく回っているかどうかだけを聞いてもあまり意味がありません。 そこでプロダクト、意思決定の方法、デリバリー、改善、チームのことを聞いてみようと考えてできたのが、以下の5つの質問です。 プロダクトは顧客の課題解決に役立っていますか?役に立つかどうか、役に立っているかどうかをどうやって確かめていますか?いま開発している機能は誰にとってどう役に

    チームの状況を把握するための5つの質問
    bobniku
    bobniku 2022/10/22
  • 【資料公開】マネジメント向けアジャイル開発概要

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

    【資料公開】マネジメント向けアジャイル開発概要
  • スプリント1を始める前にどんな準備をするか

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

    スプリント1を始める前にどんな準備をするか
  • スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみた

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

    スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみた
    bobniku
    bobniku 2019/04/09
  • プロジェクトが失敗する10の兆候

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

    プロジェクトが失敗する10の兆候
  • 【資料公開】強いチームの作り方 | Ryuzee.com

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

    【資料公開】強いチームの作り方 | Ryuzee.com
  • 開発をより良くしたい人が読んでおくべき10冊

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

    開発をより良くしたい人が読んでおくべき10冊
  • 1