最新版 本ポストをXP祭り2017で発表したので、補足を含め要点のみを抽出してリライトしております。 i2key.hateblo.jp 本ポストはプロダクト開発における特定の文脈によるものなのですべてがそうだとは言っていませんのであしからず。バイモーダル戦略でいうところのSoE領域*1であり、学びによる改善サイクルをガンガン回していくようなモデル・フェーズを対象としております。TPSやLEANを現場で実践してる方々には今更なお話かと思いますが、DevOpsやアジャイル、リーンスタートアップを実践していく上で何周かしてまた原点の理解すると深みがますというかようやく、「ちょっとだけリーンわかる」ようになったので自分用のメモになります。 共通の価値観としての「リードタイム」 SoEライクな開発をしていると、仮説を立案し、そのための仮説を実証するための機能を実装し、リリースして計測、そして学びを得
Release Management¶ OpenStack project teams produce a large variety of code repositories. Some are services providing infrastructure APIs. Some are libraries being consumed by those services. Some are supporting cast and tools. Most of those are formally released at given points. We call those deliverables and use git tags to define the release points. Each deliverable may contain one or more git
主張 ソフトウェア開発prjがなかなかアジャイルにならないのはなぜかなぁと考えてみた。 昨今、エンジニアにおいては、知識としての共有の機会も増えているし、実際に経験済み、習慣化済みになってきているように思う。要は「しっくり」くることが多いのだと思う。 しかしながら、現実のprjが経験型のアプローチ(アジャイル)を取ることはまだまだ少ない。この要因として、エンジニアと協業する他のメンバー、あるいはprjの利害関係者(組織の上層部を含む)が予測型の進め方を望むからではないか、と感じている。 というわけで、エンジニアと仕事をするエンジニア以外の人に伝えたいと思い、書いてみる。そのためにはおそらく、アジャイル開発、スクラムのプラクティスがどうこう、というよりは、プロジェクトマネジメントの世界観として語る方がよいかというのが本稿。エンジニアとして、抽象的な「しっくり」の言語化にもなればよいと思う。最
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
ドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか？ ということで、CEDEC 2012ではドラゴンクエストXの世界観を支えるサーバシステムはどのように構成されているのか、ということが講演されましたが、さらにドラゴンクエストという人気作品を制作する上でどのようなマネージメントが行われたのか、ということについても、スクウェア・エニックス開発部所属の荒木竜馬さんが大規模開発ならではの問題やそれを解決するための工夫について語ってくれています。 タイトル | CEDEC 2012 | Computer Entertaintment Developers Conference http://cedec.cesa.or.jp/2012/program/BM/C12_P0003.html 荒木竜馬： 今日はドラゴンクエストの話ということで、朝早くからたくさんの人にお集ま
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
Planning poker®, also called Scrum poker, is a consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed.
チーム開発の苦悩と模索 クレイでは、ずっと開発方法や情報共有をいろいろと模索してきました。 以前ブログで紹介した Basecamp や Backpack の紹介も、その一つです。 小さなチームを加速させる！ Basecampで簡単プロジェクト管理 Backpackでタスク管理から情報共有まで 最近、弊社ではチーム開発というものが、うまく機能するようになってきています。 @irohiroki を筆頭に全員でアジャイル開発を進めてきていることが確実に実になってきていると思います。 少しでも参考になればと思い、今までの苦悩と模索を「アジャイルへの道 第一章」として綴りたいと思います。ちなみに第十三章まではありませんし、第二章以降は @irohiroki に任せたいと思います。 1年前までの開発 基本的に受託での開発が多いため、次のようなフローになっていました。 1年前までの開発フロー 打合せの内
3つの大事なこと まず全ての受託開発に適用できるかというと、それは難しいと考えています。 これまでクレイに発注いただいた開発で、次のような案件に適用してきました。 Webサービス スマートフォンアプリ プロトタイプ、研究開発 要件が曖昧だったり、仕様が変わりやすいもの、市場の変化が大きいものなどですね。 次に規模ですが大きくても3，4人で半年から一年程度の小規模な開発が多かったです。 ただこれまでいくつかのプロジェクトを進めてきて、向き不向き以上に大事なことがあるとわかりました。 特に次の3つが進めていくために大事なことと感じています。 クライアントにプロジェクトに責任を持って参加してもらう アジャイルに適した契約にする 開発プロセスを出来るだけ透明化する クライアントにプロジェクトに責任を持って参加してもらう 「クライアントにプロジェクトに責任を持って参加してもらう」とはどういうことでし
アジャイルがダメだと思う7つの理由へのだいぶ遅い反応 導入 もうだいぶ前の話になってしまいましたが、アジャイルに関するブログエントリ「アジャイルがダメだと思う7つの理由」は予想以上に波紋を呼び、それに呼応していくつものエントリが公開されました。発端となったエントリに関していうと、通常であれば必要となる数々の留保事項や前提事項を書かずに切り込んでいるという点において、間違いなく「煽り」であると言えます。ただ、「アジャイル」という言葉をとりまく数々の事象をかなり的確に指摘することによって、「アジャイル」という言葉をパブリックな場所で語っている少なからぬ人たちに対して、（意識的か無意識的かは問わず）ある種のポジショニングを強いたという意味で、実にいい釣り針なのではないでしょうか。 個別の論点に関する「アジャイルでは全体スケジュールにコミットできない」「いや、アジャイルだって全体スケジュールにコミ
アジャイルがダメとかダメじゃない話題が盛り上がっておりますが、ソフトウェア開発プロセスには銀の弾丸なんてなく当人が置かれたコンテキスト抜きだとその議論はむずかしいよね、と思っております. アジャイルがいいとかだめとかじゃなくてアジャイル開発プロセスのどこがうちの組織にあって、どこがうちの組織にあわなかったみたいな話のがよっぽど有意義だと思う— Kazuho Okuさん (@kazuho) 2013年3月22日 禿しく同意. というわけで自分が開発リーダーやらせてもらってる今のチームでアジャイルプラクティスを導入した動機の話をエントリーにまとめてみます. なおこのエントリーのタイトルが長くなったことに反省はしてるけど後悔はしていない. 自分が置かれている組織について コンシューマー向け自社Webサービスの開発 役割ごとにチームが存在 Webディレクター フロントエンド開発 (Webアプリケー
PySpaで id:Yoshioriに「見積りって難しい」という話をしたら「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」を教えてもらった。さっそく読んでみたのでレバレッジメモ。 「不確実性に対処するためにバッチサイズを小さくしてアジャイルに開発しよう」とか言いつつ「見積りはプロジェクトの最初に立てて変更しません」という運用をしているのはおかしい。見積りや計画づくりもアジャイルに、状況に応じて変わって行かなければ、という本。 要するに「プロジェクトの最初に正確な計画・見積りが作れるはずがない。最初に正確な計画・見積りづくりをしようとして過剰にコストを掛けるのではなく、イテレーションごとにより精度の高い見積りへと更新していく形を取ろう」ということ。 従来型の見積りの仕方が失敗するパターンがいくつか上げられていて興味深い。 例えば「タスクXに何日掛かるか見積もれ」
Ultimate Agilist Tokyo セッション4 『これまでの開発から、これからの開発へのチェンジ』ソニックガーデン倉貫さんとの講演資料になります。
「アジャイルを導入したいんですが、上司や会社に話が通じません。どうすればいいですか？」・・・アジャイルに触れたばかりの人からよく聞く質問です。 先日、Ultimate Agilist Tokyo というイベントに参加させていただき、壇上インタビューという形式で登壇させて頂きました。楽天の藤原さんからの質問に答えるという形で進みます。その中でも「よくある質問」として、この話が出ました。（決して楽天藤原さんが聞きたいと思っている訳ではなくて、こういう質問ってよく出ますよね、という対談です） そのときの私の回答は、ボトムアップでは難しいんじゃないか、というものでした。そのときは時間も足りなかったので、簡単に答えてしまいました。 この記事では、ボトムアップでアジャイルを導入することについて、壇上インタビューでは答えきれなかった部分も含めて考えてみます。 あなたのアジャイルは何をすることか？ 私は「
どうもこんにちは。 Aiming で東京開発グループのゼネラルマネージャをやっている小林です。 8月に mobage と Yahoo! モバゲー で ロードオブナイツ というシミュレーション RPG をリリースさせて頂きました。 そして、先週、 Yahoo! モバゲー版の PC ブラウザ専用デザインをリリースさせて頂きました。 今回リリースしたものは元々 Unity で作られていた iOS アプリ版 Lord of Knights を HTML5 で書きなおしたものです。 （今は Android 版 もあります） HTML のポチポチゲーをネイティブに移植したというのはよく聞く話ですね。 ですが、逆にリッチなネイティブアプリを HTML5 に移植し、かつスマフォブラウザと PC ブラウザで同じものを動かすなんてのは前例が見当たりませんでした。 技術的ハードルが高かったことに加えて期日がタイ
ペアプログラミングを実践する技術系企業が増えていることに注目し始めた Wall Street Journal が，自らの見解を Computer Programmers Learn Tough Lesson in Sharing (共有を通じて厳しい教訓を学ぶコンピュータプログラマたち) という記事に発表した。 Facebook やモバイル決済の新興企業 Square など，技術系企業の間でペアプログラミングが人気です。その信奉者は，カップルによる効果を賞賛のことばで語ります。ペアコーダはコストの高いソフトウェアエラーを捕まえることができる，Web サーフィンのような時間の浪費もない，というように。 しかし実践してみれば，すぐに問題に突き当たる。デートするのとは訳が違うのだ。 現実はむしろ，最悪のブラインドデート以下かも知れません。やっかいな問題があっという間に山と積み上がり，パートナーを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
