アジャイル開発でツールを導入する5つのステップ
みなさんこんにちは。@ryuzeeです。 アジャイルな開発で利用できるツールはたくさんありますが、その導入の仕方について賛同できる記事があったので意訳にてご紹介します。 なおターゲットのチームはco-locateしたチームです。 元記事はMarc Löffler氏の5 Steps to Introduce an Agile Toolになります。 世の中にはかなりたくさんのアジャイル開発用のツールが出回っている。マイク・コーン氏のWebサイトにそれらのツールの長〜いリストがあるので見てみると良いだろう。しかし、こういうツールを自分のチームや会社に導入するには、どういう方法を取れば良いのだろうか？以下にまとめてみた。 1. 最初はツールなしで始めるツールを持ったバカはやっぱりバカだｗ。とても洗練されているアジャイル用のツールを導入する前に、まずScrumやXPやKanbanやその他のメソッドが
翻訳 アジャイル関連書籍ベスト100(2011年度版)
NOOP.NLというサイトで、今年もTop 100 Agile Books (Edition 2011)ということでアジャイル関連書籍のトップ100のリストが出ていたので、日本語訳されている本のリンクを追加してみました。 大きなトピックスとしては、日本でも勉強会が同時に多数開催されるなどアジャイルに関心がある人達の間で大きなムーブメントを起こしているアジャイルサムライがいきなり9位に登場していることだと思います。 一方で昨年から邦訳された本がアジャイルサムライ以外に増えていないところは悲しいところではありますが、現在いくつかの書籍について翻訳されている方がいらっしゃるので出版に期待です。 2010年度版はこちら The Art of Unit Testing: With Examples in .Net 前年度：5位 Roy Osherove 2009 Agile Estimating a
Google Sites: Sign-in
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
継続的デリバリーの8つの原則
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 継続的デリバリーの8つの原則1. ソフトウェアのリリースやデプロイのプロセスは繰り返し可能であり信頼性が高い必要がある。このことは2つめの原則にたどり着く。 2. 全てを自動化する！手動のデプロイは決して繰り返し可能で信頼性が高いことには成り得ない。 あなたは繰り返し行う全てのタスクを自動化することについて本気で投資する必要がある。そしてこうすることによって信頼性に繋がっていくのだ。 3. なにか難しかったり苦痛なことがあったら、それを何度もやってみる表面的には、ばかげた話のように聞こえるかもしれない。しかし基本的にこれが意味していることは、苦痛であることを頻繁に行うことは、あなたがそれを改善し、多分自動化する方向に導いてく
良本「アジャイルサムライ」チームで何かを作っている人、アジャイル入門書としては最適！ - 楽園追憶
『アジャイルサムライ〜達人開発者への道』読んだ感想です。 アジャイルサムライ−達人開発者への道− 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未出版社/メーカー: オーム社発売日: 2011/07/16メディア: 単行本（ソフトカバー）購入: 42人 クリック: 1,991回この商品を含むブログ (254件) を見る アジャイルの最適な入門書 とてもいい本でした。 アジャイルをまったくしらない人の入門書としても丁寧に説明があるので分かりやすいし、アジャイル初心者（少しは知ってるけどあまり実践してない）にも、分かりやすい例えや手法が説明されていてよかったです。 正直、物作りの現場って、あまりにも帰納的・経験則なチーム運営、マネジメントが多すぎる… もちろんそれはそれでいいところもあり、その現場に即した手法が発達することもままあって、日本人の職人的思考に
アジャイルな開発を始めたばかりの時、最初に乗り越えるもの - Change The Worlds
はじまり アジャイルな開発を始めたばかりの時、最初に乗り越えるもの@ryuzeeさんが仰る様に、今までのアジャイルではない開発のやり方からアジャイルな開発に変えると、今までの開発のやり方よりアジャイルな開発のやり方の方が作れる物の量が減ります。 例えば、『アジャイルな開発を始めたばかりの時、最初に乗り越えるもの』をいつものやり方として、左から右へ『ア・ジ・ャ・イ・ル…』と書いていくのと、昔の日本の様に右から左へ『アジャイル…』と書いていくのでは日頃書き慣れていない右から左へ書いていく方が書くのが遅くなると思います。 この理由は単純で、慣れ親しんだやり方と慣れ親しんでいないやり方では経験による作業の熟練度に差があるので、出来る量が減ってしまうのです。 何が違うのか？では何故私の開発チームは増えたかと言うと、アジャイルなやり方にする際に以下に気をつけているからです。 一気に変えない チームみん
「アジャイルサムライ−達人開発者への道−」の出版おめでとうございます！ #agilesamurai - Natural Software
アジャイルサムライ−達人開発者への道− 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未出版社/メーカー: オーム社発売日: 2011/07/16メディア: 単行本（ソフトカバー）購入: 42人 クリック: 1,991回この商品を含むブログ (253件) を見る@nawoto さんにレビューのお声がけをいただいた縁で、オーム社さまより献本いただきました。 読者の声でも書いて、昨日もツイートして、しつこいですが。。。 この本はアジャイルと名前がついていますが、ソフトウェア開発に携わる人（開発者、テスター、マネージャetc...）すべてに読んでもらいたい一冊です。 もちろん、ソフトウェア開発を始めたばかりの学生さんにもオススメです。第一線のソフトウェアエンジニアがどのようにソフトウェア開発をしているのかを知ることは、自分の能力を短期間に向上させることや、ソ
効果的なデイリースクラムのやり方に関するTips10個
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） ミーティングの前にタスクのステータスと残り時間を更新すること。これによってチームがどんな状況にあるかに関する最新のスナップショットを持っていることを保証する。ミーティング中に、ボードの更新に時間を使うべきではない 前回のミーティングから変わった点についてしゃべれるように準備しておくこと。チームにとって価値がある共有すべき情報は何なのか？について考えること。すなわちあなたが完了したことについて事細かにしゃべる必要はないということだ。他の人が聞く必要のある情報か、あなたがチームの助けを必要としている情報についてだけで良い 事実を提供することに集中することで話す内容を制限し、会話を簡潔に保ちなさい。ポイントは全員から聞くことだ。
アジャイルサムライ #agilesamurai - こくぼ＠Everything is the experience.
アジャイルサムライ−達人開発者への道− 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未出版社/メーカー: オーム社発売日: 2011/07/16メディア: 単行本（ソフトカバー）購入: 42人 クリック: 1,991回この商品を含むブログ (257件) を見る レビュアーとして 僭越ながらレビュアーの一人として参加させて頂きました。錚々たる面々の中で自分ができることをしたつもりです。 レビュアーを選ぶときに、それぞれの切り口を期待してレビュアーを選考されていたみたいですが、自分がどういう役割で選ばれたのかは謎のままでした。 内容について 監訳者・レビュアーの方々含めて多数の記事が上がっているのでそちらを参考にされた方が適切かもですが。内容としてはアジャイルなソフトウェア開発の概要から実践的な例までコンパクトに解説しています。 「アジャイルってなに？」
ペアプログラミングについてみんなが誤解していること | Act as Professional
プログラマ1人で完成できる仕事に、2人のプログラマを投入して、直感的に判断してペアプログラミングを拒否する人がいます。これには大きな間違いとリスクが潜んでいます。ペアプログラミングに対する真実を理解しましょう。 ペアプログラミングはコードを書く時間が15％増える 1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15％多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか？ 将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約できることになるのです。したがって、ペアプログラミングは寿命の長いソフトウェアほ
新しい契約形態での受託開発サービス「価値創造契約」での第1弾システムが無事稼働し始めました - Ruby x Agile
木下です。 昨年11月のニュースリリース以来、大きな反響をいただいている価値創造契約ですが、その第1弾として、首都圏を中心に理科実験教室を展開されているサイエンス倶楽部様の基幹システム開発を受託し、今年の1月より開発を行っていることはAgile Japan 2011のセッションでもご報告していた通りです。 その後、予定していた通り、今年の6月よりこのシステムは稼働を開始しています。サイエンス倶楽部様にはここ1ヶ月間、システムを使っていただいていますが、大きなトラブルがないのは言うまでもなく、現場のユーザーの方からも高いご評価をいただいています。 6月末にサイエンス倶楽部様と私たちの開発メンバーでふりかえりを行いました。ふりかえりの中でも多くのフィードバックや気づきを得ることができました。今回の開発については新しい契約形態でRubyを使ってアジャイルに開発した事例として、追々みなさまにも公表
テクノロジー : 日経電子版
レンズの口径が3.8メートルと国内では最大となる光学赤外線望遠鏡が、岡山県浅口市に完成した。将来の望遠鏡のために新しい技術を満載し、大きな割に機動的に動かせられる。宇宙で突発的に起…続き 銀河誕生の謎探れ 130億光年見通す望遠鏡の仕組み ［有料会員限定］ ケプラー宇宙望遠鏡が引退 太陽系外惑星を多数発見
人材育成、講師の視点から（3）：システム開発に関わる人をイキイキさせるヒント：エンジニアライフ
（株）永和システムマネジメント コンサルティングセンターが、システム開発に関わる人をイキイキさせる情報をお届けします。 こんにちは、天野勝です。 わたしは、コンサルタントという職業柄、人にものを教える「講師」という仕事をすることが多いです。現場カイゼンの導入教育や、C言語でのテスト駆動開発と、かなり多岐に渡っています。 この連載では「講師」をしていて気づいたことをわたしの視点で発信していきます。 ■アジャイル開発は特別か？ XPが書籍として紹介されてから約10年が経ち、アジャイル開発が広く適用されるようになってきました。おかげで、アジャイル開発について教えて欲しいとセミナーの依頼も増えてきています。 そこで出る質問にある一定の傾向があります。アジャイル開発は特別なのかという類の質問です。 XPアンギャ[*1]をはじめ10年近くアジャイル開発に関連するセミナーを行っているわたしの感覚では、そ
AgileScout - 大規模開発にアジャイルを適用する際の10のTIPS - うっかりアジャイルの推進側に回っちゃった人の日記
10 Tips for Agile Adoption in the Enterprise | Agile Scout より。 英語力は地を這っている人なので、中身についてはあまり信用しないように。 1. マネジメント層を取り込め 彼らを引き込まないと、ウォーターフォール向きのレポートに変換する作業がついて回る。 2. 全リリースの計画をしろ、1スプリントだけじゃない ストーリーポイントで見積もり、ベロシティを予測し、スプリント計画を立てよう。 でも、最初に立てた計画にガチガチに縛られないよう注意。 3. スプリントを計画しろ、特別、共有なリソースのことを念頭において 遠い未来の計画に縛られる必要はないけれど、計画は立てよう。 4. 複雑な内部の依存関係は現実に起こる、それに対処せよ リリース計画でモジュールやコンポーネントの依存関係を特定しておこう。スプリントゼロってやつ。 スプリントゼロ
チケット駆動開発について思うこと - Natural Software
先日、ふとこんなことを思い、つぶやいたところ、さかばさんが拾ってくれて、いろいろ話しをしました。 チケット駆動開発(TiDD)について思うこと - Togetterまとめ 話の続き 本来のチケット駆動開発(TiDD)とは何なのか？ - Togetterまとめ チケット駆動開発は、そろそろScrum+XPと合流してもいいと思うんだけどなぁ 2011-05-12 11:59:25 via Echofon 僕自身は純粋なアジャイル開発や、チケット駆動開発をしているわけではないのですが、いろいろ思うところがあって、こういう発言をした次第です。 あと、チケット駆動開発自体を否定しているわけではなく、自分自身も(チケット駆動と明示してませんが)同じようなことをやっていて、良さを実感しているので、そのあたり誤解しないでもらえるとうれしいです。 思うところというのは、チケット駆動開発が開発サイクルをもち、
Agile Charity Event in Osaka に参加 - 桜、抹茶、白、日記
d:id:youandi:20101030#p1 軽く興味があった程度でしたがお誘いを受けたので、参加してきました。 ThoughtWorks主催 Agile Charity Event in Osaka http://www.tech-arts.co.jp/news-and-topics/events/2011/Charity2011.html 日時：2011年4月29日(金) 11:00〜16:30 場所：大阪市立会館 鶴見区民センター(大阪市営地下鉄 長堀鶴見緑地線 横堤駅) 参加費：無料 公式Twitterタグ：#ace_osaka 会場で[twitter:@nakaji]さんと合流したら、会うなりいきなり「丁度良かった。お金貸して！」とか言われました。 オープニング 参加者は50名ちょっとだった模様。 今回のイベントの目玉と思われていたケント・ベックさん関係については、ケント・ベ
カンバンを導入する正しい理由5個
みなさんこんにちは。@ryuzeeです。 前回の投稿の続きです。 今度はMichael Dubakov氏が5 Right Reasons to Apply Kanbanということで、正しい導入理由5個について説明していますので、抜粋・意訳にてご紹介します。 カンバンを導入する正しい理由5個 1. いつでもリリースできるようにするスクラムやXPではイテレーションの途中でリリースすることはできない。 カンバンであればいつでもリリースできるかもしれない。 ユーザーストーリーの準備ができたたら、それをリリースする。 このような開発プロセスを作ることは挑戦的だろう。 このような開発プロセスでは、フィーチャー単位でソースコードレポジトリのブランチを管理し、頻繁にマージや結合やテストを行う必要がある。 ただこうすることで頻繁にリリースすることができるようになるのだ。 これはやってみる価値がある。 プロダ
カンバンを導入する間違った理由5個
みなさんこんにちは。@ryuzeeです。 ちょっと古い記事ですが、TargetProcessのサイトMichael Dubakov氏による5 Wrong Reasons To Apply Kanbanという良い記事があったので、抜粋・意訳にてご紹介します。 5つの間違い1.ユーザーストーリーの多様性我々のストーリーは1ポイントから40ポイントまでさまざまなので、大きいストーリーがスプリントに入らない。なのでカンバンを使う 2.スプリントがうまくいかない1スプリントの中でほとんどのストーリーが完成しない。なのでカンバンを使う 3.ふりかえりミーティングがうまくいかないふりかえりミーティングが無駄になっている。チームメンバーはプロセスの改善に協力してくれず、ミーティング自体をなくしたい。なのでカンバンを使う 4. 人的リソースの共有と機能別組織開発チームが１つで、プロジェクト間でメンバーを共有
「アジャイル開発の基本的な流れ」 - ヲトナ.backtrace
先日、アジャイル開発にはじめて取り組む現場向けのプチ講習をやりました。 アジャイル開発の一連の流れとそれぞれやる事をお話しして、これから自分達が何をやっていくのかを把握してもらおうというのが目的でした。 その後、実際にスプリントを始められるように準備をしましょうというところまでやりました。 その時に使った資料を公開しておきます。 実際の現場でやる時は口頭で解説つけたり詳細な部分は実際にやる際に説明したりするので、資料的には一連の流れとそれぞれがやる事をダーっと説明している内容なのですが、ちょっとしたチートシートみたいな感じには使える気がします。 The Basic Flow of Agile Development あと、今回はいつも資料の公開用に使っている slideshare が調子が悪いので Scribd を使ってみました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Y.M | 株式会社ラグザイア
