小Dev團隊的敏捷/ Scrum

-4

我們是一個3人的小型開發團隊。我們負責每個軟件應用程序的設計，開發，測試和發佈。我們還提供軟件支持，並處理用戶可能遇到的任何問題以及錯誤修復。小Dev團隊的敏捷/ Scrum

目前，每個開發人員全權負責從頭到尾查看項目。所以他們會與客戶討論軟件的需求。他們將計劃，設計和開發軟件（前端和後端）。他們負責測試和bug修復。

這是一個建議的開發過程，還是每個開發人員在每個項目上都應該指定一些任務？

我一直在考慮將SCRUM原理應用於我們的開發過程，但不知道它們的效果如何。從我們的工作中我可以得出，我們已經在使用敏捷方法進行簡短的迭代，並且需要與客戶進行討論？

您會爲我們的環境推薦SCRUM嗎？其他小團隊如何運作？

來源

2015-03-30 K09

只有意見在這裏...我們的經驗是關於Scrumban，Scrum沒有迭代交付，但回顧和日常和看板任務管理。 – Isammoc 2015-03-30 21:33:26

「從我們所做的事情來看，我們已經在使用靈活的方法進行簡短的迭代，並且需要與客戶進行討論？」這些是一些敏捷方法的一些特徵，但它們本身不是敏捷的。 – 2015-03-30 22:34:21

將團隊過渡到敏捷是一件大事。很多變化。我會更多地研究敏捷/混亂，並選擇性地挑選一些你認爲會幫助你的團隊的事情。 – 121c 2015-03-31 04:35:32

這取決於您的目標：僅僅因爲它是最新的「時尚」而實施敏捷可能會證明您的現有業務成本非常高。以我的經驗（近15年，現在），最好在公司實施敏捷，不僅在技術層面（或DevOps，因爲他們現在稱之爲）。
如果您在開發環境中實施任何敏捷方法，而不是僅僅在該環境中獲得更高的效率，那麼只有！編碼人員每天不能寫多於這麼多的行數。比起，因爲其餘的業務仍然處於「瀑布」狀態，因此發展方面因其他因素而不得不滯後而成爲瓶頸...
在您的特定情況下，或許最好與開發人員並問他們：敏捷還是現狀？一旦你們所有人都同意敏捷而不僅僅是爲了它 - 首先在書本上做，然後在幾次衝刺之後纔開始根據你的情況調整你需要的東西。也許是一對結對編程，一點交叉協作等。在一天結束時，你只有三個人：達成共識有多難？好笑

來源

2015-03-31 21:15:03

小Dev團隊的敏捷/ Scrum

回答

相關問題