學習 EA, Agile & UML 和 使用 Visual Paradigm 技能

许多技术可用于查找资产故障和我们要分析的其他重要事件的根本原因。故障树分析是其中一种技术，许多不同的公司正在使用它来提高系统可靠性。本指南旨在对故障树分析过程进行基本到中级的介绍。它讨论了用例、类型、符号、过程、示例和有用的软件解决方案。 

SWOT 分析是一個簡單但功能強大的框架，用於利用組織的優勢、改善劣勢、最大限度地減少威脅並最大限度地利用機會。SWOT 分析是 1970 年代斯坦福大學開發的一種技術，經常用於戰略規劃。

在過去的十年中，敏捷軟件開發取代了傳統的瀑布模型，成為許多企業討論的熱門話題。儘管敏捷開發很受歡迎並取得了成功，但仍有一些關於它的誤解。本文將研究一些關於敏捷方法的常見誤解。以下是我們經常遇到的關於敏捷軟件開發的 6 個常見誤解：

Scrum 是一個簡單的經驗過程，它使團隊能夠在迭代中逐步構建產品，以跟上不斷變化的市場需求並與組織的業務目標保持一致。

“Scrum 是一個敏捷的過程，它使我們能夠專注於在最短的時間內交付最高的業務價值。”
- Mike Cohn，Mountain Goat 軟件

Scrum 提倡自組織團隊通過不斷的檢查和適應朝著共同的目標努力。每次迭代結束時的最小可行產品為團隊提供了一個選項，可以快速從最終用戶那裡獲得反饋並更快地做出響應。

正如Scrum 指南中 所述，Scrum 框架由 Scrum 團隊及其相關角色、事件、工件和規則組成。然而，Scrum 規則 不像角色、事件和工件那樣可辨別。此列表試圖提煉此類 規則， 並作為 Scrum 指南™ 的補充資源提供。

数据建模是一种使用实体关系图（ER图）记录软件系统的技术，实体关系图是公司数据库表中数据结构的表示。它是公司业务需求的非常有力的表达。数据模型有多种用途，从高级概念模型、逻辑到物理数据模型，通常由实体关系图表示。它作为数据库分析师和软件开发人员在系统和底层数据库的设计和实现中使用的指南。

瞭解功能性需求和非功能性需求之間的差异將有助於客戶和提供商深入瞭解他們的需求，這將導致更好的範圍細化、優化成本，並最終獲得滿意的客戶。

在敏捷軟件開發 (Agile Development) 中，需求是從用戶的價值點捕獲的。通常有幾個參與者在稱為用戶角色的系統上起作用（例如：用戶、管理員、客戶、供應商等）。它不應該從開發人員、測試人員或經理的角度編寫。

用戶故事是敏捷團隊中捕捉功能願望的事實上的標準。用戶故事通常是從最終用戶或系統用戶的角度編寫的。換句話說，用戶故事描述了用戶的類型、他們想要什麼以及為什麼。用戶故事有助於創建需求的簡化描述。根據項目的不同，用戶故事可能由不同的利益相關者編寫，包括客戶、用戶、經理或開發團隊成員。

您的軟件的生命週期不會從編碼開始並隨著發布而結束。相反，它有一個持續的生命週期，在必要時停止和開始。它的生命週期的開始和很大一部分工作在發佈時就開始了。

軟件總是在變化，只要還在使用，就必須對其進行適當的監控和維護。這在一定程度上是為了適應組織內的變化，但更重要的是因為技術在不斷變化。

您的軟件可能出於多種原因需要維護——保持其正常運行、增強功能、重新設計系統以適應未來的變化、遷移到雲或任何其他變化。無論軟件維護的動機是什麼，這對您的業務成功至關重要。因此，軟件維護不僅僅是查找和修復錯誤。它使您的業務核心保持正常運行。

Scrum在 1990 年代初期開發,  2010 年編寫了第一版 Scrum 指南。

統一建模語言 (UML)是一種通用建模語言。UML 的主要目標是定義一種標準方法來可視化系統的設計方式。它與其他工程領域中使用的藍圖非常相似。

UML不是一種編程語言，而是一種可視化語言。我們使用 UML 圖來描繪系統的行為和結構。UML 幫助軟件工程師、商人和系統架構師進行建模、設計和分析。對像管理組 (OMG) 在 1997 年採用統一建模語言作為標準。此後一直由 OMG 管理。國際標準化組織 (ISO) 於 2005 年發布了 UML 作為批准的標準。 UML 多年來一直在修訂並定期進行審查。

用例描述了用戶如何使用系統來實現特定目標。用例圖由系統，相關用例和參與者組成，並將它們相互關聯以形象化：所描述的內容是什麼？（系統），誰在使用該系統？（參與者）以及參與者想要達到的目標？（用例）因此，用例通過從用戶的角度捕獲需求來幫助確保開發正確的系統。

用戶故事是敏捷團隊中捕捉功能願望的事實上的標準。用戶故事通常是從最終用戶或系統用戶的角度編寫的。換句話說，用戶故事描述了用戶的類型、他們想要什麼以及為什麼。用戶故事有助於創建需求的簡化描述。根據項目的不同，用戶故事可能由不同的利益相關者編寫，包括客戶、用戶、經理或開發團隊成員。

Scrum基於測試過程控制理論（Empirical Process，或所謂的經驗主義。經驗主義認為知識來源於當前已知情況下的實際經驗和觀察。（注意它不同於教條主義，以及基於固定思維的完全依靠過去的經驗，或忽視理論指導的部分經驗主義）。

（來源：  Top 7 最流行的用戶故事敏捷估算方法）

在敏捷評估方面，您不能不提及其基本原則：使用相對估計單元（如故事點），促進對用戶故事內容的詳細討論，形成共識和對解決方案的承諾，並增強團隊通過凝聚力的合作。

估算是Scrum和其他敏捷過程中的支持活動之一。這意味著評估故事大小的過程，即需要花多長時間，實施多少工作，花費多少，或者你想要它。在Scrum中，估算是團隊活動。對於每個故事，整個團隊參與估算過程。計劃撲克  （有時被稱為Scrum的撲克）是一個簡單但功能強大的工具，使團隊估計更快，更準確，更有趣。這個詞由James Grenning創造，由Mike Cohn推廣。

隨著最近開發的敏捷方法越來越多地被採用，用於開發軟件的傳統瀑布方法正在迅速普及。但兩者之間有什麼區別- 敏捷總是更好嗎？

什麼是敏捷？

敏捷是軟件開發中的重複和增量過程，有助於軟件的功能以較小的周期發布。這項工作由一個高度專業的自組織團隊完成，該團隊檢查是否真正滿足了客戶需求，從而可以相應地進行更改。例如，XYZ公司正致力於製作遊戲應用程序，並且通過敏捷方法以小周期釋放遊戲以檢查兼容性及其工作速度並相應地進行更改。通過在小周期中重複檢查和發布，公司可以通過電子郵件或聊天從客戶端獲得新想法和反饋，以便團隊可以有效地進行增量改進。使用敏捷方法，公司可以從客戶端獲得真實的反饋，以更好地改進項目。

Scrum是一種敏捷方法，旨在指導團隊進行產品的迭代和增量交付。通常被稱為“敏捷項目管理框架”，其重點是使用經驗過程，使團隊能夠快速，有效，有效地做出改變。傳統的項目管理方法確定了需求，以控制時間和成本; 另一方面，Scrum修復了控制需求的時間和成本。這是使用時間框，協作儀式，優先產品積壓和頻繁的反饋週期來完成的。整個項目中業務的參與至關重要，因為Scrum在很大程度上依賴於團隊與客戶或客戶代表之間的協作，以精益的方式創建合適的產品。

计划POKER或SCRUM POKER你需要知道的一切

嗨，本周我将讨论Planning Poker或Scrum Poker; 使用基于共识的估算的策略。来自世界各地的敏捷团队使用计划扑克技术来估计他们的产品积压。Scrum Poker可用于故事点 (Story Point)，理想日期或任何其他估算单位。