Regional Scrum Gathering Tokyo 2019
Regional Scrum Gathering Tokyo 2019
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Scrum AllianceのScrumMaster研修を受けてきました。（資格試験も合格して、スクラムマスターになりました。） 参考：https://www.scrumalliance.org/get-certified/practitioners/csm-certification トレーナーはMichael.Jamesさん、通訳はAgileコーチの榎本明仁さんでした。 ３日間の研修、非常に刺激的で深く学ぶことができました。本当にありがとうございました。 本記事は、以下目的で作成しています。 自分自身のスクラムの理解を深め
Nagoya.Testing in Tokyo ソフトウェアテストを強いられている人達の話 で発表したスライドです。ただ7割くらいは口頭での説明なので、参加した人の思い出し用です。
「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016 アジャイル開発手法の1つであるスクラムをテーマにしたイベント「Regional SCRUM GATHERING Tokyo 2016」が1月19日と20日の2日間、都内で開催されました。 そこでマイクロソフトが行ったセッション「マイクロソフトが実践したScrum導入7年間の旅。そしてDevOpsへの進化」は、アジャイル開発からクラウドサービスの提供へと進んだマイクロソフトが、サービス開発の過程で学んださまざまな知見を共有するものとなりました。 そこには、アジャイル開発の延長線上にあるDevOpsを成功させる組織と技術、そしてマインドのあり方が紹介されていました。セッションの内容をダイジェストで紹介
朝会は毎朝やるミーティングです。一般的には、立ってやるとか、こんな話するとか、スタイルの説明がありますが、それでは私たちの朝会の実態を表している感じがしないんですよね。今日はスタイルだけではわからない、私たちの朝会の実態を説明したいと思います。ちなみに私たちのチームの規模感は 十数年 x 小学校1クラスより少ないくらいのイメージです。チケット数は数万くらい。 朝会の流れ 私たちの朝会では、現在のイテレーションに配置されたチケットを全部さらいます。メンバーが順に話すのではなく、チケットをひとつずつ見ていきます。（その結果、ほとんどのメンバーにパスが回ります。） メンバーの負荷の方に興味があるチームの場合はなにかしら変化の起きる可能性の高い「メンバーが手をつけているチケット」について聞いて回る方が効率もいいかもしれませんね。 私たちは、各メンバーが昨日やったこと／今日やること、ではなく、チーム
2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その
ここ最近、自分が見ているプロジェクトの1つで、うまくスケジュール通りに作業が進んでいなかったので、その対策をした。 その中でも特に効果があった2つを紹介する。 背景 簡単にプロジェクトの背景を説明する。 スクラムっぽい開発をしている スプリントの期間は2週間 スクラムマスターはいるが専任ではない すでにリリース済みで運用中のWebサービスである 基本的によくあるスクラムっぽい感じで、2週間というタイムボックスの中にチームが作業可能なストーリーを突っ込んで、ひたすら消化する。 スプリントの最後には、レビューをして、次のスプリントの計画を立てる。 スクラムマスターは、一応自分が担当しているが、専任ではないし、他のプロジェクトも見ているので、注意深くチームを見れていない。 課題 以下のような課題があった。 バグの修正や問い合わせ対応など、計画時に含まれていなかったタスクがスプリント中に増えてしま
以前XP祭りでLTしたものの10分版。 「せっかく作った物が喜んでもらえない」 「仕様だ、バグだ、の不毛な争い」 「振り回されて疲弊するエンジニア」 など、受託開発でうまくいかない局面は多くあるが、ある一つのことを意識的に行うようにしたら、自分たちの受託開発が180°変わった、という話。Read less
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
