OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics
はじめに こんにちは、土屋と申します。バニッシュスタンダードで社内システム保守とスクラムマスターを担当しています。最近の趣味は早朝にゼルダの伝説ティアーズオブキングダムをプレイすることです。なかなかハイラルが平和になりません。トーレルーフ!! ところでみなさんスクラム開発しっくりきてますか?完璧ですか?心酔してますか? 僕は開発メンバーとして何度かスクラム開発を経験してきましたがどうもしっくりきませんでした。ウォーターフォールやデスマーチしていたあの頃に戻る気はないけど、とはいえ良さが理解できない。こんな印象が拭えないままスクラムマスターになってしまいました。 でも。こんな僕でもスクラム開発とちょっとだけ仲良くなれた気がしてきました。スクラム開発と仲良くできない、しっくりこない、そんな方に向けて1つの情報になれば幸いです。 スクラムマスターになった経緯 昨年末、スクラムマスターだった dk
今や生産性の可視化・評価指標といえば本書籍で紹介された『FourKeys』ですね。ちまたでは、絶対視されている様な表現・評価がされている記述をたまに見かけます。ですが、本当にそうでしょうか?ある方が調べたところ、FourKeys を使用している人のうち『Lean と DevOps の科学』を読んだことがない人は9割近くもいたそうです。 本記事では、FourKeys を有効に活用するために知っておくべき・理解しておくべき事柄を幅広い分野でまとめました。生産性を向上し、仕事の成果の質を上げたいと努力するエンジニアの方々が、次の日から使える情報を書けたのではないかと思います。FourKeys だけを見て生産性を上げるという行動は手段の目的化につながりかねません。Fourkeys の背景にある思想を知ることで、FourKeys を真に活用するきっかけになればと思います。 目次 初めに GW中に読も
Vercel Functions run code on demand without the need to manage your own infrastructure, provision servers, or upgrade hardware—and are now powered by Rust under the hood. We're gradually rolling out these improvements to new deployments, with all customers on our new Rust-powered functions in the coming weeks. No action is required. We've already served billions of invocations on our new system, w
Ruby typing 2024: RBS, Steep, RBS Collections, subjective feelings I was writing a new Ruby gem recently, and being a strong proponent of a type checking step, I wanted to do right by the ecosystem so that anyone using it would get the full benefit of type checking against my gem’s API in their own projects, so I dug into the current state of the art to find out how that’d be done. I used Sorbet f
WEBアプリケーション開発者です。 特別セキュリティのスペシャリストになりたいというわけでないですが、アプリケーション開発者として徳丸本に記載されている内容レベルのセキュリティ知識はあります。 システムのセキュリティに関してはベンダーの脆弱性診断を通して運用しており、個人的にはセキュリティに関して何か困ったことがいままでありません。 ただ、ふと考えてみると「情報漏洩やサイバー攻撃が発生した際などの有事にどのような行動をとるべきか」という観点ではあまり自信がないなと感じました。社内でもそのような場合の指針が整っているわけではないです。 徳丸先生は、一般的な開発者には最低限どのレベルのセキュリティ知識を求められていますか? 回答の難しい質問ですが、ここは本音をさらけ出したいと思います。 私が「安全なWebアプリケーションの作り方(通称徳丸本)」を出したのが2011年3月でして、それから13年以
機械学習・データ部 / データチームの @irotoris です。こんにちは。 データチームでは社内で使うデータプラットフォームやデータマートの開発をしています。今日は弊チームの開発スタイルの中から「プレスリリース駆動開発」を紹介します。 データチームの開発スタイル データチームの開発は1週間のタイムボックスで、月曜日にバックログやプロジェクトから今週取り組むタスクを計画し、金曜にスプリントレビューを行っています。デイリーでは夕会を行っています。ベロシティの計測などは今のところできていませんが、いわゆるスクラムっぽい開発です。 その月曜朝の計画会で、まずプレスリリースを書いています。 プレスリリースとはなにか? 本来プレスリリースは新商品や新サービス、経営・人事などの企業情報を、ニュースとしてメディアに掲載する文書ですが、ここではデータチームが開発・提供する機能や改善をユーザーに伝えるため
『みんなで小さく区切ってやる』とは『みんなで小さく区切ってやる』は複雑な問題を解決するためにみんな(チーム)で一緒になって改善していくためのやり方です。 『みんなで小さく区切ってやる』で大事な考え方は『経験から学ぶ』と『ちょっとずつ進める』です。小さく区切ることで、ちょっとやってみて、それから学び、またちょっとやってみる。それを繰り返しながら進みます。 『みんなで小さく区切ってやる』を上手にするには『見える化』『チェック』『改善』の3つが重要です。これにより『経験から学ぶ』効果を高めます。 機会を作る『見える化』『チェック』『改善』を取り入れるために5つの機会を設けましょう。これらの機会は毎回同じ時間に行うことでリズムが生まれいい感じになります。 『区切り』があることで立ち止まれます。立ち止まることで落ち着いて『チェック』し『改善』することができます。この『区切り』は1週間もしくは2週間に
はじめに 今回プロダクトマネージャーの動きを行っていく中で、新しい気づきがあったので記事としてまとめました。 プロダクトマネジメントをプロダクトマネージャーだけで行わない プロダクトマネジメントとは、プロダクトを成功に導く考えであり、これはプロダクト作りに関わる人であれば必ず必要になってくるものです。 つまり、プロダクトマネジメントとは特定の誰かが行うアクションではなく、チームや組織全体で行っていくものだと考えています。 プロダクトマネージャーの役割 プロダクトマネージャーの主の役割とは、もちろんプロダクトマネジメントを行うことです。 しかし、プロダクトマネジメントが行えている状態を組織として目指すためには 「プロダクトマネジメントをすること」だけではなく「プロダクトマネジメントができる組織づくり」も行う必要があると考えています。 そのためには、プロダクトマネージャーとして、「プロダクトマ
DPE(Developer Productivity Engineering)ユニットに所属している、alpaca-tcです。 最近モジュラーモノリス化を進めるためにRuby動的解析ツールを作ったので、その話をします。 📝 私事ですが、新潟の佐渡島に移住しました。新潟や佐渡島のRubyistの方がいらっしゃいましたら、ぜひRubyKaigiでお友達になってください! SmartHRではRailsのモジュラーモノリス化を検討をしているよ Railsにおける「モジュラーモノリス」は、アプリケーションを拡張性のある構造にするために、単一プロセスでモノリスアプリケーションを区分されたサブセット(モジュール)に分割するアーキテクチャのことです。 SmartHRでは、コード量が多いプロダクトでモジュラーモノリス化を進めています。 すでに新規機能の開発では導入されていますが、既存コードのモジュラーモノ
TypeScript の型システムを活用して、本番のアプリケーションにおける実用的な問題を解決することを目指しています。Effect-TS は、以下のような特徴を備えています。 並行性(concurrency):Fiber ベースの並行モデルにより、高いスケーラビリティと低レイテンシを実現 コンポーザビリティ(composability):小さく再利用可能なパーツを組み合わせることで、メンテナンス性、可読性、柔軟性の高いソフトウェアを構築する リソースの安全な管理(resource-safety):処理が失敗したとしても、安全にリソースを開放する 型安全性(type-safety):TypeScript の型システムを活用した型推論と型安全性に焦点を当てている エラー処理(error handling):構造化された信頼性の高い方法でエラーを処理する 非同期性(asynchronicity
顧客、ユーザーの片側だけにアプローチをしているケースが多い 吉羽龍太郎氏(以下、吉羽):あと15分ぐらいみたいなんですけど、あと2つですかね……あっ、3つだ。「ユーザーを巻き込む覚悟」「未完成なプロダクトを人に使ってもらう覚悟」「プロダクトや機能を終了する」という話にいきたいと思います。 触れているところもだいぶ多いと思うので、ちょっと順番にいきたいと思います。ここまでは人を巻き込むといっても、ステークホルダーやチームメンバーという話でした。今度はユーザーというところにいきたいと思います。 顧客とユーザーは意外と混同されがちですよね。顧客とユーザーは、toBかtoCかによってけっこう変わってきますけど、これはどういうふうに考えるといいんですかね? お金を払ってくれる人はもちろん大事だし、使ってくれる人も大事。ここでは、ユーザーを巻き込むと言っているんですけど、お金を払ってくれる人はそれなり
Next.js 型安全なルーティングを使う 2024.04.28 Next.js では実験的な機能として、型安全なルーティングを利用できます。この機能を使うことでリンク先のパス名を静的に検査できるため、typo などのエラーを事前に防ぐことができます。 この記事における「型安全」とは、静的な型検査によりランタイムで起こり得るエラーを事前に検知することを指します。 Next.js では Next.js 13.2 より実験的な機能として、型安全なルーティングを利用できます。この機能を使うことでリンク先のパス名を静的に検査できるため、typo などのエラーを事前に防ぐことができます。 なお、型安全なルーティングを利用するためには App Router と TypeScript を使用している必要があります。 型安全なルーティングの利用方法 型安全なルーティングを有効にするためには、experim
「撤退はしないくせに投資もしない」はインパール作戦みたいなもの 吉羽龍太郎氏(以下、吉羽):さてさて、あと5分ぐらいなので、最後の「プロダクトや機能を終了する」という話をして、終わりにしたいと思います。これ、僕らは散々言いますよね。もう口酸っぱく言いまくるという感じかな。 「プロダクトをやめられない」とよく聞きます。だから人が分散しちゃって勝負にならなくなっちゃうというのが、すごくありますよね。薄い人数のチームがいっぱいあって、どれも塩漬け、プラス、運用対応をちょっとだけしてみたいな。 それで、「メンバーのモチベーションが上がらないんですけど、どうしたらいいですか?」、いや、そりゃ、そんな塩漬けを運用させていてメンバーのモチベーションが上がるんだったらやり方を教えてくださいよという感じだと思います。これはもう(プロダクトを)捨てろという話だと思うんですが、それ以上の話はなにかあります? 及
はじめに どうも、元QAのエンジニア @Syahu_Writer です。 今回は、元QAが開発チームにjoinしてから行った品質向上のための施策について紹介していきます。 大なり小なりいろいろとやってますが、代表して以下3つを話します。 ・開発プロセスの改善 ・シナリオテストケーステンプレートの改善 ・不具合の再発防止 開発プロセスの改善 以下は当初の開発フローを図に書き起こしたものです。 この図から読み取れる問題点はざっくりと、 ・すべて直列のフローだが、並列処理にしていいものも混じっている ・テスト完了レビューといった、不要で実際に行われていないものがある ・レビューのタイミングが悪く、大きく手戻りが発生する箇所がある という状態でした。 それを以下の通り修正しました。 ・並列にして問題ないものは並列にする ・不要なプロセスは削除する ・手戻りが最小限となるようにレビューを設置する ま
海外版のピザ屋のデモ 森正弥氏:海外版のピザ屋のデモを流せればと思います。英語がちょっと流れますが、こんな感じです。 ピザ屋に店員のAIアバターがいて、お客さんが来て……お客さんがだいぶぶっきらぼうですけど(笑)、答えていくのをハンドリングして、最後はペイメントまでやるという感じでした。シナリオは一定はありますが、これは裏がLLMで、ここではNVIDIAのNeMoを使って会話をやっているので、シナリオじゃないアクションにももちろん普通に対応できます。 例えばいきなり「アジャイルって知っている?」と聞いたらきちんと答えてくれます。NeMoは英語とスペイン語がすごく得意なので、このデモは英語のデモになっていますが、日本語でも動きます。 あと、単にこれは単なるマイクロサービスのマッシュアップなので、23個ぐらいのマイクロサービスが立ち上がっていて、そんなに立ち上げるのかと思いながらやっています。
こんにちは、プロダクトエンジニアのa2cとプロダクトマネージャーのdaisukeです。 本稿では、2024年1月に組成され、スクラムを採用した私たちのチームが最初の3ヶ月間に直面した課題とその改善策、それによってもたらされた変化を共有します。スクラムに参加するエンジニアとPMの多様な視点を取り入れ、実際の経験に基づく具体的な事例をオープンに紹介します。 なお、この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。ぜひ他の記事もご覧ください。 チームの紹介 PM1名・プロダクトエンジニア3名の計4名がコアとなり、価値提供に責任を持ちます。そのコアチームに兼任のプロダクトエンジニア(チーフ)1名・兼任のプロダクトデザイナー1名が加わりチームを構成しています。専任のスクラムマスターはいません。 担当しているプロダクトとプロジェクトは、SmartHR Plu
「NO」と言うのはメチャ重要 及川卓也氏(以下、及川):逆に言うと、リソースが限られているからこそ研ぎ澄ます時に、どこを削るべきかというのができる。 吉羽龍太郎氏(以下、吉羽):そう、それが振りで、「NOと言う覚悟」の話をしようかなと思っていたんですけど。 及川:あと、あれですよ。「未完成なプロダクトを人に使ってもらう覚悟」というところにつながってくるんですよね。 吉羽:そうそう、そうそう。そのあたりの話をしていけたらいいかなと思うんですけど。 「NO」と言うのはメチャ重要だなって。僕らはすごく気軽に「NOと言ってください」と言うんですけど、いざ言うとなったら、むちゃくちゃ難しいワードだと思います。 及川:そのとおりですね。でも、「NO」と言っていますよね。 吉羽:そう。自分の経験上まあまあ言っていると思うんですけど、けっこう慣れが必要な気もしますよね。 及川:そうですよね。私は吉羽さんと
その人の人生を狂わせるくらいの巻き込む能力が必要 吉羽龍太郎氏(以下、吉羽):2つ目の「ヒトを巻き込む」という話も出ました。このペースでしゃべったら絶対終わらないので、そろそろ次のテーマにいきたいと思います。 次が今、及川さんから振りがあった、「ヒトを巻き込む覚悟」ですね。ちょっとこっちについて話していきたいと思うんですけど。 これもいろいろな話がありますよね。人といっても、自分のチームのメンバーも人じゃないですか。それから、ステークホルダーも当然巻き込む対象になってくると思うんですけど。 ユーザーに関しては、下で触れようと思うので1回置いておいて、チームとステークホルダーという観点でいうと、どんな覚悟が必要ですかね? 及川卓也氏(以下、及川):人の人生を狂わせちゃうかもしれないわけで。 吉羽:(笑)。 及川:スタートアップは、「俺の会社でこのプロダクトを作って世界を変えようぜ」と言って、
不確実さが増す世界のプロジェクトマネジメントとはとういうものか 倉貫義人氏:そんな不確実さが増す世界のプロジェクトマネジメントはどういうものなのか。(スライドを示して)プロジェクトがうまくいかない(理由)というのは、このあたりを見てもらうと胃が痛くなりそうな言葉がいっぱい書いてあると思います。想定よりコストがかかるとか、作ったものを直せないとか。 (スライドを示して)これに対してどうすればいいかというと、「こうすればうまくいくのかな?」と考えがちですよね。「遅いからプレッシャーをかけようか」とか「少し遅れているので人を増やそうかな」とか「一気に作ったほうがいいんじゃないの?」とか「属人性を排除しましょう」とかと言いがちですよね。 これらはけっこう言いがちですが、全部失敗するやつです。これを全部やってみたら困ったことにプロジェクトが大変なことになるので、ぜひやってみたらいいと思います。 (会
アジャイル開発に関心がある人にとって、トヨタ自動車と聞いてすぐ思い浮かぶのは「TPS(トヨタ生産方式)」でしょう。 かんばん、ジャスト・イン・タイム、リーンなど、そのクルマ作りにおける考え方は多くのアジャイル開発手法の源流にもなっています。 一方、現代のアジャイル開発が主眼としているのは、変化への迅速な適応が求められるソフトウェアシステムの開発です。 自動車やその部品(ユニット)のようなハードウェアを開発する際の手法としてアジャイル開発手法を採用するケースはまだ決して多くありません。 そのような中、トヨタ自動車のエンジンを含む駆動系の技術開発を担うパワートレーンカンパニーでは、アジャイルなハードウェア開発への取り組みを2021年ごろから本格的に進めています。 さらに2023年9月のスクラムフェス三河や、2024年1月のRSGT 2024(Regional Scrum Gathering T
テーマは「プロダクトマネージャーの“覚悟”を分解する」 司会者:それでは、キーノートセッションを開始いたします。「プロダクトマネージャーの『覚悟』を分解する」と題して、Tably株式会社、代表取締役。Global Hands-On VC、Founding Partner。アドビ、Executive Fellow。クライス&カンパニー、顧問、及川卓也さま。株式会社アトラクタ、取締役CTO、アジャイルコーチ、吉羽龍太郎さまよりご講演いただきます。 及川さま、吉羽さま、よろしくお願いいたします。 (会場拍手) 吉羽龍太郎氏(以下、吉羽):よろしくお願いします。 及川卓也氏(以下、及川):おはようございます。よろしくお願いいたします。 吉羽:じゃあ、さっそく始めていきたいと思います。今日は、「プロダクトマネージャーの『覚悟』を分解する」というテーマでお話をさせていただきます。実は、実行委員の方から
NTT Com Open TechLunch #7「エンジニアリングマネージャー と 目標設定」の登壇資料です。20分くらいの短いセッションなので網羅的ではありません 2. 吉羽龍太郎 / Yoshiba Ryutaro アジャイル開発、DevOps、クラウドコンピューティング、インフラ構築自 動化、、組織改革を中心にオンサイトでのコンサルティングとトレーニン グを提供。Scrum Alliance認定スクラムトレーナー(Regional, CST-R) チームコーチ(CTC) / 認定スクラムプロフェショナル(CSP) / 認定スク ラムマスター(CSM) / 認定スクラムプロダクトオーナー(CSPO) 2
おことわり 最初に断っておきますが、私はスクラム開発反対の立場をとっているわけではないです。また、スクラムマスターでもないのでスクラム開発について誤った見解を持っている可能性も大いにあります。 また、これから記載するスクラム開発のペインはあくまでも筆者の独断と偏見に基づいて記載されております。そのため、ペインの原因がスクラム開発ではなく、単にその所属組織の構成員の性質や文化的な要因であることも考えられます。おそらく、スクラム開発でなくても起こり得る問題も多く挙げていると思います。そういった側面も踏まえてご意見あれば忌憚なく反論異論いただければ幸いです。 なぜこの記事を書いたか チーム内で密なコミュニケーションをとりながら、個人ではなくあくまでもチームとしての成果を重視するスクラム開発の開発フローは、割と個人の活躍と成長機会を奪ってしまい、結果として組織としても開発成果が縮小均衡になってしま
そもそもポッドキャストって何?映像のない YouTube のような存在が ポッドキャストです。 つまり、ラジオのようなものです。 YouTube のように、素人も投稿できる音声 メディアです。 どうやって聞けるの?iOSからであれば、Apple Podcast Androidからであれば、Googleポッドキャスト ※Googleポッドキャストは、YouTube musicに統合の話が出ている 他にSpotify、Amazon music、radikoからも聞けるらしい。 おすすめのポッドキャストヤング日経経済系の番組はおじさんがしゃべっていることが多いが、この番組は若い大学生~大学院生の女の子が最近の経済について 話しており、非常に聞きやすく、軽い気持ちで聞けるのが良い。ポッドキャスト的な流し聞きに向いてる。 日経トレンディ & 日経クロストレンド日経トレンディ及び日経クロストレンドとい
The Agile Manifesto [1], created in 2001, brought about a significant shift in the development of (software) products. The values and principles in the manifesto have since evolved and expanded, and we continue to discover better ways to implement them. Overall, the changes have been positive and continue to benefit the industry. This article discusses the journey we have collectively taken over t
多分今回のポストは多くの人には参考にならないだろう。相当ニッチなので。でもこれは自分にとってはとても大きなことだったので、忘れないように記録しておきます。 生産性の悩み あまりこの世界では生産性とはあいまいな言葉で、何をもって生産性が高いとは言いにくい。速いのが良いのではない。ただ、自分の実感として自分は生産性が良くないといつも感じていた。だからいろいろ努力したり、考え方をできる人を観察して真似してみたり、直接本人に聞いたりして工夫をしてきた。 実は自分はめっちゃコーディングが早い人になりたいわけではない。そうではなくて、「平均的」になりたいだけだ。それぐらいいければ「Strategy」でカバーできるどころかもっと上に行けると確信があったから。でもそうではなくて明らかに遅いのでそれが自分の足を引っ張っていた 努力の方向性 様々な努力をして、特に有効だったことを自分の本に書いたつもりではある
NEW! 2024.04.12 スキル 未踏落合陽一登大遊プログラマー 登大遊、落合陽一など数々のスーパークリエータを輩出してきた、独立行政法人情報処理推進機構(IPA)の「未踏IT人材発掘・育成事業」(以下、未踏IT)。その立ち上げから現在までを知るのが、統括プロジェクトマネージャーの竹内郁雄さんだ。 2017年には、ビジネスや社会課題解決につながる人材を発掘する「未踏アドバンスト事業」にも統括プロジェクトマネージャーとして参画。国際的なデファクトスタンダードとなるソフトウェアを日本から生み出すべく、人材育成に心血を注いでいる。 前身の未踏ソフトウェア創造事業から数えて24年。のべ2000人を超える修了生を見てきた竹内さんだから言える、優れたエンジニアに共通して求められる素養を聞いた。 未踏事業統括プロジェクトマネージャー(PM) 一般社団法人未踏 代表理事 竹内郁雄さん 1946年、富
★ はGitHubによって作られるものです。 以降、ビュー名はアルファベットで表記します。 New Item Product Backlog Item (PBI)候補の新アイテム一覧を表示します。新アイテムはリファインメントの度に確認され、Product Backlogへ移るため、本ビューは空が基本の状態となります。 クエリ no:size -ready:"Drop" Product Backlog PBIの一覧を表示します。優先順位順に並んでおり、プロダクトオーナーの合意の下で並び替えを行うことができます。 クエリ is:open -no:size -ready:"Drop" Sprint Backlog 今スプリントの対象となっているPBIとその進行状況を表示します。 クエリ sprint:this レーン概要 statusカラムの値ごとに整理されます。 TODO 進行中ではないアイテ
春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で
これは、複数の他社の人から聞いた話をくっつけたり混ぜたり脚色した話になる。つまるところフィクションだ。 あるIT企業ではチームごとに始業時にスタンドアップミーティングを行っている。スクラムで言うところのデイリースクラムである。よくあるやつだ。 ある日、5〜6人くらいの小規模チームに新しいメンバーが加入した。新卒ではないけれど第二新卒くらいの若さのメンバーであった。将来的にはリードする役職(テックリードだったり、デザインリードだったりそういうやつ)につきたいという、意欲のあるメンバーだ。仮にメンバーを山田としよう。 入社後しばらくした山田からマネージャーに相談があった。 「毎朝、スタンドアップミーティングをしているが、時間の無駄にしか感じない。それぞれが進捗を共有するが、自分には関係ないタスクの話を聞いても意味がないので早くタスク消化に入りたい。」 マネージャーはスタンドアップミーティングの
みなさんこんにちは、@ryuzeeです。 今日はデイリースクラムについて、概要や注意点を紹介します。 なお、あくまで一般論であることに注意してください。スクラムの基本は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。 1. デイリースクラムの目的 2. デイリースクラムの参加者 3. デイリースクラムのタイムボックス 4. デイリースクラムの事前準備 5. デイリースクラムのファシリテーション・進行 6. デイリースクラムのアンチパターン 1. デイリースクラムの目的 スクラムを利用するとき「フレームワークで決められているから」というだけの理解で進めてはいけません。これは全てのイベントに当てはまります。 スクラムのイベントはすべて、検査と適応が行われるように明確に設計されています。 デイリースクラムの最大の目的は、
みなさんこんにちは、@ryuzeeです。 スクラムにおいてはフィードバックが重要です。プロセスに対するフィードバックはスプリントレトロスペクティブ、プロダクトに対するフィードバックはスプリントレビューを活用します。 今日はスプリントレビューについて、一般的な手順や注意点を紹介します。 なお、あくまで一般的な手順であることに注意してください。スクラムの基本は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。 スライドはこちらをご参照ください。 1. スプリントレビューの目的 2. スプリントレビューの参加者 3. スプリントレビューのアジェンダ(例) 4. スプリントレビューの事前準備 5. ステークホルダーへの質問(例) 6. 良いスプリントレビューの特徴 7. スプリントレビューのアンチパターン 1. スプリントレ
「プロダクトオーナーが誰かわからない」「うまくいっている気がしない」 “失敗しないアジャイル導入”のカギとなる「理解の共通化」 Agile Center of Excellenceの必要性を考える中で自身のアジャイルを再構築する #1/2 登壇者の自己紹介とアジェンダの紹介 島崎純一氏:よろしくお願いいたします。本日は、Agile Center of Excellenceの必要性を考えるといったところから、自身のアジャイルを再構築するというお話をいたします。 お話の前に、本セッションの注意点を共有させていただきたいなと思います。 本セッションは、Agile Center of Excellenceをキーワードにお話ししますが、A-CoEの成功例ではなくて、そのお話に至るまで、自分のアジャイルを企画の観点から見直したというセッションです。 本日のスピーカーの紹介といったところで、私、島崎純一
MP3ファイルをダウンロード 内容紹介 twadaさんをゲストに、テスト駆動開発(TDD)、TDDに関するよくある誤解などを語っていただいたエピソードです。 出演者 話したネタ 【翻訳】テスト駆動開発の定義 自動テストとテスト駆動開発、その全体像 保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 テスト駆動開発とは何だったのか? テスト駆動開発と同じレイヤの手法はある? テスト駆動開発と品質保証との関連は? TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング テスト駆動開発に関するよくある誤解 アジャイル開発との類似点(みんな丸い) IPAの試験での誤解 今回のブログを書いた(翻訳した)ことによる懸念 サバンナ便り ~ソフトウェア開発の荒野を生き抜く~ 記事一覧 書籍レビュワー募集フォーム
GovTech東京 エキスパートの杉井正克氏と東京都デジタルサービス局の下家昌美氏が、東京都庁でアジャイルを実践するための「都庁アジャイルプレイブック」を紹介しました。前回はこちら。 体験してもらえないとアジャイルの良さはわからない 杉井正克氏(以下、杉井):最後にご紹介させていただくのは体験からの反応です。2022年にプロジェクトを4つやったのですが、プレイブックには参加されたみなさんのインタビューが載っています。(スライドを示して)こういうかたちで気づきや学び、「こういうのが楽しかったです」みたいなところとか、満足度を掲載しています。 これを抽出すると、「やってみたらわかりました」とか「実際に開発を進めてみて」とか「実際の会議の中で意見交換をして」みたいなことがけっこうコメントとして上がってきたのがおもしろくて、気づきだったなと思っています。 良さを体験してもらえてよかったなというとこ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く