Agile Metrics入門
Agile Metrics入門 1. 1 Agile Metrics入門 株式会社SHIFT 太田健一郎 2. 2 • アジャイル開発のQCD+S • アジャイル開発におけるメトリクス取得の目的 • メトリクスのやってはいけない • メトリクスの入力元 • アジャイルメトリクス • メトリクス組合せ例 • 他社案件事例 • メトリクスツール • 参考情報 アジェンダ 3. 3 アジャイル開発のQCD+S 4. 4 • Quality – 品質→価値 • Cost – ポイント毎の実時間 x 総ストーリーポイント • Delivery – Agileでは通常固定 • Scope – スプリント毎に提供するストーリーの総量 – Agileでは開発するストーリーは交渉できる要素 QCD + S 5. 5 アジャイル開発におけるメトリクス取得の 目的 6. 6 • Measure – チームとプロ
日本でアジャイルが流行らない理由 - @ledsun blog
ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
「DevOpsは地道な改善活動」 エバンジェリストが語る、DevOpsの始め方（後編） | SELECK [セレック]
〜小さなリリースサイクルの見直しから始まるDevOpsの実践により、障害の発生率が1/60に、デプロイまでのリードタイムが1/200になることも 〜 「DevOpsは技術だけでは成り立たない」 エバンジェリストが語る、本当のDevOps（前編）では、DevOpsが誕生した経緯から、その本質までを伺った。DevOpsは技術的側面、組織的側面の両面から語られる必要があり、単純にツールを導入するだけでは実践しているとは言えないと、米Microsoftの牛尾 剛さんは語る。 しかし、ツールの導入だけでは解決しないとしたら何から始めていけばいいのだろうか。海外では既に大企業の多くがDevOpsを実践し始めており、日本企業との間には大きな差が開いてしまっている。後編の今回は、大企業でもDevOpsを実施できている理由、そしてDevOpsを始めるためのコツについてお伺いした。 海外では大企業もDevOp
![「DevOpsは地道な改善活動」 エバンジェリストが語る、DevOpsの始め方（後編） | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/cd2fa98f120ab45c671e64b671ecaf7105dd80df/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2016%2F03%2F16152053%2Fc13b1b09-5219-4693-ad6f-05e217b07d50.jpg)
「DevOpsは技術だけでは成り立たない」 エバンジェリストが語る、本当のDevOps（前編） | SELECK [セレック]
〜「1日に10回デプロイできる環境があること」が「DevOpsが出来ていること」の証明〜 DevOpsとは、開発担当者と運用担当者が協力しソフトウェアライフサイクルやビジネス価値の創出を改善する活動である。 しかし、その定義自体があいまいなこともあり、「何を実現することがDevOpsなのか」という理解は人によって様々である。国内でも、数年前から流行の兆しを見せているが、本当の意味でDevOpsを理解し、実践できている企業はいくつあるのだろうか。 「日本ではツールだけを導入して DevOps を導入したことになっていることも多い」と語るのは、米Microsoftの牛尾 剛 さんだ。DevOpsのエバンジェリストとして、導入支援やイベントの開催などを行い、技術的な側面と組織的な側面の両方から正しく理解させるための活動を行っている。 前編の今回は、DevOpsが生まれた背景から、本質的に理解して
![「DevOpsは技術だけでは成り立たない」 エバンジェリストが語る、本当のDevOps（前編） | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/173c6430e45374a985fd6aafeb4da4c5f3266ca3/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2016%2F03%2F16153706%2F983e7a78-f848-4cc8-afbb-bc6e60b69575.jpg)
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
ウォーターフォール型開発プロセスの有効性 - 勘と経験と読経
牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ
かんばんボードによるプロジェクトの見える化
アジャイル開発でプロジェクトを進めている現場では、やるべき作業を表す付箋や、進行状況を示すチャートをプロジェクトルームの壁に貼って状況を見える化し、共有している光景をよく見かける。 本稿では、昨今のアジャイル開発プロジェクトで広く浸透している見える化の手法を見ていく。その中で、チーム全体がプロジェクトの今の状況を把握し、開発者の自律的な作業を可能にし、協調作業を促進する、三つの視点(とき、こと、ひと)をうまく使うかんばんボードの利用法を提案する。そして最後に、三つの視点によるプロジェクトの見える化を実現している、かんばんボードのソフトウェアによる実装 “TRICHORD” を紹介する。 アジャイル開発プロジェクトにおける見える化 XP(eXtreme Programming)の中に、“情報発信する作業場所”というプラクティスが紹介されている。これはプロジェクトの進行状況を、一目で把握できる
Scrum ではコードレビューをどうやっているか？ - haradakiro's blog
森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基本はチーム全員で集まってやります。最大２時間。それ以上やっても集中力が続かないので。プロジェクタで対象
「アジャイル」と「ウォーターフォール」 - Digital Romanticism
アジャイルがダメだと思う7つの理由へのだいぶ遅い反応 導入 もうだいぶ前の話になってしまいましたが、アジャイルに関するブログエントリ「アジャイルがダメだと思う7つの理由」は予想以上に波紋を呼び、それに呼応していくつものエントリが公開されました。発端となったエントリに関していうと、通常であれば必要となる数々の留保事項や前提事項を書かずに切り込んでいるという点において、間違いなく「煽り」であると言えます。ただ、「アジャイル」という言葉をとりまく数々の事象をかなり的確に指摘することによって、「アジャイル」という言葉をパブリックな場所で語っている少なからぬ人たちに対して、（意識的か無意識的かは問わず）ある種のポジショニングを強いたという意味で、実にいい釣り針なのではないでしょうか。 個別の論点に関する「アジャイルでは全体スケジュールにコミットできない」「いや、アジャイルだって全体スケジュールにコミ
[Agile]スプリントのタスクに関するTips29個 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 Scrum CrazyというサイトでスプリントのタスクについてたくさんのTipsがまとめられているのでご紹介します。 Sprint Tasking Tips ここではTipsのタイトルだけ紹介しておきますので、詳しくは上記サイトを参照してください。 Scrum Crazyでは他にも色々なTipsがあるので是非見ておくと良いと思います。 正直に見積もり、見積りが正確であることに価値をおく環境を作ることタスクを見積もる際は時間で見積もることを強く推奨実時間ではなく理想時間を使うことが望ましいより粒度を小さくしたタスクにすることを強く推奨1日は5〜6理想時間とすること作業量を見積もるのであって期間を見積もるのではないできるだけアトミックな単位にタスクを分ける「作業中」の状態が2日以上にならないようにするタスクはチームで見積もるスプリント途中での再タスキン
![[Agile]スプリントのタスクに関するTips29個 | Ryuzee.com](https://cdn-ak-scissors.b.st-hatena.com/image/square/2739e548348eb41752b3cb6bf863f6de2d5fd0f4/height=288;version=1;width=512/https%3A%2F%2Fwww.ryuzee.com%2Fcontents%2Fblog%2Fimages%2F3959%2Fthumbnail.png)
アジャイル開発と反復開発の落とし穴
前回「『現状のソフトウェア開発は間違っていないか？』（プロセス編）」では、ウォーターフォール開発の問題点と改善方法を示した。さて、前回お話ししたようにウォーターフォール開発は本来、いくらプロセス改善をしたとしてもイノベーティブな開発がしにくい。ならば、反復開発（*1）やアジャイル開発に変えてしまおう、といいたいところ。しかし、導入するのであれば、それぞれのプロセスの特徴と弱点をしっかりと知っておくことが必要である。 ウォーターフォール開発からの乗り換えを考えている方々だけではなく、いまアジャイル開発や反復開発を実践している方たちにもぜひ一読してほしい。 （*1）反復開発とは例えばRUP（Rational Unified Process）やUP（Unified Process）のこと。 反復開発とアジャイル開発の違い 反復開発とアジャイル開発は、繰り返し型開発という意味では同じように思われる
ユーザーストーリーとは？
ユーザーストーリーとは？ 1. ユーザーストーリーとはhttp://www.flickr.com/photos/cannedtuna/4674434821/ 2. 吉羽龍太郎 (@Ryuzee) アジャイルコーチ 認定スクラムプロフェショナル(CSP) 認定スクラムマスター(CSM) 認定スクラムプロダクトオーナー(CSPO) http://www.ryuzee.com/ 野村総合研究所等を経てベンチャーのCTOhttp://www.flickr.com/photos/adforce1/2539903964/ 3. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外
ALMinium
Ko-ichi MAKITA @kmakita13714 Redmineのインストーラーがあることを教えて頂きました。Backlogsプラグインも入っているから、試してみたいですね。以前、Backlogsプラグインをインストールしようとして上手く出来ませんでした…orz - ALMinium - http://t.co/qPyhjHFz 2012-05-15 12:30:27 Δρακοντια @drakontia Ruby 1.9に対応させてないのか、該当部分を書き換えると動いたりします。最近Vanuanさんの変更が早くて追いつけないRT @mikoto20000: BacklogsがRedmine 1.4.x系でなかなかきちんと動きません＞＜、、、http://t.co/xcPZodIS 2012-05-15 09:33:44
アジャイル開発に踏みとどまっている人へ～段階的なアジャイルの導入とALMinium～
スクラムをテーマに、段階的導入という形で、いきなりの導入が難しいプロジェクトを徐々にアジャイル化する方法とツールALMiniumを紹介。講演は＠ITの大人気連載「ユカイ、ツーカイ、カイハツ環境！」「かんばん！～もし女子高生がRedmineで『スクラム』開発をしたら」の岡本隆史氏 スクラム、リーン開発をはじめとするアジャイル開発の広がりは止まるところを知りません。また、近年エンタープライズ分野でもアジャイル開発を本格的に導入する企業が再び増えつつあります。最近の開発手法の変化に伴い、そこで利用される開発ツール（プロジェクト管理ツール、バージョン管理ツール）などもExcelやSubversionに代わりRedmineやGitと言ったツールが注目を浴びています。 一方、アジャイルを導入しているプロジェクトと、さまざまな理由でいまだに導入できていないプロジェクト、あるいはアジャイルに挑戦したはいい
5分で理解するリーンな「かんばん」
Henrik Knibergさんのブログで「One day in Kanban land」という記事を見つけました。そこでは、かんばんの使い方のポイントがうまく描かれたマンガが紹介されています。各国語に訳されているので、ヘンリック氏に許可をいただき、日本語訳してみました。 赤い人がプロダクトオーナー（PO）の役割で、青い人たちが開発チーム（DEV。ここでは2名ずつ2チーム）、緑の人がテスターだと思います。テスターチームはデプロイまで担当しているみたいですね。 また、「TODO」「開発」「デプロイ」という各ステージにはWIP（Work in Progress：仕掛り作業）が制限されています。WIP制限とは、各ステージにWIPの数以上のカードを貼ることができないというルールです。
最近盛り上がってきた「かんばん」、ソフトウェア開発における「かんばん」（Kanban）とは何か
ここ数カ月、ソフトウェア開発の話題で「かんばん」（英語でも「Kanban」）という言葉を目にする機会が増えてきました。かんばんとは何で、どのようなものなのでしょうか？ 勉強がてら、いくつかのサイトを紹介していきましょう。 ビギナー向けの「Kanban101」 今年3月にかんばんビギナー向けのサイト「Kanban101」が立ち上がりました。このトップページがかんばんの特徴をよく表しています。 ソフトウェア開発におけるかんばんとは普通に日本語の「かんばん」のことで、誰でも見えるところに置かれて、ホワイトボードや黒板になっていて、記入したり、この画面のようにポストイットを貼って運用するのが一般的です。 かんばんの効果とは、このかんばんを模した画面に書かれているように「仕事のみえる化」「仕掛かりを減らす」「流れを見えるようにする」ということ。このサイトは英語ですが説明がとても簡潔で分かりやすいもの
InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ
図1 かんばんとプル生産方式 図1は、かんばんシステムの抽象的なモデルです。図1で示されているのは、上流と下流の2つのプロセスであり、上流プロセスが下流プロセスに部品を供給しています。最終的な顧客に製品を供給するために、プロセスは部品を生産し、その部品を下流に流し込まなければなりません。しかし、多すぎてはいけません。過剰生産は最悪のムダだと考えられます。そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます。(または、「スーパーマーケット」3 - 大野耐一氏 がアメリカのスーパーマーケットに行った時にかんばんの最初の考えを手に入れました。そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Project Facilitation
KPTの基本と、その活用法
大規模スクラムの失敗から学んだこと #AgileJapan2015
