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

目錄  

1 衝刺前

2 在Sprint 期間

3 衝刺中的每日站立

Table of Contents 
 

1 傳統團隊與自我管理團隊之間的差異

2 自我管理方法的好處

價值流圖 是一種識別和消除流程浪費的技術。它是一種特殊類型的流程圖，使用稱為“精益語言”的符號來描述和改進庫存和信息流。它幫助我們通過完整的價值創造流程為客戶提供最佳價值，並在以下幾個方面最大限度地減少浪費：

• 設計 （給客戶的概念）
• 建造 （訂單交付）
• 維持 （從使用到服務的整個生命週期）

我们在软件开发中总是遇到这些术语。有时人们是一个软件功能——需求/用例、待办事项……。

软件人员使用那个或哪个的约定是什么？

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

TOWS 分析是经典商业工具 SWOT 分析的变体。TOWS 和 SWOT 具有相同的优势、劣势、机会和威胁的首字母缩略词，并且单词的顺序相反。SWOT矩阵是一种规划工具，而 TOWS 矩阵是一种行动工具。在 SWOT 分析中，您可以以点的形式识别所有优势、劣势、机会和威胁。之后，您将每个点视为一个单一的视角。

TOWS 分析是SWOT 分析的變體，是威脅、機會、弱點和優勢的首字母縮寫詞。 TOWS 分析是經典商業工具 SWOT 分析的變體。TOWS 和 SWOT 具有相同的優勢、劣勢、機會和威脅的首字母縮略詞，並且單詞的順序相反。

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

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

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

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

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

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

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

SWOT 分析是评估公司内部和外部环境最常用的工具之一，是公司战略规划过程的一部分。此外，可以对产品、地点、行业或个人进行 SWOT 分析。SWOT 分析有助于战略规划和决策，因为它为公司带来了机会，作为产生战略选择的前瞻性桥梁。SWOT为的缩写 Strengths，Weaknesses，Opportunities，和 Threats。

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

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

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

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

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

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

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

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

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

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

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