ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い
2001年の「アジャイルソフトウェア開発宣言」から20年以上が経過し、アジャイル開発の認知や実践は大きく広がりを見せています。一方で、社会や環境の変化に適応するように、その実践の形も、姿を変えながら進化を続けています。今回は、スクラムマスターを務めるヤフー 田原慎也氏とChatwork 粕谷大輔氏に、「リモートでのスクラム」「大規模スクラム」など、アジャイル開発、特にスクラムにおける、ホットなトピックについて語っていただきました。 ともに複数チームでプロジェクトを推進する2人のスクラムマスター 田原：ヤフーの田原です。スクラムマスターを務めるようになったのは1年ほど前からで、まだ初心者です。今回は、自分のこれまでの取り組みをお話しして、エキスパートである粕谷さんに、いろいろと突っ込んで、教えていただければと思っています。 粕谷：Chatworkの粕谷です。こちらこそ、よろしくお願いします。
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラムでスプリント1を開始する前にどんな準備をしておくと良いかについては、Regional Scrum Gathering Tokyo 2018で話をしたのですが、改めて文章化してみました。 なお、かなり長いので関係なさそうなところは適宜読み飛ばしてください。 1. はじめに1.1 この記事の目的スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。 つまりプロダクトバックとスクラムチームが存在すると
スクラム とは、最近、特にソフトウェア開発の分野でよく使われているバズワードです。この概念は、1995年のOOPSLAでJeff SutherlandとKen Schwaberにより提唱されました。自己組織的なチーム構成と短いスパンの持続可能な繰り返し作業に重点を置くもので、複雑なソフトウェア製品やプロジェクトを扱うためのすっきりとした軽量なフレームワークです。 シンプルで軽量な性質を強みとするスクラムですが、これを導入している企業の約半数が正しく実践できていないと思われます。では、一見すぐに使えそうな手法なのに、実践するのが非常に難しいのはなぜなのでしょうか。その理由と、これを確実に成功させるために講じるべき対策を見ていきましょう。 1. 組織の賛同が得られていない どういう タイプの企業であろうと、何かを変えようとすれば必ず直面する最大の課題であると言えるのが、これです。スクラムも例外
認定スクラム研修プログラムの開始について 〜スクラム提唱者ジェフ・サザーランド博士のトレーニングを日本で実現〜 KDDIのアジャイル開発を推進している荒本です。 1月12日〜13日に開催された「Regional SCRUM GATHERING Tokyo 2017」で、KDDIは昨年に引き続きスポンサーとして支援いたしました。 「Regional SCRUM GATHERING」は、アジャイル開発のフレームワークの一つであるスクラムに関して、講演やネットワーキングを通じて参加者同士が情報共有するイベントです。“GATHERING”というイベント名称通り、スピーカが一方的に講演するだけのイベントではなく、実行委員やスピーカ、参加者が双方向に交流し、特にスピーカの方々が自身の講演時間に関わらずイベントの期間を通して参加し、参加者と交流できる時間を作り知見を共有する様子が見られ、スクラムの浸透や
アジャイルと品質 ～Scrumに秘伝のタレをつける～ KDDIでアジャイル、DevOpsを推進している川上です。本日はKDDIでアジャイル開発を進めるに当たって、社内で議論となった品質についてお話ししたいと思います。 KDDIに期待される品質 KDDIは、ネットワークからモバイル、そしてクラウド、さらにはauでんきなど、通信だけでなく幅広い分野のサービスを提供しております。その中であってはならないことではありますが、機器のトラブルや、ソフトウェアのバグなどを起因として、お客様にご迷惑をおかけしたこともゼロではありません。KDDIのサービス企画部門、開発部門、そして運用部門は、お客様はKDDIというブランドに品質まで含めたサービスを期待されていると考えており、品質はお客様に満足いただくための重要な要素だと考えています。 KDDIの秘伝のタレ KDDIでは新しくサービスの企画検討を行う際に、サ
先日、小売業のCIO（最高情報責任者）の人と話していて、互いに激しく同意したことがある。それは「大規模プロジェクトを担当してきた技術者よりも、小規模なプロジェクトを担ってきた技術者のほうが、優秀な人が多い」というもの。もう少し踏み込んで私流に暴論すると、ITベンダーかユーザー企業かを問わず、大企業の技術者の力量は大したことがない。 もちろん、大規模プロジェクトを担う技術者や、大企業に所属する技術者にも優れた人はいる。そうでないと、プロジェクトは破綻し、ITベンダーなら倒産してしまうだろう。だが、必ずしも技術者だけの職とは言えないプロジェクトマネジャーを除けば、「この人、本当にすごいな」と思える技術者は、少人数のITベンダーに所属していたり、中堅のユーザー企業で“ひとり情シス”をやっていたりする。 いま「プロジェクトマネジャーを除く」と書いたばかりだが、実はプロジェクトマネジャーも、大企業で
失敗から学ぶアジャイル開発 皆様こんにちは、アジャイル開発推進担当の川上です。本日はKDDIのアジャイル開発の現場から、いくつかの失敗談をお伝えしたいと思います。これまでは、うまくいった点や、工夫した点を中心にお話してきましたが、あえて失敗例をお伝えすることで、皆様の気付きになればと思います。 1.プロジェクト立ち上げ時のベロシティ(開発速度)の問題 グラフは、プロジェクトのスタートから1stリリースまでのストーリーの消化曲線です。見てお分かりの通り、初期は全くストーリーを消化できませんでした。当然、PO（プロダクトオーナー）やマネージメント層から、顔を真っ青にして「このままでは終わらないじゃないか」という指摘を受け、最初から頓挫するのではという懸念の声が多数上がりました。実は始める前から、開発環境の構築、CI環境の構築、初対面のプロジェクトメンバーによる不慣れなコミュニケーションの中、最
アジャイル開発の基礎的な知識を問う「アジャイルソフトウェア開発技術者検定試験（アジャイル検定）」が2015年9月に始まった（画面1）。日立製作所や東京海上日動システムズなど9社が集う試験母体である「アジャイルソフトウェア開発技術者検定試験コンソーシアム」は早期に1万人まで合格者を増やしたい考えだ。 ユーザー側として参加した東京海上日動システムズのシステム開発本部長を務める大内美樹エグゼクティブオフィサーは「まずはしっかりとしたアジャイル開発を広めたいという気持ちがあり、そのためにはアジャイル開発の基本がわかる技術者を増やす必要があった」とアジャイル検定の意義を話す。 専門書2~3冊を読み込んだ知識レベルで合格 アジャイル検定はアジャイル開発のスキルを客観的な尺度で分析・判定する。基本的な知識を問うレベル1と、アジャイル開発の具体的な開発手法を問うレベル2の2階建ての試験となる。現時点ではレ
富士通は、企業向け業務システムの受託開発に向けたアジャイル開発手法の標準モデル「アジャイル開発実践標準」を策定した（図）。2015年4月から社内向けに公開する。アジャイル開発を望む顧客企業が増加していることに対応。ウォーターフォール型開発に慣れた社内技術者に、アジャイル開発の実践的知識を身につけさせる考えだ。 この標準モデルは、初めてアジャイル開発に取り組む技術者を対象にしたもの。プロジェクトの準備フェーズと開発フェーズで必要な作業を記述する。標準の使用に当たっては、「知識の習得だけではアジャイル開発は身につかない」（同社 SI技術本部 システム技術統括部 アジャイル実践センターの和田憲明氏）との考えから、スクラム開発を一通り体験できる実践研修などの受講を求める。 標準モデルの策定と合わせ、2015年4月から社内のプロジェクトマネージャーや契約担当者を対象に、新たにアジャイル開発におけるプ
こんにちは！クックパッド編集室メディア開発グループ長の @yoshiori です。 今回はウチのチームの開発の進め方や見積もりの仕方を説明しようと思います。 実はコレ系の話は 5 年前にもデブサミで発表 したのですがこの時はリリースまで 1 年とかのレベルのプロジェクトの進め方の話でした。今回は 1,2 ヶ月でリリースまで持っていく開発の進め方を説明します。 動画サービス部分を microservices 化するときに実際に行った事を元に説明します。開発者は 3 人で 1.5 ヶ月位の開発です。 何故このようなことを行うのか 誰だって楽しく仕事がしたいし、なるべく不安などは無い方が良いはずです。 例えば自分がやっている作業がどうなったら終わりなのかわかっていなければ不安でしょうし、いつまでに作ればいいのかわかっていなければ不安でしょう。 そういった不安をなるべく無くすためにうちのチームでは
水と油？アジャイルとオフショア開発 皆様はじめまして。アジャイル＆オフショア開発を推進している 佐々木です。エンタープライズ向けクラウドサービスのIDaaSであるKDDI Business IDの開発メンバーであり、JJUG CCCにて本システムのアーキテクチャについて講演などを行っております。また、KDDI Business IDでは昨年夏よりオフショア開発を採用しており、私自身もオフショア担当として邁進している日々を過ごしております。本日は、これからオフショア開発を検討している方に向けて、先日のAgile Japan 2015にてお話をした我々がこれまで取り組んできた事とその改善内容についてお話します。 「オフショア」 世間的な動向 開発部を率いる企業のマネージャー層の方であれば、開発コストの削減を目的として一度は耳にされたことがあるのではないでしょうか？上記の文献によると、2012
チケット計測のアーキテクチャとしては、Redmineのチケット一覧画面で必要なクエリをあらかじめ作成しておく。 次に、RedmineのREST APIを使って、クエリを呼び出してCSVへ出力し、そのCSVをパース＆解析して、各種メトリクスを出力する仕組み。 仕組みは簡単だが、すごく良いアイデアだ。 従来のソフトウェア工学では、常時監視した方が良いメトリクスは既に知られている。 アジャイル開発ならば、下記が既に知られている。 詳細は「リーン開発の現場 カンバンによる大規模プロジェクトの運営」を参考にすると良い。 ・累積フロー図：ステータス毎のチケットの枚数を時系列に並べたグラフ ・Velocity：チームの開発規模を表す ・リードタイム：平均のリリース間隔を表す。チケットの平均完了日数。 ・サイクルタイム：ステータスが変更される平均時間を表す。 累積フロー図は、チケットの増減を通じて、チーム
Incremental test design 昨年度追加されたISTQBのFoundation Level Extension Syllabus Agile TesterのAgile Testing Practicesの項にはテスト設計に関する興味深い記述がある [1]。 Incremental test design: Test cases and charters are gradually built from user stories and other test bases, starting with simple tests and moving toward more complex ones. アジャイルテストのテスト設計の特徴として ユーザーストーリーをテストベースとして用いる事 シンプルなテストケースの追加から始まり、より複雑なものへと変化して行く事 Increme
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
