「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
アジャイル迷子のための「アジャイルの本質」。あとDDDとのつながり - little hands' lab
記事の構成 アジャイルソフトウェア開発とは アジャイルマニフェストとは アジャイルマニフェストの問題 そこで、アジャイルの本質 by マーティンファウラー アジャイルソフトウェア開発とは？ アジャイルソフトウェア開発とはなんでしょうか？ 「アジャイルマニフェスト(後述)の4つの価値観、12の原則に従う開発方法の総称」 これが最もオリジナルな定義です。 なぜこんなややこしい言い回しをするのは後から説明します。 重要なことは、「アジャイル」という具体的な手法があるわけではないということです。 アジャイルはマインドセット(思想、考え方)です。そのため、 ✖️ do agile 「アジャイルをやる」はありません。 ⭕️ be agile 「アジャイルになる、アジャイルの思想に則る」はあります。 アジャイルの思想に則った開発手法として ・スクラム ・エクストリームプログラミング(XP) ・リーンスタ
Agile and Requirement : アジャイルな要件定義について考える
アジャイルマニフェストとユーザーストーリーマッピングのお話です。
ソフトウェア開発以外の現場でも活用できる「アジャイルの心」とは？「アジャイルソフトウェア開発宣言」共著者が解説
世界はあまりに速く変化を続けている Alistair Cockburn博士は、1991年からソフトウェア開発の方法論を研究している人物であり、2001年に「アジャイルソフトウェア開発宣言」の共同執筆に参加した、アジャイル開発の第一人者だ。博士は、最近になってアジャイルのアイデアをソフトウェア開発以外の分野でどう生かせるのかという議論が面白くなっており、世間の注目を集めているという。そして博士自身も2015年頃から、アジャイルのアイデアをより凝縮してシンプルにすることで、ソフトウェア開発以外の現場に応用する方法を探していたと語る。 Alistair Cockburn博士 ここで博士は、アジャイル（agile）という言葉の意味を再確認する。辞書によると「素早くかつ容易に行動し方向転換する力」（Ability to move and change direction, quickly and w
スクラム導入後にアジリティが減少してしまう理由：プロダクトオーナーの役割に対する誤解、その悪影響および対処法について
https://scrummaster.jp から シーン1: プロダクトオーナーはどのような役割をするべきでしょうか？ シーン2: 大きな組織では、プロダクトオーナーの役割はどのような誤解をされがちでしょうか？ シーン3A: プロダクトオーナーの役割を誤解すると、顧客からのフィードバックがどのように遅れることになるでしょうか？ シーン3B: プロダクトオーナーの役割を誤解すると、チームのやる気や顧客への思いやりがどのように減少することになるでしょうか？ シーン4A: 真のプロダクトオーナーは、どうやって顧客の満足度を最大限に引き上げるのでしょうか？ シーン4B: プロダクトオーナーの役割を誤解すると、どのように価値のデリバリーが妨げられるのでしょうか？ シーン5: プロダクトオーナーの役割を誤ったまま果たすことは、なぜ不可能なのでしょうか？ シーン6: チームの自己管理能力や機能横断性を
初期のプロダクトバックログの作り方
みなさんこんにちは。@ryuzeeです。 別のところで依頼を受けて作った文書なのですが、皆様の参考にもなるかと思いますので共有しておきます。 まずはプロダクトゴールを検討するプロダクトバックログは、プロダクトゴールの実現のために存在します。 つまりプロダクトバックログを作るには、プロダクトとして実現したいゴール、顧客に提供したい価値などをあらかじめ検討する必要があります。 リーンキャンバス、エレベーターピッチ、ユーザーインタビュー、エスノグラフィーなどのテクニックを活用しながら、プロダクトとして解決したい課題、実現したい価値やゴールを評価しますプロダクトを実際に開発するのはお金も時間もかかるので、本来この時点で仮説検証を繰り返し、ダメなアイデアを早めに捨てる必要がありますある程度いけそうなアイデアが出てきたら先に進みますスプリント開始の条件スクラムでスプリントを開始できるのは、プロダクトバ
アジャイル領域へのスキル変革の指針 アジャイル開発の進め方
ITSS+ ／ アジャイル領域へのスキル変革の指針 2020年2月 アジャイル領域へのスキル変革の指針 アジャイル開発の進め方 All Rights Reserved Copyright© IPA 2018-2020 ITSS+ ／ アジャイル領域へのスキル変革の指針 はじめに All Rights Reserved Copyright© IPA 2018-2020 • 本書は、アジャイル開発のプロセス、アジャイル開発 チームにおけるメンバーの役割、および必要なスキル について解説しています。 • アジャイル開発には複数のアプローチ（スクラムやXP など）があります。本書では、代表的な手法である スクラムを例にして、その特徴を解説しています。 • アジャイル開発の進め方には厳格な決まりごとや規 範はありません。本書で説明（例示）する進め方、 メンバーの役割（ロール）など、実際のソフトウェア
日本の合理性
1 日本の合理性 京都大学大学院文学研究科 教授 林晋 平成19年9月18日 於 RIETI BBLセミナー 2 ちょっと自己紹介：林の研究歴 70年代 数理論理学 （数学基礎論） 80年代-00年代 ソフトウェア科学 ソフトウェア工学 形式的技法,プログラム意味論, UML, Agile methods 00年代 数学史・論理学史 00年代 情報技術の社会学 科学技術の社会学 理学部 数学の研究所 理工学部, 工学部 文学部 3 この話のテーマ 日本のソフトウェア分野（産業、研究）はハードウェア に比べれば遥かに弱い。それは何故か？ これは良く問いかけられる問題 � 産業構造が悪い。 e.g. RIETI discussion paper 07-J-018 � 日本人はモジュール型生産に弱い。（藤本隆弘） � 日本人が英語に弱いからだ。等々 林は、この問題を「日本の合理性」を鍵にして社会
アジャイルと契約 / Agile Contracts
忙しい人向けダイジェストをこちらに用意しました。 https://www.agile-studio.jp/post/agile-contracts
アジャイルコーチはなぜ1週間スプリントを勧めるのか
みなさんこんにちは。@ryuzeeです。 職業柄スクラムを始めたばかりのチームを支援することがよくあります。 そのような状況で、ロールの明確化や初期のプロダクトバックログの準備とあわせて話題にのぼることが多いのが、スプリントの期間をどうするかです。 そして、多くの場合、1週間スプリントを提案しています。 今回はなぜ1週間スプリントが良いのか見ていきましょう。 1週間スプリントがよい理由1週間スプリントがよい理由を列挙すると以下のようなものがあります。 レトロスペクティブ（ふりかえり）が頻繁にあるので改善が進む計画の精度が高くなる例え失敗しても一週間で済むので実験しやすいベロシティの数字がすぐ出るのでやる気になる中だるみする余裕がない・リズムがよい一週間で収まるサイズのプロダクトバックログアイテムにするので明確な完成を定義しやすい。従ってプロダクトオーナーの受け入れを取りやすいスパイクが必要
大企業の方がアジャイル開発を積極採用。ただし国内全体では依然としてウォーターフォールのほうが多い。ガートナー
大企業の方がアジャイル開発を積極採用。ただし国内全体では依然としてウォーターフォールのほうが多い。ガートナー 調査会社のガートナーは、日本国内におけるアプリケーション開発手法に関する調査結果を発表しました（PDF）。 調査対象は従業員数20人以上の日本企業で、有効回答企業数は715。2018年4月から6月にかけて実施されたものです。 2000人以上の企業になるとアジャイルの採用率、採用予定が飛び抜けて増加 アジャイル開発に関して従業員数の規模別に調査した結果では、2000人以上の企業の約39％が「採用中」と答え最多。一方、1000人から1999人の規模の企業でアジャイル開発を「採用中」と答えたのが約21％。500人から999人でもほぼ同様です。 つまり2000人以上の従業員の企業ではアジャイル開発の採用率がそれ以下の規模の企業に比べて2倍近くあり、しかもグラフの緑色が示す「未採用：採用予定
日本にアジャイルが普及しづらい本当の理由〜不確実性に向き合うマネジメント論〜 - Qiita
はじめに こちらの記事は、技術評論社に寄稿させていただいた「エンジニアリング組織論への招待」をご紹介するための文章です。Qiitaにも再掲しておきます。 アジャイルって何だ？ 「ウォーターフォールよりもアジャイルのほうがいいのか？」そんな言葉をIT企業の経営者から聞くことがあります。2000年代の後半くらいから、日本国内においてもアジャイル型の開発プロセスが注目を浴びて、多くの企業が実践するようになりました。 ところが、世界各国に比べて日本のアジャイル型開発の普及率は依然として低く、理解度も進んでいません。流行っているからやってみようと始めた企業も流行りが変わると今度はリーンだとか、今度は○○だといったように新しい方式を導入してみては失敗するところも珍しくありません。 アジャイル開発の専門家ですと名乗る人の話を聞いてみても、それが何なのか、けむにまかれたような説明をされてしまい、いまいち納
「何だ、アンドンじゃないか」――ITの世界に戻ってきたアジャイル・スクラムという“日本の製造現場の強み”
「何だ、アンドンじゃないか」――ITの世界に戻ってきたアジャイル・スクラムという“日本の製造現場の強み”：「デンソー、ITはじめるってよ。 #DENSOHACK」レポート（1/2 ページ） デジタルトランスフォーメーションが進展し、製造業をはじめ多くの企業がITの力を使った価値創造に取り組み始めている。だが一方で、ITを「コスト」と捉え、ソフトウェアの戦いにうまく踏み出せずにいる企業が多いのも現実だ。では今、日本企業とエンジニアに必要なスタンスとは何か？――2018年2月、都内で実施されたデンソー主催のトークショー「デンソー、ITはじめるってよ。 #DENSOHACK」に探る。 デンソーは2018年2月9日、MicrosoftやGoogleでソフトウェアエンジニアとして活躍した及川卓也氏と技術顧問契約を締結すると発表した。同社は、自動車業界が100年に一度のパラダイムシフトを迎えているとし
なぜWIPの制限が重要なのか
みなさんこんにちは。@ryuzeeです。 WIPの制限についてExplaining why Limiting WIP is so importantにて良い説明があったのでご紹介します。 ※図は上記サイトより引用 1. WIP(仕掛り中)の同時許容個数を減らす個人的には1開発者が同時に着手するタスク数は1〜2個であるべきと思っています。 したがって、WIPが「2 * チーム人数」より多いのは実質的に制限がなされていないことになってしまい効果が出ないかもしれません。 現実的に何個にするのかは仕事の内容やチームの人数に依存するので、運用しながら順次見直していけば良いでしょう。 ただし安易に数値を増やすことは慎むべきです。 2. タスクの切り替えが減る一節によればタスクの切り替えは20%程度のムダが発生するとも言われています。 ちなみにタスクの切り替えはトヨタ生産方式における7つのムダのうち運搬
スクラム崩壊からの復活、神Excel手順書ベースの運用からAnsibleでの自動化へ――泥臭い現場の取り組みに学ぶ、明日から使える開発ノウハウ
スクラム崩壊からの復活、神Excel手順書ベースの運用からAnsibleでの自動化へ――泥臭い現場の取り組みに学ぶ、明日から使える開発ノウハウ：明日の開発カンファレンス 2018（1/2 ページ） より良いサービス、より良いモノを作るため、現場で泥臭く試行錯誤を重ね、前進し続けている現場のエンジニアの「声」を、「明日の開発カンファレンス 2018」で行われたセッションの中から拾ってみた。 より良いサービス、より良いモノを作るため、開発現場は日々試行錯誤している。書籍で学ぶ方法論も大いに役に立つが、何より参考になるのは、自分たちと同じように現場で泥臭く試行錯誤を重ね、前進し続けている現場のエンジニアの「声」だ。そのような生の声を、2018年4月17日に開催された「明日の開発カンファレンス 2018」で行われたセッションの中から拾ってみた。 黄ばむTrello、崩壊するスクラム……次々変わる異
BacklogチームがScrumを始めてみた話 | 株式会社ヌーラボ(Nulab inc.)
私達Backlog開発チームでは2016年1月から現在まで約3ヶ月、アジャイル開発手法のScrumに取り組んでいて、それなりに成果がでているように思います。理想的に上手く行っているという程ではありませんが、その試行錯誤の様子について書くことにしました。Scrumに興味がある方の参考になれば幸いです。 ※なお、私達の製品であるタスク管理ツール「Backlog」とScrum用語の「バックログ」が紛らわしいので、製品のほうはアルファベット、Scrum用語のほうはカタカナで表記しています。 もくじ 発端 目的 準備段階 第1回計画ミーティング 見積もり スプリントでの作業範囲決定 最初期（1回〜3回） すぐに発生した問題 最初の頃の感想 試行錯誤期（4回〜現在） 専門家に意見を聞いた 1週間スプリント ポイント見積もり・ベロシティ ケーキ 詳細見積もりによる精度向上 助けたこと／助けられたこと 実
日本のDevOps変革を促進するバリューストリームマッピング | gihyo.jp
アジャイルとDevOpsを組織全体に適用するための指南書『変革の軌跡』が2017年1月25日（水）に発売されます。本書の発売を記念して、マイクロソフトの牛尾剛さんにバリューストリームマッピングについて寄稿いただきました。 バリューストリームマッピングの重要性 みなさんの会社で、DevOps変革を推進するために、最初の第一歩として何をすべきだろうか。筆者は間違いなく「バリューストリームマッピング」をお勧めする。バリューストリームマッピングは、リーン生産方式の技法の1つであり、製品やサービスを顧客に届けるために必要なプロセスを分析するのに使用される。トヨタで使われていた手法をもとにしている。 バリューストリームマッピングの話を始める前に、Gene Kimがまとめた「DevOpsのThree Ways」についてお話ししておきたい。これは、DevOpsの3つの目的を明確にしたものだ。1つ目はアイデ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラムチームは改善する問題を正しく選んでいますか？
Keep Your Story Map in sync with JIRA, Trello and Pivotal Tracker
アジャイルソフトウェア開発宣言の読みとき方