私がもはやベロシティについてほとんど話さない理由
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い
Technologic Arts | トップ
テクノロジックアートは、「最先端の技術でユーザーニーズに応える」を合言葉に、独自のUML/モデル駆動開発メソドロジーを武器に、皆さまのシステム開発を成功に導きます。 UML/モデリング モデリングスペシャリスト集団が長年蓄積したノウハウをもとに、モデリングを「活用」するためのトータルなソリューションをご提供し、保守性と再利用性の高いシステムを実現します。
James Shore: The Art of Agile Development, Second Edition
James Shore has totally upgraded The Art of Agile Development with new tools, techniques, and lessons from the past decade. This gem of a book will help you evolve your way of working to a truly Agile and effective way. Bill Wake, XP123, LLC Most companies developing software employ something they call “Agile.” But there’s widespread misunderstanding of what Agile is and how to use it. If you want
KPTのKがいまいち膨らまないチームに贈るパワフルな質問 - yigarashiのブログ
ふりかえりでKPTのようなポジティブ/ネガティブな話題を出すような手法を使っていると、悪いところの掘り下げはサクサクできる一方で、良いところをうまく膨らませるのが意外と難しいように思います。書いた本人に話してもらって、ファシリテーターが「いいですね」とコメントして終わりとか、「コメントないですか」と聞いて誰も話さなくて終わりとか、そういった場面を見たことがある人は多いんじゃないかと思います。悪いところを解決するのは慣れていても、良いところを伸ばすための道具箱が空っぽという状態ですね。 そんなチームの最初の道具として次の質問を贈ります。 それがうまくいった要因は何かありますか？ これです。なんとかのひとつ覚えで良いので、ちょっとでも話が広がらないなと感じたら、まずはこれを聞いてみると良いです。この質問が優れているのは、出来事や本人の経験から単刀直入にプラクティスを抽出できることです。何か聞き
モビングの感想をベストプラクティスと共に語る - Gunosy Tech Blog
広告技術部の石田です。 「ペアプロやモブプロをやっているけど、うまくできているかわからない」 そんな悩みを抱えている人はいないでしょうか？ 私はモビング(モブプロ)をやってみて、チームが団結して何か大きなことを成し遂げたいという気持ちがあればモビングは必ず報いてくれると思うようになりました。 また、ともに成果を上げてきたチームのメンバーもモビングをやって良かったと言ってくれました。 それだけでなく、世の中にはすでに『モブプログラミング・ベストプラクティス』という本が出版され、先人の知識が出回っていることも後になってわかりました。 モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める 作者:マーク・パール日経BPAmazon この記事では本書を読んだ私の感想と、実際にモビングしてチームから出た感想を交えて紹介したいと思います。 モビングの可能性に不安や疑問を持つ
アジャイルと契約 / Agile Contracts
忙しい人向けダイジェストをこちらに用意しました。 https://www.agile-studio.jp/post/agile-contracts
徹底解説 リモートワークで行うモビングとフラクタル - Gunosy Tech Blog
広告技術部の石田です。 RSGT2021での学びをきっかけに、私たちのチームでは一日の業務をモビングとフラクタルという方法で行うようになりました。 しかし、ひとくちにそう言われても具体的なイメージが湧かない人も多いのではないでしょうか。 この記事では、モビングとフラクタルの二つをわかりやすく解説します。 特にフラクタルはなじみの薄い用語なので、まずフラクタルについて図を使って説明した後にモビングの解説をします。 フラクタルを図で解説 それではまずこちらの図をご覧ください。 フラクタルで過ごす一日の流れ フラクタルとは元々は幾何学の概念で、全体とそれを構成する部分が自己相似(再帰)となるものをいいます。 フラクタルスプリントは一日をひとつのスプリントに見立て、その中を同じような構造を持った小さなスプリントで構成します。 私たちのチームでは30分の短いスプリントを一日中繰り返すこと、そして最初
Regional Scrum Gathering Tokyo 2021に参加してモブプロとフラクタルスプリントを導入した話 - Gunosy Tech Blog
広告技術部の石田です。 今年もRegional Scrum Gathering Tokyo 2021が開催され、参加してきました。 そこで色々な学びがあったのですが、この記事では講演を聴いて自分たちのスクラムを大幅に変えたという話をしたいと思います。 なぜかというと、毎年RSGTに参加するとパッションが高まるというか、胸が熱くなって帰ってくるわけですが、今回はかつてないほどに「こういうことやりたい！」という気持ちになったからです。 ３つの「やりたいこと」 やりたいことを挙げるとそれは３つありまして、 「やりたいことをやりたい」（やりたくないことに耐えるのではなく） 「それを成果につなげたい」（ただ勝手なことをやって自己満足ではなく） 「同僚と気持ちよく働きたい」（単なる同調や馴れ合い所帯ではなく） これらをすべて同時に叶えたいと思いました。 「体験の共有」が鍵になる そして、RSGT202
勝手に注釈付き参考文献 | スクラムガイド日本語版
スクラムガイド2020からは、IT以外の分野にも適用してもらいたいみたいなので、ソフトウェアに特化したものはできるだけ排除する（とはいえ、なかなか難しいね） スクラムガイドでは「我々は1990年代初頭にスクラムを開発した」とあるので、まずは当時の状況を把握しておくとよさそう。おおざっぱに言うと、ソフトウェア業界的にウォーターフォールじゃダメだという雰囲気になっていて、何かいい方法がないものか……とみんなが模索していた時代。 そこで、過去の文献を遡り、当時でも使える概念が発掘された。それが、以下の竹内・野中論文である。Jeff Sutherlandはここから「スクラム」という名前を拝借しており、両名は「スクラムの祖父」と称される。 Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard
『2時間スプリント』とフルリモートワークなシステム開発 - terurouメモ
デンキヤギという会社で『2時間スプリント』が定着してきたので、その話でも書きます。 2時間スプリント？ みなさん、すでにスクラムで開発してますよね！ ぶっちゃけ、スクラムがよくわかってなくても、とりあえずスプリントと称して開発のメリハリをつけるために、1週間なり2週間なりで区間を区切って開発をしていくのは、普通にやってるんじゃないかと思います。 2時間スプリントとは、その期間を2時間にするという話です。 スプリントを超短期サイクルにすること自体は、47機関の人たちがオリジナルだという認識です。このあたりに本家の情報がまとまっています。 kyon-mm.hatenablog.com 2018年に実際に47機関の人たちのチームに入って1時間スプリントで働くという機会があって、それ経て、デンキヤギでもパクって導入しています。本家ではのちのち15分スプリントになっていったらしいんですが、うちはうち
Scrum Boot Camp The Book 【増補改訂版】がなぜオススメされるのか #scrumbcbook - うさぎ組
ご縁があって新刊をいただいたので、オススメする理由を簡単にですが紹介したいとおもいます。 書籍の特徴 わたしがオススメしたいところ 紹介しきれないいいところ 出版イベントがあります わたしがおもうこの書籍のよくないところについて 書籍の特徴 フォント、文字の大きさ、レイアウト、漫画部分など読みやすさにこだわっている 多様なコラム ほとんどの章がチームの悩みから話がはじまる 改訂前から一緒な部分もありますが、わかりやすいのは、多様なコラムのところでしょうか。 前作およびメイン部分の執筆陣ではない人達がコラムを寄稿をしています。そして、30代前後以下のエンジニアになっているのも今の声がはいっているという感じです。 この3つを達成している書籍はなかなかなく、独特の読み味をかんじます。 もっとこういった書籍がふえると導入しやすくなるんじゃないなかなぁとおもいますね。SREとかDevOpsとか1on
アジャイルとリーン・スタートアップを組み合わせた開発プロセス ~第１回 概要~ - selmertsxの素振り日記
2019年8月にAzitに入社して4ヶ月。 私はSREとしての役割を期待されてAzitに入社したけれども、気がつけばバックエンドエンジニア兼スクラムマスターをやっていました。 バックエンドエンジニアとしては、AWSインフラ環境の完全な作り直しとTerraformによるコード化、Railsの負債解消、監視設定のコード化などを行っていました。 スクラムマスターとしては、初期の3ヶ月はアジャイル開発(スクラム、XPを組み合わせたもの)、そして12月からの1ヶ月はリーン・スタートアップ開発の導入等を行いました。 ここでは、スクラムマスターとして考えた開発プロセスについて資料にまとめます。 なおこの文章は、0-1 の開発フェーズではなく、すでにリリースされたサービスに途中で加わったスクラムマスターの目線で書かれており、対象とする読者も私と同じような境遇にあるスクラムマスターとなっています。 この開発
Good/Bad と 事実/気持ち から始める「ふりかえり」の手引き - TechとPoemeの間
これはなに 世の中の3人~8人程度のソフトウェア / システム開発チームの多くは，俗に言う「アジャイルな開発手法」のプラクティスを実践し，1週間から1ヶ月に1度といった定期的なタイムボックスを設けてチームの開発プロセスや成果物などを対象とした「ふりかえり」をしていると思います。 そして，日本の多くの現場では，「KPT」と呼ばれる Keep (続けること) / Problem (問題になっていること) / Try (次のタイムボックスで新しく試みること) を挙げる方法による振り返りをしているのではないかと思います． 私が開発リードを務めているチームでは，KPT とは違ったフレームワークで週に1度のふりかえりを行っていて，割とうまくいっていると思っているので，それを紹介しようと思います． KPT は「チーム」のふりかえりには向かない 最近個人的に思っているのは，KPT はチームのふりかえりには
アジャイルテストのテスト設計の話 - Test Automation
Incremental test design 昨年度追加されたISTQBのFoundation Level Extension Syllabus Agile TesterのAgile Testing Practicesの項にはテスト設計に関する興味深い記述がある [1]。 Incremental test design: Test cases and charters are gradually built from user stories and other test bases, starting with simple tests and moving toward more complex ones. アジャイルテストのテスト設計の特徴として ユーザーストーリーをテストベースとして用いる事 シンプルなテストケースの追加から始まり、より複雑なものへと変化して行く事 Increme
Falcon ◇ メタバース on Twitter: "めっちゃこれいいわ。発注者にわかって欲しい事実。 https://t.co/B4VQZRA0cx"
めっちゃこれいいわ。発注者にわかって欲しい事実。 https://t.co/B4VQZRA0cx
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラムガイドの変更点（2017→2020）から見えるスクラムチームが陥りやすい3つの罠 | Agile Studio
スクラムガイド - Scrum Guide 2020 年 11 月
アジャイル開発（スクラム）で、タスクの見積もり精度を上げるため、計画と実績の乖離を測定し、データに基づいて改善も試みているのですが、なかなか改善しません。何が原因で、どう対策すべきでしょうか？
アジャイル開発向けソフトウェア開発委託契約書（準委任型） 情報処理学会
Spotifyは "Spotifyモデル "を使っていない
