這是敏捷開發一千零一問系列的第七篇。（之一，之二，之三，問題總目錄）
松結對程式設計中，師傅對徒弟安排任務時，對於有想法的徒弟提出的意見怎樣解決？
步驟0：
正心，誠意。
人們到底是在管理乙個人（控制，監督，指令）還是領導乙個人（幫助，引導，培養），被管理者和被領導者其實心裡是一清二楚的。
因此在師徒關係中，不能為了師徒而師徒，而是要找到師+徒這個體系的目的，把心態放在把事情做好而非維護師徒結構上，從這個角度看問題才能做好下面的事情。
步驟1：
師傅日常要多在收尾的時候檢查徒弟的**，指出其中的問題，以讓徒弟正確認識自己的水平。
軟體開發有乙個好處是比較理性：好的就是好的，沒有什麼可爭辯的；但也有乙個壞處：好壞多半在做出來後才能看得出來，十個手指頭勝過兩張嘴皮子。
所以師傅應該多在最終結果上指導徒弟，徒弟就會意識到如果從頭就聽取師傅的意見，中間會節省很多無用功。
步驟2：
有個笑話挺逗的，有人問某人你家誰說了算？回答「一半一半。如果我們兩個意見相同，我說了算；如果不同，我媳婦說了算。」
隨著一起工作的時間變長，師傅也不用強調每次都有更優答案，反而可以鼓勵在大方向一致的情況下，讓徒弟自己進行一些「微創新」，這樣徒弟不會有一種巨大的陰影感。
步驟3：
在有些時候，師徒都拿不準，這時候應該引入更強的技術力量，就是「師祖」級別的程式設計師加入討論。
師傅不要因為自己都要接受指導而感到沒面子，其實如果徒弟發現師傅這麼厲害都還能尊重師祖的看法，自己自然更加會尊重師傅。
步驟4：
對於接近出師的徒弟，應該將其當作自己思維的延續，而非始終僅僅當作左膀右臂。
其實很多人都將經歷乙個放下程式設計，拿起業務/管理/產品/市場乃至決策的過程，如果始終放不下，就永遠拿不起來。
從這一點上說，師傅不永遠是師傅，徒弟不永遠是徒弟。從這個終極目的出發，反而應該在早期就培養有看法的徒弟，而不是簡單地把自己的看法交給他。
培養的要點，在於心和法的培養，即養成正確的思維方式、價值觀、看問題的角度，日後遇到師傅自己也沒有遇到過的問題，自然就能輕易解決。
無。作為乙個師傅，要理解實際上並不存在「我的想法」，而是應該存在乙個「正確的想法」，因此不應該每次都突出於徒弟的不同，而是在團隊內部形成正確的價值觀，鼓勵人們「正確地思考」（正確是副詞），從而得出「正確的想法」（正確是形容詞）。這一點和敏捷開發差不多。
所以師徒團隊的目標不是找到一堆能執行師傅想法的徒弟，而是一堆與師傅想法相同的徒弟，進而找到與師傅思維方式相同的徒弟，甚至超過師傅思維方式的徒弟。
當徒弟超過師傅的時候，師傅不能想「有人坐了我的位置」，而是應該想「有人替我辦所有事了，我終於可以去辦更大的事情了」。這是一種「人無我」的想法，就是不能固執地認為自己就是師傅，而不是更高職位的人。
另乙個很無奈的事實是人會變老，思維也會僵化（比如多數科學家都是在很年輕的時候做出貢獻的，老了以後基本上就是做科普工作了；多數新公司也是年輕人創造的，老了以後公司也會逐漸衰落）。因此每個人無論職位高低，都應該培養**人，按照正確的思維方式，探索新答案。（這個稱為「法無我」，就是「法」也沒有我，也在變化中，就是之前提到的「無住」）。
敏捷開發一千零一問系列之七 怎樣對待有看法的徒弟？
這是敏捷開發一千零一問系列的第七篇。在這裡提問，之一，之二，之三，問題總目錄 松結對程式設計中，師傅對徒弟安排任務時，對於有想法的徒弟提出的意見怎樣解決？步驟0 正心，誠意。人們到底是在管理乙個人 控制，監督，指令 還是領導乙個人 幫助，引導，培養 被管理者和被領導者其實心裡是一清二楚的。因此在師徒...
敏捷開發一千零一問系列之三十 敏捷怎樣估算（中）？
這是敏捷開發一千零一問系列的第三十篇。在這裡提問，之一 之二，之三 問題總目錄 續前文，預計未來還要有一篇，暫時做為中篇。這個在之前談到過很多次了，具體可以 參考敏捷開發績效管理系列 的之六 之七。另外在敏捷開發使用者故事分類與組織結構 一期 整個活動1期 中有詳細描述。這個是國際上迄今為止唯一被大...
敏捷開發一千零一問系列之十四 敏捷開發加班嗎？
這是敏捷開發一千零一問系列的第十四篇。之一，之二，之三，問題總目錄 正逢週末，又是愚人節，群中有人正在加班，想起上次培訓中間休息的時候，討論起這個 敏捷開發加班嗎 的問題，雖然後來沒有作為課後投票入選，但這裡也完整回答一下。敏捷開發加班嗎？樓下有人問到 敏捷和加班有什麼關係 補充這兩句。有些程式設計...