Scrum
Scrum是用於開發、交付和維持錯綜複雜產品 (complex products) 的敏捷框架 (AGILE framework) 。最初著重於軟體開發，之後已被用應用於其他領域，包括研究、銷售、營銷和其他先進技術領域。 一個 Scrum 團隊建議為十名成員的團隊而設計的，他們以迭代 （iterative）與增量 （incremental）式的方式交付工作，每個迭代稱作 Sprint。一個 Sprint 的時間不超過一個月，通常是兩星期…
标签：#軟體專案管理
共 21 篇文章
人月神话
《人月神话：软件项目管理之道》（）是由美國軟體工程師暨IBM System/360系統之父佛瑞德·布魯克斯（）所著文集，全書講解軟體工程、项目管理相关课题，被譽為軟體領域的聖經，內容源於作者布魯克斯在IBM公司System/360家族和OS/360中的專案管理經驗。該书于1975年首次发行（ISBN 978-0-201-00650-6），並於1995年重新发行纪念版（ISBN 978-0-201-83595-3），其中新增了对-{zh-…
迭代式开发
迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发方法，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。 在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需…
构造性成本模型
构造性成本模型（，英文全称为）是由巴里·勃姆（Barry Boehm）提出的一种软件成本估算方法。这种模型使用一种基本的回归分析公式，使用从项目历史和现状中的某些特征作为参数来进行计算。 概述 构造性成本模型最初发表于1981年巴里·勃姆《软件工程经济学》一书中，做为一种在软件项中估算工作量、成本以及时间表的模型。它基于对TRW飞机制造公司的63个项目的研究。巴里·勃姆于1981年在该公司担任软件研究与技术总监。这项研究中的项目所包含的…
應用程式生命週期管理
應用程式生命週期管理（Application lifecycle management），簡稱ALM，是指计算机程序的产品生命周期（包括软件开发过程及）。其中包括了需求管理、软件架构、程序设计、软件测试、軟體維護、变更管理、持續整合、项目管理和發佈管理。 ALM和軟體開發生命週期的關係 ALM的概念比軟體開發生命週期（SDLC）要廣，後者只限制在软件开发的階段（例如需求、設定、寫程式、測試、組態、專案管理及變更管理）。ALM在開發完成後…
用例
使用案例（），或譯-{zh-tw:用例;zh-cn:使用案例}-、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互動，也就是谁可以用系统做什么，从而完成一个明确的业务目标。人們可以通过用户的使用场景来進行需求分析。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家（domain expert）的语言。用例一般是由软件开发者和最终用户共同创作的。 …
發佈管理
發布管理或作發行管理、釋出管理、上線管理，是透過不同階段和環境以管理、規劃、排程、和管制軟體構建的流程; 包括測試和部署軟體版本。 背景 發布管理是軟體工程領域一個相對較新但迅速發展的學科。隨著軟體系統、軟體開發過程、和資源變得越來越分散，它們總是變得更加專業化和複雜化。此外，軟體產品（尤其是網路應用程式）通常處於開發、測試、和發布的持續循環中，常常在日益複雜、不斷發展的平台上運行。這樣的系統需要專門的資源來監督開發、測試、部署、和支援…
附属复杂度
附屬复杂度（Accidental complexity）是指電腦軟體開發過程中所引入不必要的复杂度。附屬复杂度不是待求解問題的本質，相對而言， 本質複雜度和待求解問題的本質有關，是無法避免的。附屬复杂度一般是因為選用求解問題的方法時所引入的。 有時附屬复杂度可以歸因於像無效的規劃等錯誤，不過有時附屬复杂度是求解問題時伴隨產生的副作用。例如因為記憶體用完而產生的复杂度是一種附屬复杂度，但只要決定使用電腦求解問題，就會存在這種复杂度。 好的…
需求可追蹤性
需求可追蹤性（Requirements traceability）也稱為需求可追溯性，是需求管理中的一部份，和软件开发及系统工程有關。IEEE Systems and Software Engineering Vocabulary有定義通用的可追溯性（Traceability），定義如下 #在開發過程中二個或是多個產品相關性的程度，特別是兩者之間有先後關係或主從關係的產品 #在產品層次結構中，工作產品的向上路徑及向下路徑的識別以及 #在…
零Code PM
0 Code PM、零Code PM為香港資訊科技界的職場現象，是對沒有軟件開發知識或經驗的軟件項目管理者群體的貶稱或嘲諷。 詞源 「0 Code PM」是由數字「0」，英語中的代碼「Code」以及職銜項目經理Project Manager縮寫「PM」所組成的混成詞、互聯網用語，可追溯到2010年代香港資訊科技界的網上討論區、社群網路服務帖文，有多個討論帖提及有關沒有軟件開發經驗的團隊所遇到的經歷，常見的討論內容圍繞有關軟件開發的項目經…
特徵蔓延
功能蔓延是指產品裡的新功能持續膨脹或增加的情形，常出現在電腦軟體、电子游戏及消費電子產品內。增加的功能超過了產品的基本功能，有可能會讓軟體無法維持簡單設計，出現软件膨胀及過度複雜的情形。 有關「怎樣算是功能蔓延」的定義，會隨终端用户而不同，某個功能對一些用戶來說，可能算是「功能蔓延」，但卻是其他客戶實際會用到的功能。功能蔓延是最常見造成及時程逾期的原因之一。這會危害專案及產品，甚至可能讓專案及產品因此而結束。 原因 特徵蔓延的主因常是因…
没有银弹
《沒有銀彈：軟體工程的本質性與附屬性工作》（）是IBM大型電腦之父佛瑞德·布魯克斯發表的一篇軟體工程論文。這篇文章最早是他在1986年都柏林IFIP研討會的受邀論文。隔年，電機電子工程師學會《Computer》也轉載了這篇文章，並配上《》等電影劇照作為說明，同時加入〈終結狼人〉的附註，帶出「只有銀彈才能解決問題」的現代寓意。文章強調，軟體的複雜性是本質性的，因此真正的銀彈並不存在；所謂「沒有銀彈」，指的是沒有任何單一技術或方法，能在十年…
分叉 (软件开发)
演化的时间线图，图上每个分支的起始端都称为一次“分叉”]] 分叉（，又译作衍生、分支）是一个软件工程名词，表示开发者从一个软件包中获取了源代码的拷贝，并开始独立开发，建立了另一个独立的软件。 这个术语不只意味着版本控制上的新开发分支，往往还表示开发人员社区的分裂，是一种意识形式的分裂。分叉的原因一般是用户偏好不同或原始软件的开发已经停滞或停止。 根据自由及开放源代码软件的定义，这些软件可以在未经事先许可的情况下，从原始开发团队分叉，并且…
軟體開發上的小事
軟體開發上的小事（）簡稱SMOP，是諷刺型的用語，是指所建議的軟體功能修改或是，會耗費許多心力。 此用語的意思是：就算很清楚「某一改變是可行的」，但可能需要投入很多心力來實現。這經常意指提出此功能修改的人低估了修改的成本。 定義 1983年的新黑客词典用以下的詞語來說明SMOP： IBM術語詞典（IBM Jargon Dictionary）定義SMOP如下： 用法 在自助心理學領域的著作《》有提到人們常有的一些「把戲」，而SMOP也是其…
敏捷软件开发
敏捷軟體開發（），又稱敏捷開發，是一種應對快速變化需求的軟體開發模式，描述了一套軟體開發的價值和原則。此模式中，自組織的跨功能團隊在緊密的協作中發掘使用者或顧客的需求以及改良解決方案，此模式也強調適度的計畫、進化開發、提前交付與持續改進，並且鼓勵快速與靈活的面對開發與變更。這些原則支援許多軟件開發方法的定義和持續進化。 「敏捷」（Agile 或 agile）一詞由「敏捷軟件開發宣言」（Manifesto for agile softwa…
快速應用程式開發
快速應用程式開發（原名：Rapid Application Development、縮寫：RAD）是指一種以最小幅度的規劃並迅速地將原形完成的軟體發展方法論。採用RAD進行軟體開發的規劃是和撰寫軟體本身交錯同時進行的。通常能在沒有大量預先規劃的情況下，讓軟體更快寫完、更容易變更需求。 有時也作為採用此種方法論的工具的代稱，此類工具大多支援所見即所得的介面設計畫面、顯示相關原始碼及說明文件，以及事件及例外處理的快速設定等等輔助使用者迅速完…
軟體供應鏈
軟體供應鏈（）是將製造業的供應鏈概念用在軟體開發上，是指在軟體制品（software artifact）開發過程中，所需要的元件（component）、函式庫、工具和流程。 軟體供應商在開發軟體時，會整合开源软件及商业软件的元件。軟體材料表（software bill of material，SBOM）中列出軟體工件開發時需要的元件。軟體材料表類似食品中的成份標籤，成份標籤說明食品的成份，因此在選擇食品時，可以避開過敏物質。在選擇軟體時…
死亡行军 (项目管理)
在项目管理中，死亡行军效应是指被上级强迫要求完成的一项被项目成员认为注定要失败或者需要不可持续的过度工作的项目所引发的效应。该术语起源于软件开发领域，并已扩展到其他领域。 “死亡行军”的发生通常出自以下原因： 对日程安排或项目范围不切实际或过于乐观的期望； 缺乏完成项目所需的文档记录、培训或外部专业知识； 项目各方之间的误解、项目假设不一致、不匹配的期望，以及外部的变化； 造成的结果是管理层极力试图引导项目方向、要求项目团队成员加班工作…
本質複雜度
本質複雜度（Essential complexity）是指由於一問題的本質不適合簡單的求解方式，所有可行的求解方式都很複雜的情形。本質複雜度和附属复杂度（Accidental complexity）不同，後者的複雜度和問題本質無關，和選用求解的工具或方法有關。 本質複雜度至少在1980年代中期已被使用，圖靈獎得主佛瑞德·布魯克斯當時已開始使用本質複雜度及其反義詞附属复杂度。他也在1995年時在《人月神話》中的沒有銀彈一段中提出他的新論點…
镀金 (项目管理)
在项目管理中，镀金是指在无关紧要或者未被要求的任务上花费时间和精力但无明显收益的现象。（即：在时间管理上，所作任务跨过了收益递减点的现象。） 现象 例如：项目组在满足客户要求后，以为额外和更完善的功能会更让客户满意，而去继续改善产品。但客户可能反而会对结果感到不满，且开发人员的额外工作反而是徒劳的。 各个项目管理最佳实践和方法（例如项目管理知识体系(PMBOK) 和PRINCE2 ）都认为镀金是一种不好的项目管理实践。“镀金”是在项目的…