Re: [翻譯] Agile 的 11 個謠言與 2 個真相

看板Translate-CS作者AmosYang (Zzz...)時間11年前 (2013/03/17 02:16)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串3/5 (看更多)

※ 引述《PsMonkey (痞子軍團團長)》之銘言： : 標題: Re: [翻譯] Agile 的 11 個謠言與 2 個真相 : 時間: Sat Mar 16 14:07:22 2013 : : 果然要體會翻譯的困難，就去看不熟悉領域的東西 [核爆] : 這一兩年來大抵上都在看 web 開發的東西 : 一旦轉到軟體工程就炸光光 : : 以下是我覺得特別彆扭的地方： : : : 原文： : Scrum Pattern language was workshoped at PLoP 1998 : 翻譯： : Scrum Pattern 語言在 1998 年的 PLoP 發表。 : : workshoped 不確定是什麼意思。 : 不過查到 PLoP 是一個類似研討會的東西，所以用「發表」這個詞。 : : btw... 原文第一次用到這個字還打成 works hoped... : 害我又苦惱了一下 [淚目] : workshop, conference, seminar, summit, symposium, 甚至 congress 這幾個字都可以粗略地解釋為“一票人聚在一起嘴炮”,或著也可以稱為 “(學術)研討會” 每個字有它的特性，像 congress 就暗示著正式性(formality) workshop 則偏向於實際親手練習(hands-on exercise) 有些比較偏向科展設攤子(booth / poster)非正式地講解發表研究成果有些則是上台拿著麥克風嘴炮然後被質詢在幾百人面前被釘在牆上 ... : : 原文： : Please be aware: documentation is often unread, : often fails to communicate, : is used as a defensive tool and : is typically the second most expensive think on : a large software project (after rework). : : 翻譯： : : 請注意：文件通常沒人讀、常常傳遞失敗、被用來當作防禦武器、 : 是大型軟體專案中第二昂貴的部份（僅次於重作）。 : : fails to communicate 感覺就是怪... 該句在這裡有“詞不達意”的意思 (文件寫一堆卻沒講到重點) : 最後那個 second most expensive think on 也... : : 好吧，我承認我亂翻 [毆飛] think 應該是 thing 的誤植(typo) : 原文： : I advise letting stories span sprints in order to improve flow. : : 翻譯： : （謎之聲：版主帶頭違反版規） : : 理論上 story 跟 sprint 在 Agile（Scrum？）有特定意思 : 但是不知道這 span 要怎麼辦？（線性代數裡頭的我知道 XD） : improve flow 也是專有名詞？ Orz : 原文裡，這句是指正下句這個錯誤觀念: “user story (的大小) 一定要能塞進一個 sprint 裡” 所以可以翻為我建議，允許 user stories 橫跨數個 sprint 以改善開發流程易言之，得在紀律與彈性之間做適當的取捨，軟體工程不是物理定律，只是幫助大型專案運作的方法(guideline) user story 可以粗略地解釋為“功能(feature)需求” sprint 則可以解釋為“專案開發週期” (以 Scrum 來說，通常是 1 ~ 3 週) 詳情可看 http://en.wikipedia.org/wiki/User_story http://en.wikipedia.org/wiki/Sprint_(scrum)#Sprint : → PsMonkey:我是因為當版主所以去翻譯 XD 不然不會想碰軟工的東西 03/16 23:40 : → PsMonkey:軟工感覺很嘴砲，你看這篇原文感覺也是滿滿的嘴砲 [逃] 03/16 23:41 軟體工程的“工程”兩字就暗示著該專案的大小如果是一、兩人就能完成的小專案，的確用不到“軟體工程” 但如果是兩百人, 一小時薪水就要燒八千美金(還不含硬體設備、人事費用)的專案換你當老闆你也會千方百計想要確保這兩百人是有紀律的精兵部隊而不是烏合之眾一盤散沙, 這時候“工程”能力就能見功 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 98.26.14.35 補述, 關於 user story 簡單來說， user story 的大小並沒有一個絕對的限制以工時來計算， 8 小時到 80 小時都可接受小於 4 小時的大概只能算是個 task / bug / issue 大於 100 小時的大概得算是一個新的 project 這些用詞在大型軟體專案裡可以幫助在花費、時程估計上的溝通 task / bug / issue 拿來描述小事情 (做錯了或做差了還可以補救) user story 表示一定大小(sizeable)的花費、投資 (做錯了或做差了還會痛) 再上去的，就是做錯了或做差了會很痛 (尤其是痛在損失的時間) 再再更上去的，我就沒有體驗過了 :D 沒那個能力爬到那麼高的位置 ※ 編輯: AmosYang 來自: 98.26.14.35 (03/17 02:34) ※ 編輯: AmosYang 來自: 98.26.14.35 (03/17 02:39)