コミュニケーションコストが大きいチームの問題と付随する課題を解決した話 - LIVESENSE ENGINEER BLOG
転職会議事業部でITエンジニアをしている@ishitan-livです。 早くも2024年が半年過ぎようとしていますね。 会社によっては上半期評価の時期だったりするので、何故かブログが乱立してるような気がしますがきっと気の所為ですね。 というわけで、前回はスクラムマスター研修で得た知見について書きましたが、今回は多くのチームが抱えていそうな問題を改善するためのヒントになればと思い、考えを共有します。 made.livesense.co.jp この記事にかかれていること3行まとめ 現在のチームの問題点 スクラムに関わる人数が多すぎた コミュニケーションコストが大幅に増えた 異なる性質のプロダクト領域を複数名が担当していた 全員が1つのプロダクトゴールに向かえていなかった 適切なスプリントゴールを決められていなかった PBIを詰め込みすぎた 差し込み対応が入るたびにスプリントゴールがずれていった
「なんちゃってスクラム」に気づくためのコツ
こんにちは。株式会社InnoScouter CTOの大西(Twitter: @monarisa_masa)です。 InnoScouterでは、開発手法として、スクラム開発に取り組んでいます。 今回は、「なんちゃってスクラム」に気づくためのコツ、というトピックで話していきたいと思います。 自分自身数年にわたり、他社の方から「スクラム開発やってる？」と聞かれたときに、「なんちゃってスクラムですかねぇ」と言い続けてきました。長らく「なんちゃって」状態だったのですが、最近個人的にそれを脱するタイミングを味わったので、その話をさせてください。 ※ そもそもスクラム開発をよく知らないという方にもわかるように、適宜スクラム開発自体の説明もしていきます。 この記事の対象読者 現在進行形で、スクラム開発をやっているが、なんか違いそうと感じている方 (前職などで)1度スクラム開発をやった経験はあるが、いまいち
アジャイル開発のコードレビューで、建設的なコミュニケーションを行うための心構え
チームでのアジャイル開発において、コードレビューは最も重要な工程の1つです。『アジャイルプラクティスガイドブック』（翔泳社）では、その目的が「ソースコードを書いた人の持ち物から、チームの共同所有物にする」ことだとされていますが、メンバーの考え方が違ったり責任の所在が曖昧になったりと、トラブルの種となることも少なくありません。今回は本書から、コードレビューで建設的なコミュニケーションを行うための心構えを紹介します。 本記事は『アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知』（著者：常松祐一、監修：川口恭伸／松元健）の「第2章 「実装」で活用できるプラクティス」から一部を抜粋したものです。掲載にあたって編集しています。 コードレビューの目的 【プラクティス】ソースコードの共同所有 筆者はコードレビューの一番の目的を「ソースコードを書いた人の持ち物から、チームの共同
スタートアップ創業期にリモート主体で進めてきたプロダクト開発チームの軌跡 - Beatrust techBlog
はじめに Beatrust VPoEの Ryo（長岡 諒） です。 Beatrust は2020年3月創業で現在3年目となりました。創業当初は3名だったのですが、現在社員は16名で業務委託の方も含めると30名以上の組織体となっており、初期からリモートワーク主体でした。しかし、リモートワーク主体の組織では意志を持って取り組まないとコミュニティのつながりが薄れサイロ化し、セールスとプロダクトなど各チームでのセクションの境界が強まり情報や意思決定の断絶が起こりがちです。我々も最初期は全員で議論していましたが、人数やチーム課題の変化に伴い共有・議論の仕方は進化しており、どんな変遷を経て行き着いたのかその過程から共有することで参考になるものもあるかと思いまとめました。 チーム開発においてどういった会議体・プロセスでプロダクト開発を進めようか試行錯誤している方や、リモートワークが主体となりチームサイズ
ミニマルなソフトウェア開発管理
何かやりたいことがあって、そのためにソフトウェアを開発したい。そのときに、技術的ではないことすべての事柄についてうまく段取りをつけて開発を進めて、そのソフトウェアに対する期待と、実際に開発されたものがズレないようにする。これがソフトウェアの開発管理だ。わたしも何だかんだでキャリアが10年を超えてしまい、いろいろなソフトウェアの開発管理を見てきたが、上手くいったときの体験を思い出して、最低限これだけやっとけばいいんじゃないかというポイントが見えてきたように思う。世間にはいろいろな管理手法が提案と実施されているが、どれも大袈裟だと感じていた。上手くいくために最低限必要な要素を押さえて、30分くらいで理解と実施ができるミニマルな手法をここでまとめてみたい。 前提 1人〜数人くらい 要素技術の検証は済んでいて技術的な実現性は見えている or 枯れた技術しか使わない リーダー的な人が一人くらいはいる
先が読めないからこそアジャイルが役に立つ 予定調和にハマらないためのスクラム活用術
スクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なるさまざまな人々が集まる学びの場でもあるスクラムフェス大阪2020。「今あえてのスクラム」のテーマで登壇するのは、株式会社アトラクタのFounder兼CBOでもある永瀬美穂氏。後半となる今回は、いよいよスクラムの話に突入します。スクラムについての振り返り方や、今までの価値観に囚われていてはダメで、新しい価値観の構築が必要など、これからのスクラムとの接し方について話してもらいました。 スクラムとは 永瀬美穂氏（以下、永瀬）：まずは、そもそも「スクラムって何ですか？」という話になります。本当に頼んだわけでもないのに、最初のオープニングトークというかネタがうまくハマっていまして。「マネジメントのためのフレームワークなんですか？」とかを考えている人ももちろんいるでしょう。例えば「スプリントを回すことによって改善し続ける方法、開発
大企業におけるアジャイル導入の壁 SOMPOの解法
エンタープライズ企業がDXを取り入れるために意識するキーワードはたくさんあります。中でも、組織作りにおいて多くの企業で導入が試行され、それと同時にさまざまなケースで壁に直面しているのが「アジャイル」でしょう。「俊敏」「柔軟」「一体化」といったアジャイルの示すメリットに共感し、導入を目指す企業は増えていますが、いざ導入に踏み切ったものの、従来とのプロセスの違いにより利益の享受以上に苦しみを感じるケースも多く見受けられます。 SOMPOホールディングスでは、デジタル戦略部という部署内に「Sprintチーム」という開発部隊を設置し、ユーザー企業自ら開発するという体制をとっています。当初はPoC（概念実証）開発のみを担当するチームでしたが、現在はPoCから本番化までを一括して担当する組織に成長しました。そこでは、プロジェクト推進のためにアジャイル型開発を取り入れ、関連するビジネス部門と密に連携を取
最高のScrumキメた後にスケールさせようとして混乱した話
41. 13th Annual State Of Agile Report(2019) 1位: SAFe (30%) 3位: Scrum of Scrum (16%) 7位: Large Scale Scrum (3%)
見積りしないスクラム/No Estimates Scrum JP
Regional Scrum Gathering Tokyo 2020 の資料です。
ヤフーのスクラムマスターが語る、失敗から導き出したチーム改善の知恵【Developers Boost 2019】
スクラムマスターとは、スクラムの理解と実践をチームの全員に促し、プロジェクトを円滑に進めていくメンバーのこと。スクラムを成功に導くために、必要不可欠なポジションだ。ヤフー株式会社の西山慧氏は、入社2年目からスクラムマスターとしてチーム改善に取り組んできた。本セッションでは西山氏が、スクラムにおける3つの失敗談と、その改善を通じて得たノウハウを解説した。 講演資料：入社2年目からスクラムマスターとしてチーム改善に取り組んだ話 ヤフー株式会社 テクノロジーグループシステム統括本部 サービスプラットフォーム本部 西山慧氏 失敗談1：終わらないユーザーストーリー 西山氏はまず、1つ目の事例である「終わらないユーザーストーリー」について解説する。このプロジェクトでは、1つのスプリントを2週間に設定した。そして、あるユーザーストーリーを終えるのに3スプリント（約1か月半）も要してしまったという。明らか
開発チームで実運用しているスクラムを画像いっぱいでまとめてみた - SMARTCAMP Engineer Blog
スマートキャンプの郷田です。 私はBiscuet（ビスケット）という新規SaaSのプロダクトマネージャーをしております。 Biscuetでは開発プロセスに課題を感じていたため、外部からアジャイルコーチの天野さんをアドバイザーとして召喚し、スクラムの導入を進めています。 そこで今回は、Biscuetチームで先月から導入を進めているスクラムの現状を、たくさんの画像を用いてまとめてみたいと思います！ スクラムの役割 開発チーム プロダクトオーナーチーム スクラムマスター スクラム全体像 スクラムのセレモニー PBL（Product Backlog） SBL（Sprint Backlog） 朝会（Daily Scrum） モブプロスペース KPT（Sprint Retrospective） その他 最後に スクラムの役割 開発チーム 開発チームはエンジニアの3人が中心となって開発を進めています。
新メンバーが多い大型プロジェクトでの不確実性との戦い方 - スタディサプリ Product Team Blog
ペアプロ・モブプロ、スキルマップ、1-on-1等々… チーム開発にまつわる各論・方法論・話題をよく見る昨今、関心の高まりは歓迎さるべきことながら つまるところそれらが現実のどのような問題を解決していくのか？ どのように相互作用するのか？ これらが有機的に結びつくことで現実のどのような問題を解決していくか？ こうした疑問に答えたり、具体例とともに記した記事はさほど多くないのではと思います。 本記事では昨年度に筆者のチームが約7ヶ月携わったプロジェクトにて、プロジェクト特性に起因する不確実性と我々がいかに戦ったかを記します。チーム開発を行う方にとってこの記事が実りあるケーススタディとなれば幸いです。*1 なお、本記事では以下のことは本旨とは逸れるため割愛させていただきます。 プロジェクトの機能的側面 技術的不確実性 各取り組み単体の詳細 はじめに / プロジェクトの雰囲気を伝える図 この記事で
スクラムで失敗する5大理由とその対策としてできること | POSTD
スクラム とは、最近、特にソフトウェア開発の分野でよく使われているバズワードです。この概念は、1995年のOOPSLAでJeff SutherlandとKen Schwaberにより提唱されました。自己組織的なチーム構成と短いスパンの持続可能な繰り返し作業に重点を置くもので、複雑なソフトウェア製品やプロジェクトを扱うためのすっきりとした軽量なフレームワークです。 シンプルで軽量な性質を強みとするスクラムですが、これを導入している企業の約半数が正しく実践できていないと思われます。では、一見すぐに使えそうな手法なのに、実践するのが非常に難しいのはなぜなのでしょうか。その理由と、これを確実に成功させるために講じるべき対策を見ていきましょう。 1. 組織の賛同が得られていない どういう タイプの企業であろうと、何かを変えようとすれば必ず直面する最大の課題であると言えるのが、これです。スクラムも例外
立ち上げ時のふりかえりKPTの４つのコツ
https://www.flickr.com/photos/visualpunch/7477997812「問題対私たち」のチームになっていくには？チーム立ち上げのころは相互参加−相互貢献−相互尊重−相互信頼がまだチーム内で醸成されていない状態であることが普通です。このタイミングでは、チームメンバーは些細な困りごとを安心して話すこともできず、仮に本丸の取り組むべき問題をチームで見つけても、チームメンバーが協力して前向きに取り組むことできないことがあります。チーム内の人と人とのコラボレーションの質が低い状態の場合は、ふりかえりの場が、無関心、他責、厄介事の押し付け、一方的な説得、ディベート（言論で打ち負かす）の言動を取りがちで、機能不全に陥ります。 では、どうやって、本丸の重要なテーマの問題にも「問題対私たち」で取り組める相互信頼のあるCool&Sexyなチームになっていくのでしょうか？ KP
スクラムにおける技術的スパイクの進め方
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラムでは、スプリントに投入するプロダクトバックログアイテムはReady（準備ができている）である必要があります （Readyとはどんな状態なのかについては以前に詳しく説明したので、そちらを参照してください）。 Readyにしておくことによって、成果の量が安定しプロダクトオーナーやステークホルダーにとっては予測精度が向上していきます。 Readyにする活動は単に受け入れ基準を用意したり、プロダクトバックログの内容を精緻化したり、並べ替えたりするだけではありません。 スプリント内でプロダクトバックログアイテムが完成する可能性を上げるために必要な活動すべてが含まれます。 そしてその中の
スクラムで開発チームが自由な取り組みをするには？
みなさんこんにちは。@ryuzeeです。 スプリントをずっと回していると、「いつもスプリントに追われている気がする」「一回立ち止まってゆっくり考えたい」「情報共有ができていない気がするので整理したい」「技術検証をもっとやりたい」「勉強時間をとりたい」といった話を聞くことがあります。 それに対して、どのように対処していくべきか考えてみましょう。 考えられる対応策はいくつもあるので、まずはそれを列挙します（ダメなものも混ざっています） 複数回スプリントを実施したら、1回分のスプリントでは開発チームは好きに活動する（✕）スプリントとスプリントの間に休憩を入れる（✕）フィーチャー開発以外の取り組みを行うスプリントを必要に応じて用意する（△）スプリントのキャパシティを見直して、開発チームが持続可能なペースで働けるようにする（◎）それぞれを順番に見ていきましょう。 複数回スプリントを実施したら、1回分
難易度は？ 効果は？ 実践して初めて分かった「ペアプログラミング」の実際
この20年ほどの間に、「ウォーターフォール」へのアンチテーゼとして現れた、XP（エクストリーム・プログラミング）やScrumと呼ばれる「アジャイル」な開発手法が浸透してきた。中でも、近年ではXPの一部を構成する「ペアプログラミング（ペアプロ）」に対する関心が高まりを見せているようだ。ただ、ペアプロという手法があることを知ってはいても「どのように導入を進めれば良いか」「どのような効果があるのか」については、漠然としたイメージしか持っていないという人も多いのではないだろうか。今回、Yahoo! JAPANのヤフオク!カンパニーにおいて「Lean XP」の一部としてペアプロを導入した山下真一郎氏と、日本におけるテスト駆動開発（TDD）の第一人者である和田卓人氏に、自らの実践の中で感じているペアプロのメリットや、導入のポイントについて語ってもらった。 「Lean XP」の一部としてペアプロの導入に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラムガイドの変更点（2017→2020）から見えるスクラムチームが陥りやすい3つの罠 | Agile Studio
スクラムガイド - Scrum Guide 2020 年 11 月
スクラムの取り組みと「全員同席」の真価
