意思決定の正しいタイミングRustが再評価される：エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...
はじめてのアジャイル
Agile Japan 2010のチュートリアルセッションで使った資料。 前半を平鍋さん、後半を倉貫が話しました。Read less
アジャイル開発とは：「アジャイル開発」をエグゼクティブサマリにまとめてみた | Social Change!
アジャイル開発を開発者以外にも２ページ程度のサマリで説明するというのに挑戦してみました。なるべくアジャイル開発の文脈で使われる言葉（適応型とか）を使わないようにしてみたのと、従事する人でなく決定権を持つ人向けに中身よりも得られる価値などを中心に記述しました。（記事の最後でPDFを皆さんの会社でも使えるようクリエイティブコモンズで公開してます。） アジャイル開発に関するサマリ アジャイル開発（アジャイルソフトウェア開発）とは、ソフトウェア開発における開発手法の総称です。その特徴は、日々変化するビジネスや市場環境に応じて、作るべきソフトウェアも変化させていくことが出来る点です。 アジャイル開発におけるゴールと狙いは、IT投資に対するソフトウェアから得られる価値を最大化することです。コストパフォーマンスの最大化であり、ただソフトウェアを作ることだけが目的ではありません。 １．誕生の経緯と求められ
ビジネス加速のためのアジャイル入門
個人から始める変化〜 IKIGAIマップ、マルチ・ポテンシャライト、ザ・メンタルモデルを入口にして〜(公開変更版）Takeshi Kakeda
#devsumi 2012 From Legacy to Agile ～レガシー開発からアジャイル開発へ～ メモ
#devsumi 2012 From Legacy to Agile ～レガシー開発からアジャイル開発へ～ メモ 野口さん 塩谷さん レガシー開発からアジャイル開発へ 移行するのに障害があるはず。それをどのように乗り越えていくか。またキャリアデザインなど アジェンダ 3周回った俺達のアジャイル レガシーの現実 レガシーからアジャイルへ クロージング 3周回った俺達のアジャイル 塩谷さん dwango の中の人。1月からドワンゴモバイル。 このセッションについて 去年の9月にXP祭りで喋ってきた内容の再演みたいなもの もう少し時間をかけて、大勢の前で喋りたいと思った カオスなゲーム開発からSI式ウォーターフォール(略)アジャイルという草原にやってきました 一昨年のdevsumiで、 @yoshiori さんの3周遅れのXP → ベストスピーカー賞 その時はまさか同じ会社で働くことになるかとは
スクラムの原典を読み解く(1)：An Agile Way：オルタナティブ・ブログ
連載で、スクラムの元になった"The New New Product Development Game"を再び読み、そこから得られるアイディアと、現在のアジャイルにおけるスクラム、を対比させて解説しよう、という試みをはじめます！ 第一回目。 竹内弘高・野中郁次郎の論文「The New New Product Development Games」 (1986年)は、日本で行われている「新製品開発のプロセス」をNASA等の米国型のそれと比較して論じたものだ（図）。 この論文では、Type Aを米国NASAのPPP(Phased Program Planning)を例にとって、「各工程の専門家集団が、文書で次の工程の集団にバトンを渡すようにリレーをしている」と書いた。これに対して、Type Bの例として富士ゼロックスが、そしてType Cの例としてキヤノンとホンダが挙げられ、「ラグビーのようにボ
Agile Overview In Ono
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese TranslationKenji Hiranabe
カンバンを導入する正しい理由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. 人的リソースの共有と機能別組織開発チームが１つで、プロジェクト間でメンバーを共有
一括請負という契約形態のままアジャイル化するのは危ない - すこしふしぎ
何年か前に、顧客（と元請けの営業）だけがアジャイルに盛り上がった結果盛大に火を噴いて関係者が闇に消えた開発に関わったことがある。立場上そのままは書けないし、適宜フェイクも混ぜていくが、バッドノウハウの一例として紹介するとともに、ウォーターフォールからの脱却という意味でのアジャイルについて書いておきたい。 前提 契約はSI型一括請負、全外注。且つ、アジャイル。 闇アジャイル化の経緯 営業がアジャイルを売り込みたかったという背景があり、「だいたいこれぐらい」で契約が成立（仕様がないのに見積もりだけはあった） その時点で、元請け企業の偉い人たちがこの案件を切り捨てた（応援要請も突っぱねるよう根回しがあった）（まあしかし偉い人はさすがである、経営的な観点では正しい） 全外注は予想されうる責任回避のための手段として決定された（選択権もなかった） 顧客は仕様を決めなくてもなんとかなるのがアジャイルだと
スクラムに関する無料の日本語資料のまとめ | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムを学習するにあたって参考になる【無料】の資料を以下にあげておきます。 僕がコーチングする際は上２つの資料については事前に読んでもらった上で、トレーニングを実施したりしてます。 スクラムガイドスクラムの父であるジェフ・サザーランド氏とケン・シュエイバー氏が書いた公式のルールブック。 これを読まないでスクラムをやるのはマズイです。 http://www.scrumguides.org/日本語版は、多くの本の翻訳をされている角さんが訳されてます塹壕よりScrumとXP昨年開催したScrum Gathering Tokyoで基調講演をされたヘンリック・クニベルグ氏によるScrumとXPの実践事例。 どういう問題がおきてどう改善したかも分かる。 http://www.infoq.com/jp/minibooks/scrum-xp-from-the-t
ソフトウェア技術者サミット in 長野 - tmtms のメモ
(これは 6/6 に書きました) アジャイルプロセス協議会主催の「ソフトウェア技術者サミット in 長野」というイベントに参加してきました。 アジャイルプロセス協議会は、こういうイベントを年に2回くらい地方で開催しているらしいです。 ソフトウェアにまつわる３つの疑問 上田出身の湯本さん(@yumotsuyo)がゲスト講師でした。 以下メモ。 HPはアジャイル。アジャイル以外の話は出てこない。アジャイルが当たり前。 テストはどこまでやれば十分か テストを設計するってどういう事か テストを開発するとは何か TDDはテスト？ 開発をドライブする手段だから品質保証しなくてよい？ 品質保証の人たち、うざい 品質はどうでもよい？ 品質保証が最後にシステムを確認するのはテスト？ 品質保証の手段だから開発のことは知らなくて良い？ 開発者は言うこと聞かない！ 「造り」を無視して品質が保証できる？ SWEBO
Kanban! お客さんの視点に立った アジャイルなやり方 | PDF
Kanban! お客さんの視点に立った アジャイルなやり方 2011/12/13 @ PASONA TECH Shibuya.trac #13 1 2011年12月10日土曜日 何者？ @kompiro こんぴろこと近藤寛喜と申します。 Change Vision.Inc,のエンジニア アジャイルコーチではありません。 チームを率いるリーダーでもありません。 1プログラマでござる。 とある事情でKanban本の翻訳に携わってます。 時間がかかってすみません。 Tracに出戻りました。 2 2011年12月10日土曜日 Kanban本とはこれ。 3 2011年12月10日土曜日 Kanban本の著者 David J.Anderson師 @agilemanager Lean & Agile 日本に何度かいらしてます 元々はTOCの人みたい 4 2011年12月10日土曜日 なので、 翻訳中なの
Agile Samurai Dojo Gathering 参加レポート ｜オブジェクトの広場
目次 1. はじめに 2. ワールドカフェ「アジャイルを導入する上で解決すべき課題は何か？どう解決するか？」 2.1 開発者が開発に集中できる環境を作る 2.2 アジャイル開発を実践するための基礎的なスキルをちゃんと身につける 2.3 関心がない人に押し付けず、本人が自分からアジャイルに取り組みたいと思えるような環境づくりをする 3. Jonathanさんに突撃Q&A 3.1 組み込みシステム開発もアジャイルになれるか？ 3.2 ハードウェアエンジニアとソフトウェアエンジニアがうまく協力するためにはどのような姿勢が必要か？ 4. おわりに 1. はじめに 3月24日に、日本全国の「アジャイルサムライ」読者、原著者Jonathan Rasmussonさん、監訳者西村直人さんと角谷信太郎さんが一同に集う「Agile Samurai Dojo Gathering」というイベントが開催されました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Happy Adapting Agile Software Development
https://jasst.jp/archives/jasst08e/pdf/A5.pdf
InfoQ: 体験レポート：ゲームで学ぶアジャイルな反復型開発
Scrumodoro
リーンやアジャイルの契約書の書き方
オンラインゲーム開発におけるアジャイルなチームビルディングの具体的手法 20110906
