企業や事業部規模のアジャイル適用のためのSAFe 企業や事業部規模でリーンとアジャイルのプラクティスを適用するためのフレームワークSAFe（Scaled Agile Framework）を紹介します。
Agileに関するhiroomiのブックマーク (158)
-
hiroomi 2018/03/02
-
-
「アジャイルは死んだ」以降に残るものは何か -リーンソフトウェア開発を再評価し、自工程完結で全体観点で改善する - - Qiita
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。 本稿でいうリーン（ソフトウェア）開発とは何か？ 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発～アジャイル開発を実践する22の方法～ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感：結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当
-
「アジャイル導入」や「プラクティス導入」といった大きい一歩を踏み出してうまくいかないと嘆くあなたに送るたったひとつのアドバイス
はじめにこの記事は一年くらい前に書きかけて放置していたのだけど、市谷さんが同じようなことを言ってるスライドをアップしていたので、二の矢として挙げることにする。 プラクティス導入がうまくいかない！！これまでも多くの人がそうだったし、これからもきっと多くの人が同じような状況に陥ると思われるのでメモしておく。 「現場でXXXを実施してみているのだがうまくいかない」という話は、色々なところで耳にする。XXXXはプラクティスでもいいし、スクラムでもいいし、ツールの導入でもいい。 例えば、プラクティスというのは、名前がついていて、各所で実践した例もいろいろあって、希望に満ち溢れているようにみえる。なので、ついつい手にとって試してみたくなる。TDD、ペアプロ、リファクタリング、カンバン、あー、たまらない！早くヤリたい！試してみたい！！ しかし、ぐっとこらえて、考えてほしい。 あなたが、その「キラキラ」し
-
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
-
-
アジャイルメトリクス実践ガイド
2017年1月12日（木）に、「Regional Scrum Gathering Tokyo 2017」で発表させていただいた資料です。 http://2017.scrumgatheringtokyo.org/ メトリクスに関する知見を、学術的視点（Agile2016・SQiP2016）および現場での活用事例から整理し、具体的な取得・活用方法を含めて説明しています。 みなさんのメトリクスの習得・活用のプラスになれば幸いです。Read less
-
-
日本のアジャイルは将来どうなる？
「アジャイルは将来、主流になりますか？」。アジャイルを検討している組織のマネジャーからよく聞かれる言葉だ。それにはいつもこう答えている「世界では既にアジャイル型が主流です」と。事実、海外のチームでは事前の想定に近い形て?アシ?ャイルチームか?うまく立ち上か?っていく。しかし、日本の企業システムの大多数の現場では今のままでは難しいだろう。 日本のITの現場が適応型に順応するための課題は三つある。一つめは「アーキテクチャー」、二つめは「教育」、三つめは「信念」だ。順に説明しよう。 “コンウェイの法則”をご存じだろうか。「アーキテクチャーは組織に従い、組織はアーキテクチャーに従う」という法則だ。巨大でモノリシックなシステムは、どんなに工夫しても巨大でモノリシックな組織でしか扱いきれない。「大規模な業務システムをアジャイルで開発する」という話が時々聞こえてくるが、うまくいった話を耳にしたことはない
-
-
-
-
アジャイルでなくなる瞬間、定義にこだわりすぎるのはやめよう
連載を続けていると、「それはアジャイルではない」「あなたの書いていることは間違っている」といった意見が届くことがある。様々な観点のフィードバックをもらえるのはうれしいのだが、失礼ながら細かい点にこだわりすぎではないかと感じる意見もある。 「スクラム以外でスプリントという言葉は使ってはいけない。これはルールだ」「アジャイルではユースケースなんて使わない。何か勘違いしているのではないか」といった反応で、「それは我々のアジャイルではない」と言われると、正直なところアジャイルの将来を懸念してしまう。 ウォーターフォールで工程の呼び方が違う（例えば基本設計と外部設計）から、「それは正しいウォーターフォールではない」という声が上がるだろうか。もちろん誰もそんなことは言わない。ウォーターフォールは道具であり、それを現場に合わせて使っていると誰もが認識しているからだ。 アジャイルもウォーターフォールと同様
-
日本企業にアジャイルを導入して考えたこと #easg - arclamp
2016年11月18日に行われたエンタープライズアジャイル勉強会11月セミナーにて「ユーザー企業へのアジャイル導入四苦八苦」という講演をさせてもらいました。資料は後段に。 エンタープライズアジャイルとは 「エンタープライズアジャイル」の定義は曖昧です。いわゆるエンタープライズ業界でもアジャイルをやっていこう、という方向性を合意しつつ、そのディテールは現場ごとに異なります。 弊社はSIerなので、別顧客で3つの事例を紹介しています。もちろん内容は異なりますが、いずれも以下のような条件になります。 顧客は日本企業で社歴が数十年以上 システムはいわゆるSoE領域（間接的にでも売上に寄与する） 10人ぐらいのチームが継続的に維持される規模 こうした案件を通じた学びはフィードバックサイクル、プロダクトオーナー、アーキテクチャの三点です。 フィードバックサイクル 企業システムではリリースサイクルを「3
-
研究者の皆様へ
2016.11.10 研究者の皆様から、様々なご意見をいただきました。 それに基づき、データを集めました。 それに関して、皆様からのご意見等をいただきたいと思います。 その一、近年、基礎研究への研究費が削られているというご指摘。 総務省統計局の科学技術研究調査を基に、開発研究、応用研究、基礎研究の金額を調べてみると(それぞれの区分は、総務省から各大学の事務局経由で研究者に区分していただいていると思います) 国公私立大学 基礎研究 応用研究 開発研究 合計(億円) 平成１３年度 10,787 7,554 1,808 20,148 (基礎研究の割合 53.5%) 平成１４年度 11,062 7,471 1,965 20,497 平成１５年度 11,213 7,446 1,736 20,395 平成１６年度 11,019 7,487 1,770 20,276 平成１７年度 11,677 7,59
-
7つのアジャイル開発手法の実践ガイド（第1回）
はじめに アジャイル開発手法が正しいことだとわかってはいるものの、いろいろある開発手法すべてを分析しようとすれば調査だけでかなりの時間がかかってしまいます。組織にとってどの方法論が適しているかを知るにはどうしたらよいでしょうか。この2回シリーズでは、7つの人気の高い開発手法の表と裏をすべて学習するので、組織に最適な開発手法を選ぶことができるようになります。第1回では、エクストリームプログラミング（XP）、スクラム、リーンソフトウェア開発および機能駆動型開発（FDD）について説明します。 Agile Manifestoの5周年が間近に迫っていますが、ウォータフォール型ソフトウェア開発からアジャイル開発手法とそのプラクティスへの移行の勢いは増すばかりです。ミネソタ州ミネアポリスで開かれた2006年のAgile 2006 Conferenceでは、アジャイルはもう「溝を越えたか」（『Crossi
-
-
アジャイル開発での根本的な改善活動--KPTから考える「ふりかえり」の重要性
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 「ふりかえり」はゴールの共有が重要 アジャイルによる超短期リリースを実現するために欠かせないのが自己組織化であることは以前に述べた。その自己組織化を実現するための具体的な手法が「ふりかえり」である。 文字通り、イテレーションの終わりに開発チームのメンバーでユーザーに価値のあるシステムを提供できているか、品質や生産性をもっと向上できないかを振り返る。デイリーミーティングが品質や生産性の微修正なら、ふりかえりは次のイテレーションに向けて根本的な改善を図る活動である。開発チームが自分たちの仕事のやり方を自らの手で改善することでプロジェクトマネージャに指示されるのではなく、ボトムアップでの自己組織化を実現できるわけだ。 アジャイル開発をやったこ
-
日本でアジャイルが流行らない理由 - @ledsun blog
ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
-
本書について
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました