中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文作者回顧了自己一次失敗的Scrum開發經歷，總結了如下問題及改進方法，望對后來者有幫助。

背景

公司是一家初創公司，因為新業務需求：另外兩個部門需要開發互聯網產品，于是成立了IT研發部。我的崗位是產品，另還有前端3枚、后端1枚、UI1枚、產品總監1枚。除產品總監外，其余都是萌新。

IT技術總監決定以Scrum敏捷開發來進行日常開發，由于其比較忙，暫由我擔任敏捷教練，帶著從沒接觸過敏捷開發的大家，一起嘗試。

到目前，大家已有1年的磨合了，開發完了兩個線上產品。然而，對于團隊的戰斗力（一個產品需要多久開發完？大概幾個sprint完成？每個sprint能做多少個任務？）還是模糊不清的，可以說scrum開發實踐的蠻糟糕的。下面就與大家分享下，希望后來者能避開我走過的坑。

Sprint1：估算埋的坑

我是運營轉的產品，對技術上可以說是比較白的，只能邊學邊摸索著推進團隊Scrum開發的進程。技術總監傳授了一些技巧讓我組織切割故事點，和程序一起估算開發任務，并組織開站會。一開始真的是一個頭兩個大，我對如何切割故事點？怎么估算開發周期？晨會每個人說完三個問題后又應該如何？這些都都很模糊，隨著業務的進展，只能硬著頭皮干了。

準備階段，我把需求和故事點迷迷糊糊屢出來后，和程序開會，讓他們了解產品的需求。關于估算，我們采取了每個程序各自估算的方法。前端負責做前端頁面和管理后臺，后端一個人做所有的業務。需求列表里屬于誰的故事，就各自估算，以人天為單位，放到teambition（協作工具）里。

到了開發階段，每天早晨會有站會，我們各自在座位上走一輪。期間，越往后感覺大家越不上心，有點應付。我做是主持角色，每天記錄成員工作完成情況。

結束總結時，我們發現了兩個問題：

1. 前端頁面兩個人寫的，各自有分配到頁面，但后期發現其中有個頁面是幾乎一樣的，這個而我切割故事的時候也沒有注意，他們各自重復的寫了，浪費了時間。
2. 延期了。我注意到，剛開始他們一天甚至可以完成估算的3天的工作量，但最終結果延期了3天（前期估算其實很不合理）。排除程序請假的因素，原因是有些任務程序不熟悉或開發期間遇到麻煩了，導致估算1天可以解決的任務，卻做了好多天。站會也詢問對方能不能解決，有沒有啥困難，都口頭上說沒問題很快能解決，可實際結果不是這樣。

失敗分析：

1. 沒有大家一起打撲克估算，討論矯正，而是各自單獨估算，估算的不準確。
2. 需求會沒有溝通到位，成員沒有對整體產品做全面的了解，產品也沒點出不同模塊的相同頁面，減少開發的浪費。
3. 站會溝通不夠，成員遇到問題沒有足夠重視，沒有延期發生時的解決方案。

Sprint2：溝而不通，有形無神

到了第二個sprint的，遇到了一個極其嚴重的問題：由于前期后端接口的任務沒有估算和切割（我當時也不懂，主要是引導者前端把故事做切割），然后，程序采取的是先寫頁面后調聯的方式（該方式也導致了后面前端程序回過頭調試時，有些功能都已經遺忘了，開發效率下降），導致前端頁面樣式都寫完了，卻沒有接口調試，只能停下來等后端寫接口。

此外，期間還暴露了很多其他問題，值得引起重視。如：

1. 后端程序不太樂于溝通，數據庫進度卡在了那里，沒有追蹤；
2. 前期切割任務沒有列入后端的任務，完全沒有發現這個問題，期間站會后端的匯報總是幫助前端調接口之類的，就略過了；
3. 另，我作為Scrum master臉皮比較薄也沒有尋求技術總監幫助，一般催程序一次兩次，對方還沒結束，只能繼續等著。

各種因素一起，導致了這個尷尬的局面。

失敗分析：

1. 前后端沒有獨立開，前端實現依賴后端的接口來完成工作。
2. 前期估算任務，忽略了后端的工作，寫接口寫數據庫表等都應該納入。
3. 前端采取先寫所有頁面樣式，再全部統一調聯的開發模式，導致后期接口壓力巨大，回過頭調聯可能已經忘記前面頁面的需求。應該采取邊寫樣式邊調聯的開發節奏。

Sprint3：士氣低迷得結束

受前一個sprint的影響，后面只能讓后端穿插著配合前端寫接口，前端等待的狀況無法避免，肯定延期了，大家的目標就是盡快交付。

由于前面頁面與調試的分離，導致每個階段都沒法進行測試，后面我測試發現很多問題，只能又退回去返工，導致延期時間延長，拖了快1個月才上線。

此外，有個前端是新手，期間也沒代碼檢驗的步驟，導致有些頁面用不了，重新返工。

延期期間每天加班，大家士氣更加低落，協作得非常糟糕。

失敗分析：

1. 沒有階段性的測試及驗收標準，開發模式不規范，應前期約定好并找專家確認。
2. 團隊氛圍不理想，沒有重視并調整。
3. 產品與程序溝通不到位，對需求理解不一致。

總結

最近一段時間，大家除了日常的開發，還有各種bug修改任務穿插，Scrum的實踐處于半停滯狀態，只有站會跟蹤在延續了。期間遇到的問題還是老問題，尤其是上線后爆發的問題，大領導責問技術總監，技術總監追責我，我看著程序無辜的眼神和忙碌的身影，也特別委屈無奈，有決心改但不知道從何開始。

有時候很迷茫，覺得自己不是在做產品的工作，除了調研產品、設計原型、溝通需求、上線前測試外，還要兼職生活委員，注冊各種賬號、走款審批、整理密碼。最難的就是要做Scrum master，很吃力，對外溝通難對內催進度難，出了事還要背鍋。自己覺得做的不好，估計領導和團隊成員也覺得我工作的不好吧，心累。期間至少有兩次，我感覺自己的自我被擊碎了。

但又很不甘心，從哪里失敗了，就想從哪里爬起來，或許沒有我想象中那么難，只要再改進一點就接近成功了。就像羅胖說的，摔倒了并沒有什么大不了的，爬起來，用簸箕把自己的碎片掃一掃，回頭再拼回去。

改進思路

針對這段經歷，我有一些改進思路想法，也希望過來人給我提提意見，幫助成長，感恩。

1. 先開一次輕松的會，團隊成員集思廣益，說說自己的改善意見，保持公開透明，下次開發時調整。
2. 規范任務開發估算的步驟，以故事點+打撲克牌來一起打個樣，看看每次大家能完成多少個故事點，慢慢提升效率。
3. 高效溝通，適當拍拍程序馬屁，他們也辛苦的，偶爾下午茶激勵大家。
4. 臉皮再厚點，只要發現延期的苗頭，放下手頭的工作，間隔性詢問追蹤，若超過一定時間則邀請專家幫助解決。
5. 確立驗收標準，每個sprint結束了，進行階段性測試，條件合適另邀請外部同事參與演示會。
6. 燃盡圖跟進進度，發現問題，及時發現并針對性改進。
7. 把線上的互動，全部轉移到線下來（白板、估算撲克），增加參與感與儀式感。

實踐結果怎么樣？暫時未知，有結果會與大家分享。

本文由 @季月 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 pexels，基于CC0協議