這個作業屬於哪個課程
這個作業要求在**
/homework/11815
這個作業的目標
構建之法讀後感
學號20188423
問題一：
我在看需求分析的時候看到這樣的說法
所謂極限程式設計，就是把一些認為重要和有效的做法發揮到極致，如果了解客戶的需求很重要，那麼發揮成極致就會變成每時每刻有客戶在身邊，隨時了解需求。
但是很多時候客戶並不知道自己真正的需求是什麼，那麼怎麼處理這種問題呢？我們要如何大概確定使用者的需求並引導他們？
我查了資料，有這些說法：
1、需求一定是要解決的，想關掉一扇門，一定要先開啟另一扇門。
2、先要確定，這是不是真正的需求。
3、兩害相權取其輕，給客戶製造衝突。
問題二：
我在看敏捷開發的時候看到，
敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。換言之，就是把乙個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態，敏捷就是「沒有既定的計畫與文件，馬上寫**，隨時發牢騷」，但是我認為開發也是需要有一定的流程的，是否敏捷就是分階段的瀑布？
問題三：
書上說如果乙個運動員在跑一百公尺衝刺, 但是跑到一半的時候，領導突然想看一百一十公尺欄的比賽, 前面馬上會擺起欄架, 大家要準備8步上欄! 怎麼辦?那一定是等衝刺完了再去解決。
如果乙個自己的乙個創新想法有風險但是很適合這個專案，但是領導態度模稜兩可，該怎麼抉擇？
對於乙個在本領域已經很強大的公司，是按部就班的跟隨現有的主流技術，還是應該去科研創新？
問題四：
如果在乙個專案中我要做一件事，但是周圍的人有不少不同意見，但是短時間又不能完全說服他們，怎麼辦 ？
課本上這樣寫，如果我是責任人，最終還要我自己拿主意，別人的意見只是參考，我的責任就是把事做出來，而不是討好所有人，讓他們知道我按照他們的意見做了就行了。
可是我還有乙個疑問，如果這個專案有一半以上的把握能成功，如果失敗了就要承擔全部責任，我要去嘗試嘛？
問題五：
文中有乙個叫「18個月效應」，大意是乙個軟體十八個月做不出來就沒有做的必要了，這是不是意味著乙個軟體的生存週期就在18個月左右？
我在網上看到這樣的說法
摩爾定律 是指半導體積體電路的密度或容量每18個月翻一番，或每三年增長4倍」
但是我還是不懂更新軟體又是如何保證軟體的生命力的？
問題六：
比如說乙個軟體設計的時候，開發人員把乙個功能當做乙個彩蛋，但是很多客戶認為是乙個bug，那麼該如何評判這個功能到底屬不屬於bug呢？
閱讀 《構建之法》
這個作業屬於哪個課程 這個作業要求在 這個作業的目標 發現疑惑並嘗試著提出自己的看法 學號 20188506 1.it行業的創新秘訣到底是啥 哪一點最重要？2.怎樣的創新才叫 成功 的創新？可能 成功 的創新這是乙個重要因素吧，具體的 成功 考慮因素可能太多。3.需求分析中提到 為什麼軟體估計這麼難...
閱讀《構建之法》
這個作業屬於哪個課程 這個作業要求在 homework 11813 這個作業的目標 讀 構建之法 提出問題 學號20188400 是蟲子 bug 還是肉芽？不同的人有不同的答案。軟體行業也有一句著名的笑話 這不是缺陷，這是乙個功能！p17 任何乙個問題的產生，本身是沒有好壞之分的，但是為什麼會有的就...
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...