AgileUX のパイオニアである Jeff Patton 氏が弊社にて2日間に渡る「Product Ownership Training（プロダクト・オーナーシップ研修）」を開講してくださいました。アジャイル開発を推進するための目的として開催されましたが、プロダクト・オーナーシップ・チームを対象としたセッションということでユーザエクスペリエンス・デザイナーとして参加してまいりました。 アジャイルは、昨年開催された Web Director's Meetup というイベントでも「アジャイルときどきUX」として発表したことがあり馴染みはありましたが、この研修ではデベロッパー観点からの Agile Experience Design を突きつけられたような衝撃を受け、今後のユーザエクスペリエンス・デザイナーとしての立ち振る舞いに少し焦りが生じ始めました。Jeff Patton 氏も元々は純粋な
わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった？ 「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile
アジャイルUX 小史 アジャイル開発と UCD（ユーザ中心設計）は別々に進化を遂げていましたが、ほぼ同時期に一躍注目を浴びるようになります。1999年にUCD の国際規格 ISO13407 が制定され、2001年にはアジャイル宣言が出されたのです。これらの手法を組み合わせて、優れたUX を迅速に開発しようという動きが現場で起きたのは自然なことでしょう。 （なお、アジャイル開発の具体的な内容についてもっと詳しく知りたい方は、ぜひ牛尾さんの連載をご覧ください。） ただ、最初の頃はそれらの試みはあまり上手くいきませんでした。そもそも伝統的な UCD はウォーターフォール的ですし、手法の多くはアジャイル特有の短期間のイテレーション（1～4週間）には収まりません。そのうえアジャイル開発者と UX の実務家は、お互いを全く理解していませんでした。ケント・ベックとアラン・クーパーの論争はそれを象徴するも
指導者として駆け出しの当初は、自分の言っていることを理解してもらうことにかなりのエネルギーを費やしました。ですから、私の素晴らしいコーチング戦略を長ったらしいスピーチで自チームの選手達に説明しました。選手に私の言いたいことを確実に理解させるために、「皆さん、分かりましたか？」と尋ねたものでした。皆がうなずいたので、私は満足でした。しかし、選手のプレーを見て、理解していなかったことが分かりました。 私の言ったことを聞いていないようでした。ですから、もっと大きな声で、より攻撃的に、そして対峙するような感じで話すようになりました。残念ながら、効果はありませんでした。私は自分の指導者にこう言いました --「才能がなくて耳の遠い選手が集まっても、大きな成果は上げられません」。するとこの指導者は、何もかも私の責任だと言いました。コミュニケーション調査の結果を見せてくれたのですが、この調査によって次のこ
Kenji HIRANABE is CEO of Change Vision, Inc., an ISV of an Agile modeling tool astah, based in Tokyo Japan. His recent articles includes "Kanban Applied to Software Development: from Agile to Lean". He is a leader of the Japanese Agile community and has translated Agile books "Lean Software Development," "XP Installed", "Agile Project Management" into Japanese. Kenji is a 2008 Gordon Pask Award re
アジャイル度を評価しよう このサイトではJames Shore氏とShane Warden氏の本『アート・オブ・アジャイル デベロップメント』に出てくる「アジャイル度を評価しよう」という質問表をとりあげています。 質問に答えることで、チームがどれだけうまくアジャイルを採り入れているか、評価結果を示します。チームがアジャイルへの理解を深めるのに役立ててください。 大事なのは会話すること この質問表を使う一番のメリットは、どうやってアジャイルに取り組んでいくかについてチームの中で議論が巻き起こることです。 チームがアジャイルかどうかに関わらず、質問にひとつひとつ答えていく中で会話が生まれることが本当に価値のあることなのです。 この質問表が、一緒に働いているチームのメンバーがお互いを知り、信頼と誠実さを築き、集中してXPプラクティスに取り組むきっかけになることを願います。 出典 このサイトではオ
やじゅ＠わんくま同盟-静岡支部 システムエンジニアを対象によりよいアプリケーションを作成する上で必要な知識および経験を紹介します。 やじゅ デジタル・デザイン・ラボラトリーな日々 twitter MSMVP Microsoft MVP for Visual Basic (January 2010 - December 2012) リンク わんくま同盟 書庫 2015年12月 (3) 2015年11月 (1) 2015年10月 (1) 2015年9月 (1) 2015年8月 (1) 2015年7月 (1) 2015年6月 (1) 2015年5月 (2) 2015年4月 (2) 2015年3月 (1) 2015年2月 (2) 2014年12月 (13) 2014年5月 (1) 2014年4月 (2) 2014年2月 (1) 2014年1月 (3) 2013年12月 (5) 2013年10月 (
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
ほんとにヤバくなってギリギリになるまで相談しない人々: 切込隊長BLOG（ブログ） Lead‐off man's Blog http://kirik.tea-nifty.com/diary/2010/03/post-1da9.html いつも予防線が突破されるので、いずれにせよ年がら年中修羅場になってるわけだが、 修羅場をこなしているうちに、常在戦場みたいな組織が出来上がって、 毎日ラットレースをしている敗戦処理のエキスパート軍団ができちゃう。 戦況だけ見ると実に見事に負けてるんだけど、 担当した局地戦だけはどうにかなっちゃってるというような。 そういう組織は、人が内部から壊れていく。鬱になったり、病気になったりする。 まあ、発展性のない業務に長時間据えられて、 強いストレスに晒されながら安い給料で働くわけだからねえ。 一個一個のデスマーチは、マーチである限り終わりはあるわけだけど、 デス
原文(投稿日：2010/03/02)へのリンク ソフトウェア開発は、創造的なプロセスである、と知られている。 ソフトウェア開発の動的な環境が無視された、伝統的な方法論の失敗によって、Agile な方法論がかなり人気を得た。Agile 方法論、特に Scrumの採用が増えている。しかし、すべてが Agileでうまく行っているか？ Kai Gilb 氏は、そう思っていない。彼は、 Agileには重大な欠陥があると言っている。 氏は、Agile の栄光にもかかわらず、 ある重大な欠陥があるという、 Agile に関する大部分の文書は、その栄光について語っていますが、私は、その欠陥について書きます：欠陥は、非常に深刻なので、もし修正されないと、あなたが好きなAgile手法は、去年の流行りだった、ということになります。 氏は、 AgileやScrumの焦点は、間違っている、と言う。これらは、ステーク
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
Shibuya-tracつながりで、IBMのAgileセミナー「チーム開発の生産性を高めるプロセスを体感しよう（入門編）」に行ってきた。 内容はScrumの基礎とRational Team Concert(RTC)の紹介。 Scrumについては、@masayang師匠から教えを受け、多数の案件をやってきているので、新たな発見というのはあまり無かったけど、改めて復習にはなった。ただセミナーの内容は純粋Scrumというよりは日本型Scrumと言った方が良いかと思う。ターゲット層がAgile初心者だったようなので「これがAgileというものなんです」と言うと誤解を招く恐れがあるのではないかな。Agileマニフェストを最初に説明しておいた方が良かったと思う。 参考になった点を列挙しておく。 Scrum概説 WFとAgileの例え。WFは長編映画。あたるかどうかは封を切ってみないと分からない。一方で
IBMで行われた「チーム開発の生産性を高めるプロセスを体感しよう（入門編）」に行ってきた。 内容としては、アジャイル開発（主にスクラム）の基礎的な話と、ちょっとした実践、IBM Rational Team Concertを使ったデモ。 以下、気づいたことなど。 ウォーターフォールとアジャイルの違いを、映画と連続ドラマに例えてたのはわかりやすいと思った。映画は公開後の手直しができなくてハイリスク、連続ドラマは毎回視聴者の反応を見ながら手直しできる 要求仕様が前提となるのがWF、リソースと納期をベースに考えるのがアジャイル。要求は24ヶ月で25%変質する ⇒個人的にはパーセンテージはもう少し高い印象 今までの組織で管理を担当していた人は、アジャイルでは役割が「プロダクトの下支え」となる。管理職も変わらなきゃいけない。 ⇒これは管理職だけでなく一般社員にも言えることだなー。自律的に動くという
http://d.hatena.ne.jp/Rinta/20070814#p1 長いので引用はしないよ。質問は4点あるようで Agileはプロジェクト管理の失敗をケアできるものなの？ 少人数のイタレーションでプロジェクトをまわしてくAgileでは大規模に対応できないのでは？ テストベンチはAgileだけの特徴ではないよね？ 設計書なしで保守をどうするの？ Agileはプロジェクト管理の失敗をケアできるものなの？ 次の質問への答が参考になるはず。失敗とはなにか？も参照のこと。 少人数のイタレーションでプロジェクトをまわしてくAgileでは大規模に対応できないのでは？ ウォーターフォールと同じものをAgile開発に期待するのなら、その通り。少人数でまわせば時間がかかるようになるだけ。 ここでいう「同じもの」というのは 全く使われない要件（フィーチャ） ほとんど使われない要件（フィーチャ） 使わ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The new new product development game