不確実なスパイクを確実にDONEする試み in スクラム
スパイクしなければ開発計画が不確実なものになる、しかしそのスパイクがいつ完了するのかわからない、そのような経験はないでしょうか。スクラムでは、ソフトウェア開発の不確実性を乗り越えるためにスパイクを実施しますが、スパイクそのものの不確実性は残ったままです。スパイクとは不確実なものを早期に確実なものに変えるための手法であり、不確実性をはじめからなかったことにできる魔法のアイテムではないからです。 私は HRMOSプロダクト本部で人財活用システム「HRMOSタレントマネジメント」のプロダクト開発をしているエンジニアの Suzaking です。私たちのチームでは、未経験の技術要素を使用し、1スプリントで完結せず完成までに数ヶ月を要する機能を開発した際に、スパイクの不確実性という課題に直面しました。 この記事では、私たちのチームがスパイクそのものの不確実性にどのように向き合い、どうやって乗り越えたの
Badプラクティスを選んで失敗しながら進めた新規プロダクト開発/Develop a new product with bad practices
Badプラクティスを選んで失敗しながら進めた新規プロダクト開発/Develop a new product with bad practices
スクラムとデッドライン壊れゆくチームをつなぎとめるもの/Scrum and Deadlines
循環する学び～現場とコミュニティの境目で考える～/Learning Cycle between a team and a community
ふりかえりは"KPTを書く"ものではない｜もっくま(Mistletoe)
ふりかえりはKPTを書くものではない… いやいや、もちろん書くものなんですが…笑 KPTは「Keepに続けたいこと/Problemに解決したい課題/Tryにカイゼンのためにやってみることを書く」というフレームなので、これらを書く、でいいのです。 しかし、あくまでこれは筋の良さそうな、皆が納得できるカイゼンアイデアをみんなで考え、合意するためのフレーム・進め方です。 このフレームがあることで、 (Keep)今回これやってみてすごく良かったから、これからも続けたい！ ↓ (Try)もっとよりよくするために、次こんなことにチャレンジしてみない？ や、 (Problem)このスプリントではこの辺りが惜しかったな、〜が原因でも今ひとつになってしまった ↓ (Try)だから、次はこういう工夫をすれば、同じ過ちは犯さないよね といった、因果関係や論旨を抑えたアイデアを出すことができ、そのアイデアの筋の良
スクラムにおいて開発者を社外から集めるとどんな問題がありますか？
開発者を社外から集めるというのは大きく分けると2つです。 開発をまるごと別の会社にやってもらう（別の会社に発注する）さまざまな会社から派遣やSESで来てもらったりフリーランスの方にチームに入ってもらったりするどちらの形態なのかによって多少の違いはありますが、以下のような問題が起こりやすいです。 開発のノウハウや暗黙知が永続しない（暗黙知をすべて形式知化することはできないので、どこかで失われてしまう）外部から参画しているメンバーは必ずしもプロダクトの成功に対するインセンティブがない。そのためプロダクトのアイデアや改善のアイデアがあまり出ないこともある（もちろんメンバーによる。ただし全員がコミットすることを期待するのは無理）発注者がプロダクトオーナーをすると、プロダクトオーナーが考えたことを開発者に伝え、開発者は言われたとおりのものを作るだけという構図になりがち新規に開発を始めるたびにチームビ
「私考える人、あなた作業する人」の関係をつくっているのはあなたかもしれない
Regional Scrum Gathering Tokyo2023 の中の moyiyuya さんの「私考える人、あなた作業する人」というセッションが大きな反響を呼んでいました。 スクラムを導入してチームとして一体感をもってプロダクト開発をよりうまくやっていきたかったはずなのに、いつの間にか「私考える人、あなた作業する人」という関係性ができてしまっていた、という相談を受けることがあります。 なぜこのような「私考える人、あなた作業する人」という関係性が生まれてしまうかについて、コミュニケーションの観点で考えてみます。 プロダクトオーナーと開発者の堺目 「私考える人、あなた作業する人」のような関係性が生まれてしまっているチームでは、開発者からプロダクトオーナーに対するコミュニケーションが以下のようになっていることが多いです。 プロダクトバックログを出してくれたらつくります 仕様を決めてくれた
私がもはやベロシティについてほとんど話さない理由
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い
Re: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている - terurouメモ
この記事を読んだ。 note.com よーある話だなと思いつつ、「業務委託はダメで、社員ならOK」という話はちょっと話が雑だなあと思ったので、コメントを書く。 スクラムチームで人の出入りが激しいとキツイ これはそう。 ただ、スクラムかによらず、出入りが激しいとキツイけど… 業務委託では、高パフォーマンス人材は単価つり上げがきつく、結果契約打ち切りになる 実際の事象としてはよくある話。ただし、業務委託のみの話ではなくて、社員でも「会社に不満があったからやめた」は良くある話。 たぶん、ここが気になるのは、このあたりの違いだとは思う。 報酬の見直し頻度 社員だと給与体系の見直しが年1回であるのが普通 業務委託だと契約期間ごと（業界慣習的に3カ月単位が多い認識） 条件交渉者が本人なのか営業なのかの違い 営業の仕事は売上を上げることなので、当然ガンガン言ってくる 対して社員が自分の雇用条件について、
SI案件でアジャイル開発を進めるときの勘所
2. 吉羽龍太郎 / Yoshiba Ryutaro アジャイル開発、DevOps、クラウドコンピューティング、インフラ構築自 動化、、組織改革を中心にオンサイトでのコンサルティングとトレーニン グを提供。Scrum Alliance認定チームコーチ(CTC) / 認定スクラムプロ フェショナル(CSP) / 認定スクラムマスター(CSM) / 認定スクラムプロ ダクトオーナー(CSPO)。青山学院大学非常勤講師 2 3. 株式会社アトラクタについて ✤ 社名：株式会社アトラクタ 英文表記：Attractor Inc. / https://www.attractor.co.jp ✤ 設立：2016年12月 ✤ 所在：東京都港区 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメインモデ
スプリント1を始める前にどんな準備をするか
みなさんこんにちは。@ryuzeeです。 スクラムでスプリント1を開始する前にどんな準備をしておくと良いかについては、Regional Scrum Gathering Tokyo 2018で話をしたのですが、改めて文章化してみました。 なお、かなり長いので関係なさそうなところは適宜読み飛ばしてください。 1. はじめに1.1 この記事の目的スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。 つまりプロダクトバックとスクラムチームが存在するところがスタート地点になっています。言い換えるとそれらがないとスプリントが開始できません。 本稿では、実際にスクラムでスプリントを開始する前にどんな準備を行うと良いのかを考察してい
Backlog Item Not Done at Sprint’s End? What to Do Next
As well-intentioned as teams are, it’s really hard to finish absolutely everything by the end of a sprint. A team may have grabbed eight product backlog items (typically user stories), but then only finish six or seven of them. The other items are often close to done, but this isn’t horseshoes so close doesn’t count. Teams earn no partial credit toward their velocity for stories that remain unfini
なぜスクラムチームの開発者が複数チームを兼任しないほうがよいのか
みなさんこんにちは。@ryuzeeです。 よく受ける相談の1つに、「スクラムチームの開発者は複数のチームやプロダクト、プロジェクトを兼任してもよいのか」というのがあります。コーチ業をしている人ならみんな受けたことがあるものだと思いますが、詳しく見ていきます。 まず最初に結論ですが、タイトルにもあるとおり、「スクラムチームの開発者は複数チームを兼任しないほうがよい」です（スクラムガイドには書いていないですが、スクラムガイドは全てを詳細に記したハウツーではありません。あくまでゲームのルールです）。 理由を順番に見ていきましょう。 1. 開発に使える時間がかなり少ないスクラムチームの開発者はスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブといったイベントと、プロダクトバックログリファインメントのような活動に一定の時間を使います。 チームによって時間は変わ
簡単！楽しい！5分でわかるユーザーストーリーマッピング(User Story Mapping) - Qiita
なぜ必要なのか？ アジャイルにしたら全体像が見えなくなる。 なんて、よく聞くことはありませんか？ スクラムの場合、製品の全体像を決めるものは、プロダクトバックログです。 プロダクトバックログを単調な優先順位とストーリーポイントのリストにしてしまうと、確かに全体像が見えにくい場合があります。 例えば、以下の様なユーザストーリーのリストを見ると、確かに少しわかりづらいです。 電子メール管理システムの場合 1.ユーザは電子メールを検索できる。 2.ユーザは電子メールをファイリングできる。 3.ユーザは電子メールをキーワードで検索できる。 4.ユーザは電子メールを移動できる。 5.ユーザはサブフォルダを作ることが出来る。なぜならそこに電子メールを移動させたいからだ。 6.ユーザはひとつのフィールドで電子メールを検索できる。 7.ユーザはひとつ以上のフィールドで電子メールを検索できる。 8.ユーザは
野中郁次郎教授に聞く「スクラム」の本質、なぜ日本より中国で普及したのか
スクラムで大事なのは「間合い」 野中 郁次郎氏（以下、野中氏）：人間の日常こそ、実はクリエイティブだという話を前回（第3回）でしました。本当にその日常の中でクリエイティブになるという場合には、徹底的に仕事で我を忘れる。根本的には真剣勝負をやりますよね。 そこでは間合い（武道の概念で、互いの距離を相互に最適に保つこと）が大事です。お互いに間合いを取りながら、忖度抜きで。そこでは過去、現在、未来が連続して身体化されていないと駄目なんですよ。この「間合い」について、アジャイルソフトウエア開発プロセスのスクラム（注1）でもよく考えられています。スクラムでは、チームは毎日会うんですよね。 それで顔を合わせて目的を共有し、現状を全員で確認する。この白板（ホワイトボード）を囲んで、立ったまま、みんなが集まるんですよ。 それぞれが「昨日の問題は何か」と振り返りをやる。反省しなければ過去はそのまま忘却されま
体験学習サイクル・経験学習モデル | Poso’ｓログ
チームビルディングやプロジェクトアドベンチャーなど体験学習と呼ばれる教育手法では、ディビット・コルブの体験学習サイクルの考え方がとても重視されています。 簡単に言えば、体験と対話のセットで学びになるという考え方です。 体験学習サイクルの考え方を知る 体験型のチームビルディング研修、リーダーシップ研修、組織づくりでは、体験からの学びを体験学習サイクル（経験学習モデル）に当てはめて説明がされます。体験学習（経験学習）のルーツは20世紀アメリカの哲学者・教育思想家のジョン・デューイに遡るとされ、デューイの学習理論を実務家に分かりやすくモデル化したのがディビット・コルブの体験学習サイクルです。 そもそも学習とは何か？ 旧来型の座学研修での学習とは、講師から受講生に対する知識の移転のプロセスです。具体的には「先生が授業で話をしたり黒板に板書したりして生徒に知識を伝え、生徒がノートに書き写し暗記して覚
プロダクトバックログアイテムの分割方法
みなさんこんにちは。@ryuzeeです。 プロダクトバックログアイテムは、複数スプリントにまたがって1つのものに着手することはありません。 必ず、1スプリントで完成できる大きさになっている必要があります。 これは、複数にまたがってしまうと変化に柔軟に対応できなくなること、成果の量の把握が難しくなること、大きいものを扱うのはそもそも難しいことなどが理由です。 そのため、プロダクトバックログアイテムがプロダクトバックログのなかで上位になっていくにつれて、リファインメントなどを活用しながら、適切なサイズに分割していきます。 最初の段階から細かく分割してしまうと、変化に対応しにくくなったり、数が多くなりすぎて管理しきれなくなったりするので避け、着手が近づいてきたらジャスト・イン・タイムで分割していくのがポイントです。 こうすることで、チームの成長にあわせてプロダクトバックログアイテムのサイズを変え
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
From the Trenches: Small Batches for the Win
Agile Project Initiation: 2013 Open Research
Product Owners Suck
アジャイル開発向けソフトウェア開発委託契約書（準委任型） 情報処理学会