変わり続けるRUP さて、このような努力の甲斐あって、RUPは中・大規模プロジェクト向けの開発プロセスとして広く認知いただけるようになりました。しかし、このRUPも急速に変化してきました。そこには、「開発プロセス、かくあるべし」の思想を見て取ることができます(図2)。 1)オープンソース・コミュニティへの寄贈 1つはオープンソース・コミュニティや標準化活動への技術提供です。 2000年代半ば、IBMは、RUPをベースに2つの活動を行います。1つは、Eclipse Foundationに対し、プロセスフレームワークを定義するプロジェクトを提案します。これが、Eclipse Process Framework(EPF)です。この際に、RUPの軽量化バージョンであるOpenUP(オープンナップ)と、プロセスを編集するツールEPF Composerを寄贈します。 2つめは、 UMLの標準化団体で知
海外ではなぜアジャイル型開発が普及しているのか、IPA(独立行政法人情報処理推進機構)が継続的に行っている非ウォーターフォール型開発についての調査や提言活動の一環として、海外でのアジャイル開発の背景などについての報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 (非ウォーターフォール型開発の海外における普及要因編)」が公開されました。 調査対象国は、アメリカ、イギリス、中国、ブラジル、デンマークです。アメリカはアジャイル宣言が行われたアジャイル開発先進国として、イギリスもアジャイル開発の先進国として選ばれ、中国は日本のオフショア先であり新しいソフトウェア開発市場が起こりつつある国として、ブラジルはアジャイルコミュニティが活発化しており、デンマークは政府がアジャイル開発を推進している国として選択されました。 報告書のハイライトを紹介します。 海外でなぜアジャイル
みなさんこんにちは。@ryuzeeです。 2012年3月16日に実施されたAgile Japanの大阪メイン会場に登壇させていただきました。発表の資料を以下に公開します。 会場の外まで立ち見が溢れるくらいの多くの方にお越しいただき感謝するとともに、ご不便をおかけした方にはお詫びしたいと思います。 僕が話した内容は、実は単に実際の現場で、現場を良くしたいと思っている皆さんの胸のうちを代弁しただけです。アジャイルという単語、スクラムやXPといった手法の名前自体の認知度があがって、ともすればこれらを導入すれば全てうまくいくんだ、と誤解を生んでいるのではないかと感じています。 でも手法は手法でしかなく(したがってスクラムやXPを導入しているからといって自分たちのアジャイル度合いが高いとは限らない)、目的に応じてそれにあった方法、自分たちがゴールを達成するのに最適だと思う方法を脳みそ振り絞って考えて
「アジャイルがダメだと思う7つの理由」という刺激的なタイトルのエントリを、先週木曜日、3月21日にグロースエクスパートナーズの鈴木雄介氏が公開してから、アジャイル開発に関する議論の波紋が広がっています。 おそらく、これだけさまざまなブログを通じてアジャイル開発の議論が活発化したことはこれまで国内ではなかったのではないでしょうか? ここでは現時点での議論をまとめますが、興味のある方はぜひここを起点にそれぞれのエントリを読んでみていただきたいと思います。 発端は鈴木雄介氏(id:arclamp)のブログarclampにポストされた「アジャイルがダメだと思う7つの理由」というエントリ。以下がその7つの理由として挙げられたものです。 1.全体スケジュールにコミットできない 2.アーキテクチャ上の無駄が生じる 3.コーチって何だよ 4.変化ヲ抱擁スルために固定化している 5.実証主義的な説明に過ぎな
鈴木雄介さんが、「アジャイルがダメだと思う7つの理由」というすごいブログを書いてくれたので、がんばって返答を書いてみる。どこかでディスカッションできるといいなぁ。 1. 全体スケジュールにコミットできない コミットメントって何だろう。コミットメントは約束なのか。約束であったら、破った場合のペナルティも受け入れるのか?受け入れたところでバッファが巨大になるだけではないのか?そして、そのバッファは見えないところで食い尽くされる。 全体を見えずに計画したところでうまくいくはずはない。アジャイルがタイムボックスで計画、実施を行うからといって、全体を計画しないわけではない。むしろ積極的にやるべきである。 全体を計画する上では、なるべく漏れがないように、実施可能なように最大限の努力をする。ただ、それに時間を掛けすぎるのは無駄だ。そして、神ならぬ人間が計画するのであるから、以下を認めなければならない。
インセプションデッキって何?って人はThe Agile Samuraiを読むと良い。 The Agile Samuraiの日本語版は@kakutaniさんや@nawotoさんが頑張ってらっしゃるので、期待して待っていよう。 簡単にいうと、インセプションデッキは10個の質問から構成されていて、プロジェクトを始めるにあたって、その質問に答えることによって、プロジェクトの全体像やこれからの方向性等を明らかにしてくれるツールだ。(逆に答えられないとするとその時点で結構ヤバイということでもある)。そしてプロジェクト期間中は見えるところに貼っておき、何か変更があれば随時更新していく。 詳細は本の著者であるジョナサンのサイトのThe Agile Inception Deckを見て欲しい。 公開されているインセプションデッキのテンプレートを日本語化してみた。 以下からダウンロードできる。ライセンスはC
I usually keep the Scrum Product BackLog (PBL) on an Excel sheet and share it across the project members. It has its own pros and cons. Some people also use Google docs spreadsheet for the same. I just found that you can also create a good looking PBL on Google Sites Apps. The idea is to simply create a new page with List as a template and then customize the list columns to show scrum pbl column’s
最初に注意書きを。本エントリは法務面で専門家ではない私が個人として意見見解を述べているものであり内容を保証するものではない(他のエントリもそうなのだけれども)。アジャイル開発に関する諸契約については専門家(自組織の法務部門等)に確認していただきたい。なんとなく本邦のIT業界には「アジャイル開発モデルは準委任契約を結べば良いという誤解」があるような気がしている。今年、IPAから『日本におけるアジャイル開発に適した契約モデル案』などが出てきているので、それを改めて読みながら論点を整理したいと思った次第。 請負、準委任 いろいろ整理する前提として、請負、準委任というものについて簡単に整理しておく。私の理解が誤っている可能性もあるのでお気づきの点があれば指摘いただきたい。たぶんポイントは「民法上(契約法)」と「労働者派遣法」の2つのスタンダードがあるという事だ。 民法上(契約法)の「請負、準委任」
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
アジャイルな開発の導入支援の現場や色々な勉強会でよく「どんな本を読んだら良いですか」と聞かれたりします。 何のために本を読んで勉強するかは人それぞれですし、自分のおかれたコンテキストでどの本が役にたつかは分からないですが、以下にあげた本は個人的に強くオススメできる本です。人に聞くのも大事だし自分で試行錯誤するのも大事だけど、本を読んで体系的に学んだり先人の知恵を学ぶことは続けたほうが良い。 プロダクティブ・プログラマ -プログラマのための生産性向上術どうやったら自分自身の生産性を高くすることができるのか。PCの使いこなしから始まり、自動化やバージョン管理等にも触れている プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)著者/訳者:Neal Ford、島田 浩二 (監訳)、夏目 大出版社:オライリージャパン発売日:2009-04-27単行
Copyright (c) 2006-2025 ESM, Inc. Oblove, AMANO Masaru 1/67 プロジェクトファシリテーション 実践編 ふりかえりガイド (株)永和システムマネジメント オブラブ 天野勝 第 1 版 2006 年 6 月 7 日 第 32 版 2015 年 11 月 24 日 第 33 版 2016 年 4 月 25 日 第 34 版 2018 年 1 月 27 日 第 35 版 2021 年 5 月 13 日 第 36 版 2022 年 10 月 30 日 第 37 版 2025 年 4 月 25 日 第 38 版 2025 年 5 月 1 日 オリジナル:http://ObjectClub.jp/community/pf/#material このドキュメントは、クリエイティブ・コモンズ・ライセンス(帰属 2.0)の下で 提供しています。このライセ
Did my yearly agile intro talk at KTH today (Royal Institute of Technology). Here are the slides.Always enjoy meeting the students and sharing insights & experiences! Some sample slides below. Continue reading Here are the slides from my keynote “The Age of AI is here – now what?”, from Crisp Day 2023. There more I use this technology, the more clear it is to me that organizations need to deeply u
尊敬するDOAの先輩である、渡辺さんがこう書いている。 「データモデルなきアジャイル」の危うさ、より その種のシステム(※引用者補記:販売管理システムや生産管理システムといった基幹系業務支援システム)をアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 それに対して、稲見さんがこんなコメントをしている。 アジャイル開発と言っても色々で、最近流行りのScrumという手法は、開発の中身に関しては何も言及していません。ですが、私の知っているある人達
Claude Code の情報はここです docs.anthropic.com Windows マシンでは WSL が必要ということでインストール wsl --install wsl --install ubuntu 一台のマシンは以下のエラーになった。 Wsl/Service/CreateInstance/CreateVm/HCS_E_SERVICE_NOT_AVAILABLE こちらを参考に。 github.com タスクバーの検索窓から「Windows の機能」で検索してWindowsの機能(Windows Features)画面を呼び出す。 "Virtual Mashine Platform"は入っていたが、"Windows ハイパーバイザープラットフォーム" は項目自体がなかった。 ということで次は以下を参考に qiita.com Powershell を管理者モードで立ち上げて
5分で分かる、「スクラム」の基本まとめ:開発チームを改善するためのスクラムTips(8)(1/2 ページ) 「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 これまで、アジャイル時代のチーム・マネジメント手法として主流になっている「スクラム」の手法を紹介してきました。今回は総集編として「スクラムの基本」をコンパクトにまとめます。 そもそもスクラムとは スクラムは、一言でいえば「チームで仕事の進めるための枠組み(フレームワーク)」です。 もともとはソフトウェア開発プロジェクトを成功させる仕組みですが、技術的な要素は取り除かれ、多くのチーム作業に共通して適用できる要素だけが残りました。そのため、ソフトウェア開発以外のチームにも適用できるのが特徴です。 ●バッ
日本のアジャイル10年、人々とコミュニティの私的物語 平鍋健児 (※)この記事は、2011年に書籍『Ultimate Agile Stories』に寄稿したものを転載しています。執筆時点で、『Ultimate Agile Stories - Iteration 2』が刊行されています。(2012/8/15) ぼくが初めてアジャイル、というか、XP、そうエクストリームプログラミングについて知ったのは、2000年の初めだった。ふと目について注文した洋書『Extreme Programming: Explained』がamazon.comから届き、それを週末に読んだのだ。このときに、どんな電流が走ったかは、多くの人の前で語ってきたが、Kent Beck という人物がとんでもなく明快に、そして極端に、人に喜ばれるソフトウェア開発、という視点でプログラミング活動を中心おいて4つの価値と12個のプラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く