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

看板Translate-CS作者 (Zzz...)時間11年前 (2013/03/17 02:16), 編輯推噓0(000)
留言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)
文章代碼(AID): #1HHBRifS (Translate-CS)
文章代碼(AID): #1HHBRifS (Translate-CS)