課程論文心得

首先，所讀這一篇的論文名稱為『Agile Development and User Experience Design Integration as an Ongoing Achievement in Practice』 所以著重點在于用戶體驗設計要怎麼融入敏捷開發的探討。

什麼是用戶體驗？先說說 UX Designer 做些什麼嗎

第一次轉UX Designer就上手（上）

第一次轉UX Designer就上手（下）

看完內容後，總之 UX Designer 算是一種設計師，與理工背景的開發人員可是天差地遠，

他們比起宅宅開發者來說，要與用戶產生關係，繪畫、表達、心理學、與現實溝通，開發人員擁有技術並且完成目標，但是行為卻不是一般使用者，最簡單的說法是『為什麼做出來的軟體只有開發者會用？』如果在軟體的需求面向是開發者們的話，這也許還不是問題，但是要做出給一般人使用的軟體，這樣是行不同的。但是開發者的邏輯古怪到自己都不明白的機率是挺高的，因此會有 UX Designer。

借由 UX design，軟體將會有耐用性、易上手、輕便化 … 等，這讓我突然想到總是會開發出根本用不著的功能，或者是相當難操作的功能。

但是要把 UX design 完全融入是有困難的，因為邏輯思維不同的人，是很難協調的，又或者會互相侵蝕。

開始談談論文的內容

這一篇論文，主要是 觀察 ，也沒有觀察到所有目前的運行方式。換句話說，不會存在唯一一個好的開發方式，根據組織的規模和文化背景，所適用的運行方式也會有所不同，在理論上百分之百照抄別人的做法運用在自己的發開方式，但是可以藉由論文中觀察的幾點來學習我們的開發方式大概需要的是哪些面向需求。

而當開發人員是怎麼樣類型的人，就可能需要運用哪些方式，這些都是需要去探討的。外國也許按照它們的方式走成功，但並不代表按照一樣的作法一樣會成功，這就所謂 新方法論 。新方法論沒有絕對的方法，說來有點玄，也就是沒有固定方法就是方法！

由於組織規模不同，彼此部門又要互相協調，在設計與開發之間的不同在於時間的週期不同，工作類型的方式不同，如果是大規模組織，『提高內聚力，降低耦合度』因此專業分工的類型將會在 Study 1 中被提及，這麼考量是有它的原因在的。

而文藝復興時期的全才－達文西類型，則可以在 Study 2 中被提及，每一個人都必須學習一點別人的領域的項目，這樣可以互相考量、共同承擔，來分散思考風險。但這樣對於一般人是相當困難的，如果是菁英組織的運行，大概就是長得這樣。

在最後的 Study 3 中，雖然使用傳統的瀑布式開發，這種神祕的設計大於開發組合相當異常，但也許是一種新的導向。在往後的時代中，當技術相對成熟穩定時，面對的將會是設計需求大於開發需求。

---

RESEARCH METHOD

這裡提供三種 Ethnography (社會學的一種寫作文本，中文翻譯：民族誌) 來探討敏捷開發人員和用戶體驗設計師的配置方式。

A. In the field

(田野調查的區域，民族誌運用田野工作來提供人類社會學的描述研究)

總共有三個組織中，四個團隊參與本次研究，參與研究的團隊中正在進行 UX 設計，而我們主要的工作是觀察他們的工作運行情況。

共計在三種情況進行觀察。

• Study 1: 觀察時間為兩個星期
• Study 2: 觀察時間為六天
• Study 3: 觀察時間為兩天

其中 Study 1, 2 過程中會涵蓋 Sprint 會議，而 Study 3 則只有涵蓋開發人員和設計師共處一室。

B. Thematic analysis

(專題分析)

C. Study participants

(研究參與者)

ACCOUNTS OF THE DAY-TO-DAY INTEGARTION WORK

Study 1

這項研究在 14 位 developer 和 2 位 UX designer，這兩位 UX designer 並不屬於 developer team，而是屬於該公司的 UX design team，因此他們並沒有參與 Sprint meeting、Standup、Retrospective，當然開發人員也沒有參與 design meeting，developer team 和 design team 在不同樓層工作。

開發人員描述道『將 UX design 與 agile develop 分開，是基於管理層面。』這很大的原因在於要將 UX 創造力發揮到極限，不能讓軟體工程的問題阻擋他們思考。

而在 Sprint meeting 中觀察到，UX designer 會提供一個 UX design 在 sprint meeting 前送達。但在隨後的 UX design 版本則是偶爾送到 developer 手上，直到 sprint 的最後一天仍持續修改，這表示著 developer 無法依靠 UX design 考慮相關的實作項目，所以大多數的關於 UX 工作將會分配在最後幾個小時來完成。

然而如果詢問 UX designer 是否已經意識到自己時間分配所造成的影響，則他們會回答說『沒有』。但事實上，在發送 UX design 時就已經造成相當多的問題。

[UX designer]: “That was never explicitly said to me … I thinks there was and still is visibility issues to do with what they’re doing and what their timeline are.”
這表示 UX designer 從來不知道這些事情，也從來沒有直接地被告知這項問題，也是因為不知道 developer 的運行工作和時程表。

當要澄清或者是修改 UX design 時，develop 會將問題寫下，並且要求 UX designer 在他們的 feedback meeting 中討論。

[senior UX designer]: “The visual designs are pretty much parallel to the wireframes … what kind of feedback do you want to give ?”
資深 UX designer 表示道：所有的視覺設計都是在線框 (wireframe) 的基礎上完成的，能有什麼樣的反饋？

developer 並不完全了解 UX design，只能依靠 UX designer 的批准和重構，這 “批准” 主要是對於敏捷開發中的維護和支持的組成用途，但是當 developer 向 designer 發問時，往往是溝通失敗的。

2pm: There is some problem with the visual design from UX [hadn’t arrived yet]. Project manager’s been trying to get in touch with the interaction designer, however can not get in contact - mobile switched off. Project manager has heard that UX are moving desks (not all the visual designs have been delivered since the developer feedback session).

上述內容看得不明白，難道是就是單純 PM 得不到完整的 visual design，因此也就不能向互動工程師聯繫嗎？

Study 2

小型手機軟件開發的公司，這一間公司有兩支團隊，每一隊有 5 名 developer 和 1 名 UX designer。其中 UX designer 設計非功能性描述和 screen mock-ups，這幾個項目將可以幫助 developer 參考進行開發。

mock-ups 相當於一種 prototype 可以支持動作的描述，通常會帶有基礎的 action code，關於 mock-ups 的相關工具有很多，但是通常價格不菲，邊設計還能自動幫忙產生代碼是不容易的工作。網路上找不到相關的解釋，就先這樣頂替了，相較於一般手繪製圖和文件描述，這樣的方式更為容易了解。

在他們會議中，每一個角色(QA, scrum master, product owner, UX designer, developer) 都參與討論會議，創造共同意識和共享決策責任。

9:30 [developer]: How should tabs appear, is ad always right-most tab ? … UX designer tells the developer what whould happen: As new chats come in ad tab moves over to right-most tab.

開發人員: 分頁到底該如何呈現，而廣告要固定在最右側的分頁嗎？ … UX designer 告訴我們應該「當新的聊天訊息進來時，廣告要移動到最右邊的分頁嗎？」

[Product owner]: Still waiting on response for some questions from the client.

Product owner: 這仍然在等待顧客的回報訊息

[QA]: Kind of hard to do QA if we don’t have the answer … wayry of starting stories without behaviours which means we might have to change thins and that wastes time.

QA: 這件事情很難做確認，如果我們沒有接收到回報，做的任何修改也許只是浪費時間，無法確定品質。

[UX designer]: Do them anyway, they might need to go through a number of iterations before they agree this is what they want … it’s better of they see something working as soon as posssible.

UX designer: 先把這問題放一旁，這需要多次迭代才能確定這是他們想要的 … 如果他們需要高效工作，則這個方式可能比較好。

[QA]: What if an ad coes in at exactly the same time as a chat ?

QA: 那如果廣告作為一個新的聊天訊息出場的話呢？

[UX designer]: That’s extreme edge case and probably very hard to test. So leave it. QA agrees.

UX designer: 這是一個相當極端的方式，非常難測試，所以先不要管這個。

這些對話通常在每一天的工作中進行，詢問另外一個團隊問題，而另外的團隊注意這些問題。

[UX designer]: “… if developers come up with issues, these are discussed on a case-by-case basis as they come up … There are lots of small things which are easily worked out on a day-to-day basis”

UX designer: 如果 developer 在每一個 case 基礎上想出了問題，這些小問題很容易在每日解決。

從會議過程中，主要，我們可以發現的每一個角色都參與了 UX design，同時也在職權外貢獻了他們的想法 - 例如 UX designer 建議在極端情況忽略 QA testing，而在 QA 沒有指責 UX designer 所做的 QA 決策，他們接受這項意見並沒有發出任何評論。其次，在這個 UX design 討論議題中也一起討論了 non-UX 的問題(如這個 QA testing 問題)。

這次的會議的下一步行動，包括實現解決方案和傳達問題給客戶。所有的角色參與討論導致決策同時考慮的設計價值和技術考量。

而在會議中，有 developer 向其他人簡單說明，他在網路空間上有一些之前專案製作時替換視覺設計的文件可以參考，這可以讓 UI designer 可以接受這些更改的項目，增加信服力。

[UX designer]: Sometimes the developers’ decisions are better, as they are much closer to the implementation. 有時候開發者的決策會更好，因為他們更接近實作。

Study 3

在非常小的公司進行，有 1 名 developer 和 2 名 UX designer，他們擅長瀑布形式的開發，在開發過程中 developer 和 UX designer 在同一間辦公室工作，目標是使得設計和開發更接近。正如 Study 1 的時候，發現 developer 會根據 UX designer 設計的線框 (wireframe) 和 visual design 努力地工作。

觀察兩天後的結果如下:

在一般的情況下，UX designer 通常和 developer 在不同樓層工作，developer 也表示他們很少去找 designer 討論遭遇的問題。

[developer]: We often find things that don’t work, but we don’t go back to design. We just do our best. 我們常發現很多事情並不會 work，但是並沒有回去檢討設計，單純盡力而為。

在這種共同工作的情況下，designer 給予了一些回應。

[UX designer]: This style of working means we can collaborate in order to get our points across, rather than dictate because there’s no communication going on. 這種工作方式可以讓我們的觀點交換，而不是因為沒有通通合作的命令。

[Head of UX]: And when we first met with the client, the first thing they did was to present to us the findings of that initial research. So we can then go and propose what would bee the next step, which is quite different from any other type of work we’ve been invited to get involved in.

在大多數的情況，不確定性，設計師在現場談話的記錄:

[visual designer]: I just feel like I’m not getting any-where.

[IA]: I also feel that way.

但是對於另一個情況下

[developer]: Just cover the site map.

developer 和 designer 共同工作

• 可以相互討論跟顧客對談時的內容 (當時在場的感受不同)
• 目標計劃做些什麼，訊息可以提前知道。(想要做第二個版本)
• 「這個設計會不會很難實作？」這些問題將會很快被反應出來。

[developer]: It would probably be just as easy.

---

THEME FOR ACHIEVING INTEGRATION

A. Integration as expectations about acceptable behaviour

在 Study 1 中可以發現，如果將兩者隔離，很容易造成規劃的浪費和開發者在最後期限前超時工作。UX designer 同時跨越多個專案進行設計，丟出設計之後就沒有可接收開發者的反饋，只有等到 sprint meeting 的反應才重新設計，這時可能已經為期已晚。

在 Study 2 中可以發現，頻繁確保兩者之間有相互支持，並且在 UX design 和代碼之間可以互相溝通，相較于 Study 1 上，溝通性有上升，但這些遭遇的問題將會在每個人參與討論會議的過程中的一部份。

在 Study 3 中，每一個成員都有機會被其他角色問到自己領域的問題，同時也可以在與客戶討論中的觀察，在隨後討論。這都歸因于他們在同一間辦公室工作。

B. Integration as mutual awareness

相對于 Study 1 中，Study 2, 3 擁有了共同享有決策的責任，同時提高了互動上的認識。

長篇大論

只求軟體開發的工程方法，最近上敏捷方法，教授開始講到了始祖 …

於是上演了輪番翻譯的戲碼，讓各種同學參與這份大型工程，關於翻譯的同時，深刻地理解到這也是為什麼無法接觸國外的最新資訊啊，曲解、誤解、亂解 …

我的語言記憶體如此小，卻搭載世界最複雜的語言。

序

In the past few years there’s been a blossoming of a new style of software methodology - referred to as agile methods. Alternatively characterized as an antidote to bureaucracy or a license to hack they’ve stirred up interest all over the software landscape. In this essay I explore the reasons for agile methods, focusing not so much on their weight but on their adaptive nature and their people-first orientation.

Probably the most noticeable change to software process thinking in the last few years has been the appearance of the word ‘agile’. We talk of agile software methods, of how to introduce agility into a development team, or of how to resist the impending storm of agilists determined to change well-established practices.

也許在這過去幾年最引人注目對軟件過程的思考的改變 - “敏捷 agile” 一詞的出現。我們將談論如何將敏捷軟體方法(agile software method)引入到開發團隊，或者如何抗拒即將到來的敏捷提倡者所帶來的風暴，這風暴將改變原先建立的好的業界實踐方法。

This new movement grew out of the efforts of various people who dealt with software process in the 1990s, found them wanting, and looked for a new approach to software process. Most of the ideas were not new, indeed many people believed that much successful software had been built that way for a long time. There was, however, a view that these ideas had been stifled and not been treated seriously enough, particularly by people interested in software process.

這新運動來自于 1990 年起不同人對於軟體程序的努力，他們發現和找到一個新的軟體程序。大多數敏捷方法的想法並不新，大多數人認為很多成功的軟件本來就有內置這種方式很久了，的確是有的，然而有一觀點指出，這些想法對於對軟體過程感興趣的人眼中並沒有受到重視，甚至被受到抑制。

This essay was originally part of this movement. I originally published it in July 2000. I wrote it, like most of my essays, as part of trying to understand the topic. At that time I’d used Extreme Programming for several years after I was lucky enough to work with Kent Beck, Ron Jeffries, Don Wells, and above all the rest of the Chrysler C3 team in 1996. I had since had conversations and read books from other people who had similar ideas about software process, but had not necessarily wanted to take the same path as Extreme Programming. So in the essay I wanted to explore what were the similarities and differences between these methodologies.

這篇文章也是新運動的起源一部份，最初發表于 2000 年 7 月。作為嘗試了解這文章一部份，您必須知曉這篇文章的風格如同其他大多數我寫的文章。在很幸運地與 Kent Beck, Ron Jeffries, Don Wells 共事後，我已經使用極限編程 (Extreme Programming) 好幾年。從 1996 年的 Chrysler C3 team 那時。我有機會與別人互相交流資訊和書籍來得到他們對於軟體過程中的類似想法，但即使是極限編程 (Extreme Programming) 也沒有一定要採用一樣的走法，所以在這篇文章中，我想要探索這些方法間的異同。

My conclusion then, which I still believe now, is that there were some fundamental principles that united these methodologies, and these principles were a notable contrast from the assumptions of the established methodologies.

以我的話來說，我至今仍相信那些方法一定有一些共同的基本原則，這些原則可能會從原本既有的(主流)方法假設中有明顯地對比。

This essay has continued to be one of the most popular essays on my website, which means I feel somewhat bidden to keep it up to date. In its original form the essay both explored these differences in principles and provided a survey of agile methods as I then understood them. Too much has happened with agile methods since for me to keep up with the survey part, although I do provide some links to continue your explorations. The differences in principles still remain, and this discussion I’ve kept.

這篇文章將會一直是一篇這個網站最熱門的文章，也意味者我會感到使命去保持這篇文章的更新。在文章原始架構中，會探討我所了解的這些原則的差異和提供敏捷方法的調查。當我在調查的同時，敏捷方法已經發生了變動，但仍我也提供一些鏈結供您探索，這些原則的差異和討論內容仍會保留在這篇文章中。

Most software development is a chaotic activity, often characterized by the phrase “code and fix”. The software is written without much of an underlying plan, and the design of the system is cobbled together from many short term decisions. This actually works pretty well as the system is small, but as the system grows it becomes increasingly difficult to add new features to the system. Furthermore bugs become increasingly prevalent and increasingly difficult to fix. A typical sign of such a system is a long test phase after the system is “feature complete”. Such a long test phase plays havoc with schedules as testing and debugging is impossible to schedule.

大多數軟體開發是一個混亂的開始，常常以一句話代以概括 ”撰寫！修復！“，這些軟體在撰寫時不用事先有基礎的計劃，也不用系統架構，將由短期項目討論就可以拼湊起來。這確切在系統很小時可以運作，但當系統越大時將會變得相當困難去增加新的功能。此外，BUG 也會越來越普遍見到，且越來越難除錯。這典型系統是在功能齊備後，才經由長時間的測試階段。這麼長時間的測試階段將嚴重破壞測試和除錯的行程，使得行程根本無法安排。試階段起著嚴重破壞的時間表為測試和調試是不可能的安排。

The original movement to try to change this introduced the notion of methodology. These methodologies impose a disciplined process upon software development with the aim of making software development more predictable and more efficient. They do this by developing a detailed process with a strong emphasis on planning inspired by other engineering disciplines - which is why I like to refer to them as engineering methodologies (another widely used term for them is plan-driven methodologies).

起源運動將要改變這種方法的概念，這些方法論所施加的紀律，將協助軟體開發變得更可預測和更有效率。他們將透過製定詳細的過程，這些過程特別強調設計，靈感來自于其他工程學門- 這就是為什麼我喜歡稱呼它們為 ”工程方法 enginerring methodologies“ (對於他們來說，另一個廣泛使用的術語為 “計劃驅動方法 plan-driven methodologies”)

Engineering methodologies have been around for a long time. They’ve not been noticeable for being terribly successful. They are even less noted for being popular. The most frequent criticism of these methodologies is that they are bureaucratic. There’s so much stuff to do to follow the methodology that the whole pace of development slows down.

工程方法已經存有一段歷史，它們都沒有被注目那背後可怕的成功，它們相當少被認為是受流行的，常見的批評為 ”它們是官僚政治的“ // 相當死板的 ？ 。有相當多的項目都遵循這套方法論使用緩慢的發展步伐。

Agile methodologies developed as a reaction to these methodologies. For many people the appeal of these agile methodologies is their reaction to the bureaucracy of the engineering methodologies. These new methods attempt a useful compromise between no process and too much process, providing just enough process to gain a reasonable payoff.

敏捷方法的發展就是反映這些工程方法論，對于大多數的人而言，敏捷方法的吸引力是反映出工程方法的官僚主義，這些新方法是在沒有進展和太多進展中的折衷妥協方案，提供一種恰當的過程來獲得合理回饋。

The result of all of this is that agile methods have some significant changes in emphasis from engineering methods. The most immediate difference is that they are less document-oriented, usually emphasizing a smaller amount of documentation for a given task. In many ways they are rather code-oriented: following a route that says that the key part of documentation is source code.

這一切的結過是，敏捷方法從工程方法中有顯的改變。最明顯的差異是少寫文件(文件導向)，通常強調少量文件的工作，在許多說法上，它們更偏向代碼導向(code-oriented: 文件的關鍵部分是源代碼 source code)

糟透的軟體開發

在土木工程中，建造一個橋來說，通常在設計草圖完成後，即使換了別的公司繼續接按下去做，一樣能按照這個設計草圖完成。如果在施工過程中遇到問題，通常問題也不會太難，而且非常容易被解決。

在了解這些設計草圖後，可以發現勞心者和勞力者的工作是分開的，設計由專家耗費心力完成，而實作能由工人來按照草圖，因此這些設計草圖是確保工人們能看得懂，但是在軟體工程中，大部分都是勞心者和勞力者集一人之中。

施工是一個相當耗費成本的工作，在早期的軟體工程開發專家，希望能將土木工程的方法轉移到軟體工程上。讓專家進行設計，再讓低成本的工作人員來完成實作，設計費用通常比實作費用來的低，工程師仍有高低薪之分，新一代的低薪工程師呢！

專家寫出來的設計草圖，要讓 programmer 看得懂，通常是非常困難的。即使是 UML 圖，雖然在紙(草圖)上看起來相當不錯，但是實作上的問題卻相當多，土木工程的設計圖可以經過數學模型去測試，但是軟體工程的設計圖只能由人腦去找到邏輯BUG，即使是設計熟練的專家，要設計出不會有實作問題的草圖也是常發生的。

接續著剛剛討論的造橋問題，設計費用只占了全部花費的十分之一，按照草圖寫 code 是相當簡單的，根據 McConnell 調查大型專案，只有 15% 的成本進行程式撰寫和測試(這裡我們需要勞力成本比例越高越好)。即使把其他成本混在一起，設計仍占了 50% 的成本比例。軟體工程只是工程分枝中之一，這其中一定有蹊蹺。

結論

• 軟體的建造相當便宜，甚至於免費(只淤需要電腦和編譯器，沒有實體。)
• 軟體受設計影響，因此需要有創造力和有天賦的人。
• 俱有創新的程序不容易去規劃，可預測的性質甚至變成不可能。
• 我們需要不同於傳統工程的方法，來解決這詭異的軟體工程的開發程序。

常常有開發者收到客戶不斷地改變需求，但是改變需求是常態，但是對於開發者而言卻是想不透的謎。這表示當初需求並沒有弄完整，但是也不能說像客戶簽訂契約——表示在軟體完成前，需求都不會改變。需求改變是很正常的，這客戶來說這個契約反而不合理。

按需求收費，加什麼功能要多少錢？估算收費也是不好量化，也會根據產品使用的方式和使用者有關，因此品質的水準與費用是不好預估。客戶以為“軟”體容易修改，但並不是每個需求都容易修改，通常會耗費大量的時間去滿足客戶的需求。

如果需求不穩定，就得不到可預測的計劃去完成軟體。

真的不可預測？

在 NASA 太空軟體開發中，他們的計劃是可以預測的，但這也只是一個特別的例子，主要原因是長期時間，龐大的團隊，穩定的需求。

更可怕的是，如果客戶需求不穩定，卻告知有可預測的計劃，這樣自欺欺人的行為相當令人詬病。

”可預測“是令人相當渴望的，這導致一開始擬定的計劃越飄越遠，最後計劃將會分崩離析。

按照方法論運行總是美好的，但是在軟體開發上必須要捨棄掉，但這樣的舉動相當困難，要捨棄一直以來處理事情的方式，但也並不是讓事情處理變得無法控制的混沌，捨棄“預測”吧！

控制 “不可預測”程序

使用迭代方式，並且將計劃越短越好，看起來就是多方面失敗的開始，但卻有機會看來進步的地方，當計劃越短，就能越早知道反饋(feedback)。

文件可以隱藏缺失，沒有經過測試將會有更多的缺失。

XP 一周或兩周，SCRUM 一個月之類的，越熟練則會越短時間。

=====

並不是每個工程師都像零件，換個人就可以繼續運行。

不可更換的人零件都跑了，也就是最有創意的人力都走了，可更換的人卻留下了。

Programmer 是有責任的專業人員？

早期是工廠的運行模式，希望能讓工人多做一點事情，來讓成本降低。

每個 programmer 是獨特的，產出的代碼也都不同，每一個人的創意不同，把人當資源就錯了。

施工和設計能不能分開？施工只是由編譯器來，因此軟體全是文創業，算是設計類型的職業。

敏捷開發

重點筆記

XP 極限開發

簡介

溝通為其特色，某方面來講有過於親密的傾向。
如果程序猿們按照 Pair Programming 的方式運行，被當成基佬們也不意外。

1. Fine scale feedback  細部回授
    * TestDrivenDevelopment via ProgrammerTests and CustomerTests (were UnitTests & AcceptanceTests) 
    * PlanningGame 
    * WholeTeam (was OnsiteCustomer) 
    * PairProgramming 
2. Continuous process rather than batch  非批次流程
    * ContinuousIntegration 
    * DesignImprovement (was RefactorMercilessly) 
    * SmallReleases 
3. Shared understanding  分享所知
    * SimpleDesign (DoSimpleThings, YouArentGonnaNeedIt, OnceAndOnlyOnce, SimplifyVigorously) 
    * SystemMetaphor 
    * CollectiveCodeOwnership 
    * CodingStandard or CodingConventions 
4. Programmer welfare  員工福祉
    * SustainablePace (original name: FortyHourWeek)

• 強調團隊溝通，確保每一步都是正確且穩定。
• 強調個人思考，藉由溝通引出每個人的思考。
• 測試驅動開發，先有測試資料，才開始撰寫。

對於台灣人

• 強烈抨擊文件不是首要任務，英文不好，還不如不要用英文撰寫。
• 英文文件能提高溝通力？請自行反思。

回過頭來，看待敏捷

• 文件越簡單越好，花在寫文件的時間可能太多。
• 同一室工作，最多 10 人一室，以免過度干擾。
  • 溝通滲透－簡單說就是偷聽長知識。
  • 惡性溝通滲透－聽到沒有用的資訊。
• 駐點客戶的存在
  • 與工程師溝通，確保需求符合，常駐程序猿們的公司，改完馬上可以詢問滿意。
  • 通常專案的費用，額外含駐點客戶員工的薪水。(畢竟不常在原公司)
• 定期交貨，一分錢一分貨
  • 功能做到哪就給多少錢，風險分散。
  • 如果做失敗，可以即早治療。
• 程序自動化測試
  • 採用連續整合 (可以去 CI 網站 看看)
  • 每天修改的程序，隔天起來就能查錯。

行動

• 請參閱考古題條目，將會給你更多的執行項目。

---

做了一點小修改，馬上就能得到回饋，所以能敏捷。
敏捷不是快速，敏捷不是力量。雖然有點慢，但是穩定運作，避開不好的危機。
我們不是工廠！不是重複做相同的事情。

Lean Development 精實開發

1. Eliminate waste 根除浪費
2. Amplify learning 大量學習
3. Decide as late as possible 盡晚決定
4. Deliver as fast as possible 盡早交貨
5. Empower the team 授權團隊
6. Build integrity in 整合思維
7. See the whole 眼觀全局

• 另一種軟體開發方式
• 敏捷開發－共同向善，督促所有人進步。
• 精實開發－剔除累贅，改善開發。

---

WHEN YOU ARE AGILE, YOU GET LEAN. 敏捷之後 自然瘦身

SCRUM

用以輔助 XP 極限開發的一種敏捷管理法

Role 主要角色

• Product Owner
  • 產品負責人，負責在有限的時間和預算將產品做到最好。
  • 下面的人全照他的想法建造產品。
• The Team
  • 團隊必須有產品製造過程中的技術。
  • 在每一個 Sprint 中，產出或增加軟體潛力。
    • The Team Resource
      開發前先餵點飼料，給予團隊之後會需要的資源。
    • Manual
      每一次 Sprint，制定軟體確切的模式(樣貌)，這比寫文件更困難。
• Scrum Master
  • 一個人管理和疏通所有程序猿、確認生存狀況以及環境障礙。
  • 程序猿通常有溝通上的障礙，需要有人引導。
  • 確認每一個人的進度，並且不會某些人有卡在相同問題(愚蠢狀況)。

Meeting 會議形式

• Sprint Meeting
  • 產品負責人將會釋放出新的功能項目。
  • 團隊要根據技術去完成它們。
  • 在會議結束後，確定每個程序猿都知道如何去實作。
  • 會議兩周一次。
• Sprint Demo
  • 開會期間，展示上次 Sprint 要求完成後的結果。
  • 同時檢查是否合乎預期，以及當初是為了造什麼來的。(工作不飽和，可能造出非物。)
• Sprint Retrospective
  • 回顧和檢討，改善開發環境，可能是採用開發工具替換。
  • 或者是會議、討論形式的改善。
  • 最後同意並確定檢討後遵守的條目。
• Daily SCRUM
  • 每個程序猿簡單報告這兩個星期做了什麼、中間遇到什麼問題、下次要完成什麼。
  • 如果遇到的問題可以自行解決，也可以協助或告知其他程序猿。
  • 這些技術或者是其他問題將要在 Daily SCRUM 後被解決。

Retrospective - 中文意思: 回顧
Sprint - 中文意思: 衝刺
Scrum - 中文意思: 爭球

Artifacts 神器

• Increment 增量
  • 每次 Sprint，將軟體潛力增加，藉由當初定義 ‘完成(done)’ 為標竿。
  • 完成(down)
    每況愈下，完成的定義越來越嚴苛。最後如下定義：

    1.    All the PO’s defined acceptance tests run,
    2.    The system is fully integrated and running on the production servers,
    3.    All the manual pages are up to date,
    4.    The code is clean and well-factored,
    5.    All the programmer tests are running green.
    

  • 由於 ‘完成’ 定義嚴苛，即使有缺陷 (Bug)，也能在短時間內修復。
  • 小檢查、小修復比起改造整個產品成本更低。
• Product Backlog 產品待辦
  有序地完成需求項目，產品負責人和團隊要一致認可。
• Sprint Backlog 衝刺待辦
  確認每一個 ‘done’ 的完成，看得到完成進度。

---

期中考古題

以下內容為本人網路搜索的轉換，如有錯誤請多多指教

• 1 張氏軟體公司有張一張二張三張四等四位工程師及客戶公司派來的駐點使用專家王五， 另聘工讀生工一工二兩位。

  • 1.1 公司現場應如何佈置

    Answer. 
    1. 分 Common 及 Cave 兩區、和四周的 White Board(白版)
        **Common 區**: 兩人一組，在一台大尺寸螢幕前工作 (pair programming)                  各組可目視、交談、溝通
        **Cave 區**: 個人處理 e-mail，電話，閱讀資料等
        **White Board**: 供討論用
    2. 採用 Central Desk (相較於 U-pod) 配置，可以相互看到對方的工作區。
    3. 細節補充:
        1. 勿用需工人搬動的傢俱，用簡單桌子即可
        2. 電源線，網路線走底下或頭上，易接到桌子
        3. 椅子勿節省，有人因背痛要跪姿椅或升降桌
        4. 白板要很多，含輪子白板，相機白板，動態顯示板(連接投影機,如顯示 build 狀況)
        5. 見下圖 Central Desk 有 eye contact，U-Pod 則有 ear contact 且易看別組螢幕
    

  • 1.2 探索需求 誰做 何處做 產生何文件

    Answer. 客戶公司兩位資深人員做需求分析，在客戶公司做，產出功能清單及相關特性、限制、偏好。
        分析工作如下：
        1. 列出使用者名單
        2. 選取使用者樣本 
        3. 觀察、訪談(2)，與之開會 
        4. 開會要充份討論 
        5. 會後得到功能清單，及相關特性、限制、偏好 
        6. 功能分次開發後，做喜好度調查
        最後派遣一位當作駐點客戶給開發團隊即可。
    
        對於顧客
        * 顧客不明白他自己需要什麼
        * 顧客不願將他們的需要固定在一系列寫在紙上的條例中
        * 在價格和時間確定後，顧客堅持要求新的需要
        * 分析者與顧客的通訊太緩慢
        * 顧客不參加回顧或無法參加回顧
        * 顧客缺乏技術上的知識
        * 顧客缺乏對軟體開發的知識
        ----
        對於分析師
        * 是否可行
        * 是否在規定的時間裡可以完成
        * 價格上是否負擔得起
        * 是否合法
        * 是否符合道德
    

  • 1.3 Scenario 誰做 文件為何

    Answer. 駐點客戶說明，並寫出 Scenario 和 User Story 文件。
        * 寫使用情節 (Scenarios) 並與開發者確認使用畫面，
        * 撰寫方式：由簡而繁、由正常到異常
    

  • 1.4 Acceptance Test Case 誰做 文件為何

    Answer. 駐點客戶寫，並且產出 驗收案例文件。
        * 由使用情節寫驗收測試(需準備大量 data )
        * 驗收測試應在程序員寫代碼之前就寫好。
        * 根據使用使用操作，會產生何種操種介面或者是輸出。
    

  • 1.5 CRC session 誰做 文件為何

    Answer. 工程師五人以內圍坐，產出 Class Diagram, Sequence Diagram 等設計圖文件
        * 群體智慧，設計出好的程式架構
        * 切割類別(C)、每個類別自己要做什麼(R)以及類別的合作類別(C)
    
        架構設計會議，準備 CRC Card (Class-Responsibility-Collaborator cards) 
        以下為 CRC Card 的欄位項目 (相當於 O-O 架構的設計)
        * 資訊保持者(information holder) ─ 知道或提供資訊，也就是說保持事實，例如郵件地址，帳號，交易記錄等；
        * 結構者(structurer) ─ 保養物件間的關聯以及與這些關聯相關的資訊，例如檔案系統的folder；
        * 服務提供者(service provider) ─ 執行工作，一般來說提供運算服務，例如信用授權；
        * 協調者(coordinator) ─ 委託工作，例如交通號誌燈，文字處理器的字體管理；
        * 管制者(controller) ─ 決定並指揮它物的行動，例如交通指揮員；
        * 介面者(interfacer) ─ 支持系統內外各部門的間通訊，例如ATM的金錢出口。
    
        決定以上內容後
        * 可以撰寫 Class header 和 Method header 的簡單說明。
        * Class header 由其下 Method header 匯集篩選而成。
    

  • 1.6 Dispatching and Scheduling 誰做 文件為何
    

    Answer. 工程師們根據自己的狀況，將認領的類別 Class 估算工作天數。產出每個人要在這段期間內完成那些功能項目的文件。
        Dispatching - 派工 (有人可能完成不了某些項目，著手工作分配)
        Scheduling - 時程 (功能所需完成時間進行分配)
        * 每一回合 - 平均三周，做一次派工和時程規劃 (工作分配，時間分配)
        * 每三回合 - 平均兩個月，交貨給客戶
    

  • 1.7 Unit test planning 誰做 文件為何

    Answer. 由工程師撰寫對於每個類別 Class method 的測試代碼 (根據之前 CRC 的討論)，產出 Unit test code
        * 這玩意必須在程式撰寫前開始，而且通常比源代碼還長。
        * Test code 又稱 Test-First Development。
        * 不知道算不算 **測試驅動開發** 前置作業
        * 每一個 method 根據參數、環境做預期結果的測試。
    

  • 1.8 Data structure design 誰做 文件為何

    Answer. 工程師，產生數據結構的 Class。
        * 除了工程師外，沒人辦得到。
        * 高級數據結構比一般數據結構好用，而且擴充性和彈性較強。
        * 通常內建標準函數庫就很好用
        * C++: #include <stack>, #include <queue>, ...
        * Java Collections Framework: ArrayList, Vector, Stack ...
    

  • 1.9 Algorithm design 誰做 文件為何

    Answer. 工程師，產出虛擬碼 pseudo code、設計草圖 design sketch
        * 虛擬碼不說自明，設計草圖就是圖形化的想法來源
        * 根據數據結構也有所不同。
        * 演算法也是有抽象層次 Abstraction levels，相互調用什麼的。
        * 要做 Trace test code 來 Debug。
        * 要做時間複雜度分析。
        * 同時簡化到可以在白板上，讓團隊審查 Group review。
    

  • 1.10 Coding 誰做 文件為何

    Answer. 工程師，產出源代碼 source code
        * 終於開始工作，還會一直被 Unit test code 
        * 程式易於閱讀、了解、維修，才是 **活著**
        * 強調重複利用別人代碼 (因為通常已經通過測試，不用 Debug)
    

  • 1.11 Unit testing 誰做 使用何文件

    Answer. 工程師使用測試軟件運行 Unit test code，產出測試結果。
        * 如 Java unit test，產出測試記錄檔，表示哪些 method test case 通過。
    

  • 1.12 Acceptance testing 誰做 使用何文件

    Answer. 駐點客戶手動測試，使用驗收案例文件，產出測試結果。
        * 手動操作所有驗收案例
        * 如果驗收案例太多，那也是駐點客戶疲累的地方。
        * 測試文檔，不外乎就是哪些連續動作 (Action) 通過或者是不通過
    

  • 1.13 Reverse Engineering Tool 何工序後可使用

    Answer. 在架構設計 (CRC) 後，便啟動這類型逆向工具。
        * 利用逆向工程工具 如 eUML2、AgileJ。
        * 工具將動態產生 Class diagram, Sequence diagram ... 等。
        * 協助設計草圖不偏離，同時能了解設計樣貌，幫助維護和修改。
    

  • 1.14 此軟體的需求有七個功能( user story ) 駐點使用專家規劃為三次交貨( release )工程師們規劃用兩個回合( iteration )完成第一次交貨的功能
    • 1.14.1 派工 (dispatching) 如何做

      Answer. 在 CRC 工作結束後，每個成員認領一項類別 Class 進行開發。而在每回合微調工作分配。
      

    • 1.14.2 時程 (scheduling) 的時間單位為何

      Answer. 平均 2-3 週
      

    • 1.14.3 工作中客戶公司會不會來催進度為什麼

      Answer. 定期交貨，以執行力達成承諾取信客戶，客戶只需固定時程檢驗進度。
      

1. 因有 Continuous Integration(CI) 使 Agile method 不須 integration testing. Explain it.

   Answer. 連續整合採用自動化的方式進行，每一天或者是固定時間，便會將團隊開發、撰寫立刻回饋分析結果，如此一來不用人工繁瑣的整合測試程序。
       * 這問題相當奇怪，因為連續整合也算是整合測試 ?
       * 連續整合不用人工測試，可以降低風險。
       * 連續整合隨時都有可以發布的版本。
       * 增加系統透明度。也就是說可以追蹤或者是預測發展趨勢。
   

2. Test-driven development 的 development, test 及 drive分別是什麼

   Answer. 因為在源代碼 source code 撰寫開始前，必須先把所有測試項目撰寫成 test code 或者是人工驗收的案例，
   * development 開發方式，做事的風格
   * test 測試，經由 test code, case, tool 產生預期結果和實際形況的差異分析。
   * drive 驅動則是根據測試結果驅使源代碼的修正。
   

3. 維修軟體時，應閱讀 sourse code 或 pseudo code? Why?

   Answer. Pseudo code，方便理解與快速找到要維修的地方。
       * 題目應為先讀哪一項，照理來講要先讀 pseudo code 再讀 source code。
   

4. Pair programming 何以能提高軟體品質?

   Answer. 一人撰寫一人修正，分散思考壓力，同時可以激發出創意，可以降低錯誤率、提升除錯效率。
       * 主要是分散思考壓力、增加思考廣度。
       * 缺點是開發時間會稍慢，但是品質不錯。
       * 編程能力水準相當才能相互激發，否則是純教導或者是管理功用。
       * [搞笑影片](https://www.youtube.com/watch?v=dYBjVTMUQY0)
   

5. Method interface 與 method header 有何相關舉例說明之。

   Answer. 
   1. method interface 指的是關於這個 method 參數型態和意義、以及額外調用的 method 說明。
   2. method header 指的是在 method 前面的說明，通常具有這個 method 如何快速簡易使用的說明。
           * 通常 method header 算是 method interface 的摘要，或者是組合使用的說明。
           * 因此 method interface 完成後，才會有完整的 method header。
           * method interface 指的並不是 java 的某種 interface 類別，而是類似 UML 有哪些 method 和 attribute，能提供做出什麼事情。
           * 別跟 class header 搞在一起，請弄清楚。
   

6. Data structure design 與 Algorithm design 有何關係

   Answer. 演算法中會調用到資料結構，根據搭配的資料結構才能估算時間複雜度，以及支持效果。同時，演算法也能針對搭配資料結構做最佳化。
       * 面相來說，Data structure 是工具 Tool。
       * 怎麼最佳化使用工具就是演算法的事情。
       * 例如: 資料結構的幾種操作的複雜度不同，調用操作的比率將會是演算法的重點。
   

Reference

Websites

1. 台灣敏捷苗圃
2. BLOG - 輕鬆談軟工
3. Wiki

Friends

• Iris
• 等待更多網友