回覆列表
  • 1 # 不一樣的自我18

    勤哲Excel伺服器是一個簡單易用功能強大的資訊系統DIY工具,可以幫助企業管理者自主構建資訊系統,不用程式設計,不依賴軟體開發人員,會Excel就能用,使得企業使用者真正成為資訊化程序的設計者、實施者和主導力量。

  • 2 # 微啟萬

    無論是創業軟體團隊,還是企業級規模化軟體研發,都會遇到提升管理能力、提升研發效率的問題。為了解決這兩個問題,許多軟體研發工具平臺也營運而生:微軟、IBM、HP、Atlassian、Rally、Collabornet、Polarion……等廠商都推出了各具特色的產品,而近年來新生的Slack、teambition等平臺也帶來了新的理念和產品,受到了許多團隊的歡迎。作為軟體研發的團隊或企業,我們該如何根據自身發展情況,對這些產品和工具進行合理的選擇?一個支撐軟體高效研發的工具平臺應該具備哪些特點?未來又將向什麼方向發展呢?

    世界範圍內軟體研發工具平臺產品發展迅速,國內產品仍是空白

    當我們在學校裡用Visual Studio編寫hello world的時候,我們就已經開始使用工具進行軟體研發。只是那個時候,工具的作用還很單一,對管理能力、研發效率的整體提升還沒有特別關照。

    在80年代,國內的計算機、軟體行業剛剛萌芽的時候,國外的同行已經開始研究使用工具提升軟體研發效率,微軟、Rational(後來被IBM收購)推出了各自的IDE,並在不斷增強IDE功能的同時,向需求管理和質量管理方向拓展。

    90年代,又有一些廠商加入到了開發軟體研發工具產品的行列中,其中國內同行非常熟悉的莫過於Mercury(後來被HP收購)的產品,90年代末和2000年前後,大家經常使用的研發工具組合一般是:需求管理用Rational Request Pro,開發IDE用Micosoft Visio Studio,程式碼庫用collabnet subversion或Rational Clear Case,測試管理用Mercury Test Director,軟體效能測試用Mercury LoadRunner。這些工具在軟體研發的每個方面都提升了個人和團隊的效率,也讓越來越多的人看到了工具平臺對軟體研發效率提升的重要性。

    進入21世紀,敏捷思想及敏捷軟體研發方法開始逐漸改變人們對軟體研發的認識。在軟體研發工具平臺方面,ALM(Application Lifecycle Management)逐漸成為各工具廠商產品努力的方向。在短短的10年內,湧現出一大批優秀的軟體研發工具平臺廠商,如Atlassian、Rally、Polarion、Versionone、Serena……一些老牌廠商,如微軟、IBM、HP透過收購、合併、開發新的工具產品等方式,更加完善了軟體全生命週期管理的工具平臺。有了新的軟體研發方法,配合眾多優秀的軟體研發工具平臺,軟體行業得到了快速的發展。此時國內同行也廣泛認識到工具平臺對提升研發效率的重要性,有條件的企業或採購,或自主研發,搭建起自己的研發工具平臺。

    2010年前後,隨著網際網路的蓬勃發展,網際網路軟體研發逐漸成為新的焦點,DevOps很快成為大家普遍的共識。很多傳統軟體研發工具廠商打著“DevOps”的旗幟適時地推出了一些產品或升級版本,同時又有一些新的廠商加入競爭的行列。在如何能夠更好地管理軟體研發活動的問題上,像Slack這樣的產品向“傳統”研發工具平臺發起了新的挑戰,在看到越來越多的軟體研發團隊更願意使用Slack進行日常研發工作時,我們不禁陷入思索:未來軟體研發工具平臺將何去何從?

    目前軟體研發工具平臺的對比研究有很多,但實用性低

    2010年以後,多家重要的IT諮詢公司分別開始定期釋出主流軟體研發工具平臺對比研究報告

    這些報告每一篇報告單獨看似乎視角都很客觀,評估方法似乎都很縝密。但當把他們放到一起比較後,會發現它們的結論大相徑庭,不同的廠商也會精心挑選“適合”自己產品的報告,懸掛於自己的產品網站首頁。而這些只有兩個維度的魔力象限對於真正需要軟體研發工具平臺的團隊或企業來說,幫助並不是很大。

    我們發現這些IT諮詢公司評判軟體研發工具平臺廠商,及其產品的視角無外乎有兩個:一個是從ALM的功能視角;另一個是商業的視角。在ALM功能視角下,各家諮詢公司會分別著眼於軟體的需求、設計、開發、測試、釋出等幾個主要環節,詳細對比各個廠商的產品功能,看誰的功能更強大,誰的功能更全面。而在商業的視角中,他們則更多以產品的市場份額、廠商服務的覆蓋程度以及盈利的多少、來衡量哪家廠商更加優秀。這樣就造成了功能越齊全的產品、體量越大廠商的在類似的比較報告中越得到好評,反之則被排在後面。

    但是,對於正在尋求軟體研發工具平臺解決方案的團隊和企業來說,尤其是正在進行敏捷、網際網路轉型的團隊或企業來說,上面的這些對比方法還是顯得陳舊、粗獷,並沒有解答哪個工具平臺更加適合我們這些正在進行敏捷軟體研發,或者網際網路軟體研發的團隊。

    在敏捷軟體研發的影響下,工具平臺發生了很大變化

    傳統瀑布模式下的軟體研發,注重軟體從概念到上線的流程以及每個流程節點上的關鍵活動,同時也重視專案的管理。許多支援瀑布模式開發的軟體研發工具平臺,在需求管理、質量管理、配置管理、專案管理等方面的功能都十分強大。

    敏捷思想強調“以人為本”,讓人們主動、自我管理、響應變化、互相信賴地工作。敏捷軟體研發方法,如Scrum、Kanban、XP實踐等指導軟體研發團隊擁抱需求變化,快速交付客戶價值,持續改進。要想使團隊或組織真正敏捷起來,需要在人、技、法三方面達到和諧。這就需要軟體研發工具平臺這個“技”的方面也要敏捷起來。

    敏捷宣言的第一句話是:“個體和互動勝過流程和工具”,但這並不是說敏捷不需要工具的支援。相反,如果有了更好地研發工具支援,提高團隊的工作效率,才能真正的敏捷起來。

    對照敏捷宣言的幾句話,我們大致能看到敏捷價值觀下的研發工具應該具備的特點:

    1. 個體與互動勝過流程和工具:研發工具應該能夠突出個人的工作,並且能夠讓團隊更好地協作

    2. 工作的軟體勝過詳盡的文件:研發工具應該精簡文件及審批流程,讓軟體交付更加順暢

    3. 客戶合作勝過合同談判:研發工具應該支撐快速交付可工作的軟體,並且能夠更好地幫助使用者反饋

    4. 響應變化勝過遵循計劃:研發工具應該打通需求、設計、開發、驗證的迴圈,持續交付

    同時,我們看到越來越多的工具平臺正在發生如下的變化:

    強化:

    1. 對敏捷軟體開發實踐的支援

    2. 對持續快速交付的支援

    3. 對團隊協作的支援

    4. 對使用者反饋的支援

    5. 使用者體驗的提升

    6. 單一工具解決特定問題,平臺提升整體效率

    弱化:

    1. 流程及審批

    2. 文件及變更管理

    3. 基於時間的任務項計劃管理(甘特圖)

    4. 把產品質量問題交給測試人員

    5. 專案中角色及許可權劃分

    6. 大而全的平臺解決所有問題

    以上的變化讓我們清楚地看到敏捷研發給工具平臺帶來的變革,我們也可以總結一下,敏捷方法下的軟體研發工具平臺應該具備以下6個特點:

    1. 敏捷管理實踐(使用者故事地圖、故事列表、優先順序、估算、卡片牆/看板、燃盡圖/CFD、回顧資料)

    2. 敏捷開發實踐-程式碼(IDE整合、程式碼掃描、程式碼審查)

    3. 敏捷開發實踐-Dev-Test-Ops的Pipeline效率提升(編譯、CI、UT、AT、釋出、部署、運維)

    4. 使用者反饋與研發流程打通

    5. 注重協作與使用者體驗

    6. 團隊能負擔的工具平臺價格

    主流敏捷軟體研發工具平臺比較,各有所長

    上面的表格是我們基於敏捷研發方法下的工具平臺應具備的功能,結合對每個工具平臺的深度試用或試用後做出的比較。看到在敏捷研發的場景下,各家平臺的功能各有所長。

    選擇適合自己團隊的軟體研發工具平臺

    在軟體研發工具平臺中,沒有通用的最完美的解決方案。錯誤的選擇會讓組織的成長、競爭以及產品的成功交付受到影響。

    在選擇軟體研發工具平臺時,先要確定使用工具平臺想要使組織在哪方面得到提升,是快速交付的能力?還是為了支撐敏捷開發實踐?或是敏捷管理實踐落地?還是為了更好地收集管理使用者反饋?亦或是為了加強團隊協作?

    確定了目標,還要結合人技法三角,綜合考慮用什麼樣的工具,即“技”。要充分了解三角的其它兩個方面,也就是了解團隊或組織的人的能力水平,和目前大家使用或將要使用的研發方法。

    只有在人、技、法三方面達到和諧,才能充分地發揮工具平臺的效果,才能真正解決問題,使組織的能力得到提升。

    軟體研發工具平臺未來的發展

    隨著軟體行業的迅猛發展,軟體研發工具平臺也必然會發生更多的變化。未來的軟體研發工具平臺將會更加突出如下特徵:

    1. 更快

    在需求、設計、開發、測試、部署、反饋的軟體研發週期中,研發工具平臺會更多提高研發整體效率,進一步縮短研發週期。

    2. 質量風險前移

    在程式碼檢查、CR、CI、單測、自動化功能、效能測試、安全測試等方面,研發工具平臺會更注重質量風險的前移,即在開發階段保證質量的優秀實踐的落地。

    3. 更多協作

    在團隊協作、客戶合作方面,研發工具平臺會更好地結合網路社交、移動網際網路等新業務新技術,讓軟體研發這種人與人的協作活動更順暢、更方便。

    文章連結:http://m.sohu.com/a/49759926_117780

  • 3 # Real遊戲引擎開發者

    相關的平臺有很多種,推薦一個我們正在使用的,Gitlab +jenkins。其中gitlab用來進行程式碼管理和程式碼review,而jenkins用來進行自動化構建,後臺使用分散式結構,從而保證反饋的實時性。

  • 4 # 葡萄芋圓啵啵

    我們公司用的是天翎的平臺。

    平臺選型三原則供你參考一下:一是技術功力,如果沒有專注該領域十年以上不要選,二是業務領域知識,沒有對應領域大型案例的不選,三是原始碼的交付,不提供原始碼的平臺也不要選。

  • 5 # EKKOxxxxx

    天翎吧,我們公司一直用的是這個,挺好用的,業務簡單的話只需要簡單的配置就能實現,就算業務複雜也能很好的相容,我也看過藍凌,泛微這些公司的產品,也都不錯,各有千秋,但還是覺得天翎的好,而且技術棧也比較新。

  • 中秋節和大豐收的關聯?
  • 車子發動不起來應該怎麼辦?