バグにストーリーポイントを割り当てるべきだろうか？Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
Firepoker.app - Agile Planning Poker® built with Firebase and AngularJS
Planning poker®, also called Scrum poker, is a consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed.
Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む（Spotifyモデル）
(注)ヘンリックの許可を得てざっくり意訳しました。原文は『Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds』です。訳に対するヘルプも歓迎します。Thanks Henrik, this article is great for me. プロダクト開発をしている組織において、多角的なチーム構成を実現するのはいつもチャレンジな作業だ！ 今まで見てきた中で印象に残っている例がひとつある。それはSpotifyだ。Spotifyは3つの都市にまたがって30以上のチームにスケールしているが、アジャイルなマインドセットをキープし続けている。 Spotifyは音楽産業を一変させている魅惑的な企業だ。創業してから6年しか経っていないのに、1500万ものアクティブユーザーを抱え、400万以上の決済が行われている。また、そのプロダクトは「
振り返りで積み上げた開発プラクティス（2020年総まとめ） - BASEプロダクトチームブログ
こんにちは。BASE BANK 株式会社 Dev Division にて Manager をしている東口（@hgsgtk）です。 昨年 2020 年は本ブログにて個人の足し算ではなく掛け算で成果が出せるようなチームを目指したアジャイル開発の取り組みを継続して紹介してきました。 チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 少人数でのアジャイル開発への取り組み実例 （一歩目の踏みだし方） | 詳説 | July Tech Festa 2020 登壇レポート アジャイル開発におけるユーザーストーリー分割実践 〜画面リニューアルの裏側〜 これらの考え方やプラクティスは全体の一部で、開発チームとしての組織ローカルなプラクティスを『BANK DEV 白書』として整理しています。『BANK DEV 白書』では次のような内容を整理しています。 一般的なアジャイ
チームの期待をマネジメントする - Adwaysエンジニアブログ
こんばんは、りょーまです。 私事ですが30になりました。 心はいつまでも少年です。 さて、今回は期待のマネジメントについて書きます。 マネージャーには必須のスキルではないでしょうか。 具体的にやり方も書いていくので気になる方は是非試してみてください。 期待マネジメントとは 目的や目標を達成するために、何をするべきか、どのように振る舞うべきか。 チームやプロジェクトの期待をすり合わせる行いを期待マネジメントと言います。 冒頭で期待マネジメントは必須と書きました。 その理由としては、チームの成立に大きく影響するからです。 チームは、「共通の目的を持ち、互いに協力し支え合う」事が出来て、初めてチームです。 期待のマネジメントを怠ると、チームは躓き、ただの集団化します。 チームが躓く最大の要因は期待と行動(結果)のギャップ A「先日のリリース、バグ起こしちゃったね」 B「Cさんがテストしてくれてい
ギルドワークスの代表を退任します。 - The Dragon Scroll
ギルドワークスの代表を2020年6月でもって退任いたします。 2014年4月からつとめてきたギルドワークス社の代表を退任することにいたしました。丸6年のつとめとなります。 「自分の会社を退任するってどういうこと？」と思われる方もおられると思います。ギルドワークスは創業メンバーおよびその設立を後押しして下さった事業会社の出資によって成り立っています。ここまで会社の代表としてその任を果たして参りましたが、ギルドワークス自体は私の個人会社ということではありません。後任についても定めております。その周知については、ギルドワークスの会社サイトで案内します。 退任を決めた理由は、自分の時間の使い方、優先度を変えるためとなります。具体的には2つあります。一つは、家族に向けた時間の優先度を上げることです。私は2006年に転職のため大阪から東京に出てきました。15年近い歳月が流れたことになります。この間、家
Mackerel開発チームカイゼンの旅（振り返り・モブプロ・スキルマップなど） - Hatena Developer Blog
こんにちは。Mackerel開発チームディレクターの id:daiksy です。 Mackerelチームでは、開発プロセスにおけるプラクティスや、チームをうまく機能させるための様々な取り組みに対して、普段から定期的なカイゼンを行っています。 世の中は新年度を迎え、いろいろと新しい取り組みにチャレンジしやすい時期でもありますし、Mackerelチームで行った最近のカイゼンの様子を簡単にまとめてみようと思います。 振り返りでKPTをやめた Mackerelチームではスクラムをベースとした開発サイクルを採用しており、1スプリント2週間というペースで開発イベントが計画されています。スプリント最終日に振り返りを実施し、2週間の間に起きた出来事や課題などを議論して、次のスプリントでカイゼンをする、というルーチンです。 チームではこれまで長い間、KPTという振り返りのフレームワークを採用していました。K
こんなスクラムには気をつけろ!?
こんにちは。@ryuzeeです。 支援をしている際に、こういう兆候があったら注意して見る、というポイントがいくつかあるので共有します。 あくまで課題発見用のツールなので、マルバツ表を作ってどうこうする、という類のものでもないですし、そうすべきでもありません。 スクラムマスターの人、外部から支援する人は、自分用の確認ポイントを整理しておくと良いと思います。 なお、スクラムを実践すること自体は目的足り得ないので改めて言っておきます。 全体なんでもアジャイルでやろうとするそもそもアジャイルを採用することが目的化しているプロジェクト初期にマイルストーンやスケジュールを決めていない十分にトレーニングを受けていない認定資格をとればそれで十分だと思っている全体の要件やアーキテクチャを考えずいきなりコードを書く予定できることなのに、「アジャイルだから」と予定しないドキュメントを書かない文化や考え方を変える
プロダクトオーナーと開発者の兼任は可能なのか？
こんにちは。@ryuzeeです。スクラムに関してオンライン上でお悩み相談を頂きましたので私見を述べたいと思います。 プロダクトオーナーと開発者の兼任は可能ですか？注意すべき点はなんですか？ さて、この手の議論をする際にまず確認すべきは、スクラムガイドです。スクラムガイドには以下の記述があります。 プロダクトオーナープロダクトオーナーは、開発チームの作業とプロダクトの価値の最大化に責任を持つ。その作業は、組織・スクラムチーム・個人によって大きく異なる。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。プロダクトバックログの管理には、以下のようなものがある。 プロダクトバックログアイテムを明確に表現する。ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。開発チームが行う作業の価値を最適化する。プロダクトバックログを全員に見える化・透明化
人を集めたからといってすぐ機能するわけじゃないという話 | Ryuzee.com
日々採用や組織がうまく動くように苦労しているみなさんこんにちは。@ryuzeeです。 ひとりで色々な物事を完結できればこんな楽なことはないのですが、特にシステム開発においてそのような規模のものは多くなく、たいていの場合複数人を集めてプロジェクトを遂行することになります。特に案件ベースで体制を作るシステムインテグレーターなんかを思い浮かべて頂くとわかりやすいかもしれません。 さて、そうやって集められた「人たち」はいきなりうまく機能して、プロジェクトのゴールに邁進できるようになるのでしょうか？というと残念ながら答えはノーです。 以下の図は、心理学者のタックマンが提唱する「タックマンモデル」と呼ばれるチーム(集団)の進化形態をあらわしたものです。 これによると、チームは以下のようなステップを経て変遷していきます。 形成期とりあえず人が集められた段階でお互いのことを知らない。なぜ集められたのか、自
【資料公開】DevOpsの基本
こんにちは。@ryuzeeです。 営業でDevOpsの基本の話をしてきましたので資料を公開しておきます。中身自体は昨年11月に楽天テクノロジーカンファレンスで話した内容を日本語化したものです。 DevOpsに関してはいまだに実体がなんなのかという議論がなされていますが、僕自身の現時点での解釈は、ビジネス上の意思決定から実際に顧客に届ける全体の流れの話であると考えています。すなわちいかにリードタイムを短くするかとスループットを大きくするか、ということです。(それってリーンじゃん、と言われればその通り) デプロイの回数が測定基準である、という記述も見かけますが、デプロイの回数は、あくまでバリューストリームの末端の「個別プロセス」の話でしかないので、物理的に一日に10回デプロイボタンが押せても、意思決定から価値化までの時間は長い、ということがありえます。 Build・Measure・Learnの
見積りってなんだろう？
み‐つも・る【見積（も）る】 目分量や心づもりではかっておおよその見当をつける。目算する。「入場者数を―・る」工事や製品などの、原価・日数・経費などを前もって計算して出す。「経費を―・る」「工事を―・る」 言葉の定義が広いため、コンテキスト依存性がある国語辞典の結果を見ると分かるように、「見積もる」というのは、おおよその見当をつける・計算するという動詞であることが分かりますが、一方で、この単語の中に既に「何を」の部分が複数含まれているのが話をややこしくしています。 つまり、誰が誰にどんな状況で「見積り」を依頼したかによって「何を」の部分がかわります。たとえば以下のような例が考えられます(乱暴に書いていますので必ずしもどこの環境でもあてはまるとはか限りません)。 お客さんがSIベンダーの営業に対して「見積りをくれ」といった場合は、実際にお客さんが支払う費用を指すことが多いでしょうSIベンダー
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。
アジャイルが否定したものを見直そう - arclamp
2014/9/6に開催されたXP祭り2014で「アジャイルを手放して得られたこと」という講演をしてきました。Togetterはこちらから。 元々は「アジャイルのダークサイド」の話がしたくて応募したのですが、その後、いろいろと考えているうちに僕自身にも気づきの多い内容となりました。 さて反応を見てると前半のアーキテクチャとマネジメントの話に興味を持っていただいたようです。なので、このブログでは「なぜアーキテクチャとマネジメントの話からアジャイルの話をしたのか」ということを書いてみます。 アジャイルがさまたげたもの アジャイル開発手法が大きく注目されるのは1999年の「Extreme Programming Explained」の出版であり、2001年の「アジャイルソフトウェア開発宣言」です。1990年代後半から2000年代初頭というのは、IT産業が大きく成長する時代であり、同時に、当時主流で
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
開発者の仕事が遅いわけではない！納期が遅れるホントの原因 | POSTD
“なぜ納期を守れなかったのだろうか？” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は本当に開発者の仕事が遅いせいでしょうか？ Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと（S、M、L、XL）、また種類ごと（ストーリー、テスト、バグ）に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目：開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目：変動があるのは、ほとんどがチケットが開始される前（SomedayからBacklogまで）の段階です。これは、関係者が仕様を理解して作業の優先順位
ユースケースの目的とユースケースの名称 - mkoszk’s blog
はじめに この記事を書くために参考にした書籍やWebの記事はたくさんありますが、よく参考にしたのが「ユースケース実践ガイド〜効果的なユースケースの書き方」です。2011年1月22日現在、中古品でないと入手が難しいようです。ユースケースを学ぶ人は必ず入手した方がよいでしょう。 ユースケースを記述する目的 ユースケースを何のために書くのか、「そんなの聞くまでもない。当たり前だ」と思うかもしれませんが、様々な文書を読むとさまざまなニュアンスの違いがあります。たとえば、 ユースケースは、システムが実行すべき内容を理解するために記述します。 ユースケースは、システムの機能要求を導き出すために記述します。 ユースケースは、ソフトウェアの仕様を導き出すために記述します。 というような内容が書かれています。 どれも同じに見えますが、目的が変われば記述レベルが変わります。システムが実行する内容を理解できるレ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう？（あるいはいったい何がないのだろう？）
アジャイルなオフショア開発(Rakuten techtalk)
【資料公開】強いチームの作り方(デブサミ2016版)
