本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ
前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳
「アジャイルソフトウェア開発という概念」の源流は日本なのか 〜『日本企業はなぜ「強み」を捨てるのか 』を読んで〜 - bonotakeの日記
夜中におもむろに書評を書き出す第2段。 日本企業はなぜ「強み」を捨てるのか～増補改訂版『日本“式”経営の逆襲』～ (光文社新書) 作者:岩尾 俊兵光文社Amazon この本自体はとても面白いし首肯できる部分も多いが、1箇所だけイチャモンをつけたい。 そもそもアジャイルソフトウェア開発という概念自体、マニフェスト（注：アジャイルソフトウェア開発宣言のこと）の発表よりも3年早く、1998年に日本の研究者から提案されている。 南山大学の青山幹雄教授による一連の研究である。 （同書より引用） ここで紹介されている「1998年」の「提案」とは、おそらくICSE1998で青山先生が発表した論文 "Agile Software Process and Its Experience" のことだろうと思う。Agile Software Process（ASP）という、実際に富士通の社内で実践されたソフトウェ
リーダーのための「スクラムガイド」手引き | サーバントワークス株式会社
Warning: Undefined array key "footer-widget-center-2" in /home/nagasawa/servantworks.co.jp/public_html/wp-content/themes/emanon-premium/inc/template-cache.php on line 190 Warning: Undefined array key "footer_widget_copyright" in /home/nagasawa/servantworks.co.jp/public_html/wp-content/themes/emanon-premium/inc/template-cache.php on line 213
「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
ChatGPTと作ったユーザーストーリーマッピングが結構使えるかも | DevelopersIO
ChatGPTを用い、過去のデータを参考にユーザーストーリーマッピングを作成、人間が作成したマップと比較しました。ただし、データの精度やユーザー視点の重要性に注意が必要です。 こんにちは。デザイナーのスギヤマです。CX事業本部に所属し、普段はモバイルアプリケーションやLINEアプリケーションの開発に従事しております。 今回はテストとして、ChatGPTを利用しユーザーストーリーマッピングを作成することを試みました。 通常、このようなユーザー体験に関する制作物はプロジェクトメンバー全員が顔を合わせて作業を行う必要があります。しかし、現実には製作時間が極端に限られていたり、メンバー全員が揃わない中で準備をする必要があるケースも存在し、様々な方法を模索することも重要だと考えました。 そこで、過去にデザイナーチームが行った勉強会のデータを活用し、ChatGPTを利用してテストをしてみることにしまし
だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか？ → 進行中です／〜をやっています なにか問題はありますか？ → とくにないです 〜までに終わりそうですか？ → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ
Done の定義
スクラムの検査と適用のサイクルを効果的にするためには、透明性が求められます。 Done の意味を正式に定義することで、タスクがDoneかUndoneか曖昧になったり、Undoneのままになったりする可能性を減らし、進捗状況（Doneか、Undoneか）を明確に測定できるようになるため、透明性が向上します。 完璧なDoneの定義は、組織がプロダクトを顧客に提供するために必要な全てのことを包含します。 単一チームの場合、完璧なDoneの定義を達成することは比較的容易なはずです。 チームが完璧なDoneの定義を達成できない場合は、その部分集合を Doneの定義とします。チームのゴールは、Doneの定義を洗練し、いつの日にか完璧なDoneの定義にし、毎スプリント出荷可能な状態を作ることです。 Doneの定義は、ソフトウェアが各PBIで達成する、合意済みの基準のリストです。 このレベルの完全性を達成
一年半同じチームで色んなふりかえりをやったので手法と学び紹介していく
Scrum Fest Mikawa 2021の登壇資料です。 以下は資料内で引用している参考リンクです DPA https://qiita.com/viva_tweet_x/items/97e819c626979b78947a KPT http://objectclub.jp/download/files/pf/KPT_TIPS.pdf TimeLine https://developers.freee.co.jp/entry/timeline-is-a-good-retrospective-method 象、死んだ魚、嘔吐 https://no-kill-switch.ghost.io/elephants-dead-fish-vomit/ Start Stop Continue https://www.retrium.com/retrospective-techniques/start-
事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering
2021年度リクルート エンジニアコース新人研修の講義資料です
ConfEngine
The ConfEngine team have been excellent to work with and are very responsive to our needs in terms of functionality, usability and also in providing an integration API for our website. ConfEngine has provided a robust and flexible event management platform for YOW! Conferences and Workshops for the last 5 years. Recently they have provided the ability to integrate with Eventbrite which we use for
界隈がざわつくほど超進化したPMBOK第7版の解説【プロジェクトマネジメント】｜Miz Kushida
・・・ ・不確実性パフォーマンス・ドメインについて加筆しました ・テーラリングについて加筆しました ・適応課題について補足を追加しました。 はじめにPMBOKといえば、PMIが世界中のプロマネの実務家から意見を集めてプロジェクトマネジメントについて知識体系化している分厚い本、というイメージです。 いや、でした。。。以前の第6版までは（7版からはすごく薄い）。 2021年8月に第7版が発表されると（ただし、日本語版はもっと先）公式からアナウンスがありましたが、本家サイトに行ってみると英語版は既に購入できる状態でしたので早速電子版を購入し読みましたので解説したいと思います。 一応前置きしておきますと、僕はPMPホルダーではありません。外資系にいるときにPMBOKをベースとしたプロジェクトマネジメントを実施したり、国内企業ではCMMI レベル5（最高レベル）を運用したりバージョンアップ対応を経験
「ゾンビスクラムサバイバルガイド」読んだ飼育係の日記 - 勘と経験と読経
「Zombie Scrum Survival Guide (The Professional Scrum Series) (English Edition)」という本を発見したので読んだ感想。良い本でした。 Zombie Scrum Survival Guide (The Professional Scrum Series) (English Edition) 作者:Schartau, Johannes,Verwijs, Christiaan,Overeem, BarryAddison-Wesley ProfessionalAmazon 2022/9 追記：翻訳本が発売されるようです 表紙が興味深い ゾンビスクラムサバイバルガイド！ さて、本書は著者たちの言う「ゾンビスクラム」への対策ガイドである。アメリカ人は本当にゾンビが好きだなぁ・・・ 本書は架空の組織ゾンビスクラムレジスタンスが発行
ITに係る全般統制とDevOpsの緊張関係 - プログラマの思索
アジャイル開発に慣れている人から見ればDevOpsなんて当たり前に見えるが、DevOpsを阻む障壁として「ITに係る全般統制」がある。 ITに係る全般統制とDevOpsは真っ向から対立する概念と捉えた方がいいのではないか、と最近考えている。 以下メモ。 【参考】 開発と運用の新しい関係、「DevOps」とは何か？ － Publickey 全般統制,業務処理統制[ITの統制] 海外会計税務用語 :総合型税理士法人山田＆パートナーズ｜東京,関西,名古屋,福岡の総合税理士事務所 【DevOpsが変える開発と運用[＃1]】 DevOpsは開発と運用の分離と対立するのか？：情報インフラ24時 眠らないシステム：ITmedia オルタナティブ・ブログ 【DevOpsが変える開発と運用[＃3]】運用が権威的になると開発のやる気が損なわれる：クックパッドのチャレンジ：情報インフラ24時 眠らないシステム：
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Exit criteria - Wikipedia
株式会社Odd-e Japan（オッドイー・ジャパン）
The Ultimate Guide to Agile | Wrike
Wie man Scrum und das V-Modell kombiniert » AgileSkills
Amazon.co.jp: カンバン仕事術: Marcus Hammarberg (著), Joakim Sundén (著), 原田騎郎 (翻訳), 安井力 (翻訳), 吉羽龍太郎 (翻訳), 角征典 (翻訳), 髙木正弘 (翻訳): 本
https://www.pmi.org/pmbok-guide-standards/about/current-projects
Amazon.co.jp: LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear): Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (翻訳), 武舎るみ (翻訳): 本![Amazon.co.jp: LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear): Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (翻訳), 武舎るみ (翻訳): 本](https://cdn-ak-scissors.b.st-hatena.com/image/square/775abe93fb860bcdbb0f0dc2528e34d748b61675/height=288;version=1;width=512/https%3A%2F%2Fm.media-amazon.com%2Fimages%2FI%2F51t4VE8uuQL._SL500_.jpg)
