Content-Length: 286642 | pFad | http://b.hatena.ne.jp/hagayu/agile/
PMP®受験対策講座 2016年8月コース（フルパッケージ）
PMP®受験対策講座 8月土日コース【フルパッケージ】＜8月21日,27日,28日＞ 開催日時：2016年8月21日（日）および27（土）28（日） 9：30～18：30 （受付開始は9：00） 受講料金：144,720円(税抜価格134,000円) フルパッケージ特別価格 10%OFF⇒129,600円(税抜価格120,000円) 場所：株式会社翔泳社 セミナールーム 〒160-0006 東京都新宿区舟町5（地図） 学習ポイント PMP®資格を取得をするために必要なPMBOK®Guide 第5版への理解を深め、PMP®試験へ合格していただくことを目標とします。 セミナーでは、受験勉強の仕方・テクニックや心構え、受験申請、試験当日の注意事項とポイントを押さえた解説で問題の傾向と対策をお伝えします。少人数制なのでゆっくり丁寧な解説で、これから勉強される方にも安心して受講いただけるコースとなっ
アジャイル開発とクラウド（SaaS）利用の位置づけ、SIerの生きる道
早口の関西弁でつっこみまくって笑いを誘い、でも最後にアジャイル開発とクラウド利用の棲み分けについて「なるほど」と思わせる素敵なライトニングトークのビデオを見つけました。 それはPublickeyでも何度か紹介している9月4日に行われたイベント「XP祭り2010」での、市谷聡啓氏によるライトニングトーク「始まらなかったAgileの話をしよう」です。 アジャイル開発、セールスナントカに敗退す ライトニングトークのあらすじを紹介しましょう。市谷氏がある海岸沿いのSIerにいたころの話。 お客様から「特定の期間しか使わない。できるだけ早く利用したい。ただし仕様は変わる可能性がある」というシステム開発案件の依頼を受け、「これはアジャイルしかないだろう」とお客様に提案。 市谷氏はこの提案で「勝利を確信したなと」。 「ところがこいつが出てきたんですね、黒船ですわ」と思わぬ競合が出現。「具体的に言うとセー
「アート・オブ・アジャイルデベロップメントへの道」へ行ってきた - 虎塚
木曜の夜、平鍋健児さん、木下史彦さんと岡島幸男さん（id:HappymanOkajima）のトークセッション「アート・オブ・アジャイルデベロップメントへの道」へ行ってきました。 アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE) 作者: James Shore,Shane Warden,木下史彦(監訳),平鍋健児(監訳),笹井崇司出版社/メーカー: オライリージャパン発売日: 2009/02/18メディア: 大型本購入: 18人 クリック: 336回この商品を含むブログ (100件) を見る アジャイルを仕事で実践する方々のお話を聞けて、とても面白かった。復習がてら、ノートと記憶から抜粋してまとめてみました。参加しなかった知人にいつか読んでもらうことを想定して書いたら、長くなってしまいましたが。 導入 開始前
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
Agile失敗パターン三部作 - masayang's diary
Allan Kelly氏の「Agile失敗三部作」を適当に日本語訳してみた。 Agileで失敗する時 続・Agileでうまくいかないとき まだあった・Agileでうまくいかないとき 読めばわかってもらえると思うけど、「Agileだからうまくいかない」というわけではない。 未知の技術を採用したり、未知の領域のアプリを開発したりするような場合には、プロジェクトはそれなりの(把握できない)リスクを抱える事になる。だとしても、プロジェクト終盤で問題が発覚することが多いウォーターフォール型開発よりは、比較的早い段階で問題を把握できるAgileの方が有利ではある。ただしそれも、「問題が起きている」ということを把握できる実力がAgileチームにあれば、の話である。 二番目と三番目は、それぞれAgile計画管理、そしてAgile開発手法に特化した話だが、ぎゅっと圧縮すれば「経験がなければ問題が起きている事
【公開】XP祭り関西2009講演資料「チケットファーストでアジャイル開発！～チケットに分割して統治せよ」 - プログラマの思索
【公開】XP祭り関西2009講演資料「チケットファーストでアジャイル開発！～チケットに分割して統治せよ」 XP祭り関西2009講演資料「チケットファーストでアジャイル開発！～チケットに分割して統治せよ」を公開します。 CC Attribution ライセンスとします。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) プログラマの思索: 【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」 まちゅさんはTracのチケット管理を元に「チケット駆動開発(Ticket Driven Development)」を提唱された。 僕は、Redmineによるプロジェクト運営でプロジェクト管理が劇的に改善した経験を昨年のKOFで話してみた。 KOF講演後、興味を持
僕がTDDをやめた理由 - カタチづくり
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
TDDはYAGNIに矛盾する？ - カタチづくり
Joel on Softwareに面白そうな記事が載っていた。 とはいえ、どうも僕の英語力では完全な読解が難しい。会話を書き起こしたものなので当然ながら文体が会話調で、僕にはなかなか理解が難しいのだ。以下で僕の読み間違いがあれば指摘して欲しい。 さて、冒頭で Joel 氏はこう言っている。 Joel: There's a debate over Test Driven Development... should you have unit tests for everything, that kind of stuff... a lot of people write to me, after reading The Joel Test, to say, "You should have a 13th thing on here: Unit Testing, 100% unit tests
角谷HTML化計画(2008-06-20) 「ふつうのシステム開発〜Rubyとアジャイルで実現する ゆるふわドンピシャ愛されシステム開発」
■1 いよいよ本日からRubyKaigi2008が! スポンサー事例発表の資料をだいたい完成させた……。これでどうにか会場設営などの準備作業に専念できそう。今日の私は 運営委員長のおしごと スポンサー事例発表(永和システムマネジメント) RubyKaigi2008 Golfコンペの景品係 といった出番を予定しています。会場で姿を見かけたらお気軽に声をかけてやってください。 Tags: rubykaigi2008 ■2 「ふつうのシステム開発〜Rubyとアジャイルで実現する ゆるふわドンピシャ愛されシステム開発」 | View | Upload your own スポンサー事例での発表がおわりました。 ふう。回線が細いので、slideshareはあとで。自分のサイトにPDFを置いておく。 http://kakutani.com/articles/ordinary_systems_develo
連載：アジャイル開発者の習慣―acts_as_agile｜gihyo.jp … 技術評論社
第4回特別コラム 「なぜそんなにも（アジャイル開発者にとって）Wikiは重要なのか」 角谷信太郎 2008-04-22
ホワイトボードを使ったタスク管理 | feedforce Engineers' blog
はじめに 弊社では、技術チームのタスク管理に、ホワイトボードを利用しています。毎朝、ホワイトボードの前にチームメンバーを集めて、スタンドアップミーティングを行っています。 今回のコラムでは、このホワイトボードとタスク管理についてお話しします。 はじめに 前知識 目的および効果 見える化 意識合わせ 振り返り ホワイトボードの使い方 (1) Q内の月別予定 (2) KPT (3) 直近のタスクプール (4) 先延ばしタスクプール (5) 定期タスクプール (6) メンバーのタスク管理表 (6a) 実行中タスク (6b) 各曜日別の実行済みタスク (7) メンバー用の汎用タスクプール タスクをホワイトボードで管理するメリット 朝ミーティングの効率 一目瞭然 振り返りの効率 公開性 まとめ 最後に はじめに 弊社では、技術チームのタスク管理に、ホワイトボードを利用しています。毎朝、ホワイトボード
デブサミ2009で発表しました:「時を超えたプログラミングの道への道」 - 角谷HTML化計画(2009-02-12)
Invalid Text■<%=sn number %> <%=flickr_left '3274768929' %>デブサミ2009で発表しました:「時を超えたプログラミングの道への道」 つかれたのであとで書く。とりあえずスライド。最後までスライドめくれてよかった。 写真はtakaiのを借りてます。練習不足(というかスライド完成したのが10分前)でリモコンを見すぎてしまいました。情けないです。 The way to the timeless way of programmingView more presentations from Shintaro Kakutani. (tags: devsumi2009 xp) slideshare.net kakutani.com よくある質問と答え Q:動画はいつ公開されますか？ A:録画してません。 Q:予稿とかないの？ A:ありません。ひとえ
アジャイルごっこ - プログラマの思索
「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」で指摘した「アジャイルごっこ」についてメモ書き。 【元ネタ】 続・書評『アジャイルな見積りと計画づくり』 - TECH-moratorium ： テクモラトリアム DeclineAndFallOfAgile - アジャイルの衰退と凋落 【1】「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」の訳者あとがきに、こんな一節がある。 XPを代表とするアジャイル開発の技術的プラクティスは、開発現場の日々の作業を明らかに改善してくれる。 しかし、その効果はいずれ限界が来る。 結局、プロジェクトのスコープとスケジュールが固定されている状況では、最終的に開発者に様々なしわ寄せが来る。 このように、開発者だけがアジャイルなプラクティスを導入している状況を、木下さん(レビューワー)は「アジャイルごっこ」
BMUF (Big Modeling Up Front)＝上流設計のインチキを斬る - masayang's diary
DDJのCounteracting the False Arguments for Big Modeling Up Front (BMUF)という記事が面白い。BMUFは、日本語なら「上流設計」だろうね。SI屋の自称上流設計エンジニアがやってる、アレだ。[*1] この記事を書いているのはScott Ambler。Refactoring Database著者だ。例によって無断適当意訳。読みやすくするために原文よりも段落を増やした。 上流設計(BMUF)にまつわる嘘を斬る 自分は１９８０年代から数々のプロジェクトで上流設計をしてきたし、様々な手法をみてきた。 そして、うまく行った事例よりは、うまくいかなかった事例の方が多いと言えるね。プロジェクトは明らかに失敗しつつあるのに、上流設計は順調に進んでいる、という現象を誰よりも多く見てきた、ということも言っておこう。 まだあるよ。上流設計担当の人た
InfoQ: 複数のアジャイルチームでのバージョン管理
複数のチームが動いているアジャイル環境では、以下の目的を実現するバージョン管理モデルが必要になります。 フェイルファースト フェイルファーストとはコードのコンフリクトや統合での問題を可能なかぎり早期に発見することです 大きな問題を数回のタイミングで修正するよりも、小さな問題を何度も修正していく方が賢明です 常にリリース可能 どんなに悪いスプリント（イテレーション）だったとしても、その成果物は何かしらリリース可能なものでないといけません シンプル このスキームはチームのメンバ全員に毎日使われることになるので、ルールや定型作業は明確かつシンプルでないといけません 紙1枚にまとめた要約図（壁張り用） この図を見て分からないことがあっても構いません。この先を読んでください。 この図を見て分からないことがなくても、この先を読んでください。 この要約図はPDFでもダウンロードできます(DL) バージョ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/hagayu/agile/
Alternative Proxies:
[本]塹壕よりScrumとXP | Ryuzee.com