以下是我所在的敏捷團隊實行的團隊章程，未完待續(xù)，如有錯誤和建議，歡迎指出~

1 前言

《敏捷實踐》《DevOps》

1.1 什么是團隊章程

????????敏捷中有多種說法，如團隊契約、Working Agreement、團隊公約等，都是指團隊章程。團隊章程是提供指導原則、規(guī)則并指導團隊成員行為的方針政策，也可以理解為團隊開展工作的規(guī)則，可以包括預期的行為、價值觀、工作規(guī)則和做事的方式。

1.2 誰制定團隊章程

????????團隊章程應由團隊成員共同制定，一致認可，并為所有成員服務。

1.3 為什么需要團隊章程

• 最大程度地降低歧義、誤解和誤會，減少團隊內(nèi)部沖突；
• 提高速度，打造高效團隊；
• 提升決策質(zhì)量；
• 樹立共同價值觀；
• 提升團隊成員的滿意度；

1.4 團隊章程的目標

????????團隊章程的目標是創(chuàng)建一個敏捷的環(huán)境，在這個環(huán)境中，團隊成員可以發(fā)揮他們作為團隊的最大動力。

2 團隊章程

2.1 敏捷團隊實踐

2.1.1 敏捷儀式

????????一個敏捷迭代為期兩周，從第一周的周二到第三周的周一。每個迭代第一天下午（即每兩周的周二下午）召開評審會、回顧會和計劃會，主持人是團隊成員輪流擔當，主要負責同一迭代內(nèi)所有會議的主持工作，包括預定會議室等；若團隊內(nèi)有遠程辦公成員，開會時應在會議室啟用視訊或釘釘會議；

Daily Meeting

• 每天10點團隊在會議室過一下禪道看板上各自的任務，若沒有更新進度和工時，host在會后跟進；
• 時間不超過15分鐘；
• 回答三個問題：昨天做了什么、今天計劃做什么、遇到什么困難；

Review Meeting

• 每個迭代第一天下午的第一個會議；
• 迭代第二周周五，host負責將代碼commit到main，merge description寫明當次迭代完成的需求；
• 會前，Scrum Master更新語雀文檔項目進度表中本次迭代和下次迭代，如YS8803_2023_Q1_Schedule；
• 會中，團隊review項目進度表和里程碑；

Retrospective Meeting

• 每個迭代第一天下午的第二個會議；
• 使用釘釘表單收集功能回答三個問題：你覺得本次迭代哪里做的好（Well）、哪里做的不好（Less Well）、應該怎么解決（Action）；
• 會前，host將數(shù)據(jù)整理到語雀文檔上；
• 會上，團隊回顧上個迭代挑選的改進點的改進情況；
• 會上，團隊進行review，做得好的鼓勵繼續(xù)保持，對發(fā)現(xiàn)的問題整理歸類，記錄在語雀文檔，選出來不超過3條進行改進；
• 會后，host將最終采納的意見在下個迭代用釘釘助手定時提醒；

Planning Meeting

• 每個迭代第一天下午的第三個會議；
• 會前，Scrum Master將迭代要完成的任務分解在Backlog，寫明任務描述和DOD；（此流程后續(xù)優(yōu)化，理論上應由團隊成員分解。）
• 會后，大家根據(jù)進度和優(yōu)先級將任務移動到當次迭代。（此流程后續(xù)優(yōu)化，理論上PO應注明優(yōu)先級）
• 故事點估算

工作進展共享

????????項目組成員每天更新禪道日志，記錄工時和進展；每周五或周一上午發(fā)周報，抄送給其他團隊成員；

2.1.2 估算措施

2.1.3 完成的定義DoD

????????在敏捷軟件開發(fā)中，存在多級的不同的完成定義Definition of Done，以下分別說明。

Release DoD

• RD內(nèi)測表
• 語雀版本記錄：修改點、
• 版本評審表
• 版本發(fā)布申請表

User Story DoD

Feature DoD

模塊學習（如有必要，新增語雀文檔，禪道任務下附上語雀文檔鏈接和Git branch path）

設(shè)計和輸出方案文檔（和第1點輸出到同一個文檔，EMB 研發(fā)設(shè)計文檔模板）

語雀方案文檔review和修改

代碼實現(xiàn)

測試通過：SIM test or Jupiter test

單元測試編寫，輸出測試報告（測試報告包括且不限于單元測試用例、覆蓋率，報告附在上述文檔的末尾）

代碼格式化，提交merge到develop branch，通過代碼評審，成功merge。

2.2 工程實踐

????????工程實踐是指與代碼緊密相關(guān)的偏技術(shù)類實踐。常見的工程實踐有：架構(gòu)設(shè)計、需求分析、持續(xù)集成、TDD、ATDD、自動化測試、探索性測試、用戶故事分析等等。

2.2.1 CI/CD實踐

《YS8803 Validation》

2.2.2 代碼評審

《代碼評審》

2.2.3 文檔評審

????????在收到審核請求時，設(shè)計類文檔審核響應的最長期限是一個工作日，其它類型的文檔則最晚在本周的最后一天做出響應。Review人員至少3個，包括但不限于模塊負責人、驗證人員、項目負責人等。

2.2.4 編碼指南

《EMB 固件編碼規(guī)范》

2.2.5 技術(shù)債務管理實踐

2.3 文化

2.3.1 團隊價值觀

Scrum五大價值觀：承諾、 專注、 開放、 尊重、 勇氣、成長

敏捷宣言四大價值觀：

個體及互動勝于過程和工具

可用的軟件勝于完整的文檔：避免編寫含可疑細節(jié)、易過時、不易維護的文檔

客戶合作勝于合同談判

應對變更勝于遵循計劃

2.3.2 協(xié)作和知識共享

• 營造學習型氛圍，不定期團隊分享。

表單收集分享主題，周五下午按實際情況召開分享會，在釘釘群Embedded FW Team直播，并記錄在The Yuque document of the Share meeting。分享課題不限，如提高效率的工具或軟件、debug經(jīng)驗、協(xié)議feature或最近閱讀的書籍等等。

• 《統(tǒng)一術(shù)語》

2.3.3 持續(xù)改進

????????勒布朗法則：later equals never，如果當時發(fā)現(xiàn)了一些問題，若能想到解決辦法就盡早解決。

????????童子軍軍規(guī)：讓營地比你來時更干凈。如果每次簽入時，代碼都比簽出時干凈， 那么代碼就不會腐壞。清理并不一定要花多少功夫， 也許只是改好一個變量名， 拆分一個有點過長的函數(shù)，消除一點點重復代碼，清理一個嵌套if語句。你想要為一個代碼隨時間流逝而越變越好的項目工作嗎？ 你還能相信有其他更專業(yè)的做法嗎？難道持續(xù)改進不是專業(yè)性的內(nèi)在組成部分嗎？

2.4 工具

代碼格式化工具 - Astyle - 《代碼格式化工具》

項目管理工具 - 禪道

版本管理工具 - Git - 《嵌入式固件Git使用規(guī)范》

AI Assistance - ChatGPT - 寫單元測試

3 總結(jié)

????????敏捷團隊章程是一份鮮活的章程，每次團隊回顧都值得來把回顧所得加入或者修改到敏捷團隊章程。這份章程不在于面面俱到，恰恰在于剛剛好并鮮活的指導團隊，讓團隊成員覺得有幫助。

????????在具體實踐中有爭議時應當首先考慮團隊章程是否對此有說明，如果有，按說明辦；如果原說明不合適，如何修改；如果沒有，是否值得加入。最后強調(diào)，團隊章程的權(quán)威性應當高于團隊里面的任何角色。保持團隊章程的鮮活和權(quán)限，是團隊持續(xù)敏捷的好辦法。

總結(jié)

以上是生活随笔為你收集整理的敏捷团队章程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。