JIRA敏捷

敏捷是一種時間盒式的迭代方法，可以逐步構建專案，而不是一次性構建專案。敏捷是一種在整個軟體中促進開發和測試的連續迭代的實踐。

什麼不需要敏捷？

• 主持會議
  團隊每天進行10-15分鐘的頻繁會議，他們認為頻繁的會議將是敏捷的。但是，只有以下會議才會敏捷。

• 需求隨時變化
  需求可以隨時更改，那不需要敏捷。例如，客戶想要添加一些新功能並希望同時更新更改，那麼這將不是敏捷。

• 非結構化發展
  假設您沒有遵循任何計畫並且您正在開發Adhoc，那麼它不是敏捷的，其中Adhoc測試，測試人員隨機測試應用程式而不遵循任何文檔和測試設計技術。

• 沒有文檔
  如果公司沒有製作文檔，那麼它不是敏捷的。

什麼是敏捷？

敏捷是一種哲學，即一套決定開發軟體的價值觀和原則。
敏捷基於迭代增量模型。在增量模型中，我們以增量方式創建系統，其中每個增量都是單獨開發和測試的。

下圖顯示了敏捷模型如何逐步工作 -

什麼是價值？

在敏捷中，需要執行下表中提到的所有八個任務。但是，我們必須確保左側任務的優先順序應該高於右側任務。

• 個人和互動，優先於過程和工具
  假設團隊在軟體中發現任何問題，然後他們搜索另一個流程或工具來解決問題。但是，在敏捷中，最好與客戶，經理或團隊就問題進行互動，並確保問題得到解決。

• 工作軟體，優先於文檔
  需要文檔，但是非常需要工作軟體。敏捷並不是說不需要文檔，但是非常需要工作軟體。例如，您有20頁的文檔，但您沒有軟體的一個原型。在這種情況下，客戶端將不滿意，因為最終客戶端需要一個文檔。

• 客戶協作，優先於合同談判
  合同談判在制定軟體預算時很重要，但客戶協作比合同談判更重要。例如，如果您堅持要求或流程，那麼就不要簽訂我們已經協商的合同。您需要與客戶互動，收集他們的需求。

• 遵循變更，優先於遵循計畫
  在瀑布模型中，一切都是有計畫的，即，在什麼時間，每個階段都將完成。有時您需要在軟體中間實現新要求，因此您需要具備多種功能才能對軟體進行更改。

注意：根據敏捷方法，左側任務應優先於右側任務。

敏捷原則

• 首要任務是通過儘早和持續交付有價值的軟體來滿足客戶。根據敏捷原則，客戶就是他們的一切。無論客戶需要什麼，他們都有任何問題或想要添加新的要求，他們總是優先考慮客戶。傾聽客戶的意見，並為客戶提供高質量的軟體。

• 它歡迎不斷變化的要求，甚至在開發的後期。敏捷流程利用變革為客戶帶來競爭優勢。在瀑布模型中，如果要在軟體中間進行任何新的更改，則整個過程將再次完成。因此，瀑布模型是剛性的而不是通用的。敏捷可將這樣的工作可以很容易地將新的變化整合到軟體中。

• 經常提供工作軟體，從幾周到幾個月，優先考慮更短的時間尺度。在瀑布模型中，當整個系統開發出來時，只有它被傳遞給客戶，而敏捷說不要等待太久，等待幾周或幾個月。無論您開發了什麼都要向客戶端演示，這樣就可以向客戶提供您在初始階段正在開發的軟體的每個功能。

• 業務人員和開發人員必須在整個專案中每天一起工作。這意味著客戶，客戶和團隊應該每天進行交互。
• 圍繞有動力的個人建立專案，為他們提供所需的環境和支持，並信任他們完成工作。敏捷相信你的團隊，客戶和公司。假設給團隊成員一個任務，然後提供他需要的所有資源，如文檔，系統，資訊研究等。
• 向開發團隊內部和內部傳達資訊的最有效和最有效的方法是面對面交談。假設有些情況需要與客戶進行交互，開發團隊通常通過郵件或電話進行，但最好進行面對面交談。
• 工作軟體是進步的主要衡量標準。敏捷無論是通過文檔還是專案經理所說的內容，開發或工作的軟體數量都是進度的衡量標準。
• 敏捷過程促進可持續發展。贊助商，開發者和用戶應該能夠無限期地保持穩定的步伐。敏捷說，讓你的團隊在交付時保持不變，這樣團隊應該有固定的工作時間意味著如果公司的工作時間是8小時，那麼團隊應該在一天工作8小時。
• 持續關注技術卓越和良好的設計提高靈活性意味著團隊成員在技術上應該是合理的，以便他們可以做出好的設計，如果做出任何改變，那麼它們可以很容易地融入軟體中。
• 最好的架構，需求和設計來自自組織團隊。無論架構團隊進行何種設計，他們都確保他們與開發團隊坐在一起並討論軟體的架構。
• 團隊定期反思如何變得更有效，然後調整並相應地調整其行為。這個原則說團隊應該經常見面，以便他們可以討論他們面臨的問題，並且可以有效地解決。