Scrum Fest Fukuoka 2024の登壇資料です。 プロポーザル:https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19575
MoSCoWは、 スクラムで一般的に使用される優先順位付け手法です。優先順位付けとは、現時点でどのタスクと目的がより重要であるかを確認する能力です。優先順位を決定する際は、価値の低い活動を犠牲にして、より重要なことに焦点を当てるようにしてください。 MoSCoWという用語自体は、次の図に示すように、4つの優先順位付けカテゴリのそれぞれの最初の文字から派生した頭字語です。 アジャイルバックログの優先順位付け手法:MoSCoW 必須—「必須」とラベル付けされた要件は、成功するために現在の配信タイムボックスに含まれている必要があります。「必須」要件が1つでも含まれていない場合、プロジェクトの実施は失敗と見なされます。 必要なもの—「SHOULD」要件もプロジェクトの成功に不可欠ですが、現在の配信タイムボックスでの配信には必要ありません。 持つ可能性—「COULD」とラベル付けされた要件はそれほど
Fearless Change のパターンリストを A4 x 2枚 のシートにしました! PDFファイルはこちらです。 Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン 作者:Mary Lynn Manns,Linda Rising出版社/メーカー: 丸善出版発売日: 2014/01/30メディア: 単行本(ソフトカバー)Fearless Change: Patterns for Introducing New Ideas (English Edition) 作者:Linda, Ph.D. Rising,Mary Lynn, Ph.D. Manns出版社/メーカー: Addison-Wesley Professional発売日: 2004/10/04メディア: Kindle版
プロジェクトマネジメント協会の元会長であるアントニオ・ニエト=ロドリゲスが「現代の経済の原動力はオペレーションからプロジェクトへと置き換わった」と指摘1するように、現代は「プロジェクトの時代」と言えます。プロジェクトは「必ず、過去に行われたことのない何かが含まれる」ものですが、現代社会はその傾向がより強まっています。そもそも何が問題かということも分からないし、仮に問題が分かったとしても、どのように解決したらよいかという手段の選択も簡単ではありません。 このような状況でも、プロジェクトを進めていくためには、どこかで進むべき方向や何をやるのか、ということを決定しなければなりません。分からないながらも、判断しなければ、一歩も動き出すことはできません。しかしながら、なんとか判断したとしても、その決定は絶対的なものではありません。良くも悪くも「仮決定」のようなものです。そのため、「仮決定」が適切なも
The Patternsハイパープロダクティブチームを体系的に生み出すため9つのパタンはこちらになります。 1. Stable Teams 2. Yesterday's Weather 3. Swarming: One Piece Continuous Flow 4. Interrupt Pattern: Illigitimus Non Interruptus 5. Daily Clean Code 6. Emergency Procedure 7. Scrumming the Scrum 8. Happiness Metric 9. Teams that Finish Early Accelerate Faster https://www.scruminc.com/wp-content/uploads/2014/05/teamsthatfinishearlyacceleratefaste
登壇内容ダイジェスト はじめに 私自身、アジャイルとオフショアというテーマに2014年ぐらいから取り組んでおり、RSGT2015では「開発モデルの作り方」というタイトルでベトナムオフショア開発でのアジャイル開発プロセスについて、RSGT2016では「フィリピンのスタートアップにスクラムを導入しようとしてみたお話」というタイトルで登壇してました。RSGTでの登壇は、去年のしくじり先生も加えて今回で4回目。たまには褒められたい…。 これは『MY JOB WENT TO INDIA』という書籍からの引用ですが、悲壮感が漂ってますね。著者はこのような状況の中で、ソフトウェア開発者が生き残るためにはどうしたら良いのかについて、書籍の中で提案してくれています。 上記引用から、私自身は以下の2つの能力が今後ソフトウェア開発者が生き残っていく上で必要な能力だと考えました。 オフショアを機能させる能力 オフ
いよいよ RSGT2022が迫ってきましたね! これはRSGT2022を待ちわびるアドベントカレンダーの記事です。 qiita.com RSGT 2022では、1月5日の14時からRoomCにて「Scrum@Scaleの理論と実装 - 組織をリファクタリングしながらスケールする」というお話をさせていただきます。 Scrum@Scaleを採用して運用しているチームに今年になって参画し、そこでの取り組みや「Scrum@Scaleってどういうものなの?」といったお話をさせてもらう予定です。 スクラムマスターとしての7ヶ月 さて、ぼくは2021年5月に今の会社にエンジニアリングマネージャーとして入社しました。現在のミッションは、Scrum@Scaleで運用されている部門全体を統括して、その開発プロセスを整えていくのが仕事です。他にも、社内にスクラムを横展開したり、採用・育成などエンジニアリングマネ
「Scrum Fest Osaka」はスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。KEYNOTEで登壇したのは、楽天グループ株式会社の椎葉氏。「誰も嫌な思いをしない変化」をタイトルに、自身が開発グループのサポートをしたときの取り組みについて話しました。全3回。2回目は、誰も嫌な思いをしない変化のために実践したことについて。前回はこちらから。 誰も嫌な思いをしない変化のために「相手に期待しない」 椎葉光行氏:その頃の自分と、今の自分でいろいろと変わったとは思うんですけど、大きくこの2つかなと思います。 「相手に期待をしなくなった」それから「相手の気持ちを考えなくなった」です。 言葉にすると、人としてどうなのという感じがしますけど(笑)、でもこの2つが自分の中でけっこう大きな軸になっています。 何年か前に、娘が「2桁のかけ算教えて」っ
https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15981 私たちは観察、理解、知識を用いて仕事をこなしています。 これらは「心の働き」といえるものです。 仕事の成果の質を左右する重要な活動で、 子供の頃から慣れ親しんだ活動です。 では、心を働かせるとはどのような活動なのでしょう。 私はほとんど答えることができませんでした。 このセッションでは何気なくしてきた観察、知識、理解を 明らかにし、その質を高め方を紹介します。 プロフィール https://note.com/mryy/n/n6f01561a6253 関連動画 シン・仮説検証 70000枚の付箋で分かった仮説検証のエッセンス https://speakerdeck.com/moriyuya/shin-hypothesis-testing 仕組みと働
Scrum@Scaleの基本と実装 - Chatworkの実践に学ぶ「スケールするスクラム」の導入戦略 スクラムのスケーリング手法であるScrum@Scale(スクラムアットスケール)の基本的な概念、そして企業内での実践例を粕谷大輔(daiksy)さんが解説します。実践例では、Scrum@Scaleにおいて「だれが」「なにをやるのか」を、1週間のタイムスケジュールとともに解説します。 2001年にアジャイルソフトウェア開発宣言 が発表されてから20年。日本のソフトウェア開発の現場でもアジャイルはずいぶん一般的に扱われるようになってきました。そのうちの手法の1つであるスクラムについても、導入事例を多く見聞きします。 スクラムは原則的に少人数のチームに適用されることを前提としている手法ですが、さまざまな現場で扱われるようになるにつれ、規模の大きなチームへと拡張されるニーズも高まってきました。現
みなさんこんにちは。@ryuzeeです。 スクラムにおいて、スクラムチーム全体のパフォーマンスをどのようにして上げていくかは難しいテーマですが、プロダクトオーナーの視点でこれを捉えた「10 things you must do to build high-performing Scrum Teams as a Product Owner」という記事が良い記事だったので、翻訳したものをご紹介します。 翻訳に際しては、著者のMaarten Dalmijnさんに快諾いただきました。 なお、著者のMaartenさんはほかにもプロダクトオーナーに関する有用な記事を書いているので、参考にするとよいかと思います。 プロダクトオーナーの開発チームへの関わり方は、開発チームのパフォーマンスにおいてとても重要です。ダメなプロダクトオーナーだと、ハイパフォーマンスチームを簡単に潰してしまう可能性があります。 私
はじめまして、Web Developerの@tricknotesです。 今回はチームの期待を合わせるためのワークショップである「ドラッカー風エクササイズ」をわたしたちのチームで実践してみました、というお話です。 背景 なんでこのワークショップをやってみようと思ったのか…という話をする前に、まずわたしたちのチームの状況をお伝えさせてください。 わたしたちのチームは、ここ半年ほどで多くのメンバーが増えました。 その結果、古くからのドメイン知識に明るい古株層とまだまだドメイン知識の吸収を必要としている新入りメンバー層の間で大きな知識の隔たりがあるという状況になっています。*1 そんな中、歴史的経緯は気にせずいまの開発に集中してほしい古株メンバーと、そういった歴史的経緯を含めて吸収していきたい新入りメンバーの思いがそれぞれある、ということが振り返りの場で明らかになりました。 どちらもチームのためを
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11890/tech-lead-in-scrum
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く