前言

這是為了準備IT Project Management的期末考而整理的重點。

Agile vs Waterfall

Agile Methodology

敏捷的原則:減少浪費、快速產出、不斷循環、快速學習

敏捷是目前在軟體開發的趨勢,因為軟體開發的需求會隨著時間改變,所以需要一個可以快速產出並且可以快速改變的開發方法。

Positive Side of Agile

  • 客戶會需要與團隊緊密合作,客戶獲得了strong sense of ownership。
  • 如果有上市時間更重要,敏捷可以更快的上市產出基本版本。

Negative Side of Agile

  • 有時候會因為衝刺到後面跟一開始的目標偏離,讓產品缺乏一致性,硬體產品也較不適用於此方法,畢竟硬體做出來就不能一直更改。
  • 客戶可能沒這麼多時間
  • 因為Agile專注在time-boxes交付和頻繁的重新確定優先順序,某些準備交付的項目可能無法在規定的時間內完成。可能需要額外的衝刺Spring(超出最初計劃的衝刺),從而增加專案成本。
  • 如果在初始架構和設計中沒有考慮系統的全部範圍,敏捷開發的迭代性質可能會導致頻繁的重構

Waterfall Methodology

瀑布式就比較不迭代式(Iteratvie),像瀑布般從上往下的線性流程:產品需求 > 設計 > 開發 > 測試 > 保養更新
開發時一般不會回去上一步驟,若有需要更改或是修正時較為困難,所以每一步驟都會非常小心仔細的產出。

對於比較大需求明確的專案,瀑布式開發是一個很好的選擇,因為需求明確,透過線性流程可以很好的控制進度,同時透過合約中的某些限制,計劃驅動可以降低風險。

Positive Side of Waterfall

  • 開發人員和客戶會在開發生命週期早期就確定需求,這讓規劃和設計更加直觀(straightforward)。
  • 由於提前了解工作的全部範圍,因此更容易衡量進度
  • 除了審查、批准、狀態會議討論之外,在需求階段釐清後客戶不需要嚴格在場
  • 有時適用同時開發多個專案的元件,因為設計在開發生命週期早期就完成。

Negative Side of Waterfall

  • 收集客戶需求是最難的部分,客戶有時會被細節嚇倒,這種方法需要在專案早期提供的具體細節。
  • 客戶並不總是能夠從需求文件中視覺化應用程式,線框和模型可以提供幫助,但是作為書面在理解內容上會遇到困難。
  • 客戶可能對其交付的軟體產品不滿意,由於所有可交付成果均基於書面要求,因此客戶可能直到快要完成時才看到將交付的內容。到那時,實施變革可能會很困難(而且成本高昂)。

When to use Agile vs Waterfall

Project factor Agile Waterfall
Customere Availability 客護需要頻繁參與討論 客戶只需要在前期參與
Features 頻繁改變,對於scope不確定時適用 如當事先知道範圍或合約條款限制變更時效果很好
Propritization 最有價值的功能要先完成,有效既低做出無用產品的風險,透過允許部分成功來降低完全失敗的風險 只做大家都同意的事情,一開始就談清楚
Team 比較小、需要高度互動的團隊 團隊的互動有限
Funding 不確定性高的預算上適合,但是在固定價格上不吃香 透過固定價格談好來降低風險
Summary Agile 在彈性高時適用 面對供應商與外部客戶之間的合約中的某些限制,計劃驅動可以降低風險

CRISP-DM

在數據科學領域中,有效地處理和分析數據是取得成功的關鍵。然而,面對不斷增長的數據量和複雜性,我們需要一個結構化、可靠的方法來引導我們完成數據專案。CRISP-DM(Cross Industry Standard Process for Data Mining)作為一個廣泛應用的標準流程模型,應運而生,為數據科學家和分析師提供了一個清晰而靈活的框架,協助他們成功地應對各種數據挖掘項目。

在這篇文章中,我們將探討CRISP-DM的流程還有問題。

Process


Weakness

  • Business Understanding 與其他步驟不依該獨立,並且缺少如何理解、驗證、細節化需求等活動。
  • 沒有考慮到其他階段也需要backtrack
    • Data Preparation 到 Business Understanding,或是Data Understanding, Data Preparation, Business Understanding 之間應該也要有循環。

  • modeling 通常是需要與其他phases iterate的
    • 尤其是在 Data Preparation, Data Understanding, Business nderstanding, 和Deployment,modeling與這些phases進行iterate的目的是在improve models。
    • 同時,應該要明確地將agile的流程整合進去 Modeling 與其他 phases 的流程中,我認為是因為結果如果沒有達到客戶需求,就需要隨時做調整。

  • CRISP-DM 不支援某些資料探勘專案所需的敏捷性

Stacey

Stacey Landscape Diagram是一個工具,可以幫助您分析項目的複雜度,並選擇最合適的管理方法。它是由管理學教授Ralph Douglas Stacey開發和發表的。

Stacey Landscape Diagram有兩個維度:

  • 協議 Agreement: 協議是指項目的目標和方法是否有共同的理解和支持
  • 確定性 Certainty: 確定性是指項目的結果和影響是否可以預測和控制。通常可以根據過去的經驗推斷新項目的結果。
    • Far from certainty: 通常情況獨特新穎的項目,通常,因果關係是不清楚的。在嘗試制定計劃時,過去的經驗幾乎沒有什麼幫助
    • Close from certainty: 人可以非常確定從過去推斷和預測行動的結果。



Stacey identified five areas:

  1. Close to agreement, close to certainty:
    • close to certainty 表示可以從過去收集數據,用於預測未來。
      • e.g. 建築和工程專案通常擁有豐富的技術數據。
    • close to agreement 舉例來說,在交付工作開始前,就有詳細的說明和安排專案或計劃工作內容。
      • e.g 可以在交付工作開始之前詳細說明和安排。透過監控詳細計劃來控制工作
    • 適合的專案管理:這個區域的項目可以使用傳統的項目管理方法,像是waterfall,因為這些方法適用於詳細的規劃和控制,以及對於需求和目標的清晰定義
  2. Far from agreement, close to certainty
    • Close to certainty 有些專案對於哪些目標是可能的以及如何實現這些目標非常確定
    • Far from agreement 但對於哪些目標具有『最大價值』卻缺乏共識
      • e.g. 專案經理很難開發出可以被對價值有不同看法的多個利害關係人接受的商業案例
    • 採取措施:在這一領域,談判、達成妥協和發展聯盟等技能非常重要。決策變得政治化而不是技術化。
    • 適合的專案管理:可以使用看板方法,因為它強調了透明度和可視性以在不同的利害關係人之間協調、溝通建立共識
  3. Close to agreement, far from certainty
    • Close to agreement 項目可能對預期目標高度一致。
    • Far from certainty 但對實現預期目標的因果關係卻不太確定。
      • e.g. 當假設產出將如何帶來效益時,產出、成果和效益之間的關係通常可以屬於這一類。
    • 採取措施:在這種情況下,利害關係人之間必須有強烈的共同願景,並且需要採取靈活、現實的規劃方法。即使具體路徑尚未完全預先確定,專案經理和發起人也必須明顯地朝著商定的未來狀態(藍圖)前進。
    • 適合的專案管理:可以使用敏捷方法,像是Scrum。因為這個方法可以讓團隊在不確定的情況下快速反應
  4. The zone of complexity
    • 猶如垃圾桶決策模式,需要集思廣益、探索錯誤,在該區域所涵蓋的區域中,低水準的協議或低水準的確定性使專案成為一個複雜的管理問題。這個領域經常引發糟糕的決策實踐
    • 採取措施:而它真正需要的是高水準的創造力、創新性和擺脫過去限制的自由來創造新的解決方案
    • 適合的專案管理:這個可以使用eXtreme Programming (XP)或其他敏捷方法的變體。目的在促進團隊的創新和協作,透過頻繁的反饋和測試提高質量和效率。
  5. The zone of chaos
    • 分裂、無秩序,需要避免。在缺乏共識和確定性的地方,無政府狀態就會盛行。個人和組織有時會採取迴避措施,但這種情況並不總是可以避免。如果發生這些情況,需要採取策略來解決。
    • 採取措施:而它真正需要的是高水準的創造力、創新性和擺脫過去限制的自由來創造新的解決方案
    • 適合的專案管理:如果到了這個區域就很難使用任何管理方法,因為缺乏明確的目標、也無法預測和控制,反而應該要進行危機管理、或是尋求專業協助。

Design Thinking

Design Thinking 結合 Diverse People + Creative Space + Iterative Approach 來解決問題。
是發散性思考階段和聚合思考階段

  • The Design Thinking Process is characterized by divergent and convergent thinking stages.
    • 設計思考過程的特徵是發散性思考階段和聚合思考階段
  • Design Thinking 重點:
    • 保持好奇心 open mind、建設性回饋文化(Constructive feedback culture)
    • 允許失敗,失敗是學習的一部分
  • 每個Step的說明:
    • Scoping: 開始提出一些ㄒtopic, questions, thoughts, ideas,先專注在思考自己的想法
    • 360 Research: 詢問跟傾聽,詢問使用者/客戶,收集回饋,了解利害關係人的動機、目標。
    • Synthesis: 把目前為止收到的意見回饋、想到的問題,進行綜合
    • Ideate: 理解問題後,開始腦力激盪想解決方法
    • Prototype: 做出最初的模型,用來展示解決方案的感覺、外觀、和工作原理,使其變得有型。可以透過prototype獲得即時回饋
    • Validate: 您要將您的原型進行測試,並根據用戶的反饋進行改進和迭代

People + Space + Approach

  • People: 團隊合作、跨領域、定義規則並遵守。最好由 T 型人員組成的團隊,這裡的T是包含縱軸跟橫軸,橫軸是知識廣度、縱軸是專業知識。
  • Space: 彈性, adapted 的工作環境可以創造出更好的想法。
  • Approach: 思考問題、腦力激盪、規劃Project

Design和Stacey之間的關聯與合作

  • 簡單介紹兩者
    • Stacey Landscape Diagram 可以用來分析問題複雜度的工具。
    • Design Thinking是一種解決複雜問題的創新方法。
  • 關聯性:
    • Stacey Landscape Diagram 可以協助設計者識別問題所處的區域,選擇合適的Design Thinking 方法,將Agreement跟Certainty更清楚和一致性。
    • 舉例來說,如果目前問題處於Far from certainty,表示目前的狀況無法透過經驗來獲得解決,那麼設計者需要透過創新和擺脫過去限制的自由來創造新的解決方案。因此於Design Thinking中,可以採用迭代不斷測試和改進,從Complex往Complicated 和 Simple 的區域移動。
    • 如果目前處於Far from agreement的狀態,表示目前團隊的共識不足,因此在Design Thinking的階段中,360 Research, Ideate 的階段需要做調整。