プロジェクトファシリテーション実践編：ふりかえりガイド
ここでは、PF=Project Facilitation(プロジェクトファシリテーション)について議論しています。 プロジェクトを活性化し、楽しくプロジェクトを成功に導くための、実践的な課題を扱います。 プロジェクトの成功に大切なものはなんでしょうか？ 個々人のスキルは重要です。そして、ここで取り上げるのは、集まった個人のスキルを１００％以上に発揮させるチーム作りとしての、「プロジェクトファシリテーション（PF）」です。 プロジェクトマネジメント（PM）が重要であることは昨今強く言われています。 PMが「計画達成のマネジメント」に重点を置くのに対してPFは「参加者の協調の場作り」に重点を置いています。PMは、計画の立案と実行、差異に注目した管理が中心で、どちらかと言うと「コマンド･コントロール型」のマネジメントスタイルが背後にあります。これに対してPFは、その場その場の変化に対応し、チーム
Certified Scrum Master Seminar 2日目 - やっとむでぽん
昨日の続きです。 総括 素晴らしいトレーニングだった。出てよかった。 来年の5月とかに、日本での実施を検討しているそうです。ぜひ参加してください。 内容も良かったし、講師も良かったし、参加者も良かった。 活発な質問、議論、コメント 英語の刺激と勉強 Bas(講師)「おれはフィンランドでトレーニングしてきたから、議論を活発化させるのはお手の物なんだ！」(フィンランド人はとってもとっても無口だ、と終わったあとの飲み会でいろいろジョークを言っていた) ScrumはXPより導入しやすい。とりわけ上層部、経営側を説得しやすい。 現場は。。。？ XPの、Kent Beck のマジックはないよね。 Tシャツもらった！ 写真はmixiで ゲーム業界で人気？ 各論 ScrumMaster 役割 感情をどう扱うか 伝えるよりも聞く 鏡のような存在 わたしの半年間の目標: Ask the others (not
Certified Scrum Master Seminar
今日は認定SCRUMマスターコース(2日間)の1日目でした。すげー疲れた(ALL英語)けど面白かった。いろいろ考えました。講師の Bas Vodde さんも、わかりやすく、飽きさせず、経験豊富で、とても良かった。(Finland で仕事をしたことがあるそう。北欧か！今は中国で、大企業で Scrum の普及なんかをしている) 終わったあと、いっしょに行った人々と話をしながら、整理。 有料セミナーなので内容はあまり具体的に書きません。 Scrum 原点 The New New Product Development Game (竹内、野中) http://apln-richmond.pbwiki.com/f/New+New+Prod+Devel+Game.pdf リーン 質問: なぜ日本のソフトウェア業界ではリーン(トヨタ生産方式)を活用していないのか？ RAD 自己管理 ゴールを狙う 計画通
お客さん側の問題 - masayang's diary
8時半まで仕事して、それから飲みに行ってきた。皆さん、当たり前のように9時10時まで残業しているそうで。なんだかなー。 発注側にも問題がある 今日の現場をみていて思ったのは、開発を発注する側の体質。お客さんのせいにするのは申し訳ないけど、もうちょっと戦略的に発注するべきじゃないかな。問題点は以下のとおり。 やたらと値切る 細かい 散々粘って発注しない 朝令暮改 「やたらと値切る」ってのは、とにかく「高い〜 安くしろ〜 高い〜 安くしろ〜」と文句をいうお客さん。費用対効果の観点がばっさりと欠如している。そのシステムでいくら儲けるのかを考えていない。同様に、いくらまで損したら中止するかという撤退戦略もない。[*1] 「○○億円投資して、N年かけてα%で回収する。損失が××万円になったら撤退する。」という基本戦略があれば、無理して値切る必要はないんだよ。そこを無理して値切るから、開発する側は開発
【XDev】「とりあえず作って，後から作り直せ」，Rubyのまつもと氏が語るエンタープライズ開発：ITpro
写真●「X-over Development Conference 2007」で講演する，まつもとゆきひろ氏 「結局のところ，顧客に何が必要かは，顧客にも開発者にも理解は不可能だ。そうならば，まずアプリケーションを作って，それを使ってもらい，顧客に合うように直すしかない。これからのエンタープライズ開発も，とにかく速く安く作って，直すことが重要になる」－－。プログラム言語「Ruby」の開発者であるまつもとゆきひろ氏は9月7日，ソフト開発をテーマにしたイベント「X-over Development Conference 2007」の講演でこう主張した。 まつもとゆきひろ氏の講演テーマは「Web 2.0時代のエンタープライズ開発」というもの。Web 2.0時代のアプリケーションは，「YouTube」に代表されるように，「仕組みそのものよりも，データがどれだけ集まっているかが生死を分けている」（ま
Agileは難しいのか？ - masayang's diary
「Agile開発は難しい（難しそうだ）」という意見を聞くことがある。「難しい」のは 政治的に難しい（社内ルールと合致しない） 営業上、難しい（道幅課金を顧客に納得させる必要がある） 技術上、難しい の３つに分類できるのだけど、ここでは「技術上難しいか」だけ書いてみたい。 Agileは「平均的な人達」のための技術 自分は「Agileは平均的な技術力を持った人達のための開発技術」だと思っている。 平均的というのは 要件分析や定義で平均的に抜けや誤りを発生させて 設計で平均的に抜けや誤りを発生させて 実装で平均的にバグを埋め込んで テストやデバッグでのバグ検知修正が平均的に下手 ということ。要は神でも天才でもない人達だ。自分ももちろんこの範囲に納まっている。 平均的な人達は平均的に間違いを犯す。 ソフトウェア開発においては、それらの間違いは「発覚が遅れるほど、傷が深くなる」のは周知の事実。 神で
あー。また日付まちがえた。: 『WikiとXPをつなぐ時を超えたプログラミングの道』江渡 浩一郎, オブラブイベント2007夏 - 角谷HTML化計画(2007-06-21)
■1 『WikiとXPをつなぐ時を超えたプログラミングの道』江渡 浩一郎, オブラブイベント2007夏 オブラブのイベントに興味を持ってもらえるような人たちに江渡さんを紹介できたことを光栄に思います。講演じたいも、自分のなかに勇気と知的興奮がみなぎるのを感じた。江渡さんにはもちろんのこと、講演の実現に尽力いただいた関係各位に感謝します。 「オブラブ行ってみたいなー」という江渡さんの何気ない一言を真に受けて講演をお願いして、ほんとうにほんとうによかった。「WikipediaをWikiと呼んでよいのか?」という素朴な問いの答えを巡るマジカル・ミステリー・ツアー。 パターンは一定の形態を生み出すルール。ランゲージは様々な大きさの部品の有機的な集合。WikiはWikiで書かれていた。WikiとXPは兄弟だ。お母さんはパターンランゲージ、お父さんはWard Cunningham。Wikiはうまくいく
ペアプロとツッコミ - 機械猫の日記
以前から書こうと思っていたペアプロとツッコミの関係が、ちょうどMLで触れられていたので、ここで書いちゃおう。 【ペアプロとツッコミ】ペアプロのナビゲータ（パートナ）はツッコミの要領で！といわれる。（これを最初に見たのは、ちゃまっ娘さんが出てるオブジェクト倶楽部の記事かな）で、僕もそう思う。じゃぁ、漫才のツッコミとペアプロのパートナの類似点から何か言えないかな、と思ったのが発端。 まず、漫才のツッコミの役割を考える。 ボケに反応する これが通常イメージされるツッコミ 漫才の流れを作る ボケに対してネタをふったり、ツッコミながら話を進めたり、 あるいはツッコミの「もうええわ」で終わる漫才の形式は一般的。 この役割のせいでツッコミが司会をすることが多いのかな？ ふくらませる ちょっとしたボケをさらに膨らませたりいじったりして大きな笑いに変える。 あるいは、何気ないことを捕まえて、ツッコミのネタに
IDE(統合開発環境)についての昔話 - グニャラくんのグニャグニャ備忘録@はてな
とあるMLを読んでいて、昔話を思い出した。 あればたぶん2000年ごろ。僕がまだJavaを触っていた時代。 バイト先での作業のために、 JBuilderを買ってもらって使っていた。 まあそれなりの環境で、それなりに気に入っていた。 あるとき、協力会社の人たちが Javaの開発は テキストエディタ+JDKだよね、 IDE使っているなんてダサい！ って陰口を言っていたのを聞いた。 多分聞こえるように言っていたんだと思う。 今考えると、 彼らが今もJavaの開発をしているとして、 「ありえないだろうけど」、もしEclipseが端末に入っていたら、 こっそりとHotJavaとかに入れ替えてやりたい。 かくいう僕は、いまだに C言語でかなり複雑なロジックを追うとき、 たまにVisual C++上で追ったりしています。 何せ、一度に画面に出る情報量が多いんだもの… gdb/dddでも同じことはできるの
【連載◎開発現場から時代を眺める by arton】第2回
【連載◎開発現場から時代を眺める by arton】第2回 テスト駆動開発（TDD）が分かると従来の設計手法の問題が見えてくる（前編） 本稿では，テスト駆動開発（Test-driven Development――以降TDDと略す）について解説する。TDDは，その名の通りテストを主としてプログラムを開発する手法だ。ここで重要なのは，TDDはテスト手法ではないということだ。では何かと言えば，TDDはその名の通り開発手法なのだ。さらに正確に言えば，プログラムの開発工程を設計，実装，テストの3段階に分割した場合の最初の段階，すなわち設計を主眼とした開発手法なのである。その意味では設計手法と言い切ってもそれほど間違いではない。TDDによってプログラムの開発工程（設計，実装，テスト）がイテレーション（反復）される以上，最初に来る「設計」がTDDの主眼となることはある意味当然のことだ。 本稿の目的は，T
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ペアプログラミング、実践してますか? | スラド デベロッパー
Greenbear Laboratory - SVKを使ってみよう
Project Facilitation の最新プレゼンテーション：An Agile Way：オルタナティブ・ブログ
XP祭り2007 〜XPブートキャンプだ！〜
Survey Says...Agile Has Crossed the Chasm
Has Agile Crossed the Chasm?
http://kakutani.com/articles/xpe2nd-chapter23/
http://release.openqa.org/selenium-core/nightly/reference.html
Amazon.co.jp: 実践アジャイル ソフトウェア開発法とプロジェクト管理: 山田正樹: 本
- XP書籍