タグ

開発に関するyou21979のブックマーク (9)

  • アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで(後編)。QCon Tokyo 2014

    アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで(後編)。QCon Tokyo 2014 4月30日に都内で開催されたイベント「QCon Tokyo 2014」では、サイバーエージェントのアメーバ事業部が混乱の中からどうやってスクラムを導入してきたのか、その経験とそこで得られた知見が語られています。セッションの内容をダイジェストで紹介しましょう。 (記事は「アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで(前編)。QCon Tokyo 2014」の続きです) アジャイルを組織に浸透させるTips ここまでの経験で、アジャイルを組織に浸透させる上でのTipsを紹介したいと思います。 まず、組織を丸ごと変えてやる、と気張ってしまうとやはりだめです。 無理矢理「君たち全員アジャイル開発を始めよ」と言って始めるのは、そもそも自律的な組織ではありません。アジャイル開発を

    アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで(後編)。QCon Tokyo 2014
  • アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで(前編)。QCon Tokyo 2014

    アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで(前編)。QCon Tokyo 2014 スクラムのようなアジャイル開発手法を採用して開発をうまく回している現場も、最初からうまくいっていたわけではありません。現場ごとに試行錯誤を重ね、よりよい方法を模索する中で少しずつ改善が進んできているはずです。 4月30日に都内で開催されたイベント「QCon Tokyo 2014」では、サイバーエージェントのアメーバ事業部が混乱の中からどうやってスクラムを導入してきたのか、その経験とそこで得られた知見が語られています。セッションの内容をダイジェストで紹介しましょう。 Ameba流 Scrumを浸透させていく方法 サイバーエージェントの大﨑浩祟です。アメーバ事業部コミュニティ事業部というところで、現在は24Logのシステム責任者をしています。

    アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで(前編)。QCon Tokyo 2014
  • OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい(もしくはコードレビューの話) - kazuhoのメモ置き場

    以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G

    OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい(もしくはコードレビューの話) - kazuhoのメモ置き場
    you21979
    you21979 2014/03/13
    こういう概念は参考になります
  • 開発支援系のサービスが充実しすぎて転職か廃業を考えた | Ore no homepage

    なんて表現したらいいかわかんなくて、開発支援系サービスって謎表現したけど…。なんつーか、開発支援向けのサービス?クラウドってやつ?ってかいわゆる外部がやってくれる系のサービス(モニタリング/ホスティング/etc)が充実してますよね。んで、一介のWebエンジニアのおれがこの先生きのこるにはどうするかを真剣に考えていたところだった。きのこ。何割かはネタ。 思いついたものを挙げてみる。AWSGitHubは割愛。言うまでもねーだろ…。 New Relic http://newrelic.com/ 有名なNew Relic。これも説明するまでもないかな。今のチームでコレのお金払う版を使ってるんだけど、「外部APIとの通信個所とDBとの通信個所が遅いように思えるので調査しますわ」→「それNew Relicで見れるよ」とか「各テーブルへのアクセス頻度集計しますわ」→「それNew Relicで見れるよ」

    you21979
    you21979 2013/11/08
    なにを選ぶか、何を使うか、どこに使うか、どうやって組み合わせるか、サービスが増えたのだから選ぶ仕事が発生する。それがアーキテクト。サービス潰れた時のリスク管理もしないとね
  • なぜリリース頻度を上げるのか

    サービスのリリースで書いたようにネットのサービスを提供している企業は新バージョンのリリースの頻度を上げるよう常に努力しています。 リリースの頻度を上げる理由は、サービス開発の方向の軌道修正を細かく行いたいからです。少しずつサービスを改良し、その改良がユーザーにどのように受け入れられたかという反応を元に将来の開発を行っていきます。このフィードバックサイクルを短くすることによりこまめな軌道修正が可能になります。 リリース頻度が低く、リリースサイクルが長いと、その期間に加えられた変更の数が多くなり それぞれのリリースでの変更量が大きくなります。変更が多い分、リリース後の不具合発生の可能性が高くなります。また、リリース後の障害発生時の問題の切り分けも難しくなります。小さなリリースを頻繁に行うことにより、一歩一歩問題がないことを確認して次の一歩を踏み出すように、よりリスクの少ないリリースが可能になり

  • あるソシャゲ会社のプロジェクトのひっくり返り方。 島国大和のド畜生

    伝聞。 あるソシャゲ会社のプロジェクトのひっくり返り方。 1年目 新卒に運営の手伝いをさせる。 2年目 運営を切り盛りさせる。 3年目 開発の頭をやらせる。 (実際にはそれぞれ6ヶ月ぐらいと思われる) そりゃひっくり返るわ。 何一つ開発で学んでないじゃんか。なぜ開発ができると思うんだ。 運営業務はウィークリーでデイリーなので、関わってると運営に関しては結構いいスピードで詳しくなるが。 開発は少なくとも数ヶ月かかるので。詳しくなるには何かの完成に付き合う必要があり数年を要する。 絵でも漫画でもゲームでも。1仕上げる度に能力がつく。 1まるっと面倒見ないと、それを作る間にどういうコストとリスクがあるのかを肌で理解できない。 どういうトラブルが発生し、それをどう解決したかの蓄積がたまらない。 そもそも今あるトラブルがどれぐらいのトラブルなのかも見当がつかない。 イベント1コつくるのとゲーム

    you21979
    you21979 2013/05/21
    俺も書こうかな。。。
  • 【GDC 2013 Vol.33】HTML5+JavaScriptで容易にWii Uでのゲーム・アプリ開発が可能に・・・「任天堂ウェブフレームワーク」発表 / GameBusiness.jp

    今回のGDCで任天堂は2つの開発者向けセッションを予定。最初に行われたのは「Nintendo Wii U Application Development with HTML and JavaScript」(HTMLJavaScriptを使ったWii Uアプリケーション開発)と題したセッション。講師は任天堂の環境制作部の島田健嗣氏です。 Wii Uの最大の特徴であるWii U GamePadは、手元にある第2のスクリーンとして、テレビ画面と連携することによって、多くの人々と体験を共有しながら、操作性の良さを同時に実現することができます。任天堂は昨年末の発売から、ゲームソフトだけでなく、『YouTube』や『ニコニコ動画』、あるいは『Wii Street U』といったアプリケーションをリリースしてきました。これらは元々、ウェブサービスとして提供されているものですが、リビングでの体験へと変化

  • 【CEDEC 2012】開発環境共通化の意義とメリット ― カプコン「MT FRAMEWORK」の場合 / GameBusiness.jp

    スクウェア・エニックスの「共通DCCツール環境」に続いて、内製ツールを発表したのはカプコン技術研究部の大井勇樹氏です。カプコンの内製ツール「MT FRAMEWORK(MTF)」について、先ほどのセッションとは違った切り口で環境共通化についてのセッションが行われました。 「MTF」は、今や知る人ぞ知るゲーム開発フレームワークです。どのような経緯で誕生し、現在のように同社を代表するエンジンになったのでしょうか。 2004年頃、次世代機開発対応の一環として開発がスタートしました。2006年に発売されたXbox360ソフトの『デッドライジング』『ロストプラネット』が初のMTF採用タイトルになります。その後は社内でもより広く認知され、PS3版『ロストプラネット』やPS3/XBOX360ソフト『デビルメイクライ4』などで、プラットフォームを越えた共通化が達成されました。そして、2011年の『ULT

  • 【CEDEC 2012】内製ツールで効率化は達成できるのか? ― スクウェア・エニックスの場合 / GameBusiness.jp

    CEDEC2012の1日目に行われたショートセッション「内製ツールは救世主たり得るか?」では、スクウェア・エニックス、カプコンの両社の開発陣がツールの説明や運用について熱く語りました。 まず、最初はスクウェア・エニックスで「共通DCCツール環境」の保守・開発を行っているテクノロジー推進部の佐々木隆典・高木啓太両氏によるセッションが行われました。Maya、Softimage、Motion Builder、PhotoshopといったDCCツールのスクリプト(Pylon等で作業を自動化するために作成)やプラグインを社内で共有し、便利に使いやすく、開発コストを低くするために導入されました。基的に全社で共通に使用されるのが「社内共通プラグイン」、有志により制作されたものが「DCC技術共有プラグイン」と呼ばれています。 まず2005年に導入されたのが、「社内共通プラグイン」です。それまでは、プロ

  • 1