tag:blogger.com,1999:blog-1298974142445162186.post7636129456086070532..comments2024-03-19T15:58:12.198+08:00Comments on 搞笑談軟工: 什麼是笨?Teddy Chenhttp://www.blogger.com/profile/02066842119056439711noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-1298974142445162186.post-63277216985529532322015-10-07T12:58:37.648+08:002015-10-07T12:58:37.648+08:00一篇不錯的文章分享:
<頭腦>轉得又快又順而去做的一天能做許多事。
http://blog.udn....一篇不錯的文章分享:<br /><頭腦>轉得又快又順而去做的一天能做許多事。<br />http://blog.udn.com/oyt0915/31932271<br />永遠的向日葵https://www.blogger.com/profile/00162099479378875333noreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-21167407885729610342012-10-04T23:01:32.927+08:002012-10-04T23:01:32.927+08:00Dear Teddy,
非常感謝你的回答,對我幫助很大! 謝謝!!
^_^Dear Teddy,<br /><br />非常感謝你的回答,對我幫助很大! 謝謝!!<br /><br />^_^Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-47265753954537385262012-10-04T23:01:32.643+08:002012-10-04T23:01:32.643+08:00Dear Teddy,
非常感謝你的回答,對我幫助很大! 謝謝!!
^_^Dear Teddy,<br /><br />非常感謝你的回答,對我幫助很大! 謝謝!!<br /><br />^_^Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-70135314963366748832012-10-03T10:49:17.419+08:002012-10-03T10:49:17.419+08:00Hi 鄉民:
我昨天一整天都在台南,所以沒有時間回覆你。
1. 但是 Product Owner...Hi 鄉民:<br /><br />我昨天一整天都在台南,所以沒有時間回覆你。<br /><br />1. 但是 Product Owner 不斷面對客戶(擔心Scrum會帶來時程無法掌控的莫名壓力)與內部成員(期望Scrum給他們帶來的好處)的雙重壓力,讓他越做越辛苦,直到放棄!關於這點是否有好的方法?<br /><br />==>『擔心Scrum會帶來時程無法掌控的莫名壓力』剛好跟我的經驗相反,在團隊剛開始導入 Scrum 的時候,的確可能會有3-6個月的適應期,在這一段時間之內,團隊的產出會有起起伏伏,比較不穩定的情況。但等團隊上手之後,我的經驗是,時程反而比較容易掌握。<br /><br />我覺得答案很簡單,就是你沒以沒找到一個好的 Agile Coach 來輔導。這好像生病需要看醫生一樣,有些小病自己買成藥吃一吃也許就好了,但是『大病』不看醫生,然後自己買藥吃發現沒用,再去怪藥不好,這種作法是於事無補滴 XD。<br /><br />2. 專注力提升真的很難,光是公司裡的電話與其他雜務干擾,真的很難進入神馳狀態!你這有好方法嗎? ^^<br /><br />答案同上 XD。<br /><br />3. 軟體專案成本的確跟開發團隊的時間(工時)有很大關係,但客戶打從一開始在需求不明確時就要求團隊評估出工時,Product Owner 真的很為難,對上要對預估工時有所交代,對下要讓團隊接受客戶期待的工時,當兩邊喬不攏的時候,一樣會怨聲載道。你如何面對這種困境?<br /><br />『但客戶打從一開始在需求不明確時就要求團隊評估出工時』--> 哪就想辦法把需求弄清楚一點,清楚團隊覺得可以估算為止啊。<br /><br />我知道這種說法你會覺得『不可能』,但你要先回頭看看你公司與專案的 Context、Problem、Force 各是是什麼,再分析你要採用 Scrum 這個 Solution 之後,對於原本的 Force 是否有辦法解決。也就是說,套用 Scrum 之後你的 Resulting Context 是什麼?這個 Resulting Context 是不是你能接受的?如果不行,要如何調整 Solution...... ( 你如果有上過 Teddy 的 Pattern 課程就比較知道要如何分析問題)。<br /><br />每家公司、客戶、專案、團隊組成、資源等等的狀況都不一樣,我無法給一個『標準解答』啊。<br /><br />***<br /><br />你的最後兩個重點:<br />(1) 一個公司認不認為自己需要改變?<br />=>通常是需要的!因為問題一直存在!<br /><br />(2) 如果需要,有沒有推動變革的勇氣與決心?<br />=>勇氣不是沒有,嘗試過後,PO 被客戶幹譙個半死,專案結束後成員全數離職,其實跟決心改革前好像還更糟糕,我們是真的很用心跑了一段時間,專案成員各個十分團結,也頗認同Scrum,但公司卻沒有好下場。不知道耶,可能是我太悲觀吧,一次失敗經驗就嚇到了,也許不適合用在【非產品研發】類型的公司吧。不知道你有何見解?<br /><br />『我們是真的很用心跑了一段時間,專案成員各個十分團結,也頗認同Scrum,但公司卻沒有好下場。』<br />=> 就說你們要花點錢找『Agile Coach 』來幫你們導入 Scrum。台灣很多公司都想『省錢』,什麼都要自己試,但是有沒有能力可以靠自己就搞好。在『省錢至上』的原則下,自己嘗試的結果,很多時候是以失敗收場。結果不但沒省到錢,反倒是浪費更多錢。<br /><br /><br />我知道任何改變都是困難的,有時候摸著石子過河,是會沉的。 XD<br />--> 找對人,成功的機率才可以提昇啊。<br /><br />Teddy 第一次幫忙導入 Scrum 的經驗,對方可是花錢請 Teddy 每天都到公司和團隊在一起。每個 sprint 開始 Teddy 以『Agile Coach』的身分參加 sprint planning meeting,然後每天早上到對方的公司參加 Daily Scrum。Sprint 結束的時候參加 sprint review, retrospective meeting。 <br /><br />就這樣進行了6個月,Teddy 才覺得慢慢把團隊給帶起來。以上經驗提供你參考一下。<br /><br />Teddy Chenhttps://www.blogger.com/profile/02066842119056439711noreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-73017273638572087122012-10-03T02:12:17.681+08:002012-10-03T02:12:17.681+08:00不好意思,不是要跟你打筆仗啦,真心想跟你腦力激盪一下,我真的很想重拾 Scrum 的懷抱。 ^^不好意思,不是要跟你打筆仗啦,真心想跟你腦力激盪一下,我真的很想重拾 Scrum 的懷抱。 ^^Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-1115990415296057172012-10-02T01:57:15.333+08:002012-10-02T01:57:15.333+08:00Dear Teddy,
多謝回答 ^_^
以下幾點討論:
1. Scrum 我 Run 過,的...Dear Teddy,<br /><br />多謝回答 ^_^<br /><br />以下幾點討論:<br /><br />1. Scrum 我 Run 過,的確如您所說像一面『照妖鏡』,好的、不好的都會被照出來,沒實力又沒人緣的人的確很快就會被逼走。但沒實力(或沒生產力)又有人緣的人(例如很努力工作+每天加班),就會留在團隊裡,大家會幫助他快速成長,這些的確都是好處。但是 Product Owner 不斷面對客戶(擔心Scrum會帶來時程無法掌控的莫名壓力)與內部成員(期望Scrum給他們帶來的好處)的雙重壓力,讓他越做越辛苦,直到放棄!關於這點是否有好的方法?<br /><br />2. 專注力提升真的很難,光是公司裡的電話與其他雜務干擾,真的很難進入神馳狀態!你這有好方法嗎? ^^<br /><br />3. 軟體專案成本的確跟開發團隊的時間(工時)有很大關係,但客戶打從一開始在需求不明確時就要求團隊評估出工時,Product Owner 真的很為難,對上要對預估工時有所交代,對下要讓團隊接受客戶期待的工時,當兩邊喬不攏的時候,一樣會怨聲載道。你如何面對這種困境?<br /><br /><br />你的最後兩個重點:<br />(1) 一個公司認不認為自己需要改變?<br />=>通常是需要的!因為問題一直存在!<br /><br />(2) 如果需要,有沒有推動變革的勇氣與決心?<br />=>勇氣不是沒有,嘗試過後,PO 被客戶幹譙個半死,專案結束後成員全數離職,其實跟決心改革前好像還更糟糕,我們是真的很用心跑了一段時間,專案成員各個十分團結,也頗認同Scrum,但公司卻沒有好下場。不知道耶,可能是我太悲觀吧,一次失敗經驗就嚇到了,也許不適合用在【非產品研發】類型的公司吧。不知道你有何見解?<br /><br />我知道任何改變都是困難的,有時候摸著石子過河,是會沉的。 XD<br /><br />謝謝!^_^Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-82633307334012811382012-10-01T23:36:04.538+08:002012-10-01T23:36:04.538+08:00Hi 鄉民:
難得有鄉民願意發表這個長篇的寶貴意見,太感動了。
=> 以我個人經驗,有企圖...Hi 鄉民:<br /><br />難得有鄉民願意發表這個長篇的寶貴意見,太感動了。<br /><br />=> 以我個人經驗,有企圖心的員工,願意主動思考、讀書、進修的人,恐怕是少數! 大部分的人都只想兼顧工作與生活,這沒甚麼不好,只是強調了這點可能會反而降低生產力,而且還可能拉不回來,尤其是當前台灣的資訊慘業。<br /><br />我也同意這些人不是多數,但是由於『齊頭式的加班文化』,讓這些人無法利用時間去培養實力,只會讓團隊的士氣與能力停滯不前 (明明沒事了卻不可以下班,還要在公司裡面假裝有事做)。<br /><br /> ***<br /><br />* 可以鑑別出「守本分」(效率不動如山)的員工與「持續成長」的員工。(這一點很重要)<br /><br />=> 這一點我百分百認同,而且真的很重要,不過這也要公司的管理制度配合,有適當的激勵與懲罰才有效果。<br /><br />當然很多事情是要公司制度的配合。Scrum 好的地方,只要你自己真的試過,就像是一面『照妖鏡』,好的、不好的都會被照出來。想打混的人會無所遁形,箇中巧妙之處真的要實施過就知曉 XD。<br /><br /> ***<br /><br />=> 專注力往往決定於團隊成員個人的自制力,公司不封鎖 FB, Plurk, Twitter, MSN, Skype, Weibo, LINE, WhatsApp, ... 通常都會讓部分成員分心導致降低生產力,阻擋了這些社交網路存取,又會引發民怨,或因為無法透過網路向外人求助而引來負面效應。<br /><br />個人自制力當然是專注力的基礎,但是很多時候,專注力會被很多『事件』給打斷。流程不順、跨部門溝通、回不完的無意義email、打嘴砲、無意識但定期會發生的會議、皇親貴族與大臣們的亂入...等等等,這些都不是光靠『個人自制力』可以應付的。<br /><br />我好像扯太遠了,原本我想說的只是:『經常性加班,隔天上班會很沒精神啦』。<br /><br /> ***<br /><br />* 反映出專案的真正成本。<br /><br />=> 專案的真正成本光從工時來看根本算不準,因為變數非常多。開發效率高的團隊成員通常比團隊中最低的還高出好幾倍。<br /><br />基本上我覺得軟體開發計畫,最大的成本應該就是開發團隊的時間,也就是工時。開發效率高的團隊成員通常比團隊中最低的還高出好幾倍,這我絕對同意,所以高效率的團隊所需的工時會比較短。但是『理稐上』公司付給高效率團隊的總薪資應該會比低效率團隊要要。我想講的是,一般軟體專案應該還是依據人/時來計算費用。<br /><br /> ***<br /><br />我個人覺得,要不要導入 Scrum其實不是重點,重點是:<br />(1) 一個公司認不認為自己需要改變?<br />(2) 如果需要,有沒有推動變革的勇氣與決心?<br /><br />如果以上兩點都成立,要導入什麼『東東』,就看產業別的需要。<br /><br />任何改變都是困難的,有時候需要摸著石子過河的勇氣與決心啊。<br /><br />報告完畢。<br /><br /><br /><br />Teddy Chenhttps://www.blogger.com/profile/02066842119056439711noreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-8616910557509403492012-10-01T23:12:06.100+08:002012-10-01T23:12:06.100+08:00Dear Teddy,
謝謝你的迅速答覆 ^_^
軟體團隊在研發的過程中多多少少都會有『流程上』...Dear Teddy,<br /><br />謝謝你的迅速答覆 ^_^<br /><br />軟體團隊在研發的過程中多多少少都會有『流程上』、『能力上』、『公司制度面』等等的問題,我覺得整體來說應該就是【公司管理制度】的問題,公司制度跟不上新形態的開發模式,也是白搭。<br /><br />對於你所提出的「固定工時,短時間看似減少生產力,但其實好處多多」的部分,我希望能跟你好好激盪一番:<br /><br />* 讓有企圖心的員工可以有時間可以去思考、讀書、進修、兼顧工作生活。<br /><br />=> 以我個人經驗,有企圖心的員工,願意主動思考、讀書、進修的人,恐怕是少數! 大部分的人都只想兼顧工作與生活,這沒甚麼不好,只是強調了這點可能會反而降低生產力,而且還可能拉不回來,尤其是當前台灣的資訊慘業。<br /><br />* 可以鑑別出「守本分」(效率不動如山)的員工與「持續成長」的員工。(這一點很重要)<br /><br />=> 這一點我百分百認同,而且真的很重要,不過這也要公司的管理制度配合,有適當的激勵與懲罰才有效果。<br /><br />* 提升員工法定工作時間的專注力。<br /><br />=> 專注力往往決定於團隊成員個人的自制力,公司不封鎖 FB, Plurk, Twitter, MSN, Skype, Weibo, LINE, WhatsApp, ... 通常都會讓部分成員分心導致降低生產力,阻擋了這些社交網路存取,又會引發民怨,或因為無法透過網路向外人求助而引來負面效應。<br /><br />* 反映出專案的真正成本。<br /><br />=> 專案的真正成本光從工時來看根本算不準,因為變數非常多。開發效率高的團隊成員通常比團隊中最低的還高出好幾倍。<br /><br />* 暴露出公司與團隊的不足之處,以謀求改善之道。<br /><br />=> 同意!<br /><br />------<br /><br />在傳統公司裡,或非技術導向的公司,導入 Scrum 我覺得應該是遙遙無期。<br /><br />而在技術型的公司,「增加工時會增加效率」這一個假設前提我覺得是有問題的,應該沒多少公司或主管真的希望刻意增加工時以提升工作效率,往往都是因為專案 deadline 趕不上才會加班,大家都是為了特定目標趕工的,並不是為了提高工作效率。<br /><br />再者,如果團隊成員每個人都能自我要求、自我提升、晚上回家都會主動看書提升軟體開發過程中的工作效率,為了專案deadline大家都能提前把工作完成(因為工作效率已經提升),那主管怎麼還會想要求加班。<br /><br />往往是專案時程離死線越遠,大家的積極程度也會越低,這是人性。或許透過Scrum可以改善人性面的瑕疵,也讓大家離死線很遠的時候也能積極點,但這真的不是件簡單的事,Product Owner 與 Scrum Master 對團隊的運作舉足輕重,一個不小心還可能會毀了一個團隊原本能有的產值,或許原本因為特定目標偶爾加班硬撐出來不錯的產能,但若因為 PO 與 SM 管理不當而導致團隊氣氛爬不起來,大家在趕工時又不願意加班,目標也不可能達成。當這種團隊氣氛蔓延至所有人身上,這個專案也差不多就要注定失敗,團隊也可以準備解散了。<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-11877064574674580092012-10-01T22:21:56.806+08:002012-10-01T22:21:56.806+08:00Hi 鄉民:
(1) 我想大部分的客戶,可能都不管施工廠商的『工時與效率』,只管時間到了東西有沒...Hi 鄉民:<br /><br /> (1) 我想大部分的客戶,可能都不管施工廠商的『工時與效率』,只管時間到了東西有沒有生出來。<br />(2) Teddy關於 Scrum 的經驗主要在於軟體開發,『廣告活動類型的公司』並非 Teddy 專長 (趕快撇清)。<br />(3) 我這一篇的重點在於 (a) 先嘗試把工時固定,可以強迫團隊把『流程上』、『能力上』、『公司制度面』等等的問題給『暴露出來』(b) 各個行業、公司、團隊的工作模式不一樣,需要自己找出一個適合自己的方法。但如果只是一味增加工時希望員工可以產出更多的產品,而非把時間花在思考如何提昇效率,在『軟體開發產業』來說,是很危險的一件事。<br /><br />Teddy 的能力有限,無法包山包海涵蓋每一個不同的產業啦 XD。<br /><br />謝謝。<br /><br />Teddy Chenhttps://www.blogger.com/profile/02066842119056439711noreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-14725228433029225862012-10-01T22:05:03.115+08:002012-10-01T22:05:03.115+08:00例如那種廣告活動類型的公司,當他們要做網站的時候,無論多少人、多少事,deadline就是deadl...例如那種廣告活動類型的公司,當他們要做網站的時候,無論多少人、多少事,deadline就是deadline,時間內就是要完成,客戶在意的只有目標能否達成,不管甚麼工時與效率,如此一來真的能夠套用Scrum嗎? 我挺懷疑的! 可否請 Teddy 釋疑? 謝謝!Anonymousnoreply@blogger.com