我正在轉移到一家新公司，在那裏我將成爲項目經理/開發人員/測試人員/發佈管理人員等等。基本上我就是一切。只要您交付產品，編程經理就不在乎您的工作。所以，我需要開發我將如何去管理我的項目。我也需要遵循一些方法，以免我不習慣壞習慣。要使用哪種SDLC方法？
那麼，基本上我應該使用什麼樣的方法？是否有一些資源可以用於我將要處理的情況？我應該採用敏捷還是混亂？這些項目相當小。
截至目前，這裏是我如何計劃做事。請評論以下任何一項。
我不知道，如果你需要用自己的品牌新戰略進入新公司，或者您可以使用任何他們爲了得到這個地方的感覺目前正在做。從那裏，你可以保持工作並改變效率低下的東西。
這是一個資源，可以幫助您記住不同的Software Development Methodologies在您的處置。
我認爲如果沒有先了解你將要管理的人員目前如何開發軟件和交付項目，那麼進入一家新公司並試圖實施開發方法學'x'會非常有害。
你不可能期望作爲一名新經理走進來，並告訴他們做這項工作，明天他們都會以不同的方式做事，因爲你這樣說。
你需要看看他們現在在做什麼，什麼起作用，什麼不起作用，然後一旦你贏得了你將要管理的人們的一點信任和尊重，並看到他們喜歡怎樣工作你可以開始指出你認爲自己在做什麼的地方。
理想情況下，您應該幫助他們得出結論，他們需要流程'a'或程序'b'。如果他們感受到所有權和流程的自下而上的發展，那麼您可能有機會被他們跟蹤。一個新流程的自上而下的法令（無論您選擇哪種方法，現在問題無論多麼好），成功的可能性非常低。
我同意抵達並實施危險的變更。事實上，我所見過的最成功的新經理人在改變任何事情之前總是需要一個月左右的時間來了解組織和團隊中的個人。 – 2009-07-13 05:31:06
然而，根據我的經驗，這可能聽起來有點老生常談，因爲處於像你這樣的情況和我從學術界學到的東西，選擇一種方法學非常困難 - 最大的兩個問題是，你無法真正評估方法學是恰當的，直到你使用它並獲得了經驗，並且成功使用方法論高度依賴於你和你的周圍環境 - 僅僅因爲你的老闆不干涉，其他員工喜歡什麼？ IT人員之前是否被糟糕的IT項目所困擾？IT的平均能力/接受程度如何？
從我在小團隊中的工作經驗來看，
線性方法論（SSADM等）
優勢
缺點
迭代方法學（RAD，UP ）
優勢
缺點
這如何適用於你？這取決於你的感受，你可以像這樣管理自己（你是否曾經有過這樣的獨家開發經驗？） - 我個人發現，一旦我失去興趣，堅持嚴格的方法論是非常困難的。
雖然你提到你的管理很不乾淨 - 這實際上可能是一個問題 - 沒有人在監督中發揮作用 - 自我激勵可能會下降，我發現無人問津的人往往會更加難以對付你當諺語擊中球迷時！
你提到你不想陷入壞習慣，這聽起來像你可能適合更加嚴格的方法 - 所以你可能會發現我使用的方法很多，也很好。 OpenUP是一種迭代的，但適度記錄的方法，頂部的櫻桃意味着您可以根據自己的需求定製方法 - 例如，開箱即用，它對於一個人的樂隊來說太重量級了 - 但它確實有合理的建議。
要求
我不能強調多少記錄儘可能多的，你可以和保持良好的版本控制系統（即使這意味着您創建Word文檔每顯著變化的新版本） 。
擁抱「敏捷」分析方法 - 白板是你的朋友。
還要考慮使用快速原型開發工具，如果能夠得到時間與你的最終用戶
設計&實現使用它們
我不得不說，這是非常依賴於你的工具設置/平臺。只需使用您熟悉的工具即可。並使用源代碼管理。
測試
如果這一切成爲可能得到發展和生活系統，這是更重要的，如果你正在做的事情反覆，推動代碼的您提供部分到現場，而你對發展中發揮。
UAT
一個雷區，你需要確保你不會有氾濫成災「這個按鈕是1個像素太遠權」的問題種類和專注於核心問題，優先他們需要解決的複雜性和時間。
而我的最後一塊 - 每個人都討厭它，每個人都應該這樣做，每個人都說他們會，沒有人會這麼做 - 規劃。如果我的計劃好了，每次驗屍都是如此。
你提出的是一個瀑布計劃。有足夠的線索可以告訴你爲什麼大多數組織在過去幾年中都轉移了它。
這是另一個想法。你嘗試實施一種你承擔所有角色（PM，BA，開發人員，質量保證，支持，發佈）的方法是必然會失敗的。你真的無法完成所有這些工作。那一天沒有足夠的時間。嘿，我知道，作爲一個團隊的領導，我讓人們每天都在向我的方向拉動我:)
此外，即使你能做到所有這些，你也無法將它們都做得很好。由於某種原因，他們是分開的角色，他們每個人都相互提供支票和平衡。例如，您最終會以開發人員的身份加入快捷方式，您將無法驗證爲分析師。作爲QA，您只能通過您開發的應用程序檢查路徑。坦率地說，如果你是一名開發人員，那麼除了開發之外，你將會急於完成所有的事情，因爲它很糟糕。
我真的會質疑公司的承諾，如果他們只僱用一個人的技術。
你顯然沒有爲一家小公司工作過。我們只是說如果你正在做一個自由職業項目，你會怎麼做？ – TheGambler 2009-07-12 21:38:31
大多數敏捷流程適用於在項目中工作的小團隊 - 看起來您將成爲一人團隊......所以，您需要爲此選擇一種方法。要取得成功，我強烈建議：
如果您拒絕接受這些項目，情況會更好。因爲當你是一個項目的一切時，這是一項任務，不能被視爲一個項目，也不需要PM。在其他方面，項目管理者應該具備識別項目正確流程的知識和能力，而目前您還沒有這個項目。所以任何一方都不會有好處。
如果您的項目很小，則堅持敏捷方法。由於您正在開發，因此您可以持續與客戶進行交互。展示你的工作，從他那裏得到結果。大多數時候他們會建議在下一次衝刺中給出一些小的改變。
與敏捷的主要益處時，其單人演出是
與客戶持續互動。
知道他想清楚什麼。
固定的時間表，沒有延遲作爲衝刺將很小。
要求沒有歧義，因爲您會進行交互。你可以用更好的方式來說服爲什麼不能根據情況來完成。
沒有繁忙的最後期限。
程序管理器是唯一一個做UAT的用戶嗎？如果沒有，那麼我會建議看看用戶目前正在做什麼，看看瀑布和敏捷的哪些部分可能對他們的期望有意義。我提出這個問題的主要原因是公司可能習慣了某種風格的項目計劃和執行，並且搖擺船可能是一件壞事。 – 2009-07-12 21:43:27