瀑布 敏捷 精益 devops

2022-06-09 22:18:15 字數 1977 閱讀 2130

敏捷:  分工角色  大專案分小專案   每個節點時間設定里程碑

scrum實施的核心可以概括為「化繁為簡」,從幾個維度解釋下:

團隊角色的定義,將團隊人員定義為三個角色,scrum master(主要負責消除障礙,帶領團隊運作)、product owner(主要負責描繪產品遠景,定義優先順序)、scrum team(主要負責實現產品)

工作任務的拆分,將產品需求拆分成小的使用者故事,並評估優先順序

時間的拆分,將專案週期拆分成固定時長的迭代週期,每個迭代交付一部分可驗收的功能,通常迭代長度為1到4周

精益: 

原則1:消除八大浪費

企業中普遍存在的八大浪費涉及:過量生產、等待時間、運輸、庫存、過程(工序)、動作、產品缺陷以及忽視員工創造力。

原則2:關注流程,提高總體效益

管理大師戴明說過:"員工只須對15%的問題負責,另外85%歸咎於制度流程".什麼樣的流程就產生什麼樣的績效。改進流程要注意目標是提高總體效益,而不是提高區域性的部門的效益,為了企業的總體效益即使犧牲區域性的部門的效益也在所不惜。

原則3:建立無間斷流程以快速應變

建立無間斷流程,將流程中不增值的無效時間盡可能壓縮以縮短整個流程的時間,從而快速應變顧客的需要。

原則4:降低庫存

需指出的是,降低庫存只是精益生產的其中乙個手段,目的是為了解決問題和降低成本,而且低庫存需要高效的流程、穩定可靠的品質來保證。很多企業在實施精益生產時,以為精益生產就是零庫存,不先去改造流程、提高品質,就一味要求下面降低庫存,結果可想而知,成本不但沒降低反而急劇上公升,於是就得出結論,精益生產不適合我的行業、我的企業。這種誤解是需要極力避免的。

原則5:全過程的高質量,一次做對

假如,團隊整體的分工模式是錯誤的,那 devops 還是沒辦法消除團隊內不同角色間的甩鍋與填坑的;能為團隊設計出正確的分工模式,是團隊能開始協作的關鍵的第一步。

在 devops 的世界裡,所犯下的最大的錯誤是:整天只知講些文化、協作, 卻完全將最重要、最關鍵,儲存在 svn, git⋯內的開發人員的 「行為資料」 視而不見。在 devops 的世界裡犯下這樣的錯誤,將使得團隊白白的耗費大量的人力、時間,只是照著 「 devops 的課本」 在演出一場 「devops 的行動劇」罷了;團隊對於如何的持續改善團隊成員的開發效率、產品的質量,還是茫然無知的。

不論團隊是要匯入 devops 、scrum、safe、less、kanban, 都應該要從 「團隊的現況」 與 「開發人員的行為資料」 開始。

所以,身為 devops, safe, scrum, less, kanban 的教練、顧問, 都不應該背離了 「程式設計」,更不該對 「人類的行為模式」 是茫然無知的。

我們總是聽到,devops 能提公升效率、質量。

我們總是聽到,不做 devops 就會面臨被淘汰的命運。

但是,為何當我們每個人都認為 devops 是必要的同時,卻很少有人會去懷疑,團隊在 devops 的 value stream 中的整合測試,其實是不可信的?

就宛如我們總是聽到,因為健康檢查,而有多少人能及早發現、**了癌症;我們每個人也都認為每年的健康健查是必要的。

但,卻很少有人會去關注,有多少比例的癌症病人當中,其實,是每年都有在做健康檢查的?!

我們往往都太急於想在急速變化的it 產業當中,去抓住一塊 「浮木」 來獲得安全感、專業感;其實,這塊浮木,往往是連我們自己都感到茫然、感到陌生的。

為何在 google, amazon, netflix 的內部永遠都只專注在:人、架構、**、自動化工具,而沒跟風的去搞所謂的 devops, safe, scrum, kanban⋯卻仍然能使得產品擁有質量、價值與競爭力?!

我並不是說 devops, safe, scrum, kanban⋯是沒有用的。

我只是想建議,我們應該要 「顛倒」 下我們理解的思路;不要急著將在 devops, safe, scrum, kanban 中所學到的 「答案」,就直接的套在我們日常的軟體開發當中。

相反的,應該是從我們日常的軟體開發當中,去引導、去設計出我們所真正需要的 devops, safe, scrum, kanban⋯

敏捷之看板 精益生產

精益生產最重要的兩個理念就是準時化和自働化,由看板為實踐工具,最終能夠達到高質量 低成本及快速響應。首先擺在大家面前的就有乙個問題,什麼是看板,它和看板牆又是什麼關係?之所以把這個問題一開始就丟擲來是因為看板的 板 字,很容易讓人產生困惑。既然是個板子,那因該就是我們平常所說的物理卡牆,就是因為這點...

精益與敏捷開發(隨筆)

在幾年前,我就對軟體的敏捷開發有著很高的興趣的。一直覺得,程式設計師應該是最自由,最輕鬆的一種職業!而且我也一直在向這個方向努力!我們應該如何做呢?一說到程式設計師,大家就公認的是腦力民工!為什麼?在程式設計師自己報怨開發環境不好,工作量大,任務重,壓力大的同時,有沒有想過,有些問題其實是程式設計師...

精益敏捷採購的外包

u0026 xd u0026 xd u0026 xd u0026 xd 採購流程是組織在運營中變敏捷的最後一道障礙。在最近的agilia會議上,mirko kleiner就精益敏捷採購提出了一種服務合同談判的方法,該方法涉及採購專家 it團隊和 商,它能夠大幅縮短合同談判的時間,並將你爭我奪的態度轉...