最新文章

敏捷方法的成功密技(九):Scrum 的衝刺目標怎麼訂?

綜合本系列之前的文章,Scrum 其實就是一個小團隊(約5-9人),利用一個個固定短週期的衝刺(Sprint),跟客戶一同逐步漸進地,完成一個產品,而這個產品的功能,就是由一個個,由客戶主導、撰寫的用戶故事(User Story)來呈現需求的(關於用戶故事的簡要陳述,有興趣的朋友可以先參考一下《能讓需求簡化,還能更省時、更省錢,提供更多價值》這篇短文,容日後有空再專文細述之)。

談判的出牌策略,靈活運用「定錨效應」產生巨大影響

如果要你用一個四字成語來代表談判,請問你會選哪一個?如果建議選「討價還價」,我想很多人應該能夠接受。討價還價的確是談判最典型的畫面。甚至對有些人來說,討價還價就是談判的全貌。這篇文中所謂的討價還價是指談判的大原則大致已經確定了之後,針對價格這個項目的商談。如果你是個談判老手,你當然知道討價還價不等於談判,但是無論如何,討價還價絕對還是談判重要的環節。

敏捷方法的成功密技(八):Scrum 的衝刺時間長短怎麼訂?

一個衝刺(Sprint)的時間長短到底應該是多少才是最好的呢?如果衝刺的時間設定得太長,那麼,應變的彈性就會變得比較小,而如果衝刺的時間設定得太短,那麼,又容易讓開發團隊能產出的成果出問題。怎麼說呢?

判斷員工去留的五個指標,公司要的是「最適合的人」

在這部落格陸續講了不少自己在職涯上的碰撞與成長,這篇想更赤裸地來談談「資遣」這件事。從 2014 年展開第一份正職工作至今,看過一些同事被公司資遣,也聽過很多荒誕的資遣故事;但實際介入資遣正職同事的流程,對我來說,真的還是第一次。

敏捷方法的成功密技(七之二):Scrum 的夢幻開發團隊該怎麼來建置?

接續上一篇文章《敏捷方法的成功密技(七之一)》,除了新領域、新團隊,最有機會嚐試新作法之外,我們也談到了,只要開發團隊夠紮實,產品的開發就能夠打帶跑,因為品質才能夠被掌控得好。怎麼說呢?  

用寫「間歇式日記」取代規劃待辦清單,不會再寫了一堆卻做不到

在之前的文章中分享了「做了什麼清單」以及可以在行動清單中加上「日記」,如果把這樣的筆記、日記方法,有系統的成為自己每天推動待辦清單的技巧,會不會讓自己更能克服拖延,提升生產力,並完成更多重要的目標呢?

從PM的角度淺談test case的應用

在PMBOK(註1)的定義裡,完整的品質管理計畫包含「品質保證」(Quality Assurance, QA,中文簡稱「品保」)與「品質管制」(Quality Control, QC,中文簡稱「品管」)兩個面向,其中,品保的目的是確保產品交付的品質,例如軟體開發專案中,交付的軟體是否能符合規格文件內所定義的功能。在編制完整的組織內,也可能會有QA這樣的角色(Quality Assurance engineer,即品質保證工程師),協助PM檢驗產品品質。