Extreme Programming Explained

Embrace Change

By

Publisher: Pearson Education Limited

4.4
(70)

Language: English | Number of Pages: 224 | Format: Paperback | In other languages: (other languages) Chi traditional

Isbn-10: 0201616416 | Isbn-13: 9780201616415 | Publish date:  | Edition US Ed

Category: Computer & Technology , Professional & Technical , Reference

Do you like Extreme Programming Explained ?
Join aNobii to see if your friends read it, and discover similar books!

Sign up for free
Book Description
The new concept of Extreme Programming (XP) is gaining more and more acceptance, partially because it is controversial, but primarily because it is particularly well-suited to help the small software development team succeed. This book serves as the introduction to XP that the market will need. XP is controversial, many software development sacred cows don't make the cut in XP; it forces practitioners to take a fresh look at how software is developed. The author recognizes that this "lightweight" methodology is not for everyone. However, anyone interested in discovering what this new concept can offer them will want to start with this book.
Sorting by
  • 5

    Complete and easy to read introduction to values, principles and practices which Extreme Programming is based on, wrote by the "father" of XP.
    A book every modern software engineering should read. ...continue

    Complete and easy to read introduction to values, principles and practices which Extreme Programming is based on, wrote by the "father" of XP.
    A book every modern software engineering should read.

    said on 

  • 5

    假設你是一位研發人員拆解一電子商品研究,通常外觀、結構、尺寸,最容易模仿。其次為電路設計,因為看得見的零件、電路,都可以一一抄襲模仿。唯獨程式這個區塊,除非你有其他辦法取得原始碼或是編譯後的機械碼(可以反組譯研究),否則你只能觀察動作,猜測設計方法,功能越複雜的商品,就越難模仿設計。

    同樣在電子產品開發過程中,工業設計(產品外觀)與機構設計是技術門檻較低的,設計到一半,有經驗的工程師大多數可以立即 ...continue

    假設你是一位研發人員拆解一電子商品研究,通常外觀、結構、尺寸,最容易模仿。其次為電路設計,因為看得見的零件、電路,都可以一一抄襲模仿。唯獨程式這個區塊,除非你有其他辦法取得原始碼或是編譯後的機械碼(可以反組譯研究),否則你只能觀察動作,猜測設計方法,功能越複雜的商品,就越難模仿設計。

    同樣在電子產品開發過程中,工業設計(產品外觀)與機構設計是技術門檻較低的,設計到一半,有經驗的工程師大多數可以立即接手繼續設計。電路設計技術門檻更高一些,必須能看懂電路圖內隱含的設計概念,才能接續工作。軟韌體設計著重抽象思考能力,如果沒有說明文件或是相關概念,看別人的程式就像看天書,更別說接手別人的程式。

    以往我所經歷的韌體專案,都是獨立設計,所有的程式以及整體系統概念很清楚,只要不是太複雜的問題,都可以很快解決。不過產品功能越來越複雜,就開始需要分工與他人同步設計,以縮短開發時程。但是分工合作之後,有時反而解決問題會拖更久時間。

    複雜專案會由老鳥帶菜鳥,功能會一區一區寫,然後整合測試,發現奇怪情形就一起查問題。我要提醒的是,發生問題時,如果是菜鳥的程式問題,老鳥請花點時間幫幫菜鳥,如果問題拖了好幾天還沒解決,務必放下手邊的工作,幫菜鳥 Code Review,一定要看程式碼!不然瞎子摸象很難對症下藥,因為我曾經沒這麼做付出慘痛代價,信任菜鳥會依循標準設計、會找到方法解決,但是他始終找不到問題,因為忙手上的案子沒立即幫忙,拖很久還是沒解決,後來介入後發現整個程式架構不對,怎樣小修改都是無效的,必須重寫解決!

    一般獨立性高的工作,單兵作戰即可,各自負責各自專案,但是需要他人協助時,別人如何介入呢?可採搭檔程編解決。假設有A、B兩人平時各自負責自己的專案,每個禮拜抽幾小時時間,這禮拜A幫B看程式,下星期B幫A看看,這樣同事間有交誼往來,當某人有事請假,就可以臨時協助,不會不清楚別人在做什麼,而無法幫忙。並且互相檢查程式可以提升設計品質,以及設計功力。有些工作輪調安排不容易,但是這樣每週搭檔合作是簡易可行的。

    當工作全丟給某人處理時風險極大,只要他出勤不正常或是要離職,都會對該專案產生極大衝擊,搭檔程編是處理這類問題的好方法。有些工程師比較內向不主動,這樣也可以讓他多跟別人互動。

    搭檔程編,這個方法我是從 極致軟體製程 extreme Programming explained EMBRACE CHANGE 這本書學到的。

    said on 

  • 4

    This book shouldn't be useful

    But unfortunately it is..and badly! It is a
    very clear, effective introduction to the development
    style and discipline that 's trying to give control of software development back to programmers and away ...continue

    But unfortunately it is..and badly! It is a
    very clear, effective introduction to the development
    style and discipline that 's trying to give control of software development back to programmers and away from dumb managers,
    fluff vendors and the like. It does so through the application of a minimum of common sense and encouraging the creation of simple, effective software over the production of heavy, useless documentation. A useful conversation with a "good programmer with great habits".

    said on 

  • 5

    very interesting

    a must for every programmer and every software manager. I would like to read more examples just to have a clearer idea...

    said on