2010-03-13 84 views
2

我在一個軟件項目上工作,並且想估算出我在軟件開發中貢獻的總貢獻中的百分比。有沒有這樣的工具?例如,這樣的工具對於評估或談判可能是有用的。畢竟,我們的工作是爲了錢(是的,不僅是金錢,而是保留點)。我認爲最重要的事情有足夠的揮手。如何估算個人對軟件項目的貢獻?

估計是非常主觀的(至少對我來說),但我不知道任何提供甚至主觀估計的工具。我知道Sloccount說明了使用代碼行的總體努力,但不是以每個開發人員爲基礎。

我用於此目的的理想工具的想法會:

  • 措施的代碼的複雜性(更復雜的是更多的努力,但更多的努力並不一定是更多的貢獻)
  • 測量可分解/軟件的靈活性(可分解性更好)
  • 使用了多少庫代碼 - 使用庫代碼加快了開發過程,增加了相關風險,並要求開發人員從以前知道或瞭解庫。
  • 要足夠聰明來區分「誰寫了代碼」,「誰複製了代碼」和「誰縮進了代碼」。

很難區分實施的複雜性和問題的內在複雜性。如果存在或者爲每個子模塊分別進行比較,也許可以與等效的開源代碼進行比較。

如果沒有這樣的工具,是否沒有這樣的工具的優點?或者你相信「我工作,我不測量」?畢竟,這需要時間。也許項目經理應該不斷地做這個估計,比如每週。有沒有任何標準?是的,標準化是困難的,因爲每個項目都有不同的目標,但也許這意味着應該有多個標準,而不是標準。這看起來很像公司在市場上的價值。

更新:看到幾個最初的答案後:想象一個只輸出百分比的工具是沒有意義的。是否有工具可以幫助人類(尤其是管理者)做出更好的決策?或者什麼是做出更好決策的充分統計數據?這些統計數據可用嗎?

回答

2

我真的懷疑有沒有可靠的可靠方法來衡量個人對解決方案的貢獻。有時候重寫一些複雜的遺留代碼會導致代碼行少,複雜性較低的解決方案(較小的圈複雜度等)可以被看作是相當重要的貢獻,而在其他情況下,刪除有價值的代碼可以覆蓋導致相同統計信息的邊緣案例更少的代碼行,更小的CC等)絕對是不好的。這一切都歸結爲人員,信任和合作,團隊中的個人主義幾乎總是錯誤的,我寧願避免它,尤其不要將它用作動機因素。

+0

團隊中的個人主義是錯誤的,因爲團隊很小,個人凝聚力很好。在大型團隊或個人與團隊認同不佳時,個人獲勝。是的,這對經理來說不要使用「積分」來激勵,而是作爲私人信息是有道理的。 –

+0

在「刪除有價值的代碼」的情況下,這將表現爲增加的錯誤計數。當然,檢測哪個更改會導致錯誤本身就是一個具有挑戰性的問題。 –

0

我不認爲你可以得到一個工具來評估你的項目份額。測量線的源頭都很好,但是源的質量如何?如果這項工作本來可以在20年輕鬆完成,你不會希望有人獲得200線的信貸額度...

另外,想到我的僱主一會兒,很多人爲項目做出貢獻代碼以外的其他方式。我能想到的直接例子就是項目經理和測試人員 - 他們兩人都是必不可少的,他們都值得信任。

Martin Martin

0

我能想象的唯一事情就是投票系統。我完全不知道,如果這可以在你的團隊或任何地方工作 - 但我相信,你會需要人類對代碼質量進行任何現實的估計。

2

這是一個獨立的研究課題。有幾種工具試圖定義像code ownership等指標。還有其他方法可以解決協同開發的其他方面問題,例如我們可以在代碼中使用的trustability

還有一些研究試圖使用來自錯誤跟蹤器的信息。例如,確定更可能引入錯誤的開發人員。但很難客觀(一位出色的開發人員被分配到系統中最關鍵的部分,但仍然更有可能引入重要的錯誤)。

實際上很難貨幣化的發展任務。一個bug的成本是多少?重構的好處是什麼?然而,這將是估計開發者貢獻的一種方式。

我看到的這種最後一個很酷的工具是Game Plugin對於Hudson 持續集成系統。得分被分配給每個顯影劑根據他們的行動

  • -10如果他們打破建立
  • -1用於破碎的測試
  • 1用於固定測試

這也是以某種方式評估開發人員貢獻的一種方式。

總而言之,我確實覺得你所要求的存在,但仍然非常不成熟。

0

在Stroustrup的C++書中,我讀過一次「不要試圖用技術手段解決社會問題」。

思考進步,程序員的態度和能力可以通過代碼審查和談論相關主題來快速估計。

enter image description here

作爲IT發燒友和作爲一個控制狂思考,這不應該是很困難,實現受教機器學習軟件,它使用版本cotrol,錯誤數據庫等併爲每個貢獻者提供實時性能數據。例如。 R,KNIME或WEKA可以用於此。