Japanese version only. Agile Japn 2012 講演資料Read less
Basic of Basics of Agile Development Returns
Japanese version only. Agile Japn 2012 講演資料Read less
アジャイル開発 基本のキ - ヲトナ.backtrace
今、アジャイルの導入のお手伝いをさせてもらっている現場で「他のスタッフにもアジャイルについてざっくり教えてよ」というオーダーで勉強会をやりました。 そこで「アジャイル開発 基本のキ」と題し、実際の進め方の説明ではなく、その手前の考え方や心構えにフォーカスして話をしました。 20名ほどの人数向けに作った資料なのですが、普段アジャイルについてのイントロダクションの話をする時にいれるキーワードは大体盛り込んだ感じになったので、もしかすると誰かの役に立つかもしれないので公開しておきます。 ただし、勉強会のターゲットがエンジニアではなかったので、エンジニアリングについては薄くなっているのでご注意を。 Basic of Basics of Agile DevelopmentView more presentations from Nishimura Naoto. あと、話は変わりますが、普段アジャイル
これからの「アジャイル」の話をしよう ――今を生き延びるための開発手法とスキル (関西バージョン)
Austin 7 friction damper New discs 16.4 plus 1 turn to 5 turns preloadAdrian Ward
アジャイルチームのアーキテクトのための10の助言
原文(投稿日：2010/09/14)へのリンク Microsoft AustraliaのソリューションアーキテクトであるTom Hollander氏は、TechEd Australiaでアジャイルチームにおけるアーキテクトの役割と題したプレゼンを行った。 氏はこの場でアジャイルチームを率いるアーキテクトとして氏が行っていることについて議論した。 アーキテクトの役割について話すとき、氏が指すのは“ソリューションアーキテクト’、つまりアプリケーションのアーキテクトだ。エンタープライズアーキテクトやある種の専門家(例えばメッセージングやインフラなどの専門家)を指してはいない。 氏のチームは、最後に2、3日のコード凍結を行う、安定した4週間のイテレーションプロセスで、毎日のスタンドアップミーティングや毎日のビルドと自動テストが伴う継続的統合を実践している。氏のチームでは次のような役割を採用している
アジャイル開発の現在・過去・未来
9月4日土曜日に、有志によるアジャイル開発のイベント「XP祭り2010」が早稲田大学西早稲田キャンパスで開催されました。イベントは200名以上の参加者が集まる盛況となり、アジャイル開発への注目の高さをうかがわせました。 基調講演では、「アジャイル開発の現在・過去・未来」というタイトルで、アジャイルの第一人者であるチェンジビジョン代表取締役社長の平鍋健児氏が登場。タイトル通り、アジャイル開発の全体と最新動向を俯瞰する、アジャイル開発のイベントでしか聞けない充実した内容となっています。 この記事では、その基調講演の内容を紹介しましょう。 なぜアジャイルが注目されるようになったのか なぜいまアジャイルが注目されるようになったのか？ 何かのビジネスを行う際には、企業が市場を分析して、企画を立て、IT関連のシステムを発注する、といったことが行われる。すると、ITが「仕様通りにできました」と納品してく
Agile2010 Day One - masayang's diary
本日はワークショップやチュートリアル中心の日。コマ数が多い中、Organization & Enterprisesを「持続可能な範囲で*1」聞いてきた。 目次 How Agile Taught IBM about New Leadership Competencies Agility@Scale - Experiences from the Trenches at IBM Rational Beyond Scope, Schedule, and Cost: Optimizing Value How Agile Taught IBM about New Leadership Competencies 現在はPitney Bowes社の国際技術担当副社長をのSue McKinney女史による「大企業のAgile化に求められる指導者の資質」に関する発表。彼女は去年まではIBMにて「世界各支社のI
楽天で角谷さんのお話を聞いた - 未来のいつか/hyoshiokの日記
解読アジャイルソフトウェア開発というタイトルでお話をしていただいた。*1 アジャイル開発の本質を角谷節で1時間あまり独演会してもらった。 Demystifying Agile Software DevelopmentView more presentations from Eiwa System Management, Inc. . ともかく映像を観てほしい。約1時間ちょっと、そしてその後に続く質疑応答も一緒に。 ソフトウェア開発における受託開発という立場ではない、もう一つのソフトウェア開発の現場が、自分のサービスを自分で作るという立場だ。 受託開発の場合はユーザー企業（発注する側）と開発する企業（受託する側）とがあって、時として敵対関係に陥る。一方の利益が他方の損というゼロサムゲームである。 自社開発の場合は、社内にユーザ部門と開発部門があったとしても、最終的にはユーザ部門の利益と開発部
日記/2010/03/07/「銀の弾丸」が無くても狼男を倒せる世界へ - Glamenv-Septzen.net
id: 608 所有者: msakamoto-sf 作成日: 2010-03-07 21:39:39 カテゴリ: システム開発 プログラミング TDDに対してのスタンスを自分の中ではっきりさせたい為、前から気になっていた書籍を読み込んでみた。 プログラマーのジレンマ 夢と現実の狭間 闘うプログラマー[新装版] ビル・ゲイツの野望を担った男達 Head Firstソフトウェア開発 ―頭とからだで覚えるソフトウェア開発の基本 アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ TDDやアジャイルに対してのスタンスが、ようやく自分の中で焦点を結んだ。 「現場でTDDを使おう/XPで行こうと言われたら、そう願う人達の静かな味方になる。」 それが、自分なりの結論だ。 アジャイル/TDD
実験駆動開発 - ポストアジャイルの手法
原文(投稿日：2010/02/25)へのリンク TDDとBDDは今や、広く使われているソフトウエア開発技術だ。しかし、単にBDDやTDDに従っているだけではビジネス機会を逸したり、もっと悪いときにはビジネスに悪影響を及ぼしてしまう。TDDとBDDには解決できないふたつの問題がある。すなわち、どのようにして開発したアプリケーションの使用を評価するのか。そして、どうやって顧客からフィードバックを得るか。 ユーザを調査する従来の方法は決して正確な結果にはならない。アプリケーションの提供者も顧客も多大な時間を必要とし、先入観にとらわれてしまう。Nathaniel Talbott氏はRubyConf 2009でのプレゼンテーションで次のような考えを発表した。すなわち、開発時におけるTDDと同じような方法でビジネスもフィードバックを得るべきだ、という考えだ。 (画像はLabnotesから) ソフトウエ
Re: アジャイルって受託開発との相性が最悪な気がする - tsuge development page
前書き 現役アジャイラー（？）を自称する立場として釣られてみるぜっ。 http://d.hatena.ne.jp/gothedistance/20100212/1265907956 「アジャイル」について 多分id:gothedistanceもわかっていると思うんですが、アジャイルはマニフェストなんであって具体的な手法ではないです。 代表的なアジャイルとしてeXtreme Programmingモデルを例にとると、イテレーションプランニングって項目があります。 簡単に言うと開発側は2週間ごとに形にしよう、顧客は次の2週間でほしい機能を決めようってやつ。 XPは改訂が多すぎてこの手の文書の参考にしにくいんですが、細かい事はこの辺見てください。 http://www.objectclub.jp/community/XP-jp/xp_relate/whatisxp-j/ 今回の記事による「アジャ
recompile.net:アジャイルソフトウェア開発と人月商売
February 12, 2010 アジャイルソフトウェア開発と人月商売 アジャイル開発では、人月商売をやらざるをえない。これは、大部分のプライムコントラクタと呼ばれるSIerにとって受け入れ難い選択肢だ。もし、アジャイル開発を導入したいのなら、まず契約について考えるべきだ。 業務委託契約には、請負契約と準委任契約という2つの形態がある。請負契約は、仕事の完成を約束し、それに対して対価を受け取る契約である。準委任契約は、善良な管理者の注意をもって委任された事務の処理を行なう契約である。 アジャイル開発は、開発中のスコープ変更を許容する。つまり、事前にどのような仕事を完成させるかということを決めることができない。そうすると、どのような仕事を完成させるか決める請負契約は結べないことになる。これは当然のことだ。 では、準委任契約にすれば良いかというと、そうそう単純な話ではない。受注者側、発注者側
「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey
日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海
Agileでやってるけどデスマったｗ
Agileでデスマになったのでそのログです。 この後同じことを繰り返すと馬鹿なので、まだデスマ中だけど、問題点と反省点を書いておこうと思う。 こういうのは渦中にやっておかないと終わった後だと「大変だけど終わって良かったね」で終わってしまいがちなんだよね。 これを読まれている方は反面教師にしてください。 契約と総生産量の関係性 期間と費用が決まっている場合、総生産量には当然上限がある。生産量はチームのベロシティが分かっていれば、ストーリーポイントに換算できるので、開発開始時点で、総生産可能ストーリーポイントについては明示すべきだった。土日出て頑張れ！とか残業して頑張れ！とかいうのはAgileを知らない証拠。 上記に関連して、プロダクトバックログにストーリーを追加することが出来るのは、プロダクトオーナーの権利なのだけれども、優先度高としてストーリーを追加したところで、バーター可能なストーリーが
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
アジャイルは二度死ぬ(Agile Only Live Twice)その１：トム・デマルコ氏の蹉跌とその誤謬 | AnyProjecTa! プロジェクト・マネジメントに関する情報ポータル
Home » headline, プロジェクト・マネジメントを考える。 アジャイルは二度死ぬ(Agile Only Live Twice)その１：トム・デマルコ氏の蹉跌とその誤謬 アジャイルの隆盛 WEBの世界の中で、日々ITに関する情報を集めていると、アジャイル開発がシステム開発の完全なる主流になった気になってしまいます。偏った情報収集をしているせいだ、といわれればそれまでですが、WEB/ベンチャー業界・SIer業界・企業IT部門/IT子会社界・オープンソース界全てを通じて、Blogなどで声の大きい方々は多かれ少なかれ『アジャイル』という考えに肩入れしているように感じられます。 当然、世の中の流れが全てそうなっているかというと、そういうわけでは無さそうです。WEB/ベンチャー業界や、オープンソース界では、ほぼメインストリームとなっていると思いますが、SIer業界・企業IT部門/IT子会
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
アジャイル開発のためのプロジェクト管理·Agilo MOONGIFT
アジャイル開発にとって重要なのは、スクラムを組み、一気通貫で開発してしまう勢いだ。手間のかかるタスクの登録やステータスの更新その他諸々の面倒ごとをやっていたら時間はあっと言う間に過ぎ去ってしまう。 タイムライン 例えばTracは素晴らしいプロジェクト管理だが、少々画面が素っ気ない。そこでもっと便利に使えるAgiloを紹介しよう。 今回紹介するオープンソース・ソフトウェアはAgilo、アジャイル開発を進めるためのプロジェクト管理だ。 Agiloはアジャイル開発を基本としたプロジェクト管理だ。VMWareのアピアランスも提供されているので、すぐに試すことができる。また、Tracのプラグインとしても提供されている。Wiki、タイムライン、ロードマップ、チケット、検索といった一般向けの機能に加え、チーム管理、グラフといった管理機能がある。 グラフ 何よりインタフェースがボタンを中心になっている。こ
XPJUG24thに参加してきた
日本XPユーザーグループ主催の「第24回XPJUGユーザ会『アジャイルな見積りと計画づくり』」に参加した。 実はこの日は嫁の誕生日だったりしたんだけど、ウチの嫁なら誕生日を優先してこういったイベントに参加しない方がDISってくるに違いない、そういう嫁だし！と勝手に解釈して誕生日の方は華麗にスルーした。 勤務先（3月末で退社するけど）が芝浦だから歩いて30分はかからないし、19時なら5分前には余裕だなーとか考えていたら、18:45集合となっていて焦った。タクる事にしたが、海岸通りは通りの大きさと比べると意外にタクシーの流通量が少なく、結局ギリで間に合うカンジだった。到着した後はビルの入り方がわからず「どうやって入ろう？どこが集合場所なんだ？」とか思っているとウマイ具合にこんぴろさんと出くわして、結局ギリギリだった。集合して受付した後はスタッフの方に誘導していただいて、会場に入ったんだが、目に
Mountain Goat Software | Planning Poker Cards
Mountain Goat Software offers Planning Poker® cards for your use in estimating. Each deck contains enough cards for four estimators to each hold cards with the following values: ?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and ∞. The cards are printed on the finest quality card stock available. Each deck comes in a box to help keep the cards from being damaged.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
理想的なイテレーション期間
