チームのメンバー変更が良い機会だったので、スクラム改善を進めた話 - クラウドワークス エンジニアブログ
crowdworks.jpでEMをしている久村です。 2023年5月より1つのチームのスクラムマスターをすることになりました。 私は開発者としてスクラムの経験はありましたが、スクラムマスターの経験はなかったです。 この記事では、直近チームで改善したことの内容と、そこからの学びを記事にしようと思います。 チーム説明 私がスクラムマスターとして関わっているチームは以下です。 エンジニアメンバーの異動・退職があり人数が減少し、プロダクトオーナー（PO）もメインとサブ（入社年次が浅い）で2名いましたが、サブの方が独り立ちしてメインで担当されるように変更になりました。 そのタイミングでスクラムマスターとして私がメンバーに加わりました。 メンバー変更した当初の状況としては、1週間のスプリント期間で以下のスクラムイベントは実施しておりました。 デイリースクラム リファインメント レトロスペクティブ プラ
スクラムチームで実践しているソロプロとモブプロを両立したスウォーミングの紹介 - Cybozu Inside Out | サイボウズエンジニアのブログ
みなさんこんにちは。kintone フロントエンドリアーキテクチャプロジェクト（フロリア）で、エンジニア兼スクラムマスターとして活動している村田（@kuroppe1819）です。 現在、フロリアには兼務も含めて約 30 人のメンバーが参加しています。フロリアは小さな 4 つのクロスファンクショナルチーム体制で、それぞれが独立したスクラムチームとして活動しています。 今回はその中のひとつのチームである、サイレントリリースを部分的に試みているチーム（Mira チーム）で取り組んだ、ソロプログラミング（以下、ソロプロ）とモブプログラミング（以下、モブプロ）を両立したスウォーミングの実践事例を紹介します。 スウォーミングとは？ まずはスウォーミングという言葉について説明します。 Swarming を直訳すると「群れる」です。ソフトウェア開発の文脈では 1 つの問題やタスクを皆で群がって解決するとい
実例に学ぶスクラム導入手順 - タスク属人化を避け、チーム開発力向上のためにRettyがやったこと - エンジニアHub｜若手Webエンジニアのキャリアを考える！
ウォーターフォールモデルから、アジャイルへの切り替えを試みる開発チームが多いなか、スクラムを導入したもののうまく浸透しなかったという声も少なくありません。公式の『スクラムガイド』のとっつきにくさが導入のハードルを上げているとの声も聞きます。 Rettyのスマホアプリ開発チームは、あえて現在の自チームに合わせたカスタマイズを一切せず、『スクラムガイド2017』に沿ってスクラムを導入。メンバーのモチベーション向上や開発メンバーの視座を高めるなど、わずか半年で効果を出しました。 参考：スクラムガイド™（日本語版PDF） いかにハードルを乗り越え、チームの生産性向上とメンバーの満足度向上につなげたのでしょうか。スクラムの導入を提案し、実際に導入したチームのマネージャー、スクラムマスター、開発者メンバーの3名に話を聞きました。 スクラム導入前夜〜タスクの属人化に課題あり 1人のプランナーが5人のエン
改善の３つの顔
ふりかえり会は懺悔の場でも責任追及の場でもありません、過去の学びを活かして幸福な未来を作る行動を生み出す場です
こんなスクラムには気をつけろ!?
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） こんにちは。@ryuzeeです。 支援をしている際に、こういう兆候があったら注意して見る、というポイントがいくつかあるので共有します。 あくまで課題発見用のツールなので、マルバツ表を作ってどうこうする、という類のものでもないですし、そうすべきでもありません。 スクラムマスターの人、外部から支援する人は、自分用の確認ポイントを整理しておくと良いと思います。 なお、スクラムを実践すること自体は目的足り得ないので改めて言っておきます。 全体なんでもアジャイルでやろうとするそもそもアジャイルを採用することが目的化しているプロジェクト初期にマイルストーンやスケジュールを決めていない十分にトレーニングを受けていない認定資格をと
プロダクトオーナーと開発者の兼任は可能なのか？
こんにちは。@ryuzeeです。スクラムに関してオンライン上でお悩み相談を頂きましたので私見を述べたいと思います。 プロダクトオーナーと開発者の兼任は可能ですか？注意すべき点はなんですか？ さて、この手の議論をする際にまず確認すべきは、スクラムガイドです。スクラムガイドには以下の記述があります。 プロダクトオーナープロダクトオーナーは、開発チームの作業とプロダクトの価値の最大化に責任を持つ。その作業は、組織・スクラムチーム・個人によって大きく異なる。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。プロダクトバックログの管理には、以下のようなものがある。 プロダクトバックログアイテムを明確に表現する。ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。開発チームが行う作業の価値を最適化する。プロダクトバックログを全員に見える化・透明化
人を集めたからといってすぐ機能するわけじゃないという話 | Ryuzee.com
ブログryuzeeによるブログ記事。不定期更新Homeブログ人を集めたからといってすぐ機能するわけじゃないという話 日々採用や組織がうまく動くように苦労しているみなさんこんにちは。@ryuzeeです。 ひとりで色々な物事を完結できればこんな楽なことはないのですが、特にシステム開発においてそのような規模のものは多くなく、たいていの場合複数人を集めてプロジェクトを遂行することになります。特に案件ベースで体制を作るシステムインテグレーターなんかを思い浮かべて頂くとわかりやすいかもしれません。 さて、そうやって集められた「人たち」はいきなりうまく機能して、プロジェクトのゴールに邁進できるようになるのでしょうか？というと残念ながら答えはノーです。 以下の図は、心理学者のタックマンが提唱する「タックマンモデル」と呼ばれるチーム(集団)の進化形態をあらわしたものです。 これによると、チームは以下のような
【資料公開】強いチームの作り方 | Ryuzee.com
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） 2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
