關於「責任」和「權力」：
「責任不能被指派，只能被接受。如果有人試圖給你責任，只有你自己能夠決定是否負這個責任。」
這點和ｓｃｒｕｍ的「團隊自管理」異曲同工，專案不是由專案經理或者什麼人去指派任務的，專案經理只是牧羊犬，而產品經理只是專案需求方，任務僅限於提出需求和對需求排出優先順序。至於本輪次中的任務，完全由開發團隊自行決定如何安排開發任務，也只有開發團隊能決定本輪次接受多少任務。
是的，這涉及到兩個問題：「權力和責任問題」，「勇氣問題」。
開發團隊這時本身需要「勇氣」，客觀地面對需求，做出切實的時間成本估算，ｘｐ的「勇氣」價值觀在這時需要表現出來。
客觀地，開發團隊也需要「權力和責任問題」的明確來對它們進行保護。
「責任和權力需要並行。兩者錯位會扭曲團隊的溝通。當乙個過程專家告訴我該怎樣工作，卻不承擔這些工作及其後果的時候，權力和責任就錯位了。我倆都無法從乙個理智的角度出發來看待或使用那些有助於我們改進的反饋。另外，錯位還要付出情緒方面的成本。」
說得太對了，責任和權力需要並行。如果乙個人對其它人指手劃腳卻不對自己的言論負責，這完全沒法工作了。老實說，我吃過這方面的虧，所以對此深惡痛絕。開發人員絕不能估息這種情況出現，如果有，一定要進行阻止，哪怕吵架！《沒人把程式設計師當回事兒》的作者說得對，工程師的注意力全放在工程本身上了，無暇顧及人事上的陷阱，不知道誰在背後捅刀子，所以老吃這方面的虧。如果不想把精力全花在這種專案之外的人事間的消耗上，就一定要明確責任和權力的問題。只有這樣才能建立起乙個健康的開發制度。
《解析極限程式設計 擁抱變化》讀後感
1.任何情況下，變化是絕對的，不變是相對的，我們不要抱怨變化的發生，重要的時要有應付變化的能力。但是那絕對不是聽從別人來變化，而是自適應形勢的變化。2.四個變數 成本 時間 質量 範圍 3.四個原則 溝通 簡單 反饋 勇氣 4.所有的實踐 a 計畫遊戲 i.業務人員需要決定的內容 1.範圍 2.優先...
《C程式設計》讀後感
c程式設計 讀後感 網上很多人評價這書不高，其實從內心裡講，是這本書帶領我入門的。我說的是譚浩強先生的書。這本書講得很細，而且知識的銜接也做得很好。我以這本書為重點，再以其它的c語言教程為輔，終於算是入了c語言的門。如果能讓我再從頭學習的話，我一定是認真的讀這本教材，再把c的標準庫的原始碼作為閱讀材...
《程式設計實踐》讀後感
程式設計實踐 讀後感 昨天晚上讀這本書，重點讀資料結構這一章，也許是因為讀gawk101原始碼有一段時間，在重讀時，感覺作者寫得真好。我重點放在書中的 上，發現那些 寫得像珍珠一樣，真是漂亮。作者寫了鍊錶，然後再寫乙個遍歷鍊錶的函式，因為遍歷鍊錶時，可能是要列印，可能是要統計元素個數，可能是要找某個...