Agile Studio プロデューサー の木下です。弊社の研修である「アジャイル開発の基礎知識」を動画で一挙 22本、公開しました。アジャイル動画のサイトでご覧になれます(以下のURLをクリック)。...
2014年3月の発表資料 2014年7月の資料 => http://www.slideshare.net/hiroosak/ca-36830962
みなさんこんにちは。@ryuzeeです。 2013年1月15日、16日にScrum Alliance Regional Gathering Tokyo 2013が開催されました。 まずは実行委員として、ご来場頂いた参加者の皆様、登壇者の皆様、スポンサー各社様、様々なコミュニティの皆様、ほかご協力いただいた全ての方に感謝したいと思います。ありがとうございました。 僕は1日目の達人に聞けのセッション、2日目のScrum The Next Generationに登壇させていただきましたが、2日目の資料について以下で公開しておきます。 大胆不敵にも本イベントの実行委員長(僕らはプロダクトオーナーというロールにしています)が基調講演の裏で、とんがったセッションをやりたい、ということでこのセッションは企画されました。 したがって僕のスライドも結構過激になっています。 単に字面だけみて誤解をしないように
Accessibility View text version Categories Technology Upload Details Uploaded via SlideShare as Adobe PDF Usage Rights © All Rights Reserved Statistics Favorites 0 Downloads 0 Comments 0 Embed Views 0 Views on SlideShare 0 Total Views 0 アジャイルに対する見方の変化 — Presentation Transcript アジャイルに対する見方の変化- ソーシャルゲーム開発を経験して- 2012/11/17 太田健一郎 @oota_ken 目次 SIerの時のアジャイル感 アジャイルマニフェストの解釈 XPのプラクティスの解釈 自分がアジャイルだと
どうもこんにちは。 Aiming で東京開発グループのゼネラルマネージャをやっている小林です。 8月に mobage と Yahoo! モバゲー で ロードオブナイツ というシミュレーション RPG をリリースさせて頂きました。 そして、先週、 Yahoo! モバゲー版の PC ブラウザ専用デザインをリリースさせて頂きました。 今回リリースしたものは元々 Unity で作られていた iOS アプリ版 Lord of Knights を HTML5 で書きなおしたものです。 (今は Android 版 もあります) HTML のポチポチゲーをネイティブに移植したというのはよく聞く話ですね。 ですが、逆にリッチなネイティブアプリを HTML5 に移植し、かつスマフォブラウザと PC ブラウザで同じものを動かすなんてのは前例が見当たりませんでした。 技術的ハードルが高かったことに加えて期日がタイ
隣席のるびりすと氏(@hsbt)と僕とで、この半月ほど、東京・福岡で合計3回にわたって勉強会ツアーをやっていました(その他のこともたくさんやっていたので、それだけではもちろんないのですが)。今日でそれもひと通り終わったので、どのようなことをやっていたのかについて、ここで公開したいと思います。 我々の話はどの回も以下の順番で行われており、いわば三題噺みたいな構成となってます。 リーンスタートアップ インセプションデッキ Scrum それは、我々が議論している模様を撮った以下に掲げた写真に見られるように、開発プロセスというものが階層的な構造を持っているからです。 www.instagram.com ここでは、その最初の話「開発者のためのリーン・スタートアップ」および「リーン・キャンバス入門」のスライドを紹介します。 開発者のためのリーン・スタートアップ 僕は技術者です。また、技術者としてさらな
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための3つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
デブサミが 10 周年でした。 残念ながらオファーなかったのですが、一昨日くらいに急に参加していいよって言われたので 「From Legacy to Agile 〜レガシー開発からアジャイル開発へ〜」に乱入してきました。 そこでチームビルディング的な話を話させてもらいました。 資料とか特に作っていなかったので僕がリーダーとしてチームメンバーにお願いしている決まり的なことを簡単にまとめておこうと思います。 テストを書け 問題を根性で解決するな 人を殺す以外なら何やってもいい 失敗を引きずるな 個別に補足書いて行きます。 一応状況の簡単な説明をしておくと、最初は 3 人しかいないチームに 「手伝ってくれないか?」と言われ合流しました。その後、僕がリーダーになり 今は 15 人前後のチームで動いています。 テストを書け これは僕がチームに入るときに最初に宣言しました。 「テストを書かないようなプ
第二回 shinagawa.redmine勉強会で「数千人が利用する楽天Redmineの過去と未来」を発表させていただきました。資料はSlideShare、SpeakerDeckで公開しております。QAの時間が取れなかったため、質問などがあればTwitterでもなんでもご連絡ください。 数千人が利用するRedmine 来月、第3回RxTstudyでもRedmine事例の発表させていただくのですが、品川Redmineはシステム視点、RxTstudyではタスクマネジメント視点で資料を作りました。 はじまりは、使われてないサーバ上に作った仮想VMを使っていました。ユーザ数も少なかったので、WEBRickを利用し、ポートを分けることで複数Redmineを構築していました。WEBRickが固まることがあったので、cronで一日一回夜間に再起動して運用していました。 自分のグループで使ってみようという
11/19 に開催された楽天テクノロジーカンファレンスで上記のタイトルで講演させていただきました。 当日の資料を公開しておきます。 How to not fail at adapting agile software delopment View more presentations from Nishimura Naoto 今回は、僕があちこちでお手伝いしているアジャイルの導入で気をつけている事ややり方などを中心にお話ししました。 もちろん、このやり方だけが正解では無いですし、みなさんなりの導入の仕方のヒントになれば幸いです。 そして、参加していただいた皆さん、サポートしてくださったスタッフの皆さん、本当にありがとうございました。 また、一緒に土壌作りとかお手伝いしてよって方がいましたら、お気軽にご連絡下さいww
アジャイル開発に関する論客の一人マーチン・ファウラー氏は、7月20日にテクノロジックアートが主催したイベント「Agile Conference tokyo 2011」で「21世紀のソフトウェアデザイン」をテーマに基調講演を行いました。 ファウラー氏の基調講演の様子を紹介しましょう。 アジャイル開発の意味が希薄化している ThoughtWorksのマーチン・ファウラー氏。 アジャイルソフトウェア開発宣言から10年がたち、そのあいだいろんな人が伝えていくうちに当初の意味の希薄化(Semantic Diffusion)が起きてしまったと思う。私の役割は、最初の意味を思い出してもらうことだ。 要件の安定性に依存するのは不健全だ まずは「予想的な計画(Predictive Plannning)」と「適応的な計画(Adaptive Plannning)」について。 土木や建築に由来するのが「計画駆動開
7/2 に開催されたデブサミ東北で、上記のタイトルでワークショップをやりました。 ワークショップなので、資料だけではうまく伝わりにくいと思いますが、当日の資料を公開します。 Agile Estimating in Your Drawing Paper View more presentations from Nishimura Naoto 今回は「アジャイルな見積り」を題材にして、アジャイル開発は特別な魔法のようなものではなく、誰でも身近なもので明日からでも始めるものである事をワークショップ形式で参加者と一緒に考えてみました。 また、明日からなるべく不安なく実践できるように、アジャイルな見積りについて丁寧に解説してみました。 見積りは一言で解説するのがなかなか難しいので、本来は見積りは計画と密接に関係するのですが、今回は計画については一切触れませんでしたww そして、見積りとは何かと見積り
10 Tips for Agile Adoption in the Enterprise | Agile Scout より。 英語力は地を這っている人なので、中身についてはあまり信用しないように。 1. マネジメント層を取り込め 彼らを引き込まないと、ウォーターフォール向きのレポートに変換する作業がついて回る。 2. 全リリースの計画をしろ、1スプリントだけじゃない ストーリーポイントで見積もり、ベロシティを予測し、スプリント計画を立てよう。 でも、最初に立てた計画にガチガチに縛られないよう注意。 3. スプリントを計画しろ、特別、共有なリソースのことを念頭において 遠い未来の計画に縛られる必要はないけれど、計画は立てよう。 4. 複雑な内部の依存関係は現実に起こる、それに対処せよ リリース計画でモジュールやコンポーネントの依存関係を特定しておこう。スプリントゼロってやつ。 スプリントゼロ
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
今、アジャイルの導入のお手伝いをさせてもらっている現場で「他のスタッフにもアジャイルについてざっくり教えてよ」というオーダーで勉強会をやりました。 そこで「アジャイル開発 基本のキ」と題し、実際の進め方の説明ではなく、その手前の考え方や心構えにフォーカスして話をしました。 20名ほどの人数向けに作った資料なのですが、普段アジャイルについてのイントロダクションの話をする時にいれるキーワードは大体盛り込んだ感じになったので、もしかすると誰かの役に立つかもしれないので公開しておきます。 ただし、勉強会のターゲットがエンジニアではなかったので、エンジニアリングについては薄くなっているのでご注意を。 Basic of Basics of Agile DevelopmentView more presentations from Nishimura Naoto. あと、話は変わりますが、普段アジャイル
Rubykaigi2010参加して本当に良かった。運営の皆様、スポンサーの皆様、参加してくださった皆様、Rubyを普段から支えてくださっている皆様。本当に有難う御座います。私もRubyに大変お世話になっていますので、少しでも私に出来ることはないかと思い、個人スポンサーとなって参加させて頂きました。そしてこのブログを残します。 本当のアジャイル 私がRubyKaigi2010に参加して一番痛感したことは、「今までの私はアジャイルをやっていなかったこと。むしろウォーターフォールに近いことをやっていた」と思い知らされたことです。 ウォーターフォールを御存知ですか?半年や1年の開発見積りを行い、それに従って開発を進めるが、見積りが合わなくなり(大抵は見積が足りない)、しかし見積は変えず、デスマーチと呼ばれる慢性的な長時間残業を行うようになり、自分への投資(技術の学習等)を行う時間を犠牲にする開発体
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く