<progress id="jnld5"><th id="jnld5"></th></progress>

        <pre id="jnld5"></pre>

        <strike id="jnld5"><noframes id="jnld5"><pre id="jnld5"></pre>
        <strike id="jnld5"></strike>

        <strike id="jnld5"><span id="jnld5"><pre id="jnld5"></pre></span></strike>

        <font id="jnld5"><track id="jnld5"></track></font>

        對產品質量的一點思考

        發表于:2019-07-02來源:未知作者:不止dotNET點擊數: 標簽:
        不管是做產品還是做項目,也不管是采用瀑布模型還是敏捷開發,我們都有一個終極目標,就是能按時交付質量可靠的功能,其中質量尤為重要。本文是我對產品質量的一點思考,如果
        不管是做產品還是做項目,也不管是采用瀑布模型還是敏捷開發,我們都有一個終極目標,就是能按時交付質量可靠的功能,其中質量尤為重要。
        本文是我對產品質量的一點思考,如果您所在的團隊代碼質量很高,很少出BUG,那么可以私信我,我們可以交流下關于代碼質量的一些問題。
        小公司面臨的問題
        大公司里每個人指責分明,團隊的人員配置也比較齊全,有完整的開發流程,流程也會不斷的迭代優化,每個環節只要按照流程嚴格去執行,基本不會出什么大的問題。但不是每個人都能夠進入到大公司,或者說會一直待在大公司,如果您是在中小公司,可能會有下面一些情況:
        沒有專職的需求分析人員,沒有專職的測試人員,很多時候是一崗多職
        沒有不急的項目,客戶永遠說的都是越快越好
        雖然說唯一不變的就是變化,我們需要擁抱變化,但常常會即便擁有一雙長臂,也無力擁抱
        需求來了,直接寫代碼,后期補文檔
        代碼中基本不寫單元測試
        沒有自主研發的需求管理平臺
        為什么會有上面的問題,我覺得很重要的一個原因是成本問題,專職需求分析需要人力成本,寫單元測試、文檔等需要時間成本,等等。短期看來是節省了成本,但從長遠來看,會導致質量下降,最終會得不償失,如果您是做項目,打一槍換個地方,我不做評價,如果是在不斷地迭代成品,那么就要停下來好好思考下了。
        我們的現狀
        10人左右的團隊,需要做的事情如下:
        需求分析
        Vue前端開發
        dotNetCore后端開發
        H5、小程序、iOS、安卓
        測試
        運維
        上面說到,在小公司會是一崗多職,我們也不例外,大概任務分配如下:
        全員做需求分析,即便是新手,也要求做簡單需求的分析
        后端工程師除了iOS和安卓不做,其他的都做
        iOS和安卓工程師除了后端不做,其他都做
        只有一兩個只做純前端的工程師
        目前來看,整個團隊是偏全棧的,全棧的團隊理論上效率會很高,的確,效率從來都不是我擔心的問題,但質量問題卻一直都沒能很好的解決:
        開發人員還是更喜歡寫代碼,文檔能力偏弱,雖然目前強制規定每個所做的需求在語雀上要寫對應的需求文檔,但很多時候寫不到點子上,關聯影響點也沒有分析,給測試提供不了很好的支撐
        文檔寫不好,加上開發者的思維,很多低級問題在自測階段不能被發現
        經常改了A模塊的一個問題,引發其他模塊的幾個問題
        同樣的問題會反反復復出現
        怎樣解決質量問題
        取舍和平衡
        我認為軟件開發其實是在時間、范圍、穩定性和代碼質量上做博弈:
        時間:交付一個功能的期限,比如老板說3個月要上線某功能
        范圍:需要實現功能的邊界
        穩定性:隨著版本的不斷更新,用戶使用產品的一個最直觀的感受
        代碼質量:代碼是否是可復用,易于維護的,用戶不能直觀感受,但也同樣重要
        領導總是會說,這個時間節點非常重要,或者重要客戶,不能延后,等等,總之時間節點后延的可能性不大。
        穩定性也不能出問題,輕則客戶滿意度降低,重則會造成事故,給客戶帶來嚴重損失,客戶可能因此就丟了。
        所以只能在范圍和代碼質量上做取舍:
        本來應該三個月做的任務,非要壓縮到一個月,那只能去和領導溝通,將一些不重要,或者不緊急的任務放到下一階段完成
        如果范圍也不能壓縮,那就只能舍棄代碼質量了,怎么快怎么來,但也因此欠下了一個技術債,債是需要償還的,也是有利息的,還的越遲,利息越多。
        自動化測試
        自動化測試分為兩個部分,構建之前的單元測試和構建之后的端到端測試
        單元測試又分為前端Vue的單元測試和dotNetCore的單元測試,在一個已成型的產品中去加單元測試是很困難的,所以只能先找一些關鍵點,經常出問題的點去嘗試
        端到端的測試我們采用TestCafe,反復出問題的地方,就提煉出來一種業務場景,有針對性地去寫測試代碼
        配合Jenkins,做到測試的自動化,那是不是有了自動化測試就能高枕無憂了呢?并不是,我覺得更重要的是,每個人員對產品要有深入的理解,對所做的需求要能完全掌握,對關聯影響點的分析要沒有任務遺漏。
        測試只是手段而不是目的,我們的目的是寫出好的代碼,交付出無缺陷的功能。
        總結
        沒有任何的方法論是可以生搬硬套的,只有不斷的去學習、吸收、結合現有資源進行實踐、不斷的重復這個過程,直到找到一種適合自己團隊的落地方案。

        原文轉自:http://mp.weixin.qq.com/s?__biz=MzU0NjgzNzQyMw==&mid=2247483862&idx=1&sn=b2993fc378c7a1c7e98f7d02238f1db4

        欧美日韩亚洲中文字幕|欧美变态另类z0z0禽交|久久国产精品-国产精|久久激情四射婷婷五月天

        <progress id="jnld5"><th id="jnld5"></th></progress>

              <pre id="jnld5"></pre>

              <strike id="jnld5"><noframes id="jnld5"><pre id="jnld5"></pre>
              <strike id="jnld5"></strike>

              <strike id="jnld5"><span id="jnld5"><pre id="jnld5"></pre></span></strike>

              <font id="jnld5"><track id="jnld5"></track></font>