ウォーターフォールを世に広めたとされる米軍がアジャイルに移行中という話 - Qiita
また、この図の説明においては理想的なケースにおいても1つ前の工程に戻る事が述べられています。 " Hopefully, the iterative interaction between the various phases is confined to successive steps. " (投稿者訳) 理想的には、各段階において工程が前後する範囲は直近の工程に限られる。 理想的でない場合はどうかというと、テストから設計まで工程が戻りうると示唆しています。 "The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as dist
AWS Dev Day 2023 Tokyoの登壇資料です。
スクラムフェス三河の登壇資料です。 https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15593
KPT縛りではなく、他の代替手法、他の手法との組み合わせも含めた知見が集まっていました。 - 1 振り返りの前に - チームで共有したふりかえりの文脈をつくる - 前回のProblem/Tryを今回のKeepにつなげる 続きを読む
まだAPIが出来ていない？私は一向にかまわんッッ
初記事です。 あるフロントエンドの悩み プロジェクトの納期は決まっていて、すぐに着手しないといけない。 だけど、API はまだできていない... 早く着手したい...、ふぬぬ...。 今回はそんなフロントエンドがバックエンドのタスクの待ちにならないように、並行してアジャイルに開発していけるツールとしてmswをご紹介します。 mswとは？ mswとはmock service workerの略で、簡単にモックのAPIを立てることができるライブラリです。 同様のことができるライブラリとしてJSON Serverもありますが、mswには以下の利点があります。 単純にJSONを返すのではなく、ロジックも書くことができる Expressのようにスッキリ書くことができる RESTだけでなく、GraphQLにも対応している 以下のようなケースに向いていると思います。 早く着手しないといけないけど、API
Tangible, Embedded and Embodied Interaction - Lecture 9 - Next Generation User Interfaces (4018166FNR)
ユーザーストーリーマッピング
JaSST 23 Tohoku https://www.jasst.jp/symposium/jasst23tohoku.html
小中新規開発グループ (a.k.a. tara チーム) の qsona です。 tara チームでは、スタディサプリ中学講座というプロダクトを開発しており、約1年前 (2022-02) に本リリースして以来、継続してプロダクト開発を続けています。 tara チームのプロダクト開発は、基本的にスクラムの手法にのっとる形で行っています。ビジネス的な境界により分けられた3つのスクラムチームが存在します。 スクラムの運用については、それぞれの現場において悩みごとが起きがちだと思いますが、tara チームでもご多分に漏れず、うまくいっていること・いっていないことが存在します。今回は、その3つのうちの1つのチームである「学習コアチーム」において存在した、Sprint Planning に関する (あるいはそこから掘り出された) 課題と、それに対してどう対処したかについて書きたいと思います。 なお、本
モブプログラミングで「一緒に働く」を戦略的に仕事に取り入れよう - Agile Journey
みなさん、こんにちは。「制御不能なアジャイルモンスター」こと及部敬雄（@TAKAKING22）です。私は現在、 Silver Bullet Club というソフトウェア開発チームに所属していますが、チームでは2017年5月にモブプログラミングを採り入れ、現在も継続しています。こうした経験のなかで得られたモブプログラミングに関する知見を、書籍、記事、コミュニティ活動などを通して発信してきました。また、アジャイルコーチとしてチームや組織へのモブプログラミングの導入支援もしています。 本稿では、モブプログラミングを実際の現場で活用する際に直面しがちな悩みポイントを抑えつつ、個人やチーム、そして組織がモブプログラミングとどう向き合っていけばよいのかについて、ご紹介します。 モブプログラミングとは モブプログラミングの流れ なぜモブプログラミングが必要なのか 分担作業とモブプログラミングの比較 2つ
実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜 / ATDD by genba example
ソフトウェア開発において、不確実性にどのように立ち向かっていくかは大きな課題です。 PHPerとしては、開発中にいかにコード品質を上げるかといったことは大きな関心で、その一つの規律のとり方としてTDDを実践されてきた方は多いのではないでしょうか。 トークの表題であるATDDは、Acceptance Test Driven Developmentの略です。TDD Cycleよりももう一つ大きなスコープでのフィードバックループをテストによって駆動します。特にアジャイル開発の文脈で「Agile Testing」という一つのテーマ内で紹介されることが多い手法です。 ユニットテスト・コンポーネントテストをカバーするテストによって開発を駆動するTDDに対して、ATDDはよりビジネスフォーカスの強いテストによって開発を駆動します。ATDDの開発プロセスの実践によって、技術レイヤ横断的な製品全体の回帰テス
デュアルトラックアジャイルとの向き合い方。あるいはエンジニアとビジネスの距離感 - id:onk のはてなブログ
昨日（もう日付余裕で回ってるので一昨日だな）Findy さん主催のイベントで話してきた。 speakerdeck.com 背景 近年「エンジニアは事業貢献してこそ」「エンジニアもユーザファーストでビジネス貢献」といった言説がIT界隈で増えて来ている感じがしている。 ……とたまたま昨日関連してるようなしてないような話をしている エンジニアとビジネスの距離感の難しさ｜ばんくし｜note という記事があったので書き出しを真似してみたんだけど。 昨今、ビルドトラップに陥るな、アウトプットじゃなくアウトカムに着目しろ、って言われることが増えてますよね。でも僕は逆張りして、アウトプットにまず着目しろという声を上げておきたいのです。 開発生産性（いろいろある*1）の話をするときに、ディスカバリーとデリバリーの 2 軸で考えるのはコモディティ化してきたと思う。でも、それによって、デリバリーの重要性が薄くな
どうもエンタープライズ企業の調達を刷新したい企業、Leanerの大平です。 エンプラSaaSの雄である会社の創業メンバー兼役員の方と、オンラインランチの機会があり、示唆深かったので許可をいただきメモ公開します。 ※この記事ではエンタープライズ企業は略称としてエンプラと書きます エンプラ向けにサービス開発している方の参考になったら嬉しいです！ 拡散していただけると次回のやる気になるのでそれも嬉しいです（重要）！ "SMBのMVP"と"エンプラのMVP"一緒にすんな当然だが、SMBとエンプラでは、業務のオペレーションや目標・ミッションなどすべてにおいて、個社性がまったく違う。 比較的、SMBでは、個社性が低く。エンプラでは、個社性が高い。 だからこそ SMBは、MVPが「画一的」で許される。 一方、エンプラは、MVPに「個別性」が求められる。 SMBは、MVPが「境域な要件」で許される。 一方
こうしてふりかえりは終わってしまった / A Demise of a retrospective ふりかえりカンファレンスで一番面白かった発表資料です。 資料をざっくり要約すると ふりかえりは最初は順調に機能するがある段階で停滞し、次第に「効果が出ていないもの」と判断されて廃止されてしまう、という話です。 理由として最初は低コスト高リターンの課題を倒していけるが、それらをすべて解決すると残るのは「リターンはあるが、コストが高すぎて解決できない課題」と「コストは低いがリターンもほぼない課題」だけになります。 開発チームは前者を「コストが高すぎて解決できない」と忌避し、後者だけに打ち込んだ結果、リターンが出ずに振り返り事態を無価値を判断してしまうからです。 ふりかえりを廃止することでチームの成長は停止してしまうでしょう。 これを防ぐために「コストが高すぎて解決できない」課題を解決する方向に頑張
強くてニューゲームなプロダクト開発 / Product development in new game plus
ログラスにおけるコード品質でビジネスに貢献する仕組み・カルチャー / A system and culture that contributes to business through code quality in Loglass
プロジェクトのスコープ調整を考える - 開発チームが信頼を獲得し変化に対応するためのアプローチ - Agile Journey
日々、懸命に開発にあたっていても、スコープ調整は否応なく発生します。Agile Journeyの読者の方も、「予定していた機能開発を削らないといけない」と判断せねばならない経験をお持ちかもしれません。こうした判断をネガティブなものではなく、「変化への対応」と捉えて前向きにプロジェクトを進めるためには、なによりも信頼が必要、と語るのは、10年以上、アジャイルコーチとしてさまざまなチームに関わってきた安井 力さんです。安井さんが信頼を積み重ね、「変化に対応できる」チームになるために必要なことを解説してくれました。 プロダクト開発の中で「あれがほしい」「いつまでにほしい」「もっと早くほしい」とリクエストされることは珍しくないでしょう。また一方で、開発側から「これは難しい」「それまでにはできない」「思ったよりも時間がかかる」と伝えないといけない状況も、これまた珍しくはありません。さまざまなツールや
開発生産性 Advent Calendar 2022 16日目の記事です。 はじめに ペイトナー株式会社の脇田（@shimpeee_）です！『ペイトナー ファクタリング』開発チームでエンジニアリングマネージャー兼スクラムマスターとして、開発生産性と日々向き合っています。 「コード品質？レビュー効率？いや、PR数だ！！！」これは、他の誰でもなく、半年前の自分に声を大にして伝えたい叫びです。 「PR作成数をKPIにすると良い」とは知っていましたが、実は勘違いしていました。 コード品質やレビュー効率が改善された結果、PR作成数が増えると思っていました。ですが、実際は逆でした。 PR数を増やそうとする（つまり、 PRサイズを小さくする）ことで、レビュー効率が改善され、コード品質も高まっていくのです。 本記事は「PRサイズが大きいことが、生産性を落としている全ての元凶だったのか・・・！」と気づくまで
ふりかえりでKPTのようなポジティブ/ネガティブな話題を出すような手法を使っていると、悪いところの掘り下げはサクサクできる一方で、良いところをうまく膨らませるのが意外と難しいように思います。書いた本人に話してもらって、ファシリテーターが「いいですね」とコメントして終わりとか、「コメントないですか」と聞いて誰も話さなくて終わりとか、そういった場面を見たことがある人は多いんじゃないかと思います。悪いところを解決するのは慣れていても、良いところを伸ばすための道具箱が空っぽという状態ですね。 そんなチームの最初の道具として次の質問を贈ります。 それがうまくいった要因は何かありますか？ これです。なんとかのひとつ覚えで良いので、ちょっとでも話が広がらないなと感じたら、まずはこれを聞いてみると良いです。この質問が優れているのは、出来事や本人の経験から単刀直入にプラクティスを抽出できることです。何か聞き
これは Chatwork Advent Calendar 2日目のエントリです。 また、このエントリの公開日翌日に開催される"だいくしーのスクラムBar #1" で取り扱うテーマについての詳細な解説記事も兼ねています。 chatwork.connpass.com スクラムマスターって何をする人なの？ 本項ではこれについて少し考えてみたいと思います。また、ぼく自身が普段どういうことを考えながらスクラムイベントや、その他の仕事をしているか、なども書いてみようと思います。 スクラムマスターは、ソフトウェア開発に関する他の職種と比べても、具体的な職務内容がわかりづらい役割なのかな、と思います。少し乱暴な言い方をしてしまうと、デザイナーがいなければデザインはできないし、プログラマーがいなければアプリケーションコードを書くのはとても困難です。しかし、スクラムマスターがいなくても別に開発はできます。 そ
マンガでわかる ソフトウェア開発 データ分析 データ分析事始め データ分析FAQ (参考)アジャイルメトリクスFAQ 1 独立行政法人情報処理推進機構 超合本版38編 データ分析事始め 目次 データ分析基礎編 01 データ分析ってなんなの？ データ分析 02 信頼幅の線、気になる 信頼幅 03 箱ひげ図のひげ、かわゆくない 箱ひげ図 04 散布図はぜんぜんばらばら 散布図と箱ひげ図 05 どれが本命なの？ 中央値と平均値 分析データ観察編 01 生産性は性癖が出る？ 生産性 02 バグを愛したソース 信頼性（不具合密度） 03 改修・保守が好き過ぎる 開発プロダクトの種別 04 規模はアンバランスでアンビバレント ソフトウェア規模 05 開発期間は短くて長くて短い 開発期間（工期） 06 ウォーターフォールってつおい？ ウォーターフォール型開発 07 ここはツールでしょ 開発ツール 08
これからの時代に求められるアジャイルな組織づくりとリーダーシップ - Mitsuyuki.Shiiba
アジャイルリーダーシップ を翻訳者の一人であるヒロオカさんにいただいて読みました。ありがとうございます！今の自分にグサッとくる内容でとてもとても良かった。今後の自分の行動も変わりそうです。今日から数日後の11月22日に発売されます www.kyoritsu-pub.co.jp 読みやすかった 著者は SCRUMMASTER THE BOOK を書かれたズージーさん ズージーさんの本自体が読みやすいのと、あと、ユーザベースさんの翻訳が読みやすいのとで、とても読みやすかった。英語の言い回しって日本語にすると分かりにくかったりするけど、そういうのがなくて、自然に読むことができた アジャイルリーダーシップ？ 「アジャイルリーダーシップ」ってタイトルを見たときは、アジャイルなチームのリーダーの話なのかな？スクラムマスターはこうあるべきだよとかって話？と思ったのだけど、読み始めてみるとそうじゃなくて、
この記事について 共感している そもそもDXとは何か デジタル中心のビジネスにどうシフトするか デジタル中心のオペレーションにどうシフトするか 顧客や従業員がラクになる体験（UX） 最近やっている案件 みんなすごい この記事について 下書きの状態で公開することにした。 主観と経験で書いているので、細かい話は要事実確認。 反響があったら後でブラッシュアップするかも。 特定の名前が分かる形での非公開情報は載せていない。 共感している DXという言葉は使わなかったけど、過去に似た内容で登壇したので、一連のツイートに共感しますhttps://t.co/bh8dWDxjpWhttps://t.co/gJjrvLf6tu https://t.co/cTW35ELvIE pic.twitter.com/ImjPYWPP5R— ゆずたそ (@yuzutas0) May 26, 2020 そもそもDXとは何
"うっすら体調が悪い"を見過ごさない。健康を目指す人に知ってほしい「アジャイル式健康カイゼン」 - りっすん by イーアイデム
なんだか毎日、うっすら体調が悪いーー。ハードな仕事や不規則な生活、テレワークによる運動不足などから「体調が万全！」と感じることが減ったという人は少なくないのではないでしょうか。ただ、病院に行くほどつらいわけでもないし……と、そのまま日々を過ごしてしまったり、心身を整えるための行動を始めてみても継続しなかったり、なんてこともありそうです。 そこで注目したのが、書籍『「アジャイル式」健康カイゼンガイド』（翔泳社）で紹介されている「アジャイル式」健康カイゼンというプロセス。 ここで言う「アジャイル」とは、システムやソフトウェア開発における進め方のひとつである「アジャイルソフトウェア開発（以下、アジャイル）」に由来します。 著者の懸田剛さんは20年に渡りアジャイルを研究・実践・指導。現在はスポーツプログラマーの資格も取得し、自身で実践しながら他者への助言も行っています。共著者で保健師の資格を持つ福
スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい5個のコツ - / How to start Scrum that is not written in the Scrum Guide
Scrum Fest Fukuoka 2024にて。 https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19555/5 プロフィールやお問い合わせはこちらからどうぞ！ https://agile-monster.com/profile/ https://agile-monster.com/contact/
これまでエンジニアやスクラムマスターとしてスクラムチームに関わって来ましたが、その過程で何度も「相対見積もり」や「ストーリーポイント」に纏わる悩みにぶち当たってきました。工数や期間での見積もりに慣れていた私にとって、それらは理解も実践もしにくい手強いものでした。 今回は、私が実際に直面した問題と、それらを打破するためチームで取り組んできたことを思い返してみようと思います。 壁1. 「相対見積もり」の考え方を理解できない 壁2. ストーリーポイントが「何を見積もる手段か」を理解していない 壁3. 見積もりをコミットメントと捉えてしまう まとめ 壁1. 「相対見積もり」の考え方を理解できない バックログ上に積まれたユーザーストーリーやエピックを見積もろうとしたとき、私たちは真っ先に「こんなコンポーネントを新規実装するだろう、おそらく2日くらい掛かる」「あの既存機能をいじる必要があるが、複雑な箇
はじめに 今回プロダクトマネージャーの動きを行っていく中で、新しい気づきがあったので記事としてまとめました。 プロダクトマネジメントをプロダクトマネージャーだけで行わない プロダクトマネジメントとは、プロダクトを成功に導く考えであり、これはプロダクト作りに関わる人であれば必ず必要になってくるものです。 つまり、プロダクトマネジメントとは特定の誰かが行うアクションではなく、チームや組織全体で行っていくものだと考えています。 プロダクトマネージャーの役割 プロダクトマネージャーの主の役割とは、もちろんプロダクトマネジメントを行うことです。 しかし、プロダクトマネジメントが行えている状態を組織として目指すためには 「プロダクトマネジメントをすること」だけではなく「プロダクトマネジメントができる組織づくり」も行う必要があると考えています。 そのためには、プロダクトマネージャーとして、「プロダクトマ
チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 - BASEプロダクトチームブログ
こんにちは。BASE BANK株式会社 Dev Division にて、 Software Developer をしている東口（@hgsgtk）です。私のいる開発チームでは、アジャイル開発の考え方・取り組みを取り入れています。アジャイル開発の導入については、「小さなチームが始めたアジャイル開発」という資料を公開しています。 今回は、アジャイル開発において、重要な振り返りについて、Mad Glad Sad(喜、怒、哀) というレトロスペクティブ（振り返り）のワークを紹介したいと思います。 TL;DR Mad Glad Sad(喜、怒、哀)は、感情データを集めるためのワーク イテレーションで起きた、喜んだり、怒ったり、哀しかったりした時間やイベント、を書き出していくイベント 素直な感情ベースでイベントを振り返ることで、 "理性のフィルター"で見つからない潜在的課題をチームが見つける きっかけに
【翻訳】あなたのスクラムチームの成熟度は？
みなさんこんにちは。@ryuzeeです。 3月23日に『スクラム実践者が知るべき97のこと』が発売になりますのでよろしくお願いします。 さて、スクラムチームがどれくらいの成熟しているかは、とくにスクラムを始めてまだ長時間たっていない場合には気になるところだと思います。 そこで今回はスクラムチームの成熟度を自己評価して、改善に結びつけるための資料を共有します。 この資料はScrum.orgのトレーナーであるRon Eringa氏がブログで公開しているものです。 このモデルでは、スクラムマスター、プロダクトオーナー、開発チーム（スクラムガイド2020で開発者に改められています）のそれぞれで成熟度を明らかにします。 そして、全体でいちばん低い数字がスクラムチームとしての成熟度になるとされています。 使い方ですが、人事評価や他チームとの比較に使うのではなく、チームとしてどう成長していくべきか、どこ
2013年に「日経電子版」のソフトウェア開発を100%外注から内製化、アジャイル開発に切り替え、開発サイクルやチームの抜本的な改革を見事成功させた日本経済新聞社。その取り組みは、多くの注目を浴び、400以上のはてなブックマーク数を獲得しました。 「あの『日経電子版開発チーム』が内製化とアジャイル開発の成功から6年がたった “その後” を語る！」では、内製化とアジャイル開発の成功体験を他の部署にも応用し、全社をあげて開発改革に取り組んでいる模様を取り上げました。 本記事では、同社が次に取り組む、個人やチームの開発成果と事業成果を結びつけるための「OKR（オーケーアール）」を導入したきっかけと運用、そして、成功したこと、失敗したことについてお伺いします。 ■自己紹介（右から） 情報サービスユニット プロダクトマネージャー 斎藤祐也さん デジタル編成ユニット プロダクトマネージャー武市大志さん
Autonomous Database - Dedicated 技術詳細 / adb-d_technical_detail_jp
「負債にも50パーセントの時間を使ってください」は機能しなかった 西村賢氏（以下、西村）：最初にやったことに価値がありました。そして、次は第2段。 原トリ氏（以下、原）：この説明会やった時に、6月は一回止めますと（話しました）。完全に機能開発を止めて、サポートから流れてくるチケットに関してはオンコール体制を組んできちんと対応するけれど、機能開発はしないというのを戦略として……。 西村：これ、カミナシの歴史で初めてですね。 原：たぶん、初めてだと思います。 西村：そこは「大丈夫なのかな？」とかなかったんですか？ 原：「この1年大きい機能、出てないよね？」みたいな共通認識は、全社にあったから経営の中で意思決定が早かったんです。 西村：なるほど。なにか技術的にうまくいっていないというのがあった。 原：そうです。プロダクトがうまくいっていないという認識がまず全社にあって、かつ、これがカミナシの底力
アジャイルなチームをつくる ふりかえりのガイド / A Retrospective Guide
2021/02/19 Developers Summit 2021 （https://event.shoeisha.jp/devsumi/20210218/session/3078/） 19-C-9 『アジャイルなチームをつくる ふりかえりのガイド』の登壇資料です。 ふりかえりが少しずつ認知されてから、様々なところでふりかえりの重要性が叫ばれてきました。ただし、どう始めたらいいのか、どう定着までに至るのか、道のりはあまり述べられてきていません。 ふりかえりは、チーム全員で定期的に立ち止まり、チームがより良いやり方を見つけるために話し合いをして、チームの行動を少しずつ変えていく活動です。COVID-19とリモートワークの加速によって、これまで顔を合わせて働いていたチームも、直接会って仕事をする機会は今後も減っていくでしょう。これから新しくチームを作ることも今まで以上に難しくなっていきます。
Agile Testingを夢見たテスト自動化 〜ATDDへの挑戦から始まる 1年間の試行錯誤〜 / dreaming agile testing at basebank
「CIのためのテスト自動化」というテーマで第17回QUESに招待いただいた際の資料です。 - Agileチームにおけるテスト自動化の試行錯誤から得られたしくじり - Agile Testingの概要とその一つの取組みとしてのATDDの実践をテスト自動化目線で - システムレベルの自動E2Eテストの作成・維持に焦点を当てる
デブサミ2020の1日目、「質とスピード」というセッションが人気を集めた。2019年10月に開催されたEngineering Organization Festival 2019で評価の高かったセッションをアップデートして再演したものだ。登壇したのは、テスト駆動開発者として有名な、タワーズ・クエストの和田卓人氏。ライオンのアスキーアートといっしょに紹介されることが多いという。プロジェクトマネジメントにはQCD（Quality：品質、Cost：コスト、Delivery：納期）という概念があり、トレードオフの関係になると言われている。確かに開発の現場でも、「いまは大事な時期だから、品質を犠牲にしてスピードを優先しよう」といった判断が行われることは少なくない。しかし、和田氏は、ソフトウェア開発の文脈において、逆の効果をもたらすことを、多くの資料を引用して再構築してみせた。 タワーズ・クエスト株式
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/
![ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c7728c664ddd298cabc00615869a23f196ad5f90/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F2022-220117111455-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
10/5 の「ふりかえりの手法をたくさん学ぼう」でいいふりかえり手法をたくさん紹介いただいたので、改めてまとめます。 記事の元になったお話、資料 ここに記載しているのは、以下で紹介された手法です。 ふりかえりの手法をたくさん学ぼう(ふりかえりam #27-28公開収録) - connpass podcast ep.27【#ふりかえりam】ふりかえり手法をたくさん学ぼう（前編）～ 紹介した手法：いっぱい ep.28【#ふりかえりam】ふりかえり手法をたくさん学ぼう（後編）～ 紹介した手法：いっぱい YouTube ふりかえりの手法をたくさん学ぼう ふりかえり手法の確認には、以下が紹介されていました。 ふりかえりチートシート 各手法、簡単に実践方法と効果を書いています。 実践例の記事が見つかったものはリンクを貼っているので、詳細はそちらをご参照ください。 各手法の参考リンクは、適当にググって出
登壇者の自己紹介 南里勇気氏（以下、南里）：登壇者の自己紹介を進めたいので、登壇者の方々に上がってもらいます。本日はよろしくお願いします。 野田克樹氏（以下、野田）：お願いします。 鈴木伸緒氏（以下、鈴木）：お願いします。 坪田朋氏（以下、坪田）：お願いします。 南里：司会のフードテックキャピタルCTOの南里勇気と申します。よろしくお願いします。ふだんはエンジニア・経営者としていろいろやっていますが、今回のテーマはPM×デザインで、もの作りの観点から登壇者の方々にいろいろ聞きたいと思うので、よろしくお願いします。それではdely株式会社の坪田さん、紹介をお願いします。 坪田：今回はCXOというタイトルで「クラシル」を運営するdely株式会社でクラシルの開発責任者としてサービスの方針を決めたり、意思決定しています。 僕自身はデザインを軸としていろいろな事業を作ったり、会社を作ってそれが丸ごと
スクラムガイド2020からは、IT以外の分野にも適用してもらいたいみたいなので、ソフトウェアに特化したものはできるだけ排除する（とはいえ、なかなか難しいね） スクラムガイドでは「我々は1990年代初頭にスクラムを開発した」とあるので、まずは当時の状況を把握しておくとよさそう。おおざっぱに言うと、ソフトウェア業界的にウォーターフォールじゃダメだという雰囲気になっていて、何かいい方法がないものか……とみんなが模索していた時代。 そこで、過去の文献を遡り、当時でも使える概念が発掘された。それが、以下の竹内・野中論文である。Jeff Sutherlandはここから「スクラム」という名前を拝借しており、両名は「スクラムの祖父」と称される。 Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard
dmm.go #6 の登壇資料です。 https://dmm.connpass.com/event/295065/
スクラムやる意味ある？を乗り越えるために
大体2、３ヶ月くらいで次のステージに進んでいることがわかります。また、気持ちい良くらいタックマンモデルに沿ってチームの状態も変わっていることもわかります。 形成期 ここからは、それぞれの段階でチームの状態の詳細、僕の心境と取り組んだことについて紹介します。まずは形成期から。昨年の6月、スクラム開発を採用してチーム開発が始まりました。開発を始める前、僕を含めたチームのメンバーからの声は「スクラムってどうやるんやろう？」とか「初めてやからワクワクするわ」みたいな感じで期待と不安が半々でした。そんな時、ひょんなことからリーダーが僕に「スクラムマスターやってみーひん？」って提案を受け、「やったことないけど挑戦してみよう」と思い、スクラムマスターに挑戦することになりました。 僕の心境は「何したら良いかわからんけどとりあえずスクラムガイドに沿って進めてみたらいいんかな？」でした。ふざけんなって声も上が
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイル開発は本当に必要なのか、何を解決するのか
スクラムマスターの育て方 / Training Scrum Master
KPT (Keep/Problem/Try) 等のふりかえりで、K (Keep) ネタを増やすみんなの工夫
経験に複利を効かせろ！ふりかえり研修2024
Sprint Planning をやめた話 - スタディサプリ Product Team Blog
https://twitter.com/Akira_Akagawa/status/1581555970840604677
エンタープライズ向けサービスのMVPはこうして失敗する。｜大平 裕介/ CEO at リーナー
「こうしてスクラムが終わってしまう」前にすべきこと
「コード品質？レビュー効率？いや、PR数だ！！！」 - Paytner Tech Blog
KPTのKがいまいち膨らまないチームに贈るパワフルな質問 - yigarashiのブログ
スクラムマスターって何をする人なの？ - だいくしー(@daiksy)のはてなブログ
IPAマンガでわかるソフトウェア開発データ分析38編.pdf
DXに関する私的な殴り書き - 下町柚子黄昏記 by @yuzutas0
スクラムチームがぶち当たる「相対見積もり」の壁と、私たちの乗り越え方
プロダクトマネージャーの役割は「プロダクトマネジメントをすること」だけではないかも - Qiita
日経電子版開発チームがOKRを8ヶ月運用してうまくいった点とうまくいかなかった点 | Backlogブログ
スクラムマスターやマネージャーのための信頼構築につながる傾聴の技術
「『50%の時間を技術的負債返済に』はぜんぜん駄目だった」 カミナシ社・原トリ氏が語る、試行錯誤の過程
ソフトウェア開発の「品質vs.スピード」、本当は何を犠牲にしているのか【デブサミ2020】
「ふりかえりの手法をたくさん学ぼう」で紹介された手法まとめ - Qiita
自社開発×アジャイルだからこそ、「スケジュールを決めない」 “組織全体で分担する”プロジェクトマネジメントの考え方
勝手に注釈付き参考文献 | スクラムガイド日本語版
組織のコード品質を向上させる “レビューシステム”の取り組み