2014-01-20 58 views
1

我是敏捷開發的忠實粉絲,幾年前在一個非常成功的項目中使用了XP。我喜歡它的一切,迭代開發方法,圍繞測試編寫代碼,配對編程,讓客戶現場運行。這是一個高生產力的工作環境,我從來沒有覺得我受到了壓力。其他人覺得Scrum不靈活嗎?

但是,我曾經工作過的最後幾個地方使用過/使用過Scrum。我知道這些日子是敏捷開發的海報小孩,但我並不是100%相信它是敏捷的。以下是爲什麼它對我不敏感的兩個主要原因。

項目經理愛它

項目經理,誰其本質都迷戀的時間表,一切似乎喜歡Scrum的。根據我的經驗,他們似乎使用Sprint Backlog作爲追蹤時間要求的手段,並記錄給定任務花費了多少時間。他們沒有使用白板,而是使用Excel表格,每個開發人員都需要在宗教上填寫。

在我看來,這對於敏捷流程來說太多的文檔/時間跟蹤。爲什麼我會浪費時間來估計一項任務要花費多長時間才能完成任務本身。或者同樣,爲什麼我會浪費時間記錄下任務花費多長時間才能進入下一項任務。

站會

在前面的地方,我工作的站會是一個噩夢。我們每天都必須解釋我們昨天做了什麼,以及我們今天要做什麼。如果我們按時完成某項任務的「估計」,項目經理會發出一聲惡意,並將Sprint Backlog列爲顯示無能的方式,因爲您不遵守時間表。

現在我明白了溝通的必要性,但是每天會議的基調應該是輕鬆愉快的,並且側重於知識共享。我認爲它不應該變成你家庭作業風格的遊戲。無疑,敏捷的洞穴在於時間軸上的變化,它們不應該成立。

結論

敏捷的思路是使軟件更好地使開發者的生活更輕鬆。因此,我認爲團隊使用的任何敏捷流程都應該由開發人員領導。我不認爲讓項目經理使用他們標記爲「敏捷」的流程來跟蹤項目與敏捷開發有什麼關係。

想到任何人?

+0

我擔心這個問題是無關緊要的。良好的答案不會提供源代碼,算法,程序設計或其他任何可以作爲編程活動證據的產品。就核心而言,SO是程序員遇到問題的程序員,而不是他們的項目管理人員。 –

+1

在http://programmers.stackexchange.com/上這可能會更好,因爲它是關於項目管理而不是編程。 但是我的兩分錢 - 一些公司表示他們正在「做敏捷」,並沒有做任何類似的事情。您的項目經理似乎並不瞭解Scrum或敏捷。 –

+1

移動到ProgrammersSO或ProjectManagementSO – jessehouwing

回答

3

雖然這個問題可能很快就會關閉,即使它可能更適合http://programmers.stackexchange.comhttp://projectmanagement.stackexchange.com,我也會試穿這個。

您所描述的是我們專業的Scrum培訓師,在「實施Scrum」的組織中看到了很多。通常他們「在開發團隊中做XP」,這意味着在某個構建服務器上運行一些單元測試。 這不是scrum

是的,項目經理可以使用產品待辦事項,尤其是已經數字化的產品待辦事項,以濫用這些系統收集的指標。但是開發團隊和Scrum Master不應該讓他。什麼是項目經理呢?這不應該是一個產品負責人?!正如XP可以做得不好,一些更嚴格的流程可以感覺非常流暢(持續集成,部署,但仍然非常計劃驅動),Scrum只是一個框架。需要了解價值觀和流程的好人才能很好地執行。需要持續學習改進才能達到目標。

3

從外觀上看,你只是不幸有一個糟糕的項目經理不理解敏捷的方式。總的來說,你無法確定你花費了多少時間來構建某個特徵,你唯一能做的就是對衝刺中哪些特徵進行合理估計。然後,如果你無法在預計的時間內完成一個功能,那麼'激起一股惡臭'是我認爲不好的做法,不符合功能截止日期是遊戲的一部分。而且,開發者應該像他的開發速度一樣評價他的代碼質量。只要平均你的功能在預計時間內完成,一切都應該很好。客戶高興,項目經理高興。

相關問題