タグ

xpに関するtenkomaのブックマーク (7)

  • フロー効率性とリソース効率性について #xpjug

    XP祭り2017のセッションのスライドになります。 http://xpjug.com/xp2017-session-a5-1/ 元ネタは以下です。 http://i2key.hateblo.jp/entry/2017/05/15/082655 ※CCPMの表記について一部誤解を与える部分がありましたので、表記を削除いたしました。 2017/09/21 0:27Read less

    フロー効率性とリソース効率性について #xpjug
  • kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥

    Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方(ビジネスモデル)に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー(経営者)にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい!・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、

    kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
    tenkoma
    tenkoma 2011/06/01
    いま読んだ
  • ユーザストーリーの概要

    by Scott W. Ambler, Copyright 2003 ユーザストーリー(Beck 2000)は、XPプロジェクトチームの主たる開発成果物の1つにあげられています。ユーザストーリーとは要求を非常に高いレベルで定義したもので、開発者が実装作業をそれなりに見積もれるぎりぎりの情報だけを含みます。ユーザストーリーは、顧客(XPのプロジェクトでは利害関係者は顧客と呼ばれます)と話をするためのメモと考えるとよいでしょう。図1を見ると分かりますが、ユーザストーリーは小さいものです。ユースケースよりもずっと小さいものです。XPでは、ユーザストーリーは2人のメンバーで1つの反復/サイクルの間に実装できるものでなければなりません。そのため、1週間単位で反復を行なっている場合には、ユーザストーリーに記述するのは1週間分よりも少ない作業にしなければなりません。 図1. ユーザストーリーの例 学生は

    ユーザストーリーの概要
    tenkoma
    tenkoma 2011/03/23
  • XP祭り関西2011 井芹さん発表

    しんすく(け) さん。 @snsk ライブラリの学習に単体テストを使う!!なるほど!!自分ドキュメントにもなるという。 (live at http://ustre.am/tehN) 2011-01-29 14:08:24

    XP祭り関西2011 井芹さん発表
  • Unthinkingly.com » Extreme Programming vs. Interaction Design

    This is a copy of this: www.fawcette.com/interviews/beck_cooper/ Which no longer exists but you can find a flaky copy of it here: http://web.archive.org/web/20060613184919/www.fawcette.com/interviews/beck_cooper/ Excerpted here COMPLETELY WITHOUT PERMISSION PLEASE DON’T SUE ME JUST GET YOUR SITE WORKING AGAIN. Extreme Programming vs. Interaction Design When two development design visionaries me

  • iandeth. - とある企業のシステム開発部に属する身として eXtreme Programming を業務や案件に適応する際の課題点/問題点

    自分の属する開発部はバリバリ「フォーターフロー型開発プロセス」が主流です。幾つか外注パートナー企業とも仕事をしましたが、未だにアジャイルやXP等の「反復型開発プロセス」が常識となっている開発部隊に出会った試しがありません。さらに言うとオブジェクト指向プログラミングを得意とする開発者にも出会えた試しがありません(悲)。そんな中で、うちの開発部でも「いい加減、予測通りに事が進んだ試しが無いウォーターフロー型開発プロセスから脱却しようよ」という声がごく一部ながらも(上層部で無く、現場層から)聞こえ始めてきています。そんな現場層の一人である、とある同僚が部内メーリングリストにはてなでのXP導入例を紹介してました: 「はてな」ではXPを取り入れていて、1時間〜1日で仕様決定からリリースまでやってしまうそうです。http://shibuya.pm.org/slides/200304/hatena.pp

    tenkoma
    tenkoma 2007/07/10
  • 小野和俊のブログ:そして、ペア・プログラミングが始まる

    ここ数日、私はずっとペアプログラミングをしている。 ペアプログラミング自体は、これまでに何度も経験したことがある。 しかし今回の試みが今までと違うのは、 一日中、ペアプログラミングしかしないという点である。 1セット1時間半、15分の休憩を入れて、 ドライバーとナビゲーターを交互に入れ替えて毎日4セットやる。 このところ、これを何日も続けている。 こうやって、ある程度ストイックに続けてみることで、 わかってきたことがある。 それは、ペアプログラミングにはメガトン級の破壊力があるということだ。 プログラマーは絶えず誘惑にさらされている。 調べ物でウェブを見たついでに何時間もネットサーフィンしてしまったり、 考えたことをメモするついでに2時間かけてブログを書いてしまったり、 仕事の用事で知人に IM したついでにしばらくだべってしまったり、 Twitter に書き込んだついでに Friends

    小野和俊のブログ:そして、ペア・プログラミングが始まる
  • 1