■前言
為什麼會有敏捷開發手法的出現
■三個真相
・我們在專案開始的時候，無法把所有的需求都收集起來。
・即使收集到了，需求也一定會發生變化。
・要做的事情總是比，當初的計畫要多（多於給定的時間和資金）
■如何應對
＞我們在專案開始的時候，無法把所有的需求都收集起來。
在設計階段，客戶很難考慮到所有的情況，
（即使我們幫助客戶想到了，我們的對應方法，也需要等待客戶的承認。）
儘管，需要的資訊不全，我們也要著手對應，
先對應已經決定下來的內容，在此過程中，同時去確認那些沒有定下來的內容。
在對應的過程中，有時也會發現，新的考慮不足的問題。
⇒比如，敏捷開發中，sprint1 sprint2
＞即使收集到了，需求也一定會發生變化。
沒有任何事物是一成不變的，
我們要接受變化，
根據變化，一邊變更計畫，一邊前進
⇒比如，敏捷開發中，feedback
＞要做的事情總是比，當初的計畫要多（多於給定的時間和資金）
列出todo事項的list，
先對應優先度高的作業，
⇒比如，敏捷開發中，優先對應，有價值，優先度高的作業
比如（不止敏捷，其他方式開發時，同樣適用）
・使用者指定要執行的，結合測試case
・發布資源的準備
・系統發布手順（本番移行リハーサル手順）
優先度低的作業，調整到之後對應
・本次修改之後，一些不重要文件的更新（git**版本管理的文件）
・it發布之後，要在git上打乙個tab（タブ作成），
如果沒有其他人提交**，這個作業的優先度也可以調低。
軟體開發中的30個錯誤
1.不理解使用者的需求。缺乏使用者提出需求，或者根本就不問。2.低估專案的規模。3.快速通過計畫編制過程，或者沒有計畫編制過程。嚴重地編碼優先，計畫靠後！4.沒有盡早的 經常性地測試，或者根本就不測試。並且養成如此習慣。5.選擇很 酷 的方法學。6.不使用方 7.讓軟體開發者執行軟體開發專案。8.盲...
如何規範自己的程式設計以及軟體開發目錄（二）
設計軟體目錄結構，就和 程式設計風格一樣 屬於個人風格問題。對於這種風格問題，一直都存在兩種態度 1.一類同學認為，這種個人風格問題 無關緊要 只要讓程式work就行，風格問題根本就不是問題。2.另外一類同學認為，規範化能更好的控制程式結構，讓程式具有更高的可讀性。大部分人都是傾向於後者的，因為大家...
如何評價個人在軟體開發團隊中的績效
我認為乙個有效評價手段應該達到以下目的 1 對團隊 讓整個團隊進入愉快高效工作狀態 2 對 高手 獎勵幹活多幹活好的人 3 對 低手 從制度上杜絕磨洋工的現象 4 對 中手 提供工作認真但是水平有待提高的成員生存成長空間 乙個團隊，總是有著各種各樣的人，每個人在這個團隊裡都是主角。為了團隊，他們有著...