「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
開発と理想主義 vs 現実主義 - Qiita
TL;DR Qiitaで現実主義的な立場の方が書いた「現実は甘くねえんだよ！」な記事がランクイン その記事の筆者とコメントでやり取りをしていた方が理想主義的立場で記事を書き、これまたランクイン 実際はどちらも大事だよ、という話をしたかった はじめに 開発者の格差を書いたある記事がQiitaでランクインしました。 現在その記事は何らかの理由でコミュニティガイドライン違反として非公開となってしまっております。 個人的に記事内容には同意できましたし、開発にも有用なものだったので、理由は定かではないのですが…… 確実に言えることは、その方はいわゆる「現実主義的な」立場から記事を書いていました。 そしてその記事のコメントでやり取りをしていた方が新たに記事を書き、そちらもQiitaでランクインしました。 エンジニア業界を少し外から眺めて こちらはまだ公開されております。 その方は、実際に記事を読んで頂
エンジニア以外も皆でGithub/Zenhub�を使ってプロダクト開発してみた話 - Qiita
はじめに LITALICOの亀田（ @kamesennin ）です。エンジニアです。 良い組織が良いプロダクトをつくる 主体性と自律性が良い組織の大きな条件の1つ などといった信念の下、日々組織のことを考えています。 TL;DR （当たり前のように使っている組織もありますが）LITALICOでもエンジニア以外の職種も交えてGithubとZenhubを使ってプロダクト開発を始めたら、幸せになったことが結構あったし、見えた課題と今後改善したい点もちらほら出てきた。 ※ Githubとは多くの開発者にとってお馴染みの「開発者をサポートする便利なプラットフォーム」 ※ Zenhubとは「Agile Project Management and Product Roadmaps Inside GitHub」と本サイトに書かれている通り、「アジャイルなプロジェクトマネジメントとプロダクトロードマップの
開発者とプロダクトオーナーの認識ギャップを埋めるには？ レッドハットのアジャイル支援に学ぶ【デブサミ2019夏】
デジタルトランスフォーメーションを背景に、システム開発に取り組む企業が増えている。顧客から依頼されるのではなく、自社で新たな顧客体験を提供するアプリでは、顧客に受けいれられるか分からない。またアジャイルやスクラムといった新しい開発スタイルに戸惑う企業も。製品リスクやスクラムチームに関するベストプラクティスをレッドハット 河野彰範氏が解説する。 講演資料：顧客が使いたくなるアプリを作る方法 レッドハット株式会社 サービス事業統括本部 第3コンサルティング部 シニアコンサルタント 河野彰範氏 PBIは開発者とPOが一緒に作りあげていくもの レッドハットというとLinuxディストリビューターやクラウド関連ソフトウェアで有名だが、近年では「Red Hat Open Innovation Labs」としてアジャイル開発の支援も行っている。登壇する河野彰範氏はスクラムチームのアジャイルコーチとしてアジ
新メンバーが多い大型プロジェクトでの不確実性との戦い方 - スタディサプリ Product Team Blog
ペアプロ・モブプロ、スキルマップ、1-on-1等々… チーム開発にまつわる各論・方法論・話題をよく見る昨今、関心の高まりは歓迎さるべきことながら つまるところそれらが現実のどのような問題を解決していくのか？ どのように相互作用するのか？ これらが有機的に結びつくことで現実のどのような問題を解決していくか？ こうした疑問に答えたり、具体例とともに記した記事はさほど多くないのではと思います。 本記事では昨年度に筆者のチームが約7ヶ月携わったプロジェクトにて、プロジェクト特性に起因する不確実性と我々がいかに戦ったかを記します。チーム開発を行う方にとってこの記事が実りあるケーススタディとなれば幸いです。*1 なお、本記事では以下のことは本旨とは逸れるため割愛させていただきます。 プロジェクトの機能的側面 技術的不確実性 各取り組み単体の詳細 はじめに / プロジェクトの雰囲気を伝える図 この記事で
たまに「スクラムが難しい」って相談があって見に行ったりする。 - Mitsuyuki.Shiiba
「プロダクトオーナーとしてやることはしっかりやってるんです」 「もちろんバックログがあります。そして、ストーリーが優先順にならべられています」 「MVP(Minimum Viable Product)も考えていて、ここまでが必須だと考えています」 「そしてこのMVPをこの日までにリリースしたいと考えているんです」 いいですね。 でも、ストーリーポイントを見たところ難しそうですね。 「そうなんです。もうプロダクトオーナーとして自分ができることは全てやりましたから、あとは開発チームに、この日までにリリースできるようになんとか頑張ってもらうしかないと思っています。スクラムではこういうときどうしますか？」 そうですね・・・。まずは、実現できないということを受け止めましょう。 「え？」 そして、ここで頑張るのは開発チームではなくてプロダクトオーナーですね。 「もう自分のできることは全てやっていますよ
プロダクトマネジメントのルーツと誤解｜Yamotty | 10X, inc.｜note
2016年5月に書いた「プロダクトマネジメントの誤解」を言う記事を加筆・編集したものになります。今読むと稚拙だな、と思うところも多々あるのですが、プロダクトマネジメントという概念のルーツについて、頑張って調べました。加筆修正してお届けします。ITスタートアップブームの起爆点はもちろんシリコンバレーだ。シリコンバレーは軍事開発からハイテク産業という歴史を経て ”development” のエコシステムを培ってきた。その歴史は あなたが知らないシリコンバレーの歴史 | 上杉周作 によくまとまっている。ぜひ一読をおすすめする。 シリコンバレーでも汎用的に用いられてきたメソッドがある。「製品を創って成功する”プロダクトマネジメント”」だ。 エリック・リースの『リーン・スタートアップ』で描かれるMVP、そしてスティーブン・G・ブランク『アントレプレナーの教科書』に描かれる顧客開発は、日本でも有名だ
フロー効率性とリソース効率性について XP祭り2017で発表してきた #xpjug - @i2key のBlog
先日、開催された XP祭り2017 にて発表してきました。スライドは以下になります。 フロー効率性とリソース効率性について #xpjug from Itsuki Kuroda www.slideshare.net また、上記発表のベースは以前のポストである「 フロー効率性とリソース効率性について（QCDのトレードオフなんて本当は無かったんだ） - @i2key のBlog 」がベースとなっております。また、Slideshareに上げたスライドが画像が若干ガビガビになってて見にくいので補足がてら要点だけ記載します。（と思ったら、元のポストより完成度高まってしまった。ので今後、誰かに説明するときはこっちをオリジナルにしよう。。。。） フロー効率性とリソース効率性についてかんたんな説明 リソース効率性について リソース効率を高めるということは稼働率を100%にあげていくことであり、リソースに空き
上流工程はシステム開発の要！プロジェクト成功に必要なスキルとは？ - システム開発のプロが発注成功を手助けする【発注ラウンジ】
上流工程は、システム開発の要件定義から計画立案までを行うプロセスであり、その後のプログラミング開発など下流工程に大きな影響を与えます。 上流工程をおろそかにすると、開発や納品後の運用フェーズでトラブルが発生する可能性が高くなります。 今回は、上流工程の概要やリスク、上流工程でのトラブルを防ぐために必要なスキルについてご紹介します。 目次 上流工程とは？ 上流工程とは、システム開発・設計において最初に行う初期の段階のことです。 いくつかの要件に分けることができ、主に含まれるのは「要件定義」「機能定義」「構成管理」「計画立案」などの工程です。要件定義では、クライアントが求めているシステムの内容をヒアリングし、要件としてまとめます。機能定義で要件を具体的な機能として決定し、構成管理では定義した機能を提供できるシステム構成や構造を管理します。計画立案は、制作物のスケジュールの全行程を計画する工程で
「開発をアジャイルで」「でも契約は一括で」と言ってくる顧客がいたらどうすべきか？ - ミッションたぶんPossible
はじめに このブログでは言及してませんでしたが、宣言どおり無事転職して、今年の1月から新宿のSIerで働いています。まぁその辺の話は来月あたりの暇な時にでも書くとして*1、今回は別の話。 ついこの間、その新会社で、PM的役割をこなす社員を対象に開かれた「法務研修」という名のついた社内セミナーに参加しました。内容は、SIerの立場で契約に携わる時にどうすべきか、というもの。SIerあるあるの契約にまつわる揉め事を事例に、それを回避するために何に気をつけるべきか、といったことが扱われました。まぁこれ自体は目新しい内容ではなく、SIerに所属する者なら当然知っておく・気をつけるべきことばかり。再確認という意味では非常に有意義でしたが、それ以上でもそれ以下でも無かったなぁ、というのがオレの率直な意見でした。……研修本編終了までは。 ちょっとこれ大丈夫か、と思ったのは、Q&Aに入ってから。社員の誰か
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
ハードな案件のやわらかいプロジェクト管理 - クックパッド開発者ブログ
研究開発部 兼 クックパッド料理教室の伊尾木です。 暖かくなったり、寒くなったりと気温差が激しいですが、皆さんお体は大丈夫でしょうか。 ところで、最近クックパッド料理教室で、ビジネスモデル変更に伴うリニューアルプロジェクトを実施しました。 (ビジネスモデル変更に伴う全面リニューアル) 私はPMと開発リーダーを担当したのですが、そこで実施した「やわらかいプロジェクト管理」についてご紹介したいと思います。 炎上しそうな予感がいっぱい！ ビジネスモデル変更に伴うリニューアルって聞いただけで炎上の予感で胸が膨らみますね。 ビジネスモデルの変更だけでも大きな話なのに、システムの全面刷新まで同時に実施したので、プロジェクトとして不確定要素が多く、管理が難しいものになっていました。 20名弱（エンジニアが8名、他には営業チーム、ユーザサポートチームなどがありました）で8ヶ月程度のプロジェクトでした。一般
ビジネス貢献するためのエンジニアリングの話をデブサミでしてきた #devsumi - @i2key のBlog
Nintendo switchの初期不良を引き当てたので、ゼルダをやるために開けておいた予定がなにもすることなくなってしまったのでブログを書いた。私のswitchは今頃京都にあるでしょう。 Developers Summit 2017 でコンテンツ委員しつつ登壇もしてきた もともとは、デブサミオーガナイザの鍋島さんからコンテンツ委員としてお声がけ頂き、今回はコンテンツ委員という立場でデブサミに関わっていました。 そのため、コンテンツ委員が登壇とか自作自演感甚だしいので自分が登壇するつもりはまったくなかったのですが、GuildWorks -ギルドワークス-の市谷さんから越境をテーマに株式会社ヴァル研究所の新井さんと自分の3人でやりませんかとお誘いを受け、以下で登壇することに。 「新規事業が対峙する現実からエンジニアリングを俯瞰する」 新規事業が対峙する現実からエンジニアリングを俯瞰する #d
なぜメルカリは、プロダクトチームのリソースを90％以上もUS版に割くのか？ | キャリアハック（CAREER HACK）
［プロフィール］伊豫健夫（Takeo Iyo） 大学卒業後、松下電器産業株式会社（現パナソニック株式会社）、株式会社野村総合研究所を経て、2006年に株式会社リクルート入社。中長期戦略策定および次世代メディア開発等、大小問わず多数のプロジェクトを牽引し、2015年3月株式会社メルカリに参画。国内プロダクトの領域強化等を担当したのち、以降は一貫してUS版メルカリのプロダクトマネジメントを担当。US発新機能の多数投入、マーケティング部門を統合した施策展開など、USにおけるプロダクトプレゼンスの成長を支える。2016年8月執行役員就任。 USにリソースを割くことで、余計な議論は起こりにくくなる。 ※2016年10月に開催された「Japan Product Manager Conference 2016」よりレポート記事をお届けします。 現在、メルカリの日米合計ダウンロード数は6,000万（日本4
チーム開発を始める時に決めること - GeekFactory
頭の中を整理するために、新たにチーム開発を始める時に決めることをリストアップしてみました。すべて書き出すと大量になるので、プロセスや開発基盤を中心に書いています。 プロジェクト計画 ゴール マイルストン スコープ リリース計画 プロセス チーム構成 リスクと対策 プロセス スプリントスケジュール（例：月曜開始の1週間スプリント） 会議体の設定（例：スプリント計画、スプリントレビュー、レトロスペクティブ） 複数チームのワークフロー（例：プロダクトオーナー、UXデザイナー、開発チーム、QAチーム） 仮説検証サイクル（例：仮説設定、リリース、分析） 進捗管理方法（例：リリースバーンダウン） 品質管理方法 障害対応のワークフロー プロセス改善の仕組み（例：レトロスペクティブ結果のバックログ化） プロダクトデザイン（略） ソフトウェアアーキテクチャ（略） インフラアーキテクチャ（略） テスト計画（略
[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル - - ソフトウェアさかば
ソフトウェア品質シンポジウム(SQiP)2015の併設チュートリアルであきぴーさんと講演をしてきました。 一人当たり2時間の講演でしたので、これまでの講演のベストチョイス3本を再構成したものに、アダプタブルウォーターフォールの講演を組み合わせました。 アダプタブルウォーターフォールの講演では、問題の多いウォータフォール型開発を変化に対応できる方法として、補完型チケット駆動開発を中心にウォーターフォール型開発をアダプタブルにする３＋１やUltimate Agile Stories Iteration 5に寄稿した記事に書いた内容を説明しました。 質問を受けた内容を総合すると、比較的大規模なプロジェクトに完全型チケット駆動開発を導入してみたものの、チケットを更新してくれない、管理が大変、といった問題で皆さん困られている様です。 やはりチケット駆動開発の導入はプロセスを改善する作業なのですから、
![[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル - - ソフトウェアさかば](https://cdn-ak-scissors.b.st-hatena.com/image/square/cb3189f8cb55f68fc5c2b0270b2e8657e0d2eb43/height=288;version=1;width=512/http%3A%2F%2Fsakaba.cocolog-nifty.com%2F.shared-cocolog%2Fnifty_managed%2Fimages%2Fweb%2Fogp%2Fdefault.png)
完璧なプロジェクトなんてない - ソフトウェアさかば
サブリーダーをやり始めた若い人に「完璧なプロジェクトなんてない」と話したら目が点になっていたので、こちらの方が驚きました。 結果的にうまくいくことはあっても、どんなプロジェクトもそれなりに苦労する事はあるものです。こうすればうまくいく、なんていう王道はなく、その時点、その時点で、ゴールに至る道のりをイメージして、順に課題を解決していくしかないと思います。 完璧を目指す？ 完璧を目指すということは理想のプロジェクトがあり、それとのギャップを埋めていく事になるのでしょう。しかし、理想のメンバーが集まるとは限りませんし、理想のメンバーが揃っていても仕様が変わったり、ミドルウェアのバージョンアップ等で問題が生じる事もあるでしょう。 そもそも理想のプロジェクトの状態になったなら、力を抜いて開発するのでしょうか？それはおかしいでしょう。余裕があるなら速く完了すれば良いですし、そもそもそんな事はめったに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
