我在一家位於印度的大型外包公司工作。我在美國，有一個由3名開發人員組成的團隊，我們正在使用Scrum實踐，並且在我們的方法上取得了巨大成功。時間跟蹤和敏捷方法
我的問題是，我們公司要求我們估計每月的活動時間，而我們每週都在進行迭代。該系統提供了45項活動的清單。爲了舉例說明它的細化程度，我們開展了諸如編碼，編碼審查，編碼返工等活動。
現在我們每天都應該輸入實際的時間aginst這些活動。而使事情變得更糟的是，時間跟蹤系統的設計很差，速度很慢。
管理層在這個過程背後的基本原理是他們希望使用這個時間記錄下來預測未來的工作。但問題是沒有任何流程來確保我們輸入正確的時間。所以我們最終將任何數字和一天結束。
這影響了團隊的生產力和士氣，擊敗了整個目的。
對敏捷項目中的時間跟蹤有什麼想法？
請確保將它和您的scrum master相提並論，並在您的回顧中提出。
因爲你可能要忍受它讓我提出兩種方法：
那麼，scrum的主人是我們的客戶，作爲一個將我們的客戶帶到這裏的供應商只會讓我們看起來效率低下。除此之外，我們的管理層將會對此感到不滿。我沒有選擇，但同意點1，你把:)。在一個擁有10000人的公司中，我無法爲時間管理系統創建更好的用戶界面。感謝您的建議保羅！ – user176687 2010-02-10 07:02:00
你處境艱難。 我會去第二個建議。我們被迫使用SAP接口在工作中輸入數據。我們的程序員之一編寫了一個Python程序，可以自動輸入所有數據。現在我們都用它並且喜歡它。爲你的情況，我想象一個按鈕欄上的所有狀態。點擊狀態將啓動該類型工作的計時器。這將全部記錄到文件中。在一天結束時運行另一個解析該文件並將其上傳到笨重系統的程序。 – 2010-02-10 14:32:44
保羅按鈕欄是一個很好的主意。跟蹤時間不那麼痛苦會很好。 – user176687 2010-02-10 16:52:51
聽起來像時間跟蹤可能有點過於細化，或者過於僵硬。如果不是讓你每天在結束的每個類別中輸入時間，而是要求你保留一個日誌，你可以填寫你當前正在做的這一天 - 所以你會得到這樣的：
上午8:30 - 9:45 AM：編碼 上午9:45 - 10:00：編碼審查
等等。
我認爲這是一個很好的建議，但它會在個人層面上起作用，以提高個人效率。日誌不能用於管理計劃。謝謝 ！ – user176687 2010-02-10 07:05:42
一旦項目完成*（或由不在項目中工作的人員），可以彙總日誌*。這樣，您可以在不中斷正常工作的情況下獲得團隊總數。 – Amber 2010-02-10 09:24:37
謝謝Dav。保羅建議的按鈕欄進一步提供了這個想法，併爲我提供了一個我們可以實施的解決方案。 – user176687 2010-02-10 17:01:29
您對敏捷項目中的時間跟蹤有什麼想法？
100％的浪費：問你這樣做的時候，你的經理實際上是讓你從代碼的工作是真正增加價值的產品（甚至未提到的應用程序，您必須唯一使用速度慢，設計不好，因此這看起來實際上接近200％的浪費）。對我來說，這聽起來像是過時的命令和控制。這應該由ScrumMaster作爲障礙來處理。
謝謝帕斯卡。就像我上面所說的那樣，scrum master是我們的客戶，作爲一個將我們的客戶帶到這裏的供應商只會讓我們看起來效率低下。 – user176687 2010-02-10 07:03:31
因此，ScrumMaster無法刪除您的經理創建的障礙，因爲它們不可見？而ScrumMaster實際上無法屏蔽團隊免受外部干擾？聽起來很奇怪，如果可能的話，不確定你的Scrum的實現是否是最優的。 – 2010-02-10 07:43:10
我同意，但鑑於客戶供應商關係，這是我們項目的現實。時間跟蹤是相關的計費，這是一個敏感問題。許多人從事許多活動，但不能爲客戶收取費用，但他們必須以某種方式「管理」系統中記錄的內容。 – user176687 2010-02-10 17:00:25
除非你在ROWE工作，否則應該在某個地方記錄時間，以便支付工資的人知道錢花在哪裏。這是多麼有用，它可以使用多少可以永遠辯論。 Evidence-based Scheduling可能是你的管理層有這樣的想法，它有可能發揮作用，並有可能發生適得其反的後果。
我會忍不住看是否管理會同意一些插圖中的時間表使這裏的迭代和規劃保持一致。試圖規劃3-4周的問題是，未來1-2周發生的事情會對此產生巨大影響。我的建議是查看是否可以同意2周的時間表，以便每次計劃差不多半個月。這有點妥協，但假定無論月度數據採用什麼系統都會接受雙週的事情。另一種方法是每月進行一次迭代，儘管這可能會導致我想象的一些動盪。如果沒有信任，誠實，最讓大家尊重有關信息
時間跟蹤是有用的。這可以問很多，因爲我可以想象許多這樣的系統已經燒燬了。管理層是否知道時間跟蹤的緩慢和糟糕的設計？例如，如果每天花一個小時記錄所有時間，並且可以解釋爲什麼確實如此，那麼可能有機會獲得更好的系統。這裏的一個關鍵點是要知道具體是什麼問題，爲什麼他們是問題，以及可以提出什麼樣的建議，雖然我認爲應該跟蹤時間，但可以使用電子表格以相對低科技的方式對於管理來說可能不是很好，但其中一部分是接受權衡，IMO。
謝謝。你遇到了一個關於試圖規劃3-4周的關鍵點。我們應該每週做一次。我計劃建議的一個折衷方案是僅跟蹤實際工時5-6個主要組織，例如編碼，體系結構，測試和組織規定的主要組織，並且我們可以計劃，在另一個工具中估計用戶故事，正在使用（拉力賽） – user176687 2010-02-11 07:09:03
這是一個艱難的。問題是使用的時間不會預測未來的工作。這是很好的文件記錄和許多陷入危險的陷阱。 Velocity可以幫助預測未來的工作，但它會通過設計隱藏時間。
與方法的問題是：不是所有的時間都是一樣的。捕捉小時會變成「理想」時間。未來的工作不是由正在從事這項工作的團隊估計的（並且沒有兩個團隊是相同的），但是管理層已經利用這些時間來提出一些算法。聽起來有點熟？這不是Scrum或敏捷。管理層既不瞭解Scrum的過程，也不瞭解Scrum的過程。
有這種困惑不好。客戶認爲你提供的不是你的東西，團隊成員是在錯誤的假設下工作的，而且管理層不在那裏提供你真正需要的支持。
所以，它真的不會不管你放什麼下來小時......很可能在過程中會回落到一個非敏捷方法，這將是統計學上只是做了個小時並隨機報告他們準確。冒着可笑的風險，你不妨節省你的時間，並花上數小時。現在
，如果時間來看看你花多少錢做採訪，這是不容易的跟蹤系統來衡量。
如果時間用於計費，那是不同的故事。這不是與Scrum相關的，而是業務流程的一部分。
我在一個正式的測試課上，講師很努力地說服學生使用時間表來跟蹤時間，因爲整個軟件工程/項目管理理論都是基於那個時間表來做線性的投影。 問題是現實是非線性的（取決於項目的水平波動） 像Scrum這樣的敏捷過程關注的不是人，而是人和業務。 ，因爲我們提到跟蹤時間用於帳單客戶。跟蹤時間的問題是它可能會傷害人們。例如，你估計任務並做10天，下次你做類似的任務，現在有10天，因爲一些不可預知的原因你不能這樣做，即使你的scrum master或PO也能理解和分享你的失落感截止日期（不完全是你的錯）......但是那個層面的其他人，高層管理者，其他項目經理，其他開發人員......他們可能會認爲你的表現存在問題是錯誤的。所以對於我來說，如果我們有一種方法可以完全落實開發人員，那麼跟蹤時間應該沒問題，然後我們使用這些數據來分析團隊從中學習的根本原因和反饋。棘手的部分是沒有給人們造成不好的感覺，我仍然找不到任何工作場所可以做到這一點，除了傳聞說谷歌是他們的花哨風格的地方。
馬丁福勒：估計既不好也不壞。如果您可以在不估算的情況下有效地工作 ，那麼請繼續並且 確實沒有它。所以我猜想跟蹤也是一樣。 http://www.thoughtworks-studios.com/sites/default/files/resource/twebook-perspectives-estimation_1.pdf – Quang 2013-06-26 17:01:40
什麼是你想要的建議的問題或類型？從下面的評論中可以看出，由於業務的原因，您處於固定位置。除了解決系統問題（自動輸入數據或簡化時間輸入）之外，還不清楚我們如何提供幫助。 – 2010-02-10 12:47:19
嗨吉姆，我不希望這個論壇的解決方案。我只是想從人們的想法中獲得想法。例如，我發現Paul提供的一個按鈕欄的建議非常有用，這符合您對自動化數據輸入的建議。 – user176687 2010-02-10 16:51:23
這個問題似乎無關緊要，因爲它涉及管理問題，而不是特定的編程問題。 – 2013-06-26 16:53:54