標籤:io 使用 sp on 代碼 工作 ad 時間 ef
1. 討論:下面的老闆犯了什麼錯誤?
老闆沒有看到學生們背後的真正動機,大學生們都是打著出來學習的幌子來到旅店開房,老闆把學生的幌子理解成了他們的需求,於是對賓館進行了整改,撤掉了學生們真正想要的床,這樣一來就沒有理解學生客戶背後的真正動機,所以旅店也只能倒閉。
2. 是否要文檔
文檔對於軟體的開發過程來說是十分有用的,而且文檔經常被作為裡程碑標記,使項目跟蹤和控制變得可能,也使軟體生產的每一部分都可前溯,保證軟體的品質。在軟體開發的過程中,文檔的作用不可小視。它們不僅能協助開發人員瞭解自己的工作進度,方便自己和他人閱讀和改進代碼,還能夠協助項目的管理員管理軟體開發進程、提高軟體開發的效率和品質、改進軟體開發過程。
3. ATM操作介面的使用者
第一類:多次使用過不同ATM系統的正常客戶,如學生,老師等白領。
第二類:基本不使用ATM的使用者,如老人,不會操作,不識字。
第三類:揀到或者偷到別人的卡來嘗試密碼,試圖取錢的使用者。
第四類:銀行的工作人員,來進行系統的測試和日常維護的。
第五類:第一次使用本系統的使用者,不熟悉環境。
4. 你想寫一個遊戲,你知道遊戲使用者有哪些種類麼?
可以根據遊戲時間來劃分:第一類人是癡迷於遊戲,把遊戲當成了生活的一部分,遊戲對於他們來說有著很高的優先順序,經常可以在大半夜來玩兒遊戲。第二類人對遊戲也有著很高的熱情,但他們對於日常工作還是更為重視,除了工作以外,遊戲有著很高的優先順序,遊戲是他們娛樂的第一選擇。第三類人則是遊戲愛好者,他們會有很多的休閑措施,遊戲只是其中之一,並沒有很高的優先順序,當無聊或者無所事事的時候他們可能會選擇來打遊戲。
5. 別做過頭
做項目的過程中過分的在意於一個項目的內容結構是否合理,資源是否充足,導致在搜集資源的時候花了大量的時間,導致接近deadline的時候才抓緊時間並行其他的程式結構。
6. 系鞋帶
第一, 我們要定義好相關的概念
—what is “shoe”, “shoe laces”, “tied shoe laces”, and “untied shoe laces” 鞋, 鞋帶, 系鞋帶, 解鞋帶都是什麼概念
—Benefit of this feature “tie your shoe laces”。 系好鞋帶的好處是什麼
—The goal of the feature? 系鞋帶的目標是什麼?
—What does “success” look like? 什麼叫系好了?
—Unambiguous steps to achieve from “untied” to “tied”明確的步驟來示範系鞋帶的過程。
第二, 規範好一些假設 (assumptions), 例如, 鞋帶是已經穿好在鞋上的麼? 什麼樣的鞋屬於我們要處理的?
第三, 避免一些誤解, 下面這個從技術上也是 “鞋帶綁緊了”, 但它是 “系好了”麼? 打了死結算成功麼? 要打多少個蝴蝶結才算好?
第四, 釐清一些邊界條件, 下面的情況屬於好的系鞋帶狀態呢, 還是不好的狀態呢? 這需要PM/Dev/Test 協商達成一致意見。鞋帶要打多緊才算好? 打好的鞋帶能拖在地上麼?
第五, 描述主流的使用者/軟體互動步驟。
現代軟體工程 練習與討論 第十章 典型使用者和情境