Lập trình và lập kế hoạch [đóng]


15

Gần đây, tôi được giao nhiệm vụ lập kế hoạch cấp cao hơn do nhà phát triển chính của nhóm tôi rời đi. Tôi ghét kế hoạch dài hạn. Bộ não của tôi dường như không có dây tự nhiên cho nó, và tôi không đủ hứng thú với nó để dành thời gian để tìm hiểu nó (nó đủ khó để theo kịp khía cạnh lập trình của bức tranh).

Một người vẫn có thể trở thành một lập trình viên giỏi mà không phải là một người lập kế hoạch cấp cao nữa chứ?

Là một lập trình viên cao cấp, người ta dự kiến ​​sẽ giỏi trong việc lên kế hoạch cho toàn bộ sản phẩm và chọn ngày hoàn thành?


Nếu vị trí của bạn là Nhà phát triển, tại sao bạn dự kiến ​​lập kế hoạch? Có thể ước tính, nhưng không có kế hoạch
superM

vâng nó có thể Trong trường hợp này mặc dù năng suất của bạn sẽ phụ thuộc mạnh mẽ vào khả năng quản lý / nhóm của bạn tốt như thế nào
gnat

1
Đây là một câu hỏi thực sự thú vị. Tôi không nghĩ rằng bạn cần phải thực hiện nhiều thông số kỹ thuật để trở thành một nhà phát triển cấp cao giỏi - trong phát triển Agile, nhiều tính năng của một hệ thống hoặc dự án mới đã xuất hiện. Xem câu trả lời của tôi để biết thêm.
Robin Winslow

1
Làm thế nào mà một trích dẫn đi? "Ngày mã hóa có thể tiết kiệm hàng giờ lập kế hoạch" hoặc một cái gì đó cho hiệu quả đó.
Drake Clarris

Câu trả lời:


17

Kế hoạch dự án dài hạn chi tiết nổi tiếng là thường không chính xác. Chức năng của hệ thống chắc chắn sẽ thay đổi trước khi ra mắt và mọi người thường dành thời gian dài để tìm ra các chi tiết cụ thể đi vào đặc điểm kỹ thuật chỉ để các bên liên quan đưa ra một cái nhìn lướt qua tốt nhất.

Bạn nên đọc thêm về lập kế hoạch Agile , bạn có thể thấy nó phù hợp hơn với suy nghĩ của bạn. Nhiều phương pháp Agile cố gắng tìm cách tránh xa kế hoạch chi tiết, dài hạn.

Các phương pháp nhanh nhẹn cố gắng giảm thiểu các thông số kỹ thuậttài liệu chi tiết có lợi cho mã tự viết tài liệucác câu chuyện người dùng nguyên tử bị cô lập và cuối cùng là phần mềm làm việc. Trong một nhóm Agile hiệu quả, sẽ có một lượng thời gian tối thiểu dành cho việc lập kế hoạch.

Đọc Tuyên ngôn Agile và tìm hiểu về Scrum . Sử dụng phương pháp phát triển lặpphát triển hệ thống động để hướng dẫn dự án.

Nhược điểm chính của phương pháp Agile là bạn phải thừa nhận một cách cởi mở rằng bạn không biết phạm vi chính xác của dự án của mình và việc mua quản lý cho ý tưởng này có thể cực kỳ khó khăn và thường mất một thời gian. Xem câu hỏi và câu trả lời nàybài đăng này cho một số lời khuyên về điều đó.

Tuy nhiên, điều chắc chắn là khi bạn trở thành một lập trình viên cao cấp hơn, bạn có thể sẽ làm ít mã hóa hơn, nhưng tôi nghĩ rằng trong một nhóm Agile thay vì bạn viết nhiều thông số kỹ thuật hơn, điều đó có nghĩa là bạn sẽ dành nhiều thời gian hơn để quản lý và dạy kèm các thành viên trong nhóm của bạn và đưa ra quyết định kiến ​​trúc về mã.


4
"Các kế hoạch dự án dài hạn chi tiết nổi tiếng là thường không chính xác." DING DING DING +1
Ryan Kinal

11

Vâng, nó là có thể. Tuy nhiên, nếu bạn muốn trở thành một kỹ sư phần mềm hoặc kiến ​​trúc sư phần mềm giỏi, đó là nơi kế hoạch cấp cao của bạn phát huy tác dụng. Đối với tôi, sự khác biệt chính giữa một lập trình viên và một kỹ sư là khả năng nhìn thấy bức tranh lớn.


1
Tôi không ngại lập kế hoạch cho công việc tôi đang làm ngay bây giờ / trong 2 tuần tới. Có nghĩa là, nếu những gì tôi sắp viết liên quan đến nhiều tác phẩm, tôi không ngại lập kế hoạch ở mức cao và sau đó thực hiện nó (thực tế - đó chính xác là những gì tôi sẽ làm). Tôi không thành công khi cố gắng đưa ra một ngày hẹn hò trong tương lai - sau đó cố gắng tìm hiểu tại sao chúng ta sẽ không đánh nó. Đó là nơi sự thất vọng cá nhân của tôi bắt đầu lên đến đỉnh điểm.
MattW

Tôi cố gắng không để điều đó làm cá nhân tôi thất vọng. Tôi cố gắng ghim loại công cụ đó vào các nhà quản lý dự án;).
Blaise Swanwick

Để thêm vào bình luận của Blaise. Các nhà quản lý tồi khăng khăng đòi họp và đổ lỗi cho nhóm vì đã bỏ lỡ "các cam kết". Trong môi trường đó, lịch trình chắc chắn là bực bội. Các nhà quản lý giỏi nhận ra rằng lịch trình ban đầu là một phỏng đoán cơ bản và không phải là một cam kết. Họ biết rằng một số nhiệm vụ sẽ mất nhiều thời gian hơn và một số nhiệm vụ ngắn hơn. Điều họ quan tâm nhất là xu hướng dài hạn. ví dụ: Chúng tôi hiện đang chậm 20% so với lịch trình cơ bản trong 3 tháng. Điều đó có thể có nghĩa là chúng tôi sẽ chạy 20% cho các nhiệm vụ tương tự còn lại. Sau đó, họ sử dụng lịch trình mới này để quản lý dự án.
Dunk

9

Có thể trở thành một lập trình viên giỏi và không phải là một người lập kế hoạch cấp cao?

Trong một thời gian, có. Có thể làm điều này lâu dài? Không.

Với nhiều người sử dụng lao động hiện nay, đó là quy trình vận hành tiêu chuẩn để đưa ra chi phí tăng lương cạnh tranh trong ngành. Nếu bạn không cải thiện bản thân, đừng cố gắng giải quyết các vấn đề lớn hơn và khó khăn hơn, những sự gia tăng cạnh tranh trong ngành sẽ khiến bạn bị loại khỏi thị trường trong năm hoặc mười năm. Giữ điều này và nhà tuyển dụng của bạn cuối cùng sẽ bắt đầu tìm kiếm một lý do để loại bỏ bạn, và việc làm của bạn ở nơi khác cũng sẽ bị giảm mạnh.


Tôi bị bối rối. Về lý thuyết, việc tăng COL nên theo kịp tốc độ lạm phát. Bạn có gợi ý rằng đô la thực trả cho các nhà phát triển phần mềm đang giảm dần theo thời gian không? Hoặc mức tăng của COL thường cao hơn mức tăng chi phí sinh hoạt thực tế? Tôi muốn nói rằng một mối quan tâm lớn hơn là bản thân nó không có khả năng chứng minh sự tăng trưởng, thường được coi là tiêu cực. Tuy nhiên, có nhiều cách khác để chứng minh sự tăng trưởng, chẳng hạn như độ rộng lớn hơn hoặc độ sâu của kỹ năng kỹ thuật.
Ethel Evans

1
Đáng lẽ tôi nên nói tăng lương cạnh tranh trong ngành thay vì tăng chi phí sinh hoạt. Tôi chỉnh sửa câu trả lời của tôi để nói rằng Những sự gia tăng cạnh tranh trong ngành là khá ngọt ngào đối với những người trẻ tuổi, điển hình là tốt hơn nhiều so với lạm phát. Chi phí tăng sinh hoạt là cho sương mù cũ. Có một vấn đề khi ai đó tăng cao hơn lạm phát nhưng kỹ năng của người đó vẫn còn mới.
David Hammen

Gotcha! Cảm ơn đã làm rõ, điều đó chắc chắn có ý nghĩa.
Ethel Evans

Đáng buồn thay, theo tôi, đáng buồn thay, theo thời gian, kỹ năng lập trình ngày càng dễ học hơn, và do đó, kỹ năng hiện tại, không tăng trưởng, của một kỹ sư phá giá vượt ra ngoài COL.
New Alexandria

6

Chắc chắn, bạn có thể là một lập trình viên giỏi, theo quan điểm của một lập trình viên. Từ quan điểm của quản lý là một câu hỏi hoàn toàn khác. Theo kinh nghiệm của tôi, tham gia vào quá trình lập kế hoạch là cách tốt nhất để 1) nhận các bài tập lập trình thú vị hơn và 2) thực hiện chúng theo cách bạn muốn.

Nói cách khác, một khi nó được đưa vào kế hoạch ngắn hạn, rất nhiều lựa chọn sẽ ra khỏi bàn. Nếu giải pháp ưa thích của bạn sẽ mất sáu tuần nhưng họ chỉ có ngân sách hai, bạn sẽ bị mắc kẹt với những gì họ quyết định. Nếu bạn lo ngại về điều gì đó mà họ đã thảo luận trong kế hoạch dài hạn, họ sẽ không muốn thử lại.

Nếu bạn hài lòng với tình trạng đó, sẽ tiếp thêm sức mạnh cho bạn. Hầu hết mọi người trở nên ít hài lòng với điều đó càng có nhiều kinh nghiệm họ nhận được.

Bí mật bẩn thỉu là không ai giỏi lập kế hoạch và dự toán dài hạn. Những người lập kế hoạch tốt hơn là những người nhận thức được những hạn chế của họ, vì vậy tin hay không, bạn đang đi trước đường cong. Nhận một số đào tạo về kế toán cho sự không chắc chắn trong ước tính. Nhìn vào các kỹ thuật như lập lịch dựa trên bằng chứng hoặc scrum, dựa trên dữ liệu lịch sử để cho thấy mức độ chính xác của các ước tính của bạn. Bạn sẽ hạnh phúc hơn trong dài hạn nếu bạn có tiếng nói lớn hơn trong công việc.


"Bí mật nhỏ bẩn thỉu là không ai giỏi lập kế hoạch và dự toán dài hạn." Đó không phải là sự thật! +1 chỉ cho điều đó. Ngay cả với một lịch sử tốt, có rất nhiều con số cần phải được rút ra từ bầu trời trong xanh bởi vì dự án tiếp theo không bao giờ là bản sao chính xác của bất kỳ dự án nào trước đó. Nếu đúng như vậy, chúng ta sẽ có thể sử dụng lại tất cả các mã như hiện tại và được thực hiện với nó càng sớm càng tốt. Luôn có một cái gì đó mới và hiệu suất trong quá khứ không phải lúc nào cũng là một chỉ số tốt về mức độ nỗ lực cần thiết cho công cụ mới đó.
David Hammen

Ok - vì vậy có lẽ sự thất vọng (và thậm chí là bản ngã ) là nhiều hơn những gì tôi cần quản lý. Nếu tôi không thể đánh bại bản thân quá tệ và trở nên tốt hơn với thời gian (thay vì nói "Tôi không thích làm điều này") - về lâu dài tôi sẽ tốt hơn. Tôi có thể khó khăn với chính mình khi tôi làm việc đó kém - nhưng dường như (dựa trên các câu trả lời ở đây) tôi đã học tốt hơn để làm tốt nếu tôi muốn làm việc như một kỹ sư phần mềm. Tôi đánh giá cao suy nghĩ của mọi người. Tôi thực sự không có ai ở công ty tôi học được điều này - vì vậy nghe điều này từ mọi người ở đây là một sự trợ giúp rất lớn!
MattW

3

Có thể trở thành một lập trình viên giỏi và không phải là một người lập kế hoạch cấp cao?

Câu trả lời ngắn: Có, nó là có thể.

Tuy nhiên, bạn càng có nhiều kinh nghiệm với loại dự án mà bạn tham gia, bạn sẽ có những ý tưởng lập kế hoạch tốt hơn. Lý tưởng nhất, là một lập trình viên, chúng tôi có một số cách tiếp cận để giải quyết vấn đề hoặc chúng tôi tìm kiếm một. Vì vậy, nếu chúng ta biết cách tiếp cận thì chúng ta có thể bắt đầu nghĩ về kế hoạch :)

Một lộ trình khả thi khác là một lập trình viên trở thành một người lập kế hoạch giỏi cuối cùng cũng hướng đến Quản lý dự án. Vì vậy, nếu bạn quan tâm đến việc quản lý các dự án, bạn có thể nỗ lực thêm theo hướng đó.


1

Có và Không là câu trả lời của bạn.

Một mặt, bạn đang bị đẩy vào quản lý dự án. IMO, tất cả các lập trình viên giỏi đều có một số mức độ về khả năng quản lý dự án, nhưng họ là những bộ kỹ năng khác nhau. Khả năng lập kế hoạch dài hạn giúp cải thiện khả năng giao tiếp với quản lý dự án thực tế. Vì vậy, "không", bạn không thể trở thành một lập trình viên giỏi mà không có khả năng lập kế hoạch dài hạn.

Điều đó đã được nói, quản lý dự án là một bộ kỹ năng khác nhau thu hút các khía cạnh có liên quan nhưng khác với lập trình. Vì vậy, đây là nơi "có" phát huy tác dụng. Bạn không cần phải là người quản lý dự án để trở thành một lập trình viên tuyệt vời.

Đối với tình huống cụ thể của bạn, hãy cố gắng trở nên khách quan hơn về những gì công ty cần cũng như những gì bạn thích làm. Có quá nhiều cái tôi phản ánh trong câu hỏi của bạn và điều đó thiên vị khả năng của bạn để xem xét tình huống này. Nếu bạn có thể tìm cách đóng góp nhiều hơn cho chủ nhân của mình trong khi vẫn làm những việc bạn thích, thì bạn nên xem xét chúng và nói chuyện với sếp.


1

Lập kế hoạch và Bungie-Boss

Dilbert có nhiều dải về ông chủ bungie. Những thách thức và kỳ vọng của chúng tôi về việc lập kế hoạch có thể là cả nguyên nhân và kết quả của việc lãnh đạo. Kinh nghiệm của tôi tại một công ty Fortune 100 là trong một năm, tất cả những người bắt đầu năm làm trưởng dự án đều thoát ra. Có lẽ điều này là do vấn đề quy hoạch. Không chắc chắn nếu cựu lãnh đạo của bạn rời đi vì lý do này, nhưng khi vai trò của bạn yêu cầu bạn lập một kế hoạch với một cam kết, nếu nó không đi qua, thường, một lối thoát liên quan đến thời hạn là kết quả.

Bối cảnh tổ chức của kế hoạch

Nếu bạn không thoải mái với việc lập kế hoạch, có lẽ bạn không thoải mái với việc chịu trách nhiệm về các cam kết thực hiện tiếp thị hoặc các bên liên quan khác trước khi các vấn đề cần giải quyết được ghi lại hoặc hiểu rõ. Đây là một bản năng tốt.

Kế hoạch là một công cụ quan trọng. Đừng bỏ bê nó. Đừng hiểu lầm nó.

Lập kế hoạch được liên kết toàn diện với các cam kết, trách nhiệm và quyền lực đàm phán. Kế hoạch nhanh nhẹn có nhiều giá trị. Bạn nên biết các kỹ thuật của nó, cũng như các kỹ thuật của các phương pháp được lên kế hoạch. Tổ chức của bạn có thể có cách tiếp cận riêng và nhận lời khuyên và làm việc với một người đã sống sót trong vai trò lãnh đạo của nhiều dự án, rất hữu ích.

Một ví dụ lập kế hoạch đơn giản - Không phải là về phần mềm ...

Nếu một công ty lợp mái đến nhà tôi để trả giá thay thế, nếu họ trả giá quá thấp, họ có thể mất tiền trong công việc, nhưng nếu họ trả giá quá cao, họ sẽ không nhận được công việc. Dù bằng cách nào, họ đã hết kinh doanh. Trong vai trò mới của bạn, nếu bạn hơi quá thấp, bạn sẽ chạy dự án cho đến khi trách nhiệm giải trình, thì bạn sẽ gặp vấn đề. Nếu bạn ước tính một dự án có đủ phần đệm để đảm bảo thành công trước thời hạn, nhiều người chỉ cần chọn người khác để lãnh đạo. Các kicker là bạn không giống như thợ lợp. Anh ta có thể thấy mái nhà lớn như thế nào và có dữ liệu lịch sử về việc mái nhà đó mất bao lâu.

Trở thành một kế hoạch tốt hơn

Bạn có thể muốn xem xét một số loại đào tạo. Trong các phương pháp Agile và các phương pháp được lên kế hoạch gần đây nhất, ước lượng là một hoạt động toàn nhóm. Do đó, bạn cũng nên xem xét việc đào tạo cho nhóm của mình.

Từ kinh nghiệm, tôi có thể nói với bạn rằng có thể nản lòng khi lấy ước tính từ các thành viên trong nhóm, người sẽ đưa nó ra, đưa cho bạn ước tính họ thực hiện trong hai phút dựa trên tên nhiệm vụ mà không cần tham khảo mô tả tính năng hoặc yêu cầu hoặc mã hiện có hoặc người nhấn mạnh rằng một số nhiệm vụ bạn liệt kê có thể được thực hiện trong một số phần của một ngày mặc dù các dự án trong quá khứ đã dành hàng tuần cho các vấn đề tương tự.

Có nhiều khóa đào tạo và chứng chỉ quản lý dự án khác nhau, nhưng tôi sẽ theo dõi một khóa học được công nhận độc lập. Có thể đáng để suy nghĩ lần thứ hai trước khi chọn chứng nhận bằng các phương pháp dựa trên phương pháp đã được lên kế hoạch nếu bạn muốn làm việc với các nhóm Agile (hoặc ngược lại).

SLIM là một phương pháp được Putnam phát minh sau khi làm việc tại GE và các công ty khác trong các dự án DoD trong những năm 1970. SLIM có ảnh hưởng và công ty QSM của anh ấy cung cấp một chứng nhận dường như chảy ra từ một công cụ mà họ tạo ra. Tùy thuộc vào việc công ty của bạn đã áp dụng công cụ của họ, nó có thể không có giá trị hoặc giá trị cao.

Steve McConnell (tác giả của Code Complete) cũng đã viết một cuốn sách về ước tính phần mềm và công ty của ông Construx dạy hai lớp cho các khoản tín dụng PDU được công nhận thông qua Viện Quản lý dự án. Tôi có cuốn sách của anh ấy, và nếu tôi muốn tìm hiểu về chủ đề này thông qua đào tạo trong lớp, có lẽ tôi sẽ chọn Construx. Họ cũng thực hiện đào tạo Scrum và quản lý các đánh giá Scrum khác nhau được công nhận thông qua Scrum.org.

Một nguồn khác có thể cung cấp đào tạo học thuật tuyệt vời về ước tính dự án phần mềm, là nhóm của Barry Boehm tại USC , dựa trên công trình mở rộng của họ về mô hình chi phí xây dựng COCOMO và COSYSMO đã được sử dụng tại NASA và các nhà thầu lớn khác để ước tính các dự án lớn. Tôi không chắc chắn mình là một người tin tưởng thực sự vào COCOMO, nhưng tôi thích công việc thực nghiệm mà họ đã làm để tương quan với các tác động của quy mô và trình điều khiển chi phí trong thời gian biểu.

Tôi cũng tìm thấy một chương từ một cuốn sách giáo khoa được xuất bản bởi O'Reilly, thảo luận ngắn gọn về các phương pháp ước tính phần mềm chính bao gồm Watts Humphreys PROBE và trò chơi lập kế hoạch của Kent Beck. PROBE bao gồm một khái niệm rằng các kỹ sư theo dõi các số liệu về năng suất của chính họ, sau đó áp dụng chúng cho phần phân công của họ trong các dự án mới. Trò chơi lập kế hoạch rất hợp tác giữa các nhà phát triển và các bên liên quan khác.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.