アジャイルはなぜアジアで普及しないかSpring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
ウォーターフォール型開発プロセスの有効性 - 勘と経験と読経
牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ
日本でアジャイルが流行らない理由 - @ledsun blog
ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
ウォーターフォールとアジャイルを考える - arclamp
初めて単独主催の勉強会をしました。ワークショップなので後半の1時間はディスカッションにしたのですが40人のわりには、それなりに面白い話ができた気がしています。資料とワークの結果、あとTogetterは以下から。 togetter.com 今回のプレゼンは純粋な「プロジェクトマネジメント論としてのウォーターフォールとアジャイルの違い」に絞った話をしたので、後半のワークが現実的な話になって面白かったです。話をしたのは以下のようなことです（資料の後半に細かいメモ書きがあります）。 そもそもウォータフォールは必要なのか？ とはいえ、ウォータフォールを採用しなくてはならない状況は？ なぜ、アジャイルを採用できないのか？ チームは重要だけど、どういうメンバーがいいのか？ アジャイルとはいえPM的な人が必要になることってあるよね？ アジャイルの立ち上げってどうするのがいいの？ 偶然、牛尾さんの 私は間違
Martin Fowler's Bliki (ja)
ここは、Martin Fowler's Blikiの日本語翻訳サイトです。Martin Fowler氏本人の許可を得て公開しています。データはGitHubで管理していますので、どなたでも翻訳に参加することが可能です。 ※現在、移行中につき、Markdown形式になっていないものが多々あります……。PRいただけると大変ありがたいです。 API design / agile / agile adoption / agile history / application architecture / application integration / bad things / build scripting / certification / clean code / collaboration / computer history / conferences / continuous deliv
それは実験 ― 形骸化した「アジャイル」を再考する新手法”GROWS”について | POSTD
(この記事は 「アジャイルの破綻―原因、そして新たな提案」の続編にあたる記事です。) 前回のブログで、私はアジャイルの変動について、「調査と順応の概念は一体どこへいってしまったのか」、「近い将来起こり得る問題に対処できるよう手法の革新を図ろう、新たなやり方を導入しよう、という考えはどうなってしまったのだろう」、と問いかけました。 VersionONEによるアジャイル開発の2014年アンケートによると、アンケートに答えた56％のチームがスクラム、10%ほどがスクラムとXPの併用、8%がアジャイル手法の混合（XP, かんばん, リーンなど）を使っていることがわかりました。私からすると、アンケートに答えた18%はだいたい正しいことをしているように見えます。他は、もしかしたら、いつもしている単なる朝礼をアジャイルと呼んでいるかもしれません。 それは少し言い過ぎたかもしれませんが、同アンケートの別の
TechCrunch
In an attempt at damage control, the CEO of the equity management startup Carta, Henry Ward, today emailed customers, telling them that if they are concerned about “negative press” tied to the out In the Lego-like world of Roblox, about a hundred blocky avatars march through a lamplit street, wielding Palestine flags that are larger than their own animated bodies. Characters dressed like cartoo
企業システムにアジャイルは必要か
2015/6/22にアイ・ラーニング様にて開催された「悩める管理職のためのエンタープライズ・アジャイル導入セミナー」の講演資料です。
「#ぶつかり稽古」という事件について - Kentaro Kuribayashi's blog
去る11月23日、あるイベントが開催された。「秋のエンジニアぶつかり稽古 2013」という。何を目的にしたイベントなのか誰も(主催者側ですらも)わからないまま始まったこのイベントは、しかし、最後までその目的が明らかにならないままに、なぜか大成功の余韻だけはしっかり残して終わった、異常な「事件」と呼ぶ他ないものとなった。 事の発端 そもそもの始まりからして意味不明だったのである。発端はこれだ。 @__kan こんにちは、ペパボです。YAPC::ASIA参加者スペシャル特典にご応募いただき、ありがとうございます ！ @kentaro とのぶつかりげいこをぜひ開催したく思います。ご都合のよろしい日をいくつかご連絡下さい！ pic.twitter.com/uoj2uExHBU— ペパボ(paperboy&co.) (@pepabo) October 2, 2013 2ヶ月ほど前、YAPC::Asi
組織パターンを用いたScrumの微調整 - @m_seki の
組織パターン (Object Oriented SELECTION) 作者: James O. Coplien,Neil B.Harrison,ジェームス・コプリエン,ニール・ハリソン,和智右桂出版社/メーカー: 翔泳社発売日: 2013/08/06メディア: 大型本この商品を含むブログ (15件) を見る 2013-10-30、コプリエンの研修にレポータ枠として参加しました。がんばってレポートします。 本来は組織パターン (Object Oriented SELECTION)を読んだ人、組織パターンやScrumの好きな人、そしてコプリエンファンの人が参加する研修だと思いますが、どれにも該当しないままでの参加となりました。 会場入り 9:45。6Fにつくと喫煙所に角谷さん(id:kakutani)を発見。朝からついてる感じです。会場に入ると裸足のコプリエンと三人の通訳、TAの皆さんが準備し
久々に壮絶な自爆、というかブーメランを見ました。 - 30近いおっさんのブログ
「おい！どの口がアジャイル出来るって言ってるねん！」 さて、私にしては珍しくブチ切れ気味で記事を書いているのでこんな事書いていますが、ここからは、効果を本当に上げるアジャイル開発を実施したいときのリクルートで、どういうスキルを持った人を雇えばいいか？という話を進めたいと思います。これはとてもシンプルな一言で言えます。 テスト駆動開発が適切にできる能力があること この一言につきるのです。クライアントの皆さんは、是非アジャイルベンダーを雇うときはプログラマの人にこの能力を要求してください。注意しないといけないのは、テスト駆動が適切にできていないプログラマは、わかっていない事すらわかっていないこと、そして、営業さんとかマネージャさんのレベルだと、「テスト駆動が適切にできる人かどうか見分けがつかない事」が問題になってきます。これは、まともにテスト駆動ができる人がその人と話をすればテスト駆動をちゃん
こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
RubyKaigi2010で「本当のアジャイル」を学んだ - 基本へ帰ろう
Rubykaigi2010参加して本当に良かった。運営の皆様、スポンサーの皆様、参加してくださった皆様、Rubyを普段から支えてくださっている皆様。本当に有難う御座います。私もRubyに大変お世話になっていますので、少しでも私に出来ることはないかと思い、個人スポンサーとなって参加させて頂きました。そしてこのブログを残します。 本当のアジャイル 私がRubyKaigi2010に参加して一番痛感したことは、「今までの私はアジャイルをやっていなかったこと。むしろウォーターフォールに近いことをやっていた」と思い知らされたことです。 ウォーターフォールを御存知ですか？半年や１年の開発見積りを行い、それに従って開発を進めるが、見積りが合わなくなり（大抵は見積が足りない）、しかし見積は変えず、デスマーチと呼ばれる慢性的な長時間残業を行うようになり、自分への投資（技術の学習等）を行う時間を犠牲にする開発体
ソフトウェア開発をシンプルにする考え方のコツ ― ＠IT
ソフトウェア開発ではこれまで、できるだけ「シンプル」に設計・開発することの有効性が繰り返し提言されてきた。ソフトウェアをシンプルにすればするほど、設計は見通しが良くなり、開発は容易になり、メンテナンスも楽になる。 では、開発を＜シンプル＞にするというのはどういうことなのか？ 一体どうすれば＜シンプル＞になるのか？ これらの質問にあなたは即答できるだろうか。実際のところ、頭ではシンプルにすることが良いと分かっていても、現実には実践できていなかったりするのではないだろうか。 そこで本稿では、現実の開発現場でシンプルな設計・開発を行うための1つの手段として、その「考え方のコツ」を考察する。もちろんこのコツを身に付けることは、すべてのソフトウェア開発で役立つものだろうが、特にNAgile（エヌ・アジャイルまたはナジャイル）を実践していくうえでは、ぜひ知っておいてほしい（NAgileについての概要は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
モデリングもしないでアジャイルとは何事だ
7462
スクラム入門