丨大廠都在用哪些敏捷方法下

這個小組是做開發(fā)的，基于微服務負責的某一個小模塊。標準配置7人，4個程序員（至少有一個資深程序員，有架構能力），1個產品經理（Scrum里面叫ProductOwner），1個測試，1個項目經理（Scrum里面叫ScrumMaster）。主要負責某Ticket，隨時和項目成員溝通確認需求；開發(fā)人員：每天從看板上按照優(yōu)先級從高到低領取Ticket，完成日常開發(fā)任務；Bug，提交Scrum程管理，基于極限編程做工程實踐，看板可視化。每周一個Sprint。如何完成需求和修復沒有人愿意星期五部署，那意味著如果部署后發(fā)現故障，可能周末都沒法好好休息了。所以即使程序早已經測試好了，除非特別緊急，否則都會留在下一周再部署。所以部署放在上半周，這樣后面遇到問題還有足夠的時間去應對。部署很簡單，按照流程執(zhí)行幾個命令就可以完成生產環(huán)境部署。部署完成后，需要對線上監(jiān)控的圖表進行觀察，如果有問題需要及時甄別，必要的話對部署進行回滾操作。但輕易不會打補丁馬上重新上線，因為倉促之間的修復可能會導致更大的問題。Sprint每周二開迭代回顧會議，總結上個迭代回顧會議(SprintRetrospective)會議，目的是回顧一下在迭代中，團隊有哪些做的TicketBacklog例如會議上，測試人員反饋說，上一個Sprit，開發(fā)人員上線前幾個小時還往預部署的分支里面更新代碼，導致測試需要重新做回歸測試，但因為時間不夠了，沒來得及測試完整，導致上線后不穩(wěn)定，建議以后不要隨意在上線前，在部署分支更新代碼。 如果會議中要形成涉及項目的決策最好是通過集體表決的方式決策，盡可能避免式決策。因為敏捷的原則之一是要激勵項目人員，給他們以所需要的環(huán)境和支持，并相信他 nningMeeting）SprintTicket高到低從Backlog中選出下個Sprint的內容。SprintBacklogTicket1-5，1示容易1天以內可以完成的工作量，2分表示2天內可以完成的工作，5分表示非常復雜，需要5天以上的工作量。評估每條TicketTicketBug，可能是優(yōu)化任務。同時會大家一起討論這個Ticket，確保充分理解這個Ticket每個團隊成員在心中對Ticket會議組織者確認大家是否都已經確定估算結果，確認后，開始倒數：“3，2，1”，大家一起伸出一只手，亮出代表分數的手指頭。大家積極參與，詳細了解需求。相比以前，可能只有當某個功能模塊分配到自己頭上的工作量是由實際參與開發(fā)的成員作出評估，往往更準確也更容易被接受。以前項目經理促進成員的交流和經驗。我們知道一般經驗淺的新手估算工作量都會偏樂觀，而經驗豐富的老手則會更準確，通過這種方式，新手可以向老手學習到很多工作量估算甚至技術實現的經驗。SprintSprint如說這樣一個7人的小團隊，一個Sprint預計可以完成20-30分的Ticket。周五標志著一周的工作要結束了，所以下班之前（4），branchcut（分支切經過一周的開發(fā)，master（主干）已經合并了不少新的PR（PullRequest求），master所以我們需要把master上的代碼部署到測試環(huán)境進試，并且對測試出來的Bug進行master次Sprint結束，從master創(chuàng)建一個分支版本出來，然后基于這個分支部署和修復Bug。所以需要基于主干做一個branchcut，創(chuàng)建一個預部署的分支，將預部署分支的代碼部署部署測試環(huán)境，每周的branchcut（分支切割），回答其他小組的問題，主持每日會議通常來說，基于敏捷開發(fā)一個Sprint、一個Sprint迭代，節(jié)奏還是比較穩(wěn)定的，這個SprintSprint，不影響發(fā)布。不像瀑布模型那樣前松后以前我在使用迭代模型開發(fā)時，一般是4周左右的迭代周期，2周就是極限了，所以最開始看敏捷開發(fā)用1周的迭代周期，心中也有疑惑，1周時間又要開發(fā)又要測試怎么保證質1Sprint有足夠比例的自動化測試代碼，可以很好地保證質量。當用戶的主要功能都通過自動化測試覆蓋時，基本可以保證主要功能流程不會出問題。一個Sprint開發(fā)完成后，并不馬上部署生產環(huán)境，而是先部署到測試環(huán)境，會有有專業(yè)的測試人員進試，并非完全依賴自動化測試。有時候一些大的功能更新，甚至會組織全組成員一起測試，以彌補測試人員不足的情況。在一個Sprint也就是說，雖然是1周的Sprint，但是其實還有1周的時間進試。每個Sprint不僅開發(fā)新功能，同步還要修復以前版本的Bug。這樣基本上可以保證有好的質量。而且這種1周的迭代，可以保持每周都有內容更新，還有個好處就是每周更新的內容不多，出現問題的話，很容易就定位到是什么地方導致的問題。Sprint去做，并且確保在規(guī)定的時間范圍內完成。至于工期的估算，在迭代規(guī)劃會上會對每個Ticket進行打分，根據分數可以預估有多少工組和組之間的溝通協(xié)作，主要通過郵件、會議、內部溝通工具，最終任務會以Ticket的形在敏捷開發(fā)中，有一種實踐叫結對編程，就是兩個程序員在一臺電腦上一起工作。這個一直爭議比較大，但是如果用來兩人一起排查一些問題，或者是資深程序員帶新手程序員，則是一種非常好的協(xié)作方式。上面介紹的實踐案例和標準Scrum我上面介紹的內容，確實和標準的Scrum首先是角色名稱不一樣，在crum里面是分ProdctOwer、SrumMaser和Team三種角色，而在這個案例中是產品經理、項目經理和團隊成員，但其實只是名字叫法不一樣。還有要注意一點，就是傳統(tǒng)的項目經理，會是偏控制型角色，SrmMaser則是一種服務型的角色，主要職責是保障敏捷流程的執(zhí)行，以及提供必要的幫助，很多團隊的決策就是采用集體決策的方式。另外，Scrum有四種會議，除了前面介紹的三種：每日站會（DailyScrum）、Sprint計劃會（Sprintnning）和Sprint回顧會議（SprintRetrospective），其實還有一種會議是Sprint評審會（SprintReview）。Sprint評審會主要是客戶Sprint的完成結果。因為上面這個小組并沒有直接的客戶，這個小組的站立會議并不是“標準”的站立會議，Scrum的站立會議通常只有15分鐘，這里增加的每天Ticket環(huán)節(jié)，主要是為了將優(yōu)先級高的Bug修復之類的Ticket放到當前Sprint，及時響應，及時處理。有的項目組沒有這個環(huán)節(jié)，是由測試人員或者ScrumMaster直接將Ticket放到看板。這個小組并沒有使用用戶故事來開發(fā)需求，而是由產品經理事先寫好需求文檔。在上一篇文章里面，提到了Srm采用用戶故事的方式，分拆需求，減少繁重的需求文檔，在實現的過程中再溝通確認需求。這是Scrum推薦的式，也是一種高效的方式，但并不代表這是唯一的方式。如果有產品經理，可以提前幾個Sprint就將需求文檔寫詳細，一樣可以達到高效的理解需求的效其實在《05|敏捷開發(fā)到底是想解決什么問題？》就有講過，是不是敏捷開發(fā)，并不比如說非標準的站立會議效率更優(yōu)，那么就應該采用非標準的站立會議；如果有專業(yè)產品經理事先做好需求分析，可以達到解釋清楚需求的效果，就沒必要一定要用用戶故事來理解需求。Sprint，怎么保證每周都有交付，還能起來。大廠會注重流程和工具的應用，通過Ticket的方式來管理和開發(fā)任務，通過自Scrum、極限編程和看板，針對各自項目組的特點，會有所希望上面介紹的敏捷應用，能對你理解敏捷開發(fā)有所啟發(fā)，幫助你優(yōu)化改進日常項目流程。還有要注意的一點就是，沒有萬能的開發(fā)模式，只有適合項目的開發(fā)模式，最重要的還是要摸索出一套適合你自己項目特色的開發(fā)模式。限于篇幅，對于crum、極限編程和看板，我并沒有展開細講，還需要大家自己輔助看看書，我在《學習攻略|怎樣學好軟件工程？》和《05|敏捷開發(fā)到底是想解決什么問題？》文章中也列了一些參考書籍。留言區(qū)有同學推薦的文章《天下武功，唯快不破—新時代敏捷項目管理之道》對敏捷開發(fā)Sprint試，而是把測試放在下一個Sprint，這樣做有什么優(yōu)缺點？歡迎在留言區(qū)與我討論。 不得售賣。頁面已增加防盜追蹤，將依法其上一 06|大廠都在用哪些敏捷方法？（上下一 08|怎樣平衡軟件質量與時間成本范圍的關系言言 一路向 4目前認為的難處：1探索無止 3以及時同步bug修復，缺點是麻煩，每次要cherrypick。 作者回復:贊，可以先實驗，看看估算是不是適合，如果好的話就可以進一步固定下來。結對編程（英語：Pairprogramming）是一種敏捷軟件開發(fā)的方法，兩個程序員在一個計算機上共同工作。一個人輸入代碼，而另一個人他輸入的每一行代碼。輸入代碼的人稱作駕駛員，代碼的人稱作觀察員（或導航員）。兩個程序員經?；Q角色。十斗簸 2作者回復:這個問題幫不上你，因為我C++不懂，你得自己去網上問問別人。 作者回復:我覺得當前Sprint的測試，還是應該和當前Sprint一起走比較好，因為這個Sprint的內 2關于分支部署那里，我們采用的辦法是拉個新分支做開發(fā)，在預發(fā)測試好了再合并但天之大 天之大 2編程國 2我覺得可能是第一個spntspnt…劉曉 1什么也不 這個sprintv1.2v1.2不包含sprintv1.1 1星星童 哈 1哈 Bug，測試提了一個Bug（例如：Ticket-234），這個Bug的Ticket屬于Sprint1.1，而不是Sprint像Jira這種軟件，可以多個Sprint共存，也就是你看Sprint1.1，可以看到Sprint1.1的所有的Ticket狀態(tài)；切換到Sprint1.2，可以看到Sprint1.1