国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

本文將總結(jié)在過去的一段時(shí)間里，我們?cè)谵D(zhuǎn)型過程中踩過的坑，以作前車之鑒。也聊聊在轉(zhuǎn)型過程中，哪些優(yōu)秀的實(shí)踐可以嘗試，走上漸進(jìn)變革的道路。

到今天，我們已經(jīng)在敏捷轉(zhuǎn)型的路上已經(jīng)磕磕碰碰的走了16個(gè)月。從啟程時(shí)的興奮到現(xiàn)在的淡然，回想起來還是“圖樣圖森破”，原以為把敏捷那一套運(yùn)作模式拿過來，隨著時(shí)間的推移，一切就會(huì)好轉(zhuǎn)起來。然而，并沒有那么簡單，受限于組織架構(gòu)，僅僅是把敏捷那一套運(yùn)作模式照搬過來我們就做不到，更別說照搬過來后能不能適應(yīng)我們的產(chǎn)品研發(fā)了。

雖然，目前敏捷轉(zhuǎn)型和預(yù)期比起來進(jìn)展不夠理想，但是在期間我們還是運(yùn)作起來部分優(yōu)秀的實(shí)踐，提高了產(chǎn)品研發(fā)效率。本文將總結(jié)在過去的一段時(shí)間里，我們?cè)谵D(zhuǎn)型過程中踩過的坑，以作前車之鑒。也聊聊在轉(zhuǎn)型過程中，哪些優(yōu)秀的實(shí)踐可以嘗試，走上漸進(jìn)變革的道路。

1.敏捷初識(shí)，我們的敏捷做對(duì)了嗎

在接觸敏捷之處，大家對(duì)敏捷都是一知半解，更多的停留在字面意思的理解上：“敏捷就是快“。一旦有人覺得不快時(shí)，就會(huì)發(fā)出質(zhì)疑，我們的敏捷做對(duì)了嗎？另外一方面，由于剛接觸敏捷，我們開始變得理論化，嚴(yán)格遵循敏捷定義的方式方法，條條框框，帶著對(duì)敏捷的敬畏，天真的認(rèn)為敏捷規(guī)定的都是好的，敏捷之外的方式方法都是不完美的，有缺陷的。對(duì)，這就是我在剛接觸敏捷時(shí)，最大的兩個(gè)誤區(qū)。

1.1.目光不要只關(guān)注敏捷的快

快，僅僅是敏捷帶來的一個(gè)結(jié)果而已。單純的只關(guān)注這個(gè)結(jié)果，并不能對(duì)我們的轉(zhuǎn)型帶來什么幫助。關(guān)于快的定義，我們習(xí)慣性的參考別人做產(chǎn)品是什么樣的節(jié)奏，找到業(yè)界的優(yōu)秀企業(yè)作對(duì)比，認(rèn)為做到那樣才是快。然而，我們卻很少去關(guān)注對(duì)應(yīng)產(chǎn)品的品類和復(fù)雜度，忽略他們的組織文化、組織架構(gòu)、人員素質(zhì)、開發(fā)過程中的取舍等各種細(xì)節(jié)?？吹絼e人家的孩子全是優(yōu)點(diǎn)，自家的孩子一堆問題，卻不去了解別人是如何解決那些問題的，付出了什么代價(jià)，只想取別人的優(yōu)點(diǎn)，忽略別人的缺點(diǎn)。

欲思其利，必慮其害，欲思其成，必慮其敗。–《便宜十六策·思慮》

我們?cè)谧雒艚蒉D(zhuǎn)型時(shí)，引入了外部咨詢培訓(xùn)，培訓(xùn)過程中老師舉了一個(gè)例子：“他們以前做產(chǎn)品時(shí)，一天可以發(fā)20幾個(gè)版本?！?，這樣的例子對(duì)于我們來說簡直是太刺激了，我們的產(chǎn)品要一個(gè)多月才能發(fā)出去一個(gè)版本。雖然我們知道老師舉例的產(chǎn)品是web端產(chǎn)品與我們的產(chǎn)品完全不一樣，我們還是不由自主的認(rèn)為我們是不是可以做到1周發(fā)一個(gè)版本，甚至更快，畢竟別人一天20多個(gè)版本啊。對(duì)，我們的目光完全被“快”吸引了，于是什么都圍繞怎么能更快去開展改革，想方設(shè)法的充分利用資源，各種并行，反而導(dǎo)致混亂。

1.2.不忘初心，實(shí)事求是

我們是一家銷售消費(fèi)類硬件產(chǎn)品為主的公司，在引入敏捷之前，我們采用的瀑布開發(fā)模式，在產(chǎn)品復(fù)雜度低，研發(fā)人員較少的情況下，運(yùn)作還比較良好。但是，隨著產(chǎn)品復(fù)雜度的增加，研發(fā)人員增多，人員依賴度的增加，這樣的研發(fā)模式變得十分笨重，連一個(gè)基本的信息傳遞都出了問題，集成一個(gè)版本變得十分困難，發(fā)布日期也總是一拖再拖。從結(jié)果上看就是我們不能按時(shí)發(fā)布，發(fā)布的周期比較長，產(chǎn)品研發(fā)變得“不敏捷”。然而要實(shí)際落地解決問題我們需要在這幾方面改善：

• 建立新的溝通機(jī)制，保障跨領(lǐng)域協(xié)作的有效溝通。
• 需求要進(jìn)行有效的優(yōu)先級(jí)排序，并控制數(shù)量，并承諾對(duì)應(yīng)優(yōu)先級(jí)需求的交付率。
• 避免建立過大的團(tuán)隊(duì)組織，如果存在，需要根據(jù)業(yè)務(wù)的獨(dú)立性，拆解為適當(dāng)規(guī)模的小團(tuán)隊(duì)。
• 團(tuán)隊(duì)之間人員要解耦，盡量避免一個(gè)人在多個(gè)項(xiàng)目團(tuán)隊(duì)。
• 信息透明，盡量讓團(tuán)隊(duì)成員能基于已有的信息自己做出決策，而不是詢問上級(jí)。
• 建立跨領(lǐng)域團(tuán)隊(duì)，并對(duì)團(tuán)隊(duì)進(jìn)行敏捷開發(fā)知識(shí)的宣導(dǎo)和指導(dǎo)。
• 引入持續(xù)集成。
• 限制在制品，避免一個(gè)人同時(shí)開展多項(xiàng)工作，原則上不能超過2個(gè)未完成的任務(wù)。

等等……

我們不再糾結(jié)于是否一定執(zhí)行了敏捷里面規(guī)定的活動(dòng)，又或者說我們現(xiàn)在的項(xiàng)目過程，也談不上是完整意義的敏捷開發(fā)，我們更注重什么樣的招式能有效解決我們當(dāng)下的問題。

1.3.我們的絆腳石

本文開篇講到了組織架構(gòu)導(dǎo)致我們并不能完整的引入敏捷開發(fā)的各項(xiàng)機(jī)制。我相信，做過敏捷轉(zhuǎn)型的人應(yīng)該都遇到了這樣的問題。以下是我們?cè)诿艚蒉D(zhuǎn)型中遇到的一些實(shí)際問題，當(dāng)你遇到這些問題時(shí)，不要驚訝，對(duì)于一個(gè)傳統(tǒng)的成熟組織來說很難改變，尤其在沒有上層領(lǐng)導(dǎo)積極推動(dòng)的情況下。

沒有產(chǎn)品經(jīng)理，敏捷團(tuán)隊(duì)只關(guān)注開發(fā)與發(fā)布，不管開始，不管結(jié)果。

在我們公司的組織架構(gòu)采用了弱矩陣形式，敏捷團(tuán)隊(duì)更多的起到協(xié)作開發(fā)前端需求的作用，他們不需要對(duì)產(chǎn)品直接負(fù)責(zé)，也不會(huì)關(guān)注產(chǎn)品在市場上的反饋。

測試與開發(fā)職責(zé)界限清晰。

在理想的敏捷中，在開發(fā)過程中就開始做測試，而我們還是需要開發(fā)完成后再進(jìn)入測試，走上了“小瀑布模式”之路。

無法進(jìn)行短周期迭代，放棄迭代。

由于走上了“小瀑布模式”之路，根本沒辦法做到較短周期的迭代，對(duì)于一個(gè)月一個(gè)版本來說，超過2周的迭代周期已經(jīng)失去了實(shí)際的意義。

做好的功能都會(huì)發(fā)出去，基本沒有功能灰度驗(yàn)證，功能越堆越多，維護(hù)越來越難。

需求人員都會(huì)認(rèn)為自己想法是完美的，能有效提高產(chǎn)品的價(jià)值，他們更關(guān)注自己提的需求，而不是這個(gè)產(chǎn)品。

沒有項(xiàng)目經(jīng)理，只有項(xiàng)目負(fù)責(zé)人，項(xiàng)目負(fù)責(zé)人不專注，不專業(yè)。

由于公司項(xiàng)目是弱矩陣形式，項(xiàng)目更多的是協(xié)作作用，項(xiàng)目負(fù)責(zé)人更多的是起到拉通團(tuán)隊(duì)協(xié)作的作用，由于項(xiàng)目負(fù)責(zé)人往往身兼多職，并不能有效的持續(xù)投入精力優(yōu)化項(xiàng)目過程。

等等……

2.成功的每一小步

固然，我們?cè)谵D(zhuǎn)型中問題眾多，還有很大的優(yōu)化空間，但是和以前比起來我們還是取得了不小的進(jìn)步，以下招式在實(shí)際項(xiàng)目開展過程中具有明顯的實(shí)際意義，并不受傳統(tǒng)組織架構(gòu)排擠：

2.1.跨職能團(tuán)隊(duì)

對(duì)于傳統(tǒng)企業(yè)來說，一般根據(jù)職能屬性進(jìn)行部門劃分，各部門互相協(xié)作完成項(xiàng)目。然而，跨部門的協(xié)作成本明顯過高，當(dāng)產(chǎn)品需要頻繁的跨部門協(xié)作時(shí)，這樣的模式明顯無法勝任。而在這時(shí)，公司必然也會(huì)暴露出由于這樣的缺陷，導(dǎo)致的開發(fā)效率低下的問題。此時(shí)，以事業(yè)部或核心部門主導(dǎo)，建立虛擬的跨職能團(tuán)隊(duì)，也就順理成章，一氣呵成?？缏毮軋F(tuán)隊(duì)能有效解決產(chǎn)品在開發(fā)時(shí)，頻繁協(xié)作溝通的問題。在這樣的團(tuán)隊(duì)里，溝通由實(shí)際的開發(fā)、測試、需求人員直接當(dāng)面溝通，頻率更高，信息失真也比較少，也避免了部門之間扯皮的問題。

2.2.每日晨會(huì)

晨會(huì)，是跨職能團(tuán)隊(duì)進(jìn)行溝通的標(biāo)準(zhǔn)活動(dòng)，每天在固定的地點(diǎn)、固定時(shí)間花10分鐘左右舉行，是一種很有效的團(tuán)隊(duì)同步機(jī)制。然而晨會(huì)看上去簡單，但是要開好，卻沒有那么容易。敏捷里面的推薦晨會(huì)內(nèi)容主要包括以下三方面。

• 昨天做了什么？
• 今天要做什么？
• 有什么問題？

對(duì)于敏捷小白的我們，剛開始照本宣科的組織晨會(huì)，但是采用標(biāo)準(zhǔn)的模式，我們卻始終都開不好這樣的晨會(huì)，下面會(huì)詳細(xì)的說說我們都遇到了哪些問題。

• 晨會(huì)溝通時(shí)，大部分信息對(duì)改善項(xiàng)目進(jìn)展的實(shí)際意思很小，口水話太多。
• 當(dāng)一位同事在描述自己昨天做了什么，今天要做什么時(shí)，大部分人并不在意。
• 大部分工程師晨會(huì)都是自顧自說，不關(guān)心自己表達(dá)的內(nèi)容是否有效傳遞。
• 推廣晨會(huì)輪流組織時(shí)，發(fā)現(xiàn)大部分人并沒有這個(gè)能力有效的組織晨會(huì)，并不太好實(shí)踐。
• 晨會(huì)討論的內(nèi)容很離散，看不到整個(gè)項(xiàng)目的進(jìn)展。

2.2.1.怎么開好晨會(huì)

正如敏捷宣言里面提到的“個(gè)體交互勝過流程和工具”一樣。晨會(huì)，需要將當(dāng)前項(xiàng)目的進(jìn)展透明到整個(gè)團(tuán)隊(duì)，并促使團(tuán)隊(duì)成員基于各自目前的情況，通過溝通及時(shí)主動(dòng)的解決問題。那如何才能做到快速有效的溝通呢，我認(rèn)為需要做到以下幾點(diǎn)：

• 團(tuán)隊(duì)成員都清晰的知道項(xiàng)目的目標(biāo)和當(dāng)前的狀態(tài)。
• 項(xiàng)目中的各項(xiàng)工作內(nèi)容都有清晰的優(yōu)先級(jí)，以及明確的責(zé)任人和當(dāng)前的進(jìn)展信息。
• 晨會(huì)有明確的規(guī)則，每個(gè)人都知道在何時(shí)做何事。
• 參與晨會(huì)的每一個(gè)人都能隨著輕松的了解到與他相關(guān)人員的任務(wù)進(jìn)展?fàn)顟B(tài)。

要做到這些，當(dāng)然就少不了一面合理的看板墻了。它是整個(gè)晨會(huì)的核心載體，晨會(huì)時(shí)，所有的項(xiàng)目成員都基于看板墻的信息進(jìn)行討論并更新看板墻的信息。

2.3.看板墻

看板墻，看似只是簡單的將項(xiàng)目中要展示的信息帖到一個(gè)版本上面去，但是如果貼得不合理，整個(gè)晨會(huì)就會(huì)一團(tuán)亂麻，思路離散，最終導(dǎo)致晨會(huì)的失敗。接下來，我將談?wù)勎覀兛窗宓难葸M(jìn)過程。

剛開始，我們采用上圖那樣的看板墻，紙片上僅僅寫了用戶故事，每天晨會(huì)的時(shí)候，大家圍成一圈，按順序每個(gè)人講自己昨天做了什么，今天做什么，有什么問題。當(dāng)發(fā)現(xiàn)某項(xiàng)用戶故事改變了狀態(tài)時(shí)，就挪動(dòng)到對(duì)應(yīng)的列里面去。

漸漸的問題就暴露出來，我們發(fā)現(xiàn)看板墻上的卡片會(huì)有很多，而且會(huì)越來越多，因?yàn)槲覀兛偸窍胱龈嗟挠脩艄适?，一旦某?xiàng)用戶故事在開發(fā)過程中受阻，我們就會(huì)考慮開展一項(xiàng)新的用戶故事，我們不能接受一個(gè)人“閑下來”。另

外，由于每個(gè)人講的內(nèi)容，并沒有和卡片直接關(guān)聯(lián)起來，導(dǎo)致我們并不能很好的把講的信息和看板墻結(jié)合起來，以至于看板墻成了一個(gè)背景，沒有起到太多的實(shí)際意義，我們開始質(zhì)疑，輪流講問題是不是不合理，轉(zhuǎn)變?yōu)橛梢粋€(gè)人主持，根據(jù)看板墻上的信息逐個(gè)詢問探討，為了實(shí)現(xiàn)輪流主持，我們定期換不同的人進(jìn)行詢問探討，但是有時(shí)候有的人卻完全不知道如何有效的主持，導(dǎo)致晨會(huì)下來的有效溝通很少。由于看板卡片上記錄的信息很有限，卡片數(shù)量又比較多，以至于項(xiàng)目負(fù)責(zé)人都難以清晰的了解當(dāng)前項(xiàng)目的進(jìn)展，更別說其他團(tuán)隊(duì)成員了。于是我們把看板改成了下圖的樣子：

這樣子，看上去比以前的看板清晰了一點(diǎn)，能比較清晰的知道目前視覺、軟件、測試的任務(wù)情況，可惜還是存在不斷的向后面推用戶故事的問題，導(dǎo)致看板的在制品過多。

另外，還是存在部分用戶故事較大，在某個(gè)位置停留過長時(shí)間的問題，并且我們并不能清晰的了解到該用戶故事目前的進(jìn)展情況。

這里附帶提一下，總會(huì)有人提要把需求的粒度拆分得更小，把一個(gè)用戶故事拆分到1到3天的工作量，可惜我們一直沒有實(shí)現(xiàn)，或者我們勉強(qiáng)把一個(gè)大的用戶故事拆分成了幾個(gè)小的用戶故事，但是在我們這種敏捷并沒有完全轉(zhuǎn)變過來的團(tuán)隊(duì)，我們還是喜歡一個(gè)需求完整的交付。因?yàn)橹挥羞@樣我們的黑盒測試才能有效的測，不然會(huì)讓測試重復(fù)測，浪費(fèi)測試資源，前端需求對(duì)于一個(gè)沒有做到發(fā)布狀態(tài)的需求，也覺得不好體驗(yàn)。

為了有效的跟進(jìn)較大的用戶故事的進(jìn)展，我們開始進(jìn)行任務(wù)拆分，我們規(guī)定一項(xiàng)任務(wù)的粒度最大不能超過三天的工作量，我們趨向于團(tuán)隊(duì)成員盡量把任務(wù)都拆解到小于一天工作量的粒度，因?yàn)檫@樣有利于我們每日晨會(huì)進(jìn)行跟進(jìn)，于是看板上的卡片就分為了兩類，出現(xiàn)了下面的看板。

我們將看板上的卡片分為用戶故事和與用戶故事對(duì)應(yīng)的任務(wù)，當(dāng)所有與用戶故事相關(guān)的任務(wù)都完成時(shí)，將用戶故事挪到待發(fā)布中。用戶故事與任務(wù)之間使用編號(hào)進(jìn)行關(guān)聯(lián)，這使得我們的晨會(huì)過程討論的內(nèi)容更加具體，而不是簡單的匯報(bào)工作，項(xiàng)目進(jìn)展情況也比以前更加清晰。

然而，問題依舊存在，當(dāng)任務(wù)卡片較多時(shí)，任務(wù)與用戶故事的對(duì)應(yīng)關(guān)系找起來相對(duì)麻煩，不能一目了然的了解到用戶故事的進(jìn)展情況。同樣的，這樣的看板依舊會(huì)存在前端需求大量的向后端涌入，導(dǎo)致后端負(fù)荷過重，效率降低的情況。得益于精益的限制在制品概念，結(jié)合我們之前的各種經(jīng)驗(yàn)，我們最終使用了下面這種看板墻。

在這個(gè)看板墻里，只有用戶故事卡，用戶故事卡上拆分了用戶故事的不同任務(wù)，我們不再追求多個(gè)領(lǐng)域能針對(duì)一個(gè)用戶故事并行開展任務(wù)，而是一個(gè)領(lǐng)域做完后，再流入到下個(gè)領(lǐng)域。表面上并行開展工作看起來效率更高，但是那樣各領(lǐng)域信息并不一致，返工較多，反而導(dǎo)致效率低。由于任務(wù)和故事在同一張卡片上，我們可以從看板上一目了然的看到用戶故事當(dāng)前的狀態(tài)。

另外，我們將卡片分為三種顏色，對(duì)應(yīng)于三個(gè)優(yōu)先級(jí)，這樣大家在領(lǐng)取任務(wù)時(shí)，能更加自主。還有一點(diǎn)十分重要，每個(gè)領(lǐng)域我們根據(jù)他們的人數(shù)設(shè)置在制品限制，目前規(guī)定一個(gè)人同時(shí)開展的工作不能超過兩項(xiàng)。我們由推的模式轉(zhuǎn)變?yōu)槔哪Ｊ?。這樣能清晰的暴露領(lǐng)域邊界的資源匹配情況，同時(shí)也能保護(hù)相關(guān)領(lǐng)域不至于任務(wù)過多引起混亂，進(jìn)而導(dǎo)致效率降低。我們由要做更多的需求轉(zhuǎn)變?yōu)椤巴Ｖ箚?dòng)，聚焦完成”。

一個(gè)人的同時(shí)工作項(xiàng)不超過兩項(xiàng)并不是一個(gè)標(biāo)準(zhǔn)答案，我們內(nèi)部也未完全按照該標(biāo)準(zhǔn)執(zhí)行。對(duì)于基本不會(huì)出現(xiàn)阻塞的領(lǐng)域，也許一項(xiàng)也是一個(gè)合適的選擇。

2.4.版本規(guī)劃

由于我們的產(chǎn)品包括iOS應(yīng)用、Android應(yīng)用、手表端、服務(wù)器、H5這樣5個(gè)技術(shù)領(lǐng)域。在初期，我們?cè)庥隽烁黝I(lǐng)域互相依賴，因某個(gè)領(lǐng)域有bug未能及時(shí)修復(fù)，導(dǎo)致整體發(fā)布延期的問題，而且還經(jīng)常發(fā)生。

因此，我們采用了版本火車的概念，以發(fā)布為主，功能為輔。也就是在固定的時(shí)間節(jié)點(diǎn)必須發(fā)布，如果對(duì)應(yīng)功能沒有達(dá)到發(fā)布要求，就推遲到下一個(gè)發(fā)布版本。這樣做卻帶來了幾個(gè)比較揪心的問題，我們版本沒有明確的主題，僅僅是一堆已完成的需求而已，導(dǎo)致每個(gè)版本的亮點(diǎn)不夠。

另外，由于沒有規(guī)劃版本，因此無法給到前端明確的心理預(yù)期，他們不知道他們的需求在什么時(shí)候能發(fā)布，他們也不知道我們的下一個(gè)版本將會(huì)攜帶哪些需求。而對(duì)于開發(fā)而言，也缺乏明確的目標(biāo)感，給人一種來了需求我就做，做多少算多少的感覺。于是，我們最終還是放棄了版本火車，改為版本規(guī)劃的方式進(jìn)行整個(gè)產(chǎn)品的研發(fā)。

版本規(guī)劃，最頭痛的問題就是選哪些需求進(jìn)入該版本進(jìn)行開發(fā)的問題。要知道，需求永遠(yuǎn)都是源源不斷的來，需求的總量總會(huì)遠(yuǎn)遠(yuǎn)大于你當(dāng)前版本能開發(fā)完成的總量。因此就涉及到一個(gè)需求收集和篩選的問題。如果每次版本都要篩選那么多需求，需要耗費(fèi)很大一撥人大量的時(shí)間來進(jìn)行需求優(yōu)先級(jí)討論，以及該需求是否在該版本做的問題。另外，在這么短的時(shí)間內(nèi)也得不到太有效的討論結(jié)果。在《看板實(shí)戰(zhàn)》中，有一個(gè)“優(yōu)先級(jí)過濾器”的實(shí)踐方案，如下：

在這個(gè)看板上，明確了一個(gè)團(tuán)隊(duì)的產(chǎn)能，以及接下來要做的需求。當(dāng)一個(gè)需求被挪走后，就會(huì)觸發(fā)后續(xù)需求的進(jìn)入和討論，這樣每次只需要討論少量的需求，更加聚焦。這固然是一個(gè)好的實(shí)踐，可是我們現(xiàn)階段的團(tuán)隊(duì)并不能適應(yīng)它，因?yàn)槲覀儾]有真真的做到精益里面提到的拉動(dòng)式開發(fā)。于是我們?cè)谶M(jìn)行版本規(guī)劃時(shí)，采用了如下方案：

• 在下一個(gè)版本開展前兩周開始收集需求。
• 一個(gè)版本一定要有一個(gè)明確的主題。
• 版本有明確的時(shí)間節(jié)點(diǎn)。
• 需求要明確必須、應(yīng)該、可以三個(gè)優(yōu)先級(jí)，比例要適中。
• 必須的需求未按期完成時(shí)，版本發(fā)布時(shí)間后延。
• 應(yīng)該的需求要保障至少80%的交付率。
• 可以的需求要保障至少50%的交付率。
• 需求收集完后分為多次進(jìn)行版本規(guī)劃討論會(huì)議。

分多次進(jìn)行版本規(guī)劃討論會(huì)議很關(guān)鍵，由于需求收集的量比較大，另外參會(huì)的人比較多，大家很難一次性達(dá)成一致。當(dāng)一次會(huì)議結(jié)束后，需要給到整個(gè)團(tuán)隊(duì)一些線下時(shí)間做更多的思考以及了解更多的附加信息來進(jìn)一步評(píng)估。我們一般會(huì)開2到3次這樣的會(huì)議，每次會(huì)議時(shí)間為1到2個(gè)小時(shí)，這是一個(gè)逐步收斂和達(dá)成一致的過程。

3.未來

我們的項(xiàng)目過程，還有很多值得優(yōu)化的地方。到目前為止，我們的項(xiàng)目開展過程只能說做到了有序。而在接下來的日子里，我們還需要加強(qiáng)項(xiàng)目的度量。做到，不憑感覺規(guī)劃版本內(nèi)容的多少，不憑感覺說項(xiàng)目做得好還是差。通過度量數(shù)據(jù)，更客觀和明確的暴露項(xiàng)目中的問題。

4.推薦書單

對(duì)于我自身，經(jīng)歷過公司組織的一次敏捷咨詢后，就踏上了部門敏捷轉(zhuǎn)型的道路，期間踩坑無數(shù)，幸得以下書籍把我從一個(gè)一個(gè)坑里面拉了出來。推薦的書單中，部分書籍還未讀完，大部分書籍閱讀完一兩遍后還不得其道，還需要反復(fù)閱讀和實(shí)戰(zhàn)，這里就不好意思寫自己的感悟和對(duì)這些書的評(píng)價(jià)了，以免誤導(dǎo)大家。但是，這些書都是在我轉(zhuǎn)型的道理上，給予我不少啟發(fā)和幫助的書籍，我相信讀過這些書的人都能有所收獲。

• 《敏捷軟件開發(fā)實(shí)戰(zhàn)-估算與計(jì)劃》
• 《敏捷軟件測試》
• 《精益創(chuàng)業(yè)》
• 《精益創(chuàng)業(yè)實(shí)戰(zhàn)》
• 《看板方法》
• 《看板實(shí)戰(zhàn)》
• 《網(wǎng)易一千零一夜》
• 《人月神話》
• 《四步創(chuàng)業(yè)法》
• 《目標(biāo)》
• 《卓有成效的管理者》
• 《最后期限》
• 《思考，快與慢》

本文由 @小螞蟻 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。