IPA版アジャイルプラクティスのパターン言語集 - プログラマの思索
IPAがアジャイルプラクティスのパターン言語を公開していたのでメモ。 これは凄い。 パターン言語というアイデアは、かなりマニアックな考え方と思っていたのに、世間に認知されてきたのかな？ 調査報告書や「アジャイル型開発におけるプラクティス活用リファレンスガイド」を読んでみて、気づいた点を抜粋して書き出してみる。 【元ネタ】 情報処理推進機構：｢アジャイル型開発におけるプラクティス活用事例調査｣の報告書とリファレンスガイドを公開 情報処理推進機構：｢アジャイル型開発プラクティス・リファレンスガイド」を公開～アジャイル型開発の初心者向けに実践ノウハウを事例から分類・整理～ Twitter / IPA_SEC:SECでは、アジャイル型開発で用いられる組織、プロセス、技術等の実践のための指針である「プラクティス」について、先駆的企業を対象に事例調査を行い、リファレンスガイドとしてまとめ、本日3月19
"ほむらはオレなんだッ！オレだ！" in #横浜道場 - koeだめ 過去アーカイブ[〜2013-12-14]
アジャイルサムライ横浜道場 特別編「Domain-Specific Language としての魔法少女まどか☆マギカ入門」に参加してきました。 「私は何度でも繰り返す」 システム開発に携わっている方であれば、この言葉を使う機会は多いのではないでしょうか。 ・全てのテストがグリーンになるまで ・Jenkins のエラーが解決するまで ・全ての仕様をユーザから聞き出すまで 等々 「知っている」人であれば、この状況を「ほむほむ」と一言で表現することができます。 我々？はこうした言葉・語彙を、「特定の用途向けに特化した言語」、すなわち「Domain-Specific Language」（以下「特定ドメイン」）として使うことを提唱しています。 そして、システム開発については、特定ドメインの知識の多くを「魔法少女まどか☆マギカ」（以下「まどマギ」）に見出すことができます。 もっとよいシステム・サービス
!["ほむらはオレなんだッ！オレだ！" in #横浜道場 - koeだめ 過去アーカイブ[〜2013-12-14]](https://cdn-ak-scissors.b.st-hatena.com/image/square/81c07861cbe311f58349f6434bd7a9b4eaf1564d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117126976353052%2F17680117126976357116%2F1550818885)
備忘 - ikeike443のブログ
アジャイルがダメだと思う7つの理由 この記事を読んで、特に1番を見て感じた違和感をTweetしました。備忘。 よほどひどい目にあったのかな / “アジャイルがダメだと思う7つの理由 - arclamp” htn.to/DLRhnX— Takafumi Ikedaさん (@ikeike443) 2013年3月22日 大変ですねという感想しかない— Takafumi Ikedaさん (@ikeike443) 2013年3月22日 全体計画にコミットしなきゃいけないってのがダウトなきはする。経営者がコミットしなきゃいけないのは収益であり顧客価値でしょ。顧客価値最大化のために毎スプリント計画を見直して優先順位を議論するわけだし。そういうことに納得してユーザーが選択するのがアジャイルでは。— Takafumi Ikedaさん (@ikeike443) 2013年3月22日 @ikeike443 同感
ソフトウェア工学は失敗している - きしだのHatena
特に学術的にソフトウェア工学に触れたことはないのですが、むしろそうではなく現場にいる身としては、ソフトウェア工学は失敗しているように見えます。 「成功していない」ように見えるのではなく「失敗している」ように見えるのです。 もちろん、いまソフトウェア開発で使う技法やツールなど、ソフトウェア工学の産物はたくさんあり、現在のソフトウェア開発がソフトウェア工学から生まれたもので支えられていることには間違いありません。 でも、そうやって築き上げてきたものが、1999年以降ガラガラと崩れて、そしてうまく再構築できていないように見えます。 1999年、なにがあったかというと、XPエクストリーム・プログラミング入門という本が発行されたのです。リンク先は2版ですが、日本語版でも初版は2000年12月になっています。 ここからソフトウェア工学がガラガラ崩れた気がしています。 では、ここまでソフトウェア工学がど
「アジャイルがダメだと思う7つの理由」と「ソフトウェア工学は失敗している」は同じ次元の釣り？ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 最近、この２つの記事が話題なんですってね アジャイルがダメだと思う7つの理由 http://arclamp.hatenablog.com/entry/2013/03/21/233012 と ソフトウェア工学は失敗している http://d.hatena.ne.jp/nowokay/20130322#1363969460 だけどこれ、同じ次元で議論している。 製造業に直すとわかりやすい ベルトコンベヤー（＝ウォーターフォール：流れ作業）と セル生産方式（＝アジャイル） どっちがいい？っていう議論に見える。 セル生産方式が増えてきた＝ベルトコンベヤーは間違えている、失敗している？ ベルトコンベヤーはいまだに健在＝セル生産方式はだめ？ 変な議論だよね・・・ セル生産方式の工場も、ベルト
アジャイル開発の優しい教科書 - The Dragon Scroll
わかりやすいアジャイル開発の教科書を読みました。この本の著者の皆さんは関西の方で、いずれの方ともコミュニティにて繋がった方々でした。前川さんには、私が企画した東京の方のイベントでお話を頂いたり、細谷さんとも同じくイベントや本作りでお世話になっています。西河さんには、昔私が関西で開いたイベントに来て頂いたことがありました。お三方ともソフトウェア開発に真摯に向き合っている方々で、私が開発コミュニティに顔を出し始める前から活動をされていて、尊敬する先輩諸氏です。身近に感じる方々がアジャイル開発の、教科書と銘打った書籍を出されると知って、これはどうしても読みたいと思いました。先輩諸氏がアジャイル開発についてどんな言葉を残すのか。どんな言葉を日本の開発現場に届けるのか。楽しみでした。 本には、様々な工夫が凝らされていました。まずは、構成から。冒頭のテーマは「なぜアジャイル開発なのか」です。Start
プロダクトバックログのためのプロセスマップとストーリマップ
プロダクトバックログの体系化は，ユーザストーリの概要を把握し，全体像を見るためには有効な方法だ。Shrikant Vashishtha氏のブログ記事 ストーリマッピングとプロセスマップ (story mapping and/vs process maps) には，ユーザストーリをプロセスマップにマッピングするための方法が説明されている。その記事で氏は，ユーザストーリを体系化するための方法としてのプロセスマッピングアプローチを，Jeff Patton氏の提唱するストーリマッピングと比較してみせている。 スクラムでのプロダクトバックログは，プロダクトに対するニーズを管理するために使用するものだ。 大規模なプロダクトの場合には，バックログに多数のユーザストーリが登録される可能性がある。そうなると概要をまとめたり，全体を把握する作業が困難になる。さらにはユーザストーリの数が多くことによって，チーム
なぜ Agile Japan 2013 の基調講演に 枡野俊明 さんを呼びたかったか - mnishikawaのブログ
AgileJapan2013の開催が5/24に決まりました。 今年も実行委員長として、企画から推進を担当しています。 AgileJapan2013 AgileJapanの基調講演は、海外の著名なアジャイル開発者＋日本人というスタイルが定着しています。（去年は「アジャイルサムライ」の著者であるJonathan Rasmussonさんと岸良裕司さん。2010年のAlan Shallowayさん、野中郁次郎先生の組み合わせも印象的でした。） 特にこのスタイルが決まっているわけではないのですが、アジャイル発信の地から最新のお話が聞けるのと、日本の他業種含めたものづくりに関する広い考え方を知った上で考え、その日のセッションにのぞむことができるので、私は気に入っています。 今年はJames Grenningさんと、枡野俊明さんにおねがいしました。 James Grenningさんは、アジャイルソフトウ
安定したチーム作りと機能不全なチームの対処
複数のプロジェクトにわたる安定したチームを持つことは、アジャイルソフトウェア開発にとってプラスになる。安定したチームがあると、プロジェクトの開始時に新しいチームを作って終了時に解散するのではなく、仕事は既存のチームに対して作られ与えられる。だが、もし安定したチームが期待通りに機能しない場合には、どうすればよいのだろうか？ 安定したチーム作りとその育成について、また機能不全なチームの対処について、さまざまな人がブログに記事を書いている。 Joe Little氏は「we want a stable team」というブロク記事で、安定したチームを持つことは重要だと考える理由について説明している。 (…) すばらしいプロダクトを考え出すためには、何か特別なものが必要になります。私は最近、この「特別なもの」というのは、すぐれたチームから生まれる可能性が高いと思っています。したがって、ビジネスマネジメ
自己組織型アジャイルチームにおけるリーダシップ
自己組織型アジャイルチームを実践している組織にもマネージャは必要だ。しかし，マネージャがチームと接する方法が違ってくる。目標達成を目指して努力を続けるチームは，マネージャに仕事のやり方を指示されたり，管理されたりはしない。奉仕型リーダシップ(Servant Leadership)を持ったマネージャによって支えられた彼らは，学習を通じて自らを継続的に向上させるように指導され，方向付けられるのだ。 デジタルマーケティングエージェンシCiplexの創設者であるIlya Pozin氏は，LinkedInにポストした 会社を成長させたい？マネージャを解雇しなさい！ という記事の中で，仕事の質的向上と社員の幸福のために自らが実践したことを説明している。これによって氏の会社は顧客を満足させ，コストを低減し，全体としてよい結果を得ることに成功した。氏が実現したのは，学習と継続的向上をサポートするリーダシッ
アジャイルを学ぶの巻 | いきあたりばったり
アジャイル・・あじゃいる・・agile・・ IT業界に身を置いてると意識せずとも聞こえてくるWord・・ 形容詞なのに、ちまたでは、動詞や名詞として使われがちです・・ そして勤めているSIerではアジャイルは禁止されています。 これまでアジャイルな開発(でも実態はそもそも最初から入札、請負契約というアジャイル風だった…)に手を出しては、もはや顧客の奴隷のようになり、赤字という顛末のPJが多かったからです (｡´Д⊂) ｳﾜｧｧｧﾝ このツイートが身に染みる、そんな状況です。 なのでスキーム変えられないうちは「禁止」という判断は正しい気がします。 最近とても勉強になってるんですが、ウォーターフォールのスキームの一部にアジャイルいれても赤字になるのです、黒字にしたいならスキーム変えないとだめなのよ — Yasuko Ohbaさん (@nay3) 2013年4月25日 でもやっぱり気になっていた
アジャイルの大規模なふりかえりでプロジェクトを改善する
原文(投稿日：2013/04/25)へのリンク ふりかえりは、チームが働き方を学び、改善するのに役立つ。大規模プロジェクトや複数のチームでふりかえりを実施するように、ふりかえりを広められるだろうか? アジャイルコーチたちが、ふりかえりとオープンスペーステクノロジの技術を使って、大規模なふりかえりを実施した。ここで、大規模なふりかえりがどのように実施されたのか見てみよう。 大規模なふりかえりをする方法というブログの投稿の中で、アジャイルとリーンのコーチであるHenrik Kniberg氏が、Spotifyで実施した大規模なふりかえりを紹介している。 ふりかえりの目的は、半年以上、何十ものチームを巻き込んで、大きな組織的な努力から学んだことを見つけ出すことでした。プロジェクト期間中、チームはスプリントのふりかえりをしていましたが、1つの大きなグループになって全体像を見る必要があると感じていまし
アプリケーションの漸進的リリースについて - おともだちティータイム
とりあえずメモ アプリケーションの機能や UI を大きく変更する際、変更後のアプリケーションがどんなに優れていたとしても既存ユーザからは悪い反応しか来ない。 それはそうだ、既存ユーザは "優れた UI" や "画期的な機能" を使いたいのでは無くて、いままで使っていたアプリケーションを明日も変わらず同じ操作で使い続けられることを期待しているからだ。 しかし、今のアプリケーションでは、明らかに良くない UI 、不足した機能、 UX 上の問題がある。開発者としてはアプリケーションを変更する必要を感じている。 では、一体どうやってアプリケーションをリリースすれば良いのだろうか。 当たり前の話なんだけど、少しずつアプリケーションを変更していけば、そういった問題は無くなる。だけど、一般的にはそういうリリースをしているアプリケーションをあまり見掛けない気がする。 そもそも少しずつ変化していくアプリケー
最高の成果を出す「アジャイル＋ウォーターフォール開発」
毎日打ち合わせをすることに抵抗を感じる開発者もいる。では、アジャイルソフトウェア開発を採用している組織はどのようにプロジェクト管理の改善を図っているのだろうか？ かつてITチームは、話はよく聴くが、ユーザーの期待に応えられないとやゆされていた。従来のウォーターフォール開発では、ITチームは長い時間をかけて顧客と擦り合わせをし、プロジェクトの正規の仕様書をまとめ、そこから通常はさらに12カ月かけて、顧客が同意し承認した内容に従って機能を実装する。 注：本記事は、プレミアムコンテンツ「Computer Weekly日本語版 2013年5月15日号」（PDF：無償ダウンロード提供中）に掲載されている記事の抄訳版です。 しかし、12カ月のうちにビジネスの状況は変わり、プロジェクトの仕様がビジネスのニーズに合わなくなることは日常茶飯事。紙やPowerPointスライド上では素晴らしく思えたアイデアは
かんばん方式を実践する
InfoQ: では，変化を受け入れる合意ができたとしましょう。私たちは正しい選択をしたいと思います。それが革新的な変化を伴うのならば，その心構えもします。その一方で，斬新的な変化で大きな改善が望めるのなら，できればそちらを選びたいとも思うでしょう。デリバリや予測可能性，透明性の改善といった観点で，結果を目にしたいのです。 Roock博士: 経験から言えば，かんばん方式を導入するまでは，大きな目標に対する同意が必要です。それはつまり，マネージメントの介入が必要だということです。 あるいは草の根的な "ステルス" アプローチで，マネージメントから隠れて，チーム内だけで事を進めようとする場合もあるでしょう。そのようなアプローチでもある程度は成功できるかも知れませんが，すぐに限界に突き当たってしまいます。企業規模での本当の成功を望むなら，マネージメントの介入は必要なのです。マネージメントと話して，
NTTコミュニケーションズの内製エンジニアは実はわりとアジャイラー - はたらくコンピュータ
2013-02-16 NTTコミュニケーションズの内製エンジニアは実はわりとアジャイラー Redmine Scrum アジャイル Jenkins YARD Sphinx Chef Git Subversion @hamaknがDevSumiで『OSSで作る！クラウドサービス開発戦記』というNTTコミュニケーションズのアジャイル開発事例をしてくれたので、私も同僚としてアジャイル開発現場の紹介をしてみたくなりました。同じ会社の中でもチームが違うと全然何やってるかわからなかったりするので。ちなみに今回の記事は 「DevSumiでも発表してたし、NTTコミュニケーションズのエンジニアって結構アジャイラーなんだ」と思ってもらうこと 社内、NTTグループ内のアジャイラーにBuzzFinderでのアジャイル開発の様子を知ってもらうこと を目標にしています^^ BuzzFinderインキュ開発チームと準ス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://jp.startup-dating.com/2013/04/lean-kaizen-movement-vietnam
Spotifyはどうやってアジャイルをスケールアウトしたか: Henrik Kniberg氏へのインタビュー
アジャイルの再発見： 価値からソリューションへ
SGT2013 技術トークス「アジャイルテスティング」
