在靈活的工作環境中，我的工作方式應該如何變化？

Question

在我的工作場所，我們「遵循」敏捷方法。但是，我們所做的只是立場。我還需要改變我作爲開發人員的工作方式，才能遵循敏捷？

謝謝

Answer 1

這聽起來像每天開會的瀑布。實現敏捷是一個巨大的差異，你不能只是從瀑布變爲敏捷，你需要其他人遵循它的工作。

我認爲最大的變化將是停止在「項目」範圍內的思考，並開始以極小的工作量進行思考。例如，當項目「創建網站X」出現時，您需要逐頁將其分解。確定需要做什麼，我們究竟如何獲取，存儲，更新和顯示數據。需要多長時間才能寫出所需的不同代碼段？一旦完成了這個任務（根據我的經驗，有更多的計劃涉及敏捷），那麼你可以開始說「到星期三，我將能夠向你展示我可以保存在X頁上，然後我將顯示數據在Y頁上「。

通常會有一個「計劃」會議。這可能需要一個小時，或者可能需要6個小時，這取決於您的標準傳達得有多好，團隊中有多少成員，以及您正在使用的衝刺多長時間。每個人都選擇他們會做的工作，並對其進行估算。在你的衝刺之後（大多數人推薦一到兩週），還有一次會議。理想情況下，在這次會議中，每個人都會演示他們過去一週所做的事情，並且它會完美地工作。之後有一些反思，什麼運轉良好？我們是否錯估了一些可怕的東西？

這是一個「循環」，做到50次，網站X完成！ :)

Answer 2

Agile實際上是一組基於迭代開發的軟件開發方法論，其中需求和解決方案通過自組織跨職能團隊之間的協作而發展。你自己很難做到。

這就是說，有事情可以做，這將使你更加靈活，和你的隊友可以選擇仿效一旦看到優點：在小塊

• 工作。你想把你的任務分解成可以在合理的時間內完成的部分。 （我所從事的團隊通常以半天爲單位進行測量，因此您可以每天完成2個工作單位，並且每週完成10個單位。）
• 提交功能代​​碼。當你在工作時，你想經常提交你的代碼，但只有當代碼編譯時，並且沒有打破你的單元測試的情況下工作。你不想成爲提交破壞構建的代碼的人。
• 編寫單元測試。你的團隊正在爲其代碼編寫單元測試，對吧？如果沒有，那麼現在就開始吧。編寫單元測試將迫使您將您的代碼構建爲可測試的，這也將迫使您改進您的實現和設計。它還會檢測迴歸錯誤，通過檢查有人在進行更改時曾經工作的所有內容。
• 單元測試所有錯誤。無論何時您需要修復一個錯誤，首先編寫一個單元測試，導致您的代碼以與錯誤相同的方式失敗。然後修復你的代碼。如果修正是好的，你的單元測試現在應該會通過 - 並且所有其餘的單元測試應該繼續通過。
• 單元測試所有新代碼。當你構建新的代碼時，你應該建立一個規範。確保規範是好的最好方法之一是使用規範爲您的代碼編寫單元測試。一旦你有足夠的測試來驗證你打算寫的代碼，去工作，根據你的測試測試你的代碼。一旦您的代碼通過測試，您可以提交到團隊存儲庫。
• 使用持續集成。這是團隊本身應該做的事情，但是如果您可以使用額外的PC（它不必很快，只需要有足夠的內存和磁盤空間來構建工具和構建軟件）即可。加載CruiseControl.net或Hudson，將它指向您的存儲庫，並將其配置爲等待新提交，檢出工作空間，構建軟件並運行單元測試。爲什麼？因爲在變革傳播到整個團隊之前，有人忽視了他們所做的所有變革，因此它會被抓住。
• 自動構建。在您使用持續集成之前，您需要能夠重複構建您的軟件，而無需人工干預。如果您使用Visual Studio，請學習如何使用MSBuild或Nant進行構建。如果你在做Java，學習如何使用Ant或Maven構建。通過自動構建，避免了與手動步驟相關的構建和發佈問題。 （我曾經從一臺筆記本減少了一個項目的構建過程，每週需要兩名專業人員完成，一組腳本需要大約一個小時才能運行 - 您最好相信這會改進發布的質量。）

Answer 3

首先，有像「的敏捷方法」沒有這樣的事，敏捷是一個描述幾種敏捷方法的總稱，如果你所有的工作正在做的是standups，我已經可以告訴你，這並不能讓工作場所變得敏捷。其次，儘管你可以在個人層面採用一些「敏捷實踐」（特別是工程實踐），但這永遠不足以讓你變得敏捷：1.敏捷在我看來更多關於推動產品開發的方式比工程實踐2.敏捷是一個集體的團隊遊戲。

因此，我的建議是潛入Scrum and XP from the Trenches，併爲您的同事，老闆或潛在贊助商提供一些副本。

Answer 4

恭喜你做了站立。這是一個很好的第一次改變。

你在問，暗示你或團隊想在這方面做得更好。在這種情況下，你可以去以下兩種方法之一：

• 巨大的變化，或
• 逐步改善

如果你決定你想要一個巨大的變化，你可能需要一些書籍，培訓，也可能是一個教練或經驗豐富的從業人員。如果組織中的更高層人員也投入到變革中，這往往是成功的。

如果您決定要逐步改進，那麼爲了獲得一些想法值得閱讀一下Agile。我推薦「XP解釋」。這裏也有很多博客，以及這裏的帖子。你需要做的兩兩件事是：

• 嘗試提供一些軟件，或者至少從相關人士處
• 明白爲什麼這是硬，你可以做什麼，使之更容易得到反饋。

我們通常先做展示，第二次做回顧展。我建議至少每兩週進行一次回顧，即使很難展示工作代碼。

事情我經常看到快速標記了的問題包括：

• 隊不在同一位置（「團隊」包括學士學位，質量檢查）
• 環境不適合在
• 工作缺乏可見性進度或總體目標
• 太多的工作正在進行 - 事情已經開始但尚未完成
• 正在進行的項目沒有人真正在意
• 項目進度顯而易見，它不值得做
• 代碼庫真的很難改變
• 責備文化阻礙合作。

不管你找出來，你不會是第一次。

注意，敏捷是一種透明的方法，所使用的任何版本。很多人被透明度嚇到了。這個是正常的。有時候，高層管理者有一個既得利益，不讓事情變得透明。這也很常見，那時您可能需要外部幫助。但是，交付工作軟件可能非常有說服力。

祝你好運！

Answer 5

如果你想從頭開始做這一點，那麼你需要的是敏捷宣言和經常性的回顧，每星期。但我想這是遠遠不夠的，所以這裏是我的啓動列表：

1. 轉換現有的項目任務/點/待辦事項到用戶故事
2. 對程序上的一切。經常切換對！
3. 使用測試驅動開發。力爭100％覆蓋！
4. 使用一週迭代。重複正在學習！
5. 提供有價值的軟件，在每次迭代的客戶。

Answer 6

即使整個團隊不能以敏捷的方式工作，您也可以將其作爲開發人員採用的做法很少。您可以從CI，TDD，自動部署開始。作爲一個團隊，你可以嘗試回顧性會議。