Modern Agile JP
Modern Agileとは 初期のXP(Extreme Programming)賛同者、Joshua Kerievsky が世界最大のアジャイルカンファレンスである Agile2016 の基調講演において、モダンアジャイルというコンセプトを披露しました（→InfoQ記事）。 2001年に宣言されたアジャイルマニフェストが、15年を経ましたが、今の時点でアジャイルを再度考えてみよう、という命題です。http://modernagile.org より（超訳）… アジャイル宣言から10年、イノベーティブな企業、ソフトウェアの思想的リーダーたち、アジャイルとリーンの開拓者たちは、よりシンプルで、より強く、より合理化されたアジャイルを模索してきた。この「モダンアプローチ」は、「実験的な成果の創出」と、「優れたカルチャーの育成」に焦点をあてている。今日、伝統的なアジャイル定義をバイパスして、モダンア
朝会のパターン:立ってるだけじゃないよ - Martin Fowler's Bliki (ja)
以下の文章は、Jason YipによるIt’s Not Just Standing Up: Patterns of Daily Stand-up Meetingsの日本語訳である。Jasonの許可を得て、ここに掲載する。 立ってやるのはミーティングの時間を短くするためだ 朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル(訳注：ハドルとは群になって集まること)、朝のロールコール(訳注：ロールコールとはメンバが順番に答えていく方式)を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、その
Modern Agile
Over the past decade, innovative companies, software industry thought leaders and lean/agile pioneers have discovered simpler, sturdier, more streamlined ways to be agile. These modern approaches share a focus on producing exceptional outcomes and growing an outstanding culture. Today, it makes far more sense to bypass antiquated agility in favor of modern approaches. Modern agile methods are defi
これからアジャイル開発を学びたい人向けの基礎知識と５つの事例
アジャイル開発という言葉が騒がれるようになってしばらく経ちますが、ピンときていない人もまだいるかと思います。あるいは、概念は理解していても、実際どう実務に取り入れたら良いのかわからない方も多いかもしれません。 今回はアジャイル開発の簡単な紹介と、導入を検討している方のためのサイトやスライドを紹介していきたいと思います。 アジャイル開発とは アジャイル開発とは、迅速かつ柔軟な開発手法の総称を指します。ちなみに、アジャイル（=agile）とは英語で「すばやい」「俊敏な」という意味です。アジャイル開発の手法としては、スクラムやエクストリーム・プログラミング（XP）などがあります。 アジャイル開発と言われる手法の特徴としては、１〜２週間の短い期間で１つの機能を開発し、これを繰り返して全体のソフトウェアを作り上げていく点が挙げられます。 ウォーターフォール型とアジャイル型の違い アジャイル開発はしば
Misoca開発プロセス2016年版 - 弥生開発者ブログ
こんにちは、こくぼ id:yusuke-k @yusuke_kokubo です。 株式会社ファントムタイプ @phantomtype という会社をやってます。 Misoca社には2年半ほど前からお世話になってます。 開発のプロセスや生産性をあげる組織のあり方を考えるのが好きです。 最近はUIデザインをしたり、Misocaが目指すプラットフォームのUXデザイン(見習い)をしたりしています。 ここ3年ほどでMisocaはスタートアップして資金調達からexitまで行きました。 その過程で開発プロセスもいろいろ変わってきたのでここらでいちど整理したいと思います。 注意事項 ここでは開発チームに限った話を書きますが、他にもマーケティングやユーザーサポートなどのチームがあります。 チームプロフィール メンバー 約8人 (女性比率0%) リモートワーク 1~3人 こちらのメンバー紹介記事もあわせてご覧く
デブサミ2016夏でDevOpsお悩み相談室というセッションをやりました
みなさんこんにちは。@ryuzeeです。 7月29日に御茶ノ水のソラシティでおこなわれたDevelopers Summit 2016 Summer (デブサミ2016夏)で、「DevOpsお悩み相談室〜カイゼンの文化を組織に根付かせるために」というタイトルのパネルディスカッションを実施しました。当日は多くの方にお越しいただきありがとうございました。当日の資料は以下になります。 事前にアンケートに回答いただき、全部で10個のトークテーマを用意していたのですが、時間の関係で後半の3個は扱えませんでした。それをお待ち頂いていた方もいるかもしれないので、この場で私見を説明しておきたいと思います。 Q. スクラムの定着方法開発プロセスをカイゼンするためにスクラムを導入しましたが、みんななんとなくこなすだけになっており、カンバンやデイリースクラムも形骸化しています。 今のやり方はうまく回っているように
要件をどう取り扱うか--アジャイル開発で重視すべきは「ユーザーストーリー」
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 「要件」を明確に理解している顧客はいない 今回はアジャイルにおける要件定義を取り上げる。要件定義は、業務システムに対してアジャイル開発を適用する際、最大の関門となるフェーズである。失敗原因の大半を占めるといっても過言ではない。逆に言えば、要件定義のコツを押さえれば成功の確率を高められる。 本題の前に、最初に「要件」と「要求」という言葉があるが、どちらも「Requirements」である。要求を取りまとめたアウトプットが要件であるといった語感はある。しかし、些細な違いであり、どちらも同じ意味と考えた方がいい。また、ここでの要件とはシステム要件である。ビジネス要件や業務要件ではない。 まずは、要件定義に対する考え方を整理しよう。アジャイル開
[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)
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール ＆ アジャイル編～ – とあるコンサルタントのつぶやき
とあるコンサルタントのつぶやき とあるコンサルタントのつぶやき MCS （Microsoft Consulting Services） の某コンサルタントがまったり語るテクノロジのお話です。 ご存知の方も多いと思いますが、ここ最近、うちの会社の歌って踊れる DevOps エバの牛尾さんが、こんなエントリを書かれていました。 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い http://simplearchitect.hatenablog.com/entry/2016/06/20/080807 「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない http://simplearchitect.hatenablog.com/entry/2016/06/24/080049 特に前者は炎上気味でしたが；、二回分のエントリを通して読めば、牛尾さんが言いたい
YWTという振り返り手法について | ナカシマガジン
YWTという振り返り手法について 今回はYWTという振り返りの手法についてご紹介してみたいと思います。前、メール版で書いてた記事ですが、ブログでもアップしときます。 さて。 振り返り、その手法はいくつかあるのですが、大御所の手法はやはりKPT（ケプト）と言われる手法でしょう。 KPTとは、その名の通り K：Keep P：Problem T：Try の頭文字を取った手法のことで、（やってみて）Keepしたいこと、Problemだと思うこと、次にTryしてみたいことを、分野別にまとめることができます。 KPTはシンプルながらかなり使える方法でして、以前僕もこんな記事をまとめていました。 YWTとは何か？ KPTは最近知っている方も多くなってきたのですが、YWTという手法はまだあまり知られていないようです。 かくいう僕も、昨年くらいにどっかで見かけて、「これ面白いなー」と教えてもらった手法です。
発売のお知らせ：アジャイルコーチの道具箱 - 見える化の実例集
こんにちは。@ryuzeeです。 既にご存知の方も多いと思いますが、昨日4月13日に新刊の「アジャイルコーチの道具箱 - 見える化の実例集」(Jimmy Janlén著、原田騎郎・吉羽龍太郎・川口恭伸・高江洲睦・佐藤竜也訳)が発売になりましたのでお知らせです。なお、こちらの書籍はLeanpubでの電子書籍(PDF)形式のみでの販売です。 本書の内容と特徴は以下のとおりです。 本書は、仕事の見える化を進める際に役立つ方法を図と説明つきで96パターン紹介する書籍です。全体で124ページで、各パターンを1ページあたり1つずつ紹介しています。通読するというよりはパラパラと見ながら気になるパターンを探すとよいと思います「見えないものは改善できない」というのがカンバンなどの見える化に共通する基本的な考えです。そして見えるようにした後の課題として、どうやってもっと分かりやすくするか、どうやって毎日維持す
カンバン仕事術が活かせそうな点満載だった
会社でホワイトボードに書き出してはいるものの上手くいってなかったので、いっときAmazonでも在庫切れになったりとい人気っぽいカンバン仕事術を読んでみた。 総論 ってきり、はじめはスクラムとかXPとかアジャイルの手法ゴリゴリかな？と思っていたのだが、むしろ逆で、かなりピュアなカンバンの本だった。 スクラムとかXPとかのアジャイルを現場に持ち込むのはそれなりにパワーいるが、この本のようなカンバンだけなら簡単に導入できる部分がありそう。 カンバンでの見える化からはじめて、いきなりやるには、作法がわからないとか、その作法の裏にあることを理解できてなくて諦めがちなアジャイルの手法にも段々ともっていくというようなこともできるのではないだろうか。 カンバン仕事術だけでは具体的案イメージがつかなかった点も多いのだが、アジャイルコーチの道具箱 – 見える化実例集を合わせて読んだらよりイメージがわいたのでセ
アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー！) | DevelopersIO
アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー！) はじめに 2月某日、Ryuzee.com の Ryuzee さんこと吉羽龍太郎さんに、アジャイル・クラウド・DevOps についてのお話を伺う機会がありました。本エントリーは、その時の様子を文章化したものです。 アジャイル・クラウド・DevOps は実際のところどんなものなのか？ 上手くいく／上手くいかない取り組みの違いはどこなのか？ そもそもそれは本当にやるべきか？ 組織とエンジニアの関係、評価はどのようにすれば良いのか？ といった幅広いテーマについて語っていただきました。 このインタビュー記事は、 アジャイル・クラウド・DevOps などをやりたいけど、どこから手を付けていいのかわからない方 手を付けたけど、なんだか上手くいっていないことにお悩みの方 もしく
ユースケース、それともユーザストーリー？
Murali Krishnaはこう言う(リンク)。 アジャイル開発へ効果的に移行できないという失敗は、ユーザストーリーが何たるかを理解できていないという根本的な失敗に根ざしていることが多い。 ユーザストーリーの最も重要な側面は、ユーザストーリーが要件（機能）の「スケジュール可能な」ユニットであり、スケジュールは他に依存していないということです。ユーザストーリーの「他に依存せずスケジュール可能な」特徴を実現する鍵となるのが、「ユーザ」がどう使うかという目線に立ってユーザストーリーを表現することです。そうすればユーザが実際にインタラクトできるエンドツーエンド（UIからバックエンド）に実装された機能性のユニットが手に入ります。 Krishnaはアジャイルコミュニティで多数の人々が信じている「ユーザストーリーは唯一、最良のよりどころ」を正確に描写し、Mike Cohnによる「Advantages
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
omoiyari.fm (lean-agile podcast) #omoiyarifm
世界最大級のアジャイルカンファレンス報告：Agile2016参加レポート
良きモノの提供に向けた協働 - 開発とテストが一体となったソフトウェア開発 -
Agile2016のオープニングキーノート：Managing for Happiness
InfoQ: アジャイル/スクラムプロジェクトにおけるバグへの対応
