圖片 1.jpg

2024 線下課程 第一梯次

開課時間: 4  13 日 (星期六) (09:00-16:00)

報名網址: https://forms.gle/xJahvQ23SCs6qmVM7

 

以協作方式, 和具體描述範例的方式, 讓大家對需求有共識

 

課程特色

手把手實際練習

    利用真實案例來練習

    每種範例開立方式都會嘗試

    小組分享交流不同做法

回答常見問題

如何確認需求已經寫得足夠了

需求的範例可能的來源有哪些

好的需求範例有什麼要素

如何評估這個流程的成效

 

 

課程簡介

在 Standish Report 2014中說到, 專案會成功的前五個原因, User involvement 排第一, clear statement of requirements 排行第三. 而失敗的專案中共同的因素裡, incomplete requirements 是第一個, Lack of user involvement 排第二. 因此, 如何邀請用戶來整理出有共識的需求, 是軟體專案的第一要務.

過去專案在需求處理方面, 先是客戶訪談, 然後再根據會議中所討論的, 整理出需求的規格和說明. 可是, 不管撰寫需求的人寫的再怎樣詳細, 雙方總是會有誤解, 開發人員會以為客戶或是 PM 要的就是這樣, 而客戶或 PO 會誤判以為開發人員已經聽懂. 這樣的事情老是一而再的發生.

還有傳統的方式, 會先寫完需求文件, 可是這段時間通常不短, 等到寫完後交給開發, 才又發現客戶已經要改需求了. 另外, 中途當需求有變動, 卻發現要改的地方很多, 你不容易每個地方都找出來修改, 常常會放棄處理, 導致文件和真實需求或系統不同.

為了解決解決以上問題, Gojko Adzic 提出一個改善的做法, 利用測試範例來說明系統的行為, 讓雙方不會只看抽象的敘述 而是從實際的案例上來解釋事情. 此外, 這些範例在系統完成後, 便可以用來確認系統是否真的做到當初所說的, 因為這是具體的測試案例, 有特定的資料數值, 在驗證上沒有模糊的空間. 這堂課就是要來介紹這樣的好方法給大家, 你怎麼可以錯過這個好機會呢!

在這堂課中, 我們將會手把手教大家, 如何以具體範例來說明需求, 在這個過程中如何識別範例中的壞味道, 並且會實際拿不同功能來練習列出範例, 讓大家上完後就可以實際運用到專案上面.

 

適合對象

  • 軟體開發人員, 測試人員
  • 專案經理, 系統分析師
  • 需要處理軟體系統需求的人
  • 對於需求不清楚感到痛苦的人

 

課程大綱

爲什麼要用範例來說明需求

需求文件常見的問題

用範例描述需求的想法

描述範例的方法

範例可以幫忙什麼

驗收條件

驗收測試

如何協作討論出範例

協作方式

Example Mapping

系統化開立範例的方法

驗收條件的格式

開立範例的方法

實例化需求的歷史和流程

實例化需求的來源

實例化需求的流程

要寫多少才足夠

如何評量做得好不好

刻意練習

分享和討論目前需求處理流程

作業分享

練習開立需求範例

 

常見問題

  1. 不會程式開發是否可以上此門課?

不用會寫程式也能聽得懂. 只要簡易知道軟體開發流程即可

  1. 開發人員也適合這堂課嗎?

合適, 不管你有沒有專職測試人員幫你測試, 或者不管是手動測試或是自動測試, 你總是需要開立測試個案, 來驗證自己的程式. 這時候你就需要此方面的技能.

  1. 需要懂敏捷開發嗎?

不需要, 課程中只有一小部分會提到, 提到到的部分當場也可以聽得懂

  1. 上課會介紹自動化工具或寫程式嗎?

不需要, 本課程不會介紹自動化工具, 也不會有任何撰寫程式的部分, 是要讓大家對於這個流程有認識並且知道怎麼實施

 

 

arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(2) 人氣()