一定期間更新がないため広告を表示しています
2012/10/19(金) 「Agile Conference Retrospective」に参加してきました。 Doorkeeper(告知サイト) http://esminc.doorkeeper.jp/events/1771 ツイートまとめ(ゆかりんノート) https://yukar.in/note/ckFj1s Agile2012 Summary(ManasLink) http://www.manaslink.com/articles/4796 ハッシュタグ: #agile2012ja 会場は品川シーサイドの楽天タワーです。 参加者は40名くらいでしょうか。 先日10/3(水) にも「オブラブ Agile2012報告会」というイベントがあり、こちらも私、行ってきてブログにも書きました。コチラ 今回も2012年のAgile Conferenceの報告会という意味では、同じ趣旨のイベン
皆さんは、『Ultimate Agile Stories(以下、UAS)』という冊子をご存知でしょうか?UASは、様々な場で活躍しているアジャイル実践者たちのアジャイルに対する熱意がつまった本です。 アジャイルが日本に上陸してから10年以上経ち、ビジネス、マネジメント、コミュニケーション、テクニカル・・・、様々な領域でアジャイルが語られるようになりました。しかし、広がれば広がるほど様々なアジャイルが混在し、情報はまだ少なく、本を読んだだけでは実施するだけでも難しい場合があります。 私たちは、日本のアジャイルをさらに加速させるために、本気でアジャイルに取り組んでいる人達が集まり、経験を双方向に共有できる場を作るためにこのイベントを計画しました。 第1回目のイベントは、UASの執筆者を中心にセッションプログラムを構成しています。スピーカーは様々な領域を得意とするアジャイル実践者たちであり、きっ
アジャイルプロセスへのUCDの適用:対話William Hudson Syntagm Ltd, Design for Usability Abingdon, UK william.hudson@syntagm… エクストリーム・プログラミングや他のアジャイルプロセスは、無秩序と厳格すぎる手法(時に「文書化による死」といわれる)との間に妥協点をもたらす。多くのチームにとって、アジャイルな取り組みの特に魅力的な面は、どれだけ開発が進行していようとも変更に適応しようとする勇気だ。しかし、この柔軟性こそがユーザーインターフェースデザインの問題とそれに伴うユーザビリティ上の問題を引き起こす。 ユーザーインターフェースデザインにユーザー中心の取り組みを適用することでこれらの問題に取り組むことができる。ここからのユーザー中心デザイン(UCD、ユーザーセンタードデザイン)コンサルタントとエクストリーム・プ
どうもこんにちは。 Aiming で東京開発グループのゼネラルマネージャをやっている小林です。 8月に mobage と Yahoo! モバゲー で ロードオブナイツ というシミュレーション RPG をリリースさせて頂きました。 そして、先週、 Yahoo! モバゲー版の PC ブラウザ専用デザインをリリースさせて頂きました。 今回リリースしたものは元々 Unity で作られていた iOS アプリ版 Lord of Knights を HTML5 で書きなおしたものです。 (今は Android 版 もあります) HTML のポチポチゲーをネイティブに移植したというのはよく聞く話ですね。 ですが、逆にリッチなネイティブアプリを HTML5 に移植し、かつスマフォブラウザと PC ブラウザで同じものを動かすなんてのは前例が見当たりませんでした。 技術的ハードルが高かったことに加えて期日がタイ
10月22日におこなわれた、Regional Scrum Gathering® Tokyo 20192日目のワークショップとして、「スクラムプロジェクト逆計画ゲーム」をやってきました。 ゲームは「プロジェクトが成功して終わった」ところから、どうやって成功までたどりついたのかを、時間を逆回しにして終わりのスプリントから始めのスプリントに向かって、計画と実績を組み立てていくというものです。 スクラムに限らずアジャイルなプロジェクトにおいて、プロジェクトの最初に計画を立てて後はそれに従うというのでは不十分です。プロジェクトの途中でも計画を変更する覚悟で、むしろ計画を変更しつつ進めることを前提として、「計画づくり」という活動を積み重ねなていきます。そうした考え方を直感的に理解し、そうした認識をチームで共有するためのゲームを、今回のために作りました。 今回はイベントのワークショップとしてやりましたが
メモ。 アジャイルとウォーターフォールを対比させるのは違和感があった。ので、少し考えてみた。 アジャイルソフトウェア開発宣言にある「包括的なドキュメント」とか「契約交渉」とか「計画に従う」とかと、「対話」「顧客との協調」「変化への対応」とかは、わりとばらばらなお題目が並んでいるように見える。少なくともこれがMECEだと思う人はいないと思う。 ばらばら並んでいる項目の共通点、類似点は何か。それはたぶん、「顧客」と「開発者」という2つのロールを仮定して、そのロールの人同士の間でのコミュニケーションコストを最大化する(という言い方が悪ければ「最大限許容する」と言い換えてもいい)というものだろう。文書や契約や計画は、あらかじめ(多少はコストをかけて)まとめておけば、それ以降のコミュニケーションは省略できる(ような気になる)、というものだろう。ツール・プロセスも同様だ。一方で、個人や対話、顧客との協
さて、今日2発目のブログは、多くの人に書いてくれ〜と言われて約束していたネタです。 目下最近の私の2大関心毎は「Lean Startup/UX」と「Continuous Delivery」です。Lean Startupは書きましたので、何で「Continuous Delivery」か?というのは、理由があります。 最近実は企画フェーズのコンサルの中でプログラムを書いています。JQuery Mobile + Ruby on Rails on EC2 という感じです。インフラからアプリケーション、そしてUX的な要求開発なんかもやっています。チームは企画フェーズのアジャイルなので小さいですが、今回のアプリケーションを作っていて思っていることですが、Agileに加えてRailsやJQuery Mobileを使うとかなり開発って加速するのですが、どうしてもめんどくさい事があります。1つはインフラ構築
図 1. アジャイルのアーキテクチャに関する作業のハイブリッドなフレームワーク。プロジェクトにアーキテクトを巻き込むことは、プロジェクトの目的を達成する手助けとなります。テーブル1では、さらに相互作用ポイント(緑)、重要な技術(金)、アーキテクチャ機能(紫)というフレームワークの要素を説明しています。 テーブル 1 は、図1の要素を簡単に説明しています。このリストは網羅的ではありませんが、アーキテクチャ機能は、アーキテクトが通常プロジェクトで実行するものです。 テーブル 2は、交差している点においてアーキテクトの主な関心や相互作用点とアーキテクチャ機能がどのように交わるのかを示します。まとめて言うと、3つのカテゴリと4つの項目によって、他の優先順位や選択肢に基づいてカテゴリや項目を追加することで、アジャイルアーキテクチャを拡張できることを理解し、指導するのに役立つフレームワークが作り出され
早口の関西弁でつっこみまくって笑いを誘い、でも最後にアジャイル開発とクラウド利用の棲み分けについて「なるほど」と思わせる素敵なライトニングトークのビデオを見つけました。 それはPublickeyでも何度か紹介している9月4日に行われたイベント「XP祭り2010」での、市谷聡啓氏によるライトニングトーク「始まらなかったAgileの話をしよう」です。 アジャイル開発、セールスナントカに敗退す ライトニングトークのあらすじを紹介しましょう。市谷氏がある海岸沿いのSIerにいたころの話。 お客様から「特定の期間しか使わない。できるだけ早く利用したい。ただし仕様は変わる可能性がある」というシステム開発案件の依頼を受け、「これはアジャイルしかないだろう」とお客様に提案。 市谷氏はこの提案で「勝利を確信したなと」。 「ところがこいつが出てきたんですね、黒船ですわ」と思わぬ競合が出現。「具体的に言うとセー
_ DevLove: Change The Future 僕らの開発がアジャイルであるために papandaさんに呼んでもらってDevLoveでしゃべってきました。XP祭り関西2010の再演です。 泥臭い話にも関わらず、真剣に聞いてくださってありがとうございました。 倉貫さんがサービス開発の話をして、私が受託開発の話をして、対比としては面白かったんじゃないかと思います。質疑応答の時間も取れたのでよかった。 XP祭り関西のときとほとんど同じですけど、資料をあげておきます。
原文(投稿日:2010/03/02)へのリンク ソフトウェア開発は、創造的なプロセスである、と知られている。 ソフトウェア開発の動的な環境が無視された、伝統的な方法論の失敗によって、Agile な方法論がかなり人気を得た。Agile 方法論、特に Scrumの採用が増えている。しかし、すべてが Agileでうまく行っているか? Kai Gilb 氏は、そう思っていない。彼は、 Agileには重大な欠陥があると言っている。 氏は、Agile の栄光にもかかわらず、 ある重大な欠陥があるという、 Agile に関する大部分の文書は、その栄光について語っていますが、私は、その欠陥について書きます:欠陥は、非常に深刻なので、もし修正されないと、あなたが好きなAgile手法は、去年の流行りだった、ということになります。 氏は、 AgileやScrumの焦点は、間違っている、と言う。これらは、ステーク
Home News Spotlight 創刊100号記念:CIOの明日 Case File 国内事例 海外事例 Industry Review CIO Interview >>Strategy View CIOの役割 経営革新 業務改革 IT投資/ROI コスト削減 ITガバナンス ベンダー・マネジメント IT組織改革 人材育成 内部統制 コンプライアンス プロジェクト・マネジメント アウトソーシング >>Technology View IT基盤 仮想化 システム統合 クラウド/SaaS セキュリティ管理 データ/ストレージ管理 クライアント管理 IT運用管理 BCM/リスク・マネジメント ERP SCM/設計製造 CRM システム開発 SOA/Webサービス オープンソース/Linux BI 情報共有/コラ
9月末に開催された、UK Lean & Kanban Conference に参加してきた。今回は、スピーカーとして呼ばれる、という光栄に預かった。これは、現在、アジャイル界で起きているスピンオフ・ムーブメントである、「Kanban」に関してぼくが発言をしているからだ。 一言でKanbanを言うのは難しいが、2009年10月時点では、「ソフトウェア開発のフローを見える化し、WIP(Work in Progress=仕掛)を制限することで、顧客価値のスループットを上げ、同時に改善を促す活動」、とぼくは定義してみた。もちろん、トヨタ生産方式のかんばんから来ているが、ソフトウェア開発向けにここ3年間でずいぶんとBoKが積み上げられていて、Agile2009 でも Limitting Wip Society というグループが、"Yes, We Kanban" というTシャツを着ていた。(アイコンは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く