「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
サイボウズさんのイベント #CybozuMeetup で「リモートスクラム」について話を聞いてきた - えいのうにっき
昨日・7/26、【東京開催】Cybozu Meetup 西日本でのリモート開発事情 - connpass というイベントがあり、そこに参加してきた。 cybozu.connpass.com 僕は出身が岡山県で、「いつとは言わずともいつかは地元に帰りたいなぁ」という気持ちはずっと持っているので、そういう意味では「西日本」というワードに惹かれたのもウソではないのだけど、今回参加してみようと思った理由はもうひとつあって、それが「リモートスクラム」というキーワードがconnpassページ内に見られたこと。僕は前職でスクラムマスターをやっていた経験があり、現職でも（スクラムチームには入っていないものの、）スクラムのプラクティスが活用されている・しかもリモート拠点でやっている、ということもあり、「スクラム開発」はいまだに僕の興味トピックのうちのひとつであり続けている。 connpassページにもあると
スクラムの概要を1分で理解できるイラスト【2018版】
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 アジャイル開発のコーチングやトレーニングでスクラムの全体像を1枚の絵を使って説明することが多いのですが、以前作成したものを最新化したので公開します。 スクラムの本質的な価値やスクラム以外でも日々のプロセスに組み込んだほうが良いこと（テスト自動化や継続的インテグレーション）は含めていません。 あくまでスクラムの概要のみを書いています。 PDF版はこちらにおいておきます。 ※改変なしで引用元併記の上であれば自由に使っていただいて結構です。著作権自体は私に留保します。 内容の誤りや足りない事などがありましたらTwitterなどでお知らせください。 自分のスライドに入れて使うためのパワーポイ
スクラムチームの「心理的安全性」を高める7つの方法 - log4ketancho
先日、社内でアジャイル関連のイベントがありました。私は参加できなかったのですが、大変な盛り上がりをみせていたようです。私の所属する有志団体のSlackでも同様に盛り上がっていたのですが、その中で「心理的安全性って何だ？」という話題になっていました。スクラム開発をしたことがないメンバーにとっては聞き慣れない言葉だったようだったので、心理的安全性がいかに大事かを紹介しました。（後述しますが、スクラムだろうがなんだろうが、心理的安全性はどんな組織においても非常に重要だと思います。） その後、過去のスクラム案件で、心理的安全性を高める上で良かったことを整理するのは有意義かもなー、と思い記事にまとめることにしました。どれも私が主体的に施策として考えたもものではなく、自然発生的に始まったもの、お客さんのそもそも風土などが中心ですが、どんな組織でもすぐに取り組めるものばかりだと思います。 「心理的安全性
「開発をアジャイルで」「でも契約は一括で」と言ってくる顧客がいたらどうすべきか？ - ミッションたぶんPossible
はじめに このブログでは言及してませんでしたが、宣言どおり無事転職して、今年の1月から新宿のSIerで働いています。まぁその辺の話は来月あたりの暇な時にでも書くとして*1、今回は別の話。 ついこの間、その新会社で、PM的役割をこなす社員を対象に開かれた「法務研修」という名のついた社内セミナーに参加しました。内容は、SIerの立場で契約に携わる時にどうすべきか、というもの。SIerあるあるの契約にまつわる揉め事を事例に、それを回避するために何に気をつけるべきか、といったことが扱われました。まぁこれ自体は目新しい内容ではなく、SIerに所属する者なら当然知っておく・気をつけるべきことばかり。再確認という意味では非常に有意義でしたが、それ以上でもそれ以下でも無かったなぁ、というのがオレの率直な意見でした。……研修本編終了までは。 ちょっとこれ大丈夫か、と思ったのは、Q&Aに入ってから。社員の誰か
スクラムの新しさ - プログラマの思索
スクラムが従来のアジャイル開発に比べて優れている点は、役割のバランスが絶妙なことにあると思う。 また、日本の受託ソフトウェア開発の最大の弱点は、プロダクトオーナー不在が常駐化している事だと思う。 色々考えたことをラフなメモ書き。 【参考】 日本のSIerは"フィックスドプライス"型契約から脱却できるか - ジャスミンソフト日記 ソフトを他人に作らせる日本、自分で作る米国：日経ビジネスオンライン Twitter / akipii: PMBOKではプロジェクトマネジャが発注者にいることが前提になっている。日本ではIT企業すなわち受注者にPMがいることがほとんどだから、米国の手法を修整して取り入れないとうまくいかない。ソフトを他人に作らせる日本、自分で作る米国 http://business.nikkeibp.co.jp/article/tech/20121010/237890/?P=3&rt=
スクラムの先へ進む
アジャイル初心者の多くは、スクラムでアジャイルをはじめる。スクラムには明確な指針、ルール、プラクティスがあり、チームにアジャイルを導入するのに役に立つ。ところがスクラムもまた組織の中でさまざまな問題に直面し、多くの会社にとって成功を難しくする一因になっている。スクラムをやってきた人たちは自問する。どうすればよいのだろう？ スクラムだけで十分なのだろうか？ Jimmy Bogard氏は、なぜスクラムをやめたのか、なぜ彼のチームはスクラムで成功した後、そのコアプラクティスをいくつかやめることでパフォーマンスを改善できたのかについて、次のように説明する。 イテレーションはpullベースのアプローチほど効率的ではない。 タイムボックスで仕事をすること、割り当てて空きを埋めることには、何かしら心理的影響があります。明確なタイムボックスのイテレーションをやめて、できる限り早く納品することにのみ注力する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム＆リーンスタートアップ導入)について #devlove #devlove創