博客 / 列表

敏捷開發 - 研發效率低下？試試這些改進方法

最近這段時間，互聯網上發生了很多大事： 極越汽車突然宣佈破產解散； 養樂多上海工廠關閉； 網傳海信大規模裁員； …… 2024年已經結束，如果給2024年打個標籤，有人説是“愈加魔幻”的一年，有人説是“挑戰激增”的一年，也有人説是“生存指數飆升”的一年。 根據裁員追蹤機構layoffs.fyi提供的數據，截至12月，2024年全球科技公司至少裁員了14.9萬人，覆蓋了互聯網、電子通信、

敏捷開發 , 職業發展 , 程序員發展 , 研發團隊 , 研發管理

敏捷開發 - 代碼審查完整指南來了！

代碼審查不是戰場，審查員也不是作者的對手。他們的目標是一致的——解決產品問題並創建高質量的代碼庫。讓我們深入探討並瞭解如何從審查者的角度進行一次代碼審查。 不要浪費時間 總有些問題時常重複出現。先是在一個拉取請求中，然後又在另一個拉取請求中；先是來自一個作者，然後又來自另一個作者。這些問題完全相同，這就是例行公事。事實上，如果某件事情可以自動化，那麼它就必須自動化。 代碼風格。沒有必要為代碼風格而

項目管理 , 敏捷開發 , 持續集成 , 代碼審查 , 編程技巧

敏捷開發 - 極限編程要完全遵守的12個實踐

極限編程的12個實踐是極限編程者總結的實踐經典，是體現極限編程管理的原則,對極限編程具有指導性的意義，但並非一定要完全遵守12個實踐，主要看它給軟件過程管理帶來的價值。 1、小版本 為了高度迭代，與客户展現開發的進展，小版本發佈是一個可交流的好辦法，客户可以針對性提出反饋。但小版本把模塊縮得很小，會影響軟件的整體思路連貫，所以小版本也需要總體合理的規劃。 2、規劃遊戲 就是客户需求，以

項目管理 , 敏捷開發 , 持續集成 , 結對編程 , 代碼規範

敏捷開發 - 為什麼單元測試不是持續交付的唯一答案

為了讓持續集成和持續交付（CI/CD）成為現實，企業必須審查其內部流程，並重新思考如何處理軟件交付生命週期。過去的清單和評論根本不是前進的方向。殘酷的事實是，大多數企業在持續交付的道路上相當落後。對軟件交付過程本身進行根本性的改變與從貨架上取下一些工具這樣的半個步驟是完全不一樣的。 如果目標是對客户和用户做出更好的響應，軟件團隊需要專注於軟件交付週期的更快迭代，並圍繞快速響應用户反饋進行組織。雖然

項目管理 , 持續集成 , 軟件開發 , devops , 單元測試

敏捷開發 - 持續測試性能的方法

持續測試是指在軟件開發生命週期中的不同階段納入自動反饋的過程，其中包括探索性測試等自動化測試外的活動。持續測試是CI/CD流程取得成效的關鍵因素，通過提高代碼質量來避免付出多餘的人力、物力和財力，從而加快DevOps流程。在Dan Ashby創建的DevOps持續測試模型圖（如圖1）中，他表明我們可以在任何一個階段進行測試。 對於持續測試存在一個誤區：持續測試就是測試左移。這是兩種不

性能測試 , 敏捷開發 , devops , 自動化測試 , ci

敏捷開發 - MVP發佈後，下一步該怎麼辦?

MVP發佈後，接下來該做什麼？我們又應如何衡量MVP是否成功？在弄清楚這些問題之前，我們首先要明白MVP是什麼。 MVP（minimum viable product）即最小可行產品，是一個產品的最初版本，旨在滿足目標受眾的基本需求。其核心是用最小的成本和最有效的方式，把產品快速推向市場，然後基於市場的反饋快速迭代。 一、為什麼要從發佈MVP開始？ 每家初創企業都可能面臨資金短缺、產品無人

項目管理 , mvp , 敏捷開發

敏捷開發 - MVP、原型、概念驗證，傻傻分不清楚？

MVP、原型以及概念驗證這三者的概念雖然沒有密切的聯繫，但也有不少人會分不清這三者的區別，在這篇文章中，我們會幫大家區分一下這三個概念。 首先是MVP，MVP是Minimum Viable Product的縮寫，即最小可行性產品。MVP通過發佈一個產品的早期版本，來獲取用户對該產品的反饋，從而開發出更能滿足用户需求的產品。簡單來講，MVP提供了測試市場以及客户需求的機會，從而避免產品開發方向出現偏

mvp , 開發