「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
チーム・組織が「効率化のための最適化を続けてしまう」問題 今までとは違う判断を下すのに必要な“エンジニアのちから”
ソフトウェア開発に関わる人々の新たなきっかけを生み出す場となることを目指す「Qiita Conference」。ここで「アジャイル開発は世界を変える夢を見るか 」をテーマに株式会社レッドジャーニーの市谷氏が登壇。続いて、ファイブフィンガー3（FF3）の罠を抜けるために、チームや組織に求められる動きについて話します。前回はこちらから。 DXは“変える”ことに意味がある 市谷聡啓氏：巷で聞くDXという言葉。（この単語を）「そんなに好きじゃない」という人もいるかもしれません。僕もそんな信じていないですが、この言葉に意味があると思うのは“変える”ということなんです。 「最適化への最適化」路線。いつから始まったかわかりませんが、みんなが無意識のようにやっている感じを意識的に止める。そういう機会として捉えることができる。そういう意味では、DXという言葉には利用価値があります。 というと、「なんだ、DX
朝会カイゼンのコツー5本指朝会 | オブジェクトの広場
今回紹介するプラクティスは朝会と名付けしていますが、上記に上げたどのイベントやプラクティスでも共通する内容となっています。 朝会でありがちな問題と解決の糸口としてのパターン ここから先は朝会とデイリースクラムを厳密には分けずに話を進めようと思います。多くの現場で朝会が行われているもののマンネリになり、最終的には「意味がない」と結論付ける現場も見たことがあります。私が直面した現場でも以下のような現象が見られました。 朝会というイベントが形骸化して、その目的を失っている状態になってしまっていると感じ、朝会を行う目的を再考するためにScrum Patternsで公開されているデイリースクラムパターンを確認しました。 デイリースクラムパターン デイリースクラムは Scrum Patternsとして公開されている ので、その定義を見てみましょう。以下は筆者がデイリースクラムを翻訳して要点を抜き出した
ベロシティに対する誤解 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基本からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 ストーリーポイントとは？まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』（Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29）の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。 ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような
「ストーリーポイント神話」を考える - bluebird
はじめに アトラシアン社のJira Softwareでは、ユーザーストーリーの見積もりの単位には、 時間単位の絶対見積もり ストーリーポイントでの相対見積 の両方を選択可能です。 ですが、Jira上の課題として作成したタスクの進捗のトラッキングは作業に用いた工数の時間単位で行うため、課題タイプの「サブタスク」にはストーリーポイントを設定できないという仕様があります。 この仕様の是非については論を避けますが、Jiraに限らずアジャイル開発について様々な方とやりとりをして感じるのは、「スクラムをはじめとするアジャイル開発のプロセスでは、見積もりに『ストーリーポイント』を用いて相対見積を使うものである」という認識の存在です。 もちろんストーリーポイントを用いて相対的なサイズを 用いる見積もり手法には、過剰バッファーや、理想日と実作業日の差異、不確実性への対処、コミットメントと進捗管理の分離など、
「誰もが幸せになる」プロダクト開発を、リリースプランニングの見える化で可能に【デブサミ2017】
ビジネスにおけるITソリューションの役割と影響は年々大きくなっており、そこに求められるソフトウェアも複雑で高度になってきている。開発プロジェクトの不確実性はますます高まり、変化の激しい市場のニーズに応える製品やサービスを、いかに的確に提供するかは開発者にとって最重要課題の一つだ。株式会社エウレカ 経営管理本部 情報システム部 梶原成親氏は、これまで数多くのプロジェクトを通じて、アトラシアンの開発管理ツールを活用してきた。そして、より良い開発プランニングの方法を探ってきた。Atlassian User Group Tokyoでも活躍する同氏が、「ユーザー、デベロッパー、そして誰もが幸せになる」プロダクトオーナーの役割について語る。 講演資料：正しくプロダクトを作り、リリースプランニングするためのプロダクトオーナーの役割とは 株式会社エウレカ / eureka, Inc. 経営管理本部 情報シ
アジャイルを無責任に広めるのはもうやめよう
（画像：wikimedia commons） こんな記事を見かけました。 記者の眼 – 「アジャイル嫌い」はもうやめよう：ITpro http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/082400357/?ST=system&P=1 開発の経験が長い人からすると、「あーはいはい」と昏い目をしてしまうような記事なのですが、実際のところアジャイルを宣伝する本やブログなどは多く、「プロジェクトを始めよう！」となったときに、候補に上がることが多い開発手法ではあります。 しかし、現場の現実から言うと、安易にアジャイルを導入して失敗するケースは非常に多いです。 私は20件以上のアジャイルプロジェクトを見てきましたが、そのうちちゃんと成功していたプロジェクトはたったの3件だけです（ウォーターフォールは100件以上見ていますが、成功率はそんなに低くはあり
プロダクトオーナーと開発者の兼任は可能なのか？
こんにちは。@ryuzeeです。スクラムに関してオンライン上でお悩み相談を頂きましたので私見を述べたいと思います。 プロダクトオーナーと開発者の兼任は可能ですか？注意すべき点はなんですか？ さて、この手の議論をする際にまず確認すべきは、スクラムガイドです。スクラムガイドには以下の記述があります。 プロダクトオーナープロダクトオーナーは、開発チームの作業とプロダクトの価値の最大化に責任を持つ。その作業は、組織・スクラムチーム・個人によって大きく異なる。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。プロダクトバックログの管理には、以下のようなものがある。 プロダクトバックログアイテムを明確に表現する。ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。開発チームが行う作業の価値を最適化する。プロダクトバックログを全員に見える化・透明化
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
おじさんにも分かるITトレンド説明と日本のエンプラITの限界 - arclamp
System of Record と System of Engagement
普通の開発メンバーが リーダーになってやったこと
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove