資料結構
網路
關係型資料庫管理系統
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝設計
法律研究解釋敏捷軟體開發流程及其原則
**敏捷宣言**首次出現於2001年。它旨在改變軟體建立流程。該宣言有四個關鍵方面，但很少有人瞭解**12條敏捷原則**。它們更具體地解釋了可以進行敏捷產品開發的過程。多年後，幾乎所有公司都聲稱提供“敏捷服務”，但大多數只是對敏捷宣言的理念和概念敷衍了事。軟體開發行業也發生了巨大變化。值得重新審視敏捷標準，以檢查其含義以及它們是否仍然適用。
及時且持續地交付有價值的軟體
根據第一條原則，“我們的首要目標是透過及時且持續地交付有用的應用來滿足客戶。”
我們通常在別人的時間和金錢上設計應用，以儘可能地提供幫助。如果我們花費大量時間來生產產品，客戶很可能會感到不滿意。這現在比以往任何時候都更加適用。客戶不僅重視流程中的早期和持續反饋，而且還要求快速執行。並且每次交付都應為客戶的生活帶來價值。例如，客戶不關心您調整登入頁面的想法。他很高興他現在可以透過她的社交媒體帳戶登入。
Plutora 彌合了 DevOps 和敏捷之間的差距
管理敏捷、DevOps 和瀑布方法之間的關係可能很困難。Plutora 提供了一個共享的環境，團隊可以在其中快速工作。
使用者越來越依賴應用程式來執行各種任務。他們通常習慣於定期提醒。因此，如果他們申請更新，他們將沒有足夠的耐心等待數月才能看到它們。
接受變化
根據第二條原則，“我們必須接受不斷變化的環境，即使是在生產後期出現的變化。”敏捷系統利用轉型來為客戶的戰略優勢服務。”
在快速變化的環境中，沒有人能夠預測軟體的規格會是什麼。另一方面，企業不喜歡意外。他們不喜歡在不再重要的商品上花費資金。如果我們擁抱進步，該平臺將為客戶提供戰略優勢，因為它滿足當前和最近的期望，而不是去年的期望。
多年來，關於環境快速變化的說法確實屬實。社會在發展，經濟在發展，我們的企業在發展，人們也在發展。與其試圖阻止或減緩此操作，不如擁抱並利用它們來造福我們自己和我們的客戶。
更快、更統一的交付
以下原則為“定期釋出可工作的應用程式/軟體，從幾天到幾個月，重點放在較短的時間範圍內。”
這個理論似乎是先前原則的重複，在某些方面確實如此。但是，先前的理論指出，我們必須儘快開始提供有用的應用程式。這個理論更深入地探討了持續交付需要什麼。它建議儘快釋出應用程式的新更新。這意味著更新更少，釋出更少，意味著故障潛入的機會更少。更頻繁的釋出也提供了更多獲得客戶反饋的機會。如果您在幾個月內都沒有獲得任何更新的反饋，那麼您將有更多工作要做才能處理這些評論。
隨著時間的推移，這個理論變得更加進步。“幾個月”的釋出週期不再被認為是敏捷的。行業標準已變為定期或每週釋出。
開發人員和業務人員共同協作
另一條理論說，“業務人員和程式設計師應在專案期間定期協作。”
程式設計師經常與業務人員隔離。專家被安置在他們中間，以便他們能夠將營銷術語翻譯成程式設計師能夠理解的語言。這就是鼓勵公司消除這些障礙並使開發人員和公司能夠每天聯絡的原則。這培養了更大的共享意識和欣賞。
我們希望您在孩提時代玩過傳話遊戲；每個人都知道，每一次溝通階段都會導致知識損失。與公司和開發人員密切合作減少了（但並沒有消除）這種風險。在當今分散的團隊世界中，我們必須努力定期進行協作。儘早識別誤解並彼此頻繁獲得反饋有助於產生良好的結果。
充滿激情的個人
這條原則建議程式設計師“構建圍繞充滿激情的個人的程式”。我們應該為他們提供他們需要的環境和資源，並相信他們能夠完成任務。”
敏捷團隊通常經驗豐富，能夠開發出高質量的應用程式。這需要一定程度的信任。但是，如果您不信任工程師，為什麼還要聘用他們呢？在正確的指導、環境和軟體下，積極的開發人員會感到有權正確地完成他們的工作。
如果您的專案圍繞著缺乏動力或由於缺乏信心或鼓勵而變得缺乏動力的個人構建，那麼您的專案不太可能成功。
面對面溝通
還有一個哲學認為，“面對面溝通是向生產以及生產內部傳遞知識最有效和可靠的媒介。”隨著技術的進步，人類互動的方式越來越多。但是，這些都不如面對面聊天有效。我們的思想不僅可以感知來自我們聲音的聲波，還可以檢測其他型別的訊號。肢體語言和麵部表情也很重要。使用非同步通訊時，誤解是正常的。
自 2001 年以來，我們的工作方式有了很大的改進。許多公司都有遠端工作的員工，即使他們身處不同的時區。問題跟蹤器和 Slack 等技術支援非同步通訊，而 Skype 和 Hangouts 等軟體支援遠端面對面通訊。但是，它永遠不會像面對面溝通那樣，但它足夠了。世界各地的團隊正在證明，即使他們沒有面對面地見面，他們也可以具有競爭力和靈活性。
可工作的軟體
根據此原則，“可工作的軟體是成功的首要指標。”
軟體開發需要很長時間。因此，企業有必要監控其成功情況。這條敏捷理論指出，可工作的軟體是衡量成功的首要手段。在將其轉換為可工作的應用程式之前，已完成的分析、完整的模板或優雅的模型毫無意義。它們可能很重要，但如果您沒有將其中的一部分投入到可執行的產品中，那麼您就沒有為您的客戶創造價值。
如今，我們通常更進一步。如果可工作的軟體尚未交付，則表示它尚未完成，因此沒有取得任何進展。未釋出的軟體是庫存。庫存是成本，而不是收入或價值的一部分。
現在，我們經常超越甚至超越。如果可工作的程式尚未交付，則表示它尚未完成，因此沒有取得任何成就。未釋出的軟體被視為庫存。庫存是成本，而不是收入或增值來源。
長期發展
第八條理論如下：- “敏捷流程鼓勵長期增長。贊助商、建立者和消費者應該能夠永遠保持這種速度。”
它表明人們可以生活在一個他們不斷受到可以承受壓力的環境中。壓力以各種形狀和形式表現出來。考慮預算、時間表、企業政治和同事欣賞等主題。
任何這些專案都可能成為繁重工作和壓力的來源，並可能導致人們離開，或者這些專案可能存在並且似乎沒有造成困擾。事情是這樣的。這並不是說任何這些問題都不可能出現在敏捷企業中。這確實意味著它們不可能一直存在。例如，敏捷團隊可以管理一段密集的、快節奏的工作時間。但是，此後他們應該休息一下。如果組織不斷將團隊推向崩潰的邊緣，那將無利可圖，因為團隊無法無限期地保持這種速度。
請注意理論中的“贊助商、開發人員和消費者”一詞。因此，每個人都必須能夠跟上當前的增長速度。例如，如果程式設計師為消費者生產功能的速度過快，他們應該跟隨他們。減速是一種實現此目的的方法。另一種選擇將是投入更多時間來記錄和培訓使用者瞭解最新功能。
這條原則的核心思想是，所有相關人員都應跟上程式建立的速度。
技術卓越
另一句諺語是，“持續致力於工程能力和良好的架構可以提高敏捷性。”
公司通常選擇將上市時間置於成功的技術設計之上。老實說，他們無法為此負責。我們剛剛說過未釋出的軟體很昂貴。終端使用者不關心技術能力，它也不會為公司帶來收入。
但是，如果團隊長時間忽視良好的工程設計，他們的速度和上市時間將開始放緩。他們根據不斷變化的需求修改商品的意願會下降。他們正在犧牲自己的敏捷性。
該理論至今仍在廣泛使用。根據我的經驗，管理者和工程師對這一理念都存在不確定性。在小型專案中，快速工作而不考慮良好的設計可能是合理的。但是，如果專案足夠大，那麼關注技術卓越性是值得的。
這並不意味著我們必須在開始編寫程式碼之前先建立大型的理論設計。隨著軟體的進步，良好的設計將會發展。然而，開發人員必須抽出時間並具備足夠的專業性來做到這一點。
簡潔性
另一個原則是“簡潔性——最大限度地減少未完成的工作量——至關重要”。
最佳化未完成的工作量可以透過多種方式實現，包括消除過時的流程、自動化重複性任務、使用現有庫而不是自己編寫等等。所有這些都能節省時間和資源，使我們能夠專注於提供更多價值。
所有組織都在持續努力。但是，確定何時以及如何進行改變需要付出一些努力。
自組織團隊
根據最終規則之一，“最佳的架構、規範和設計源於自組織團隊”。
該理論是許多先前概念的綜合。如果我們希望公司和程式設計師能夠持續高效地相互配合，如果我們希望透過執行應用程式而不是理論模型來評估成功，如果我們希望與富有創造力的人員合作，那麼我們必須擁有在沒有太多來自上層干預的情況下交付高質量軟體的團隊。
團隊必須學會在軟體生產的各個方面進行自組織，包括透過與公司溝通收集規範、編寫高質量軟體、組織工作等等。這將帶來優秀的應用程式，因為程式設計師將開始“擁有”軟體。
開發人員也被視為可以接受規範的流水線員工。然而，軟體開發是一項更加複雜的任務。允許團隊自行組織執行至關重要。
另一方面，敏捷軟體開發人員必須專注於這一角色。敏捷團隊要求開發人員承擔任務，而不僅僅是編寫程式碼。
定期反思和調整
最後，該理論指出，“團隊定期專注於如何變得更加成功，然後相應地調整和改變其行動”。
自組織團隊應該定期審查其流程，並在需要時進行更改。沒有一個團隊能夠完美執行。成熟的敏捷團隊會認識到挑戰，同時保持信心，然後採取措施改變運營。
該理論仍然具有重要意義。這就是使個人、團隊和企業具有競爭力的原因，他們拒絕承認現狀，並不斷努力改變現狀。
它們仍然都很重要
您會發現所有敏捷標準在今天仍然適用。這就是它們關注經濟現實和人性的原因，所有這些都沒有發生太大變化。如果有任何想法，它們比預期的更具進步性。例如，我們可以每週甚至定期部署，因為我們現在可以執行比 2001 年多得多的操作。另一方面，自 2001 年以來，某些概念有了新的含義，例如，人們不再需要在同一個空間才能有效地溝通。
182 次瀏覽
