Làm thế nào tôi có thể vượt qua một mô hình phát triển phần mềm có cấu trúc xấu?


11

Tôi gia nhập công ty hiện tại tôi đang làm việc như một người mới. Do số lượng người có kỹ năng phát triển phần mềm GIS hạn chế và vì tôi là một trong số họ nên tôi được tuyển dụng trực tiếp làm Quản lý dự án.

Tôi đã khá trò chuyện với Java và GIS và tôi đã tự nghiên cứu về các dịch vụ dựa trên vị trí, nhưng không phải với quản lý dự án và phát triển phần mềm có cấu trúc. Đó là một năm sau khi tôi tốt nghiệp chuyên ngành Địa chất và trong năm trước tôi đã làm việc như một học giả trong một trường đại học.

Nhờ vào sự quan tâm mà tôi có trong công việc, một cơ hội đã xuất hiện và cuối cùng tôi cũng chịu trách nhiệm cho bộ phận Business Intelligence của công ty. Công ty tin tưởng vào tôi. Bản thân tôi đã nghiên cứu kho dữ liệu và khái niệm BI và cũng thành công trong việc kết hợp GIS với BI.

Ngoài ra, tôi hiện đang làm việc với hai nhà phát triển trên công cụ BI của chúng tôi trong C # WPF, nơi tôi cũng đóng vai trò là nhà phát triển đôi khi (mà tôi thích).

Tôi đã rất cố gắng để áp dụng các phương pháp phát triển phần mềm tốt với quản lý dự án nhanh, nhưng nó không thành công lắm. Ngoài ra, mặc dù tôi tin vào mã được thiết kế tốt khi có liên quan đến sản phẩm, do thiếu kiến ​​thức kỹ thuật mà CEO của tôi có (người trực tiếp ở trên tôi), tôi thường không có được thời gian cần thiết để làm điều đó. Thời gian thực hiện được tăng cường đáng kể do thiếu chuyên môn mà chúng ta có trong ngôn ngữ mã hóa cụ thể nói chung (ví dụ WPF trái ngược với Java). Ngoài ra không có hệ thống kiểm soát phiên bản tại chỗ là tốt.

Tôi vô cùng chán ngán với cách mọi thứ đang diễn ra vì nó không có cấu trúc và tôi thấy phần lớn thời gian của mình suy nghĩ hơn là làm việc để làm thế nào để có được mọi thứ có cấu trúc. Tôi hy vọng các bạn có kinh nghiệm chuyên môn tốt sẽ có thể giúp tôi khắc phục tình trạng này.


4
Tôi không chắc chắn nếu bạn đã có, nhưng bạn đã thảo luận về tình hình với các đồng nghiệp ngay lập tức của bạn?
Fanatic23

Câu trả lời:


14

Chúng tôi đã có một vấn đề tương tự (tất nhiên là không có các chi tiết kỹ thuật) trong công ty tôi làm việc khoảng hai năm trước.

Bạn chỉ cần làm một bước một lần. Đừng cố gắng áp dụng sự phát triển phần mềm nhanh một cách vội vàng. Có rất nhiều thứ để tìm hiểu và áp dụng. Đừng để sự thiếu chuyên môn làm bạn thất vọng.

Xây dựng từ từ (nhưng nhanh nhất có thể: P), đều đặn và chắc chắn.

Tôi muốn giới thiệu các bước tiếp theo (để làm điều này, bạn có thể chuyển từ quản lý sang phát triển trong một thời gian, nhưng điều đó sẽ ổn thôi)

  1. Tìm hiểu một hệ thống kiểm soát phiên bản tốt , và tìm hiểu nó tốt. Cá nhân tôi muốn giới thiệu git hoặc đồng bóng. Có rất nhiều tài liệu về cả hai.
  2. Xây dựng một cốt lõi vững chắc về thực hành và các mẫu . Đọc sách, đọc blog, xem screencasts với các thành viên trong nhóm. Điều này sẽ cung cấp một không khí mới cho sự phát triển.
  3. Tìm hiểu TDD / BDD và thử áp dụng nó trong mã mới , cũng như trong mã cũ mà bạn có thể chạm vào khi thực hiện một tính năng mới.
  4. Làm lập trình cặp . Hai cái đầu nghĩ tốt hơn một, và 4 mắt cũng tốt hơn 2 :).
  5. Tìm hiểu về các công cụ mới nhấtphổ biến nhất được sử dụng trong cộng đồng ngôn ngữ bạn hiện đang phát triển. Tìm hiểu về họ và cố gắng đưa một số trong số họ vào dự án. Xem cách chúng được xây dựng và học hỏi.
  6. Sử dụng scrum . Lặp đi lặp lại, câu chuyện, điểm câu chuyện, trở ngại là tất cả các khái niệm bạn nên làm quen với. Đối với tôi, scrum đã được chứng minh là quy trình làm việc tốt nhất để phát triển và quản lý phần mềm. Áp dụng nó và học hỏi từ kinh nghiệm mỗi ngày.
  7. Dạy bằng ví dụ . Hầu hết các nhà phát triển mới bắt đầu rất muốn học những thứ mới, nhưng cũng có một số trong số họ rất lười biếng. Dù sao, hãy cho họ thấy những thứ mới mà bạn đang học và áp dụng và hy vọng điều đó sẽ kích thích trí não của họ.

Ngoài ra, nếu có thể, hãy thuê một chuyên gia tư vấn để anh ta có thể kiểm tra quy trình và đưa ra lời khuyên tốt hơn.

Đừng lười biếng hay nản lòng. Chỉ cần học hỏi từ những sai lầm của bạn và thử các phương pháp khác nhau. Điều này chỉ là khởi đầu!

Biên tập:

Đây là một số liên kết và sách mà tôi đã đọc / sử dụng gần đây ...

Học git: Pro Git

Đây là một số blog mà tôi muốn giới thiệu (hầu hết trong số chúng đều theo định hướng .NET):

Đối với sách, bạn có thể xem danh sách Buiding A Solid Lập trình lõi trên amazon. Tôi cũng muốn giới thiệu những điều này:


@Edgar, cảm ơn bạn rất nhiều. Thật tuyệt và tôi nghĩ những gì bạn đã giải thích sẽ làm việc tốt cho tôi. Vì tôi không thấy cách nào khác, hãy cho tôi biết nếu bạn trả lời đúng và chấp nhận nó một cách mù quáng.
picmate

1
@picmate Chắc chắn rồi, đó là cuộc gọi của bạn. Ngoài ra, khi làm công nghệ bằng ví dụ, hãy chắc chắn khen ngợi bất kỳ tiến bộ nào mà các nhà phát triển đạt được.
Edgar Gonzalez

@Edgar, chắc chắn rồi. Nếu bạn biết bất kỳ tài nguyên tốt nào mà tôi có thể sử dụng, vui lòng đặt chúng cho tôi theo từng điểm trong câu trả lời của bạn (nếu có). Đây có phải là cách mà bất kỳ công ty phát triển tốt nào có được với sự phát triển phần mềm của họ không? (vì tôi chưa bao giờ có cơ hội ở trong một công ty phát triển tốt)
picmate

1
@picmate trước hết, các bước này không được áp dụng riêng. Chúng chồng chéo lên nhau, chúng không theo thứ tự cụ thể nào (ngoại trừ cái đầu tiên). Tôi sẽ đăng một số liên kết sau trong ngày
Edgar Gonzalez

2
@picmate. Vì CEO không có kiến ​​thức kỹ thuật về những gì bạn làm, bạn có thể thuyết phục anh ấy thông qua những gì anh ấy biết. Ví dụ, bạn có thể giải thích rằng nếu có quyền kiểm soát phiên bản tại chỗ, bạn có thể tránh việc mất dữ liệu, và do đó về mặt tài chính ngăn chặn thất thu trong việc khôi phục đang bị mất, Hoặc bằng cách học thực tiễn phát triển tốt nhất, bạn có thể giúp công ty bằng cách hiệu quả, do đó giảm thời gian để phát triển một tính năng.
OnesimusUnbound

6

Là người quản lý, công việc của bạnlấy thời gian cần thiết để hoàn thành một dự án đúng cách. Khi tiếp cận Giám đốc điều hành, hãy đảm bảo rằng bạn có tất cả các số liệu ủng hộ bạn và lý do tại sao các ước tính cũng dài như vậy. Nó là của bạn chịu trách nhiệm như một người quản lý để làm CEO hiểu tại sao phải mất n giờ / ngày / tuần để hoàn thành một nhiệm vụ nhất định. Điều này đôi khi có thể khó khăn, nhưng tôi chưa gặp một CEO nào muốn công ty của mình thất bại và tôi cá là nếu bạn đặt nó theo những điều khoản đó (nếu tất cả đều thất bại), anh ta có thể thay đổi giai điệu của mình.

Nếu Giám đốc điều hành không sẵn lòng cho bạn thời gian cần thiết để hoàn thành các nhiệm vụ, thì IMHO, hãy sẵn sàng chuyển sang một công việc khác hoặc chuẩn bị cho các cuộc tuần hành tử vong liên tục. Như một phương sách cuối cùng, giải thích cho CEO sự kiệt sức mà không nghi ngờ gì sẽ đến từ những kỳ vọng không thực tế.

Phải nói rằng, bạn cũng cần đảm bảo rằng các nhà phát triển của bạn đang cung cấp cho bạn các ước tính chính xác (cực kỳ khó khăn, gần như không thể nếu không có các thiết kế kỹ thuật phù hợp được thực hiện, cũng nên có ở đâu đó).

Agile không tốt trong tất cả các lĩnh vực phát triển. Làm việc cho một số loại dự án, thất bại thảm hại ở những người khác. Bạn có thể phải thử một vài phương pháp khác nhau trước khi bạn tìm thấy một phương pháp hoạt động tốt .

Nhận thiết lập kiểm soát phiên bản . Thực sự, phải mất 5-10 phút để thiết lập Git, thêm vài phút để hoàn thành các thao tác cơ bản và một hoặc hai ngày đọc để có được các khái niệm nâng cao hơn.


1

Hmm, không chắc là tôi đã gặp bạn tại một sự kiện Agile / XP ở Toronto - điều này nghe có vẻ quen thuộc

Có vẻ như bạn cần nghỉ ngơi. Cuối tuần dài, say rượu nếu bạn thích, và quên đi công việc trong vài ngày.

Dễ lên chính mình. Tự học là tốt, và chỉ vì một phương pháp không hoạt động với các tính cách liên quan, không có nghĩa là bạn làm sai và đó không phải là một thất bại cá nhân.

Có một trang web (beta) pm.stackexchange.com, được nhắm mục tiêu tại Quản lý dự án, bạn cũng có thể nhận được một số lời khuyên / hỗ trợ hữu ích ở đó - nhưng bằng mọi cách, hãy giữ câu hỏi ở đây.

Chuyển sang các công nghệ:

không có phiên bản kiểm soát hệ thống

Đặt một trong những ưu tiên hàng đầu của bạn. Tôi thích các hệ thống tập trung như SVN (Subversion) hơn git / mercurial, bởi vì một máy tính xách tay bị đánh cắp sẽ không có nhiều lịch sử tại địa phương. Đặc biệt quan trọng nếu bất cứ điều gì siêu bí mật (như mật khẩu và khóa ssh) được kiểm tra do nhầm lẫn. Nhưng, đó là vấn đề của hương vị. Không có gì lãng phí thời gian hơn các lỗi từ control kiểm soát phiên bản thủ công '- ví dụ: đặt mã trở lại với những gì bạn nghĩ.

Chúc may mắn


Xin chào, cảm ơn vì câu trả lời và có lẽ đó không phải là tôi, người bạn đã gặp ở Toronto. Tôi ở vị trí này trong gần một năm rưỡi. Bạn có nghĩ rằng tôi đang lãng phí thời gian mà không có bất kỳ thành công?
picmate

0

Có vẻ như bạn có một số vấn đề: 1. Giao tiếp với quản lý cấp cao phi kỹ thuật để họ sẽ hỗ trợ chương trình cải tiến của bạn; và 2. Thúc đẩy chương trình cải tiến để thành công.

Phần khó nhất của số 1 chỉ đơn giản là nhớ rằng quản lý cấp cao thường không quan tâm đến các chi tiết về những gì bạn đang làm việc. (Nếu là họ, họ sẽ tự làm chứ không phải giao nó cho bạn!) Nghe có vẻ như trở ngại lớn là 'tại sao' và bạn có thể muốn xem CMM 1.1 để biết mô tả về lợi ích kinh doanh của việc cải tiến quy trình chương trình. Cho dù bạn sử dụng CMM hay thứ gì khác để thực sự cải thiện quy trình của mình sẽ không thành vấn đề trong cuộc thảo luận này, chỉ có dữ liệu từ nghiên cứu Carnegie-Mellon cho thấy các tổ chức trưởng thành hơn cung cấp các dự án nhanh hơn với thời gian giao hàng ít hơn.

Có rất nhiều con đường dẫn đến thành công khi cải tiến quy trình, tất cả chúng đều có xu hướng rất dài. Kinh nghiệm với CMM cho thấy có thể mất từ ​​8 đến 10 năm để chuyển từ cấp 1 lên 5. Kinh nghiệm với 6 sigma cho thấy mỗi lần lặp lại mang lại một số cải tiến nhưng cần nhiều lần lặp để loại bỏ hầu hết các vấn đề tiềm ẩn và đến lúc bạn gặp phải 6 sigmas chất lượng, công việc đang được thực hiện hoàn toàn khác nhau mà không phải mạo hiểm để cố gắng thay thế mọi thứ cùng một lúc.

Nếu có một phương pháp cải tiến chất lượng thường được sử dụng trong ngành của bạn, hãy dành thời gian để thử xem nó áp dụng như thế nào cho phần mềm và sử dụng nó để phần còn lại của công ty nghe về điều gì đó mà họ đã quen thuộc và ủng hộ. Chúng ta có thể nói hàng giờ về các công cụ và thực tiễn phần mềm cụ thể nhưng các CEO không phải phần mềm sẽ nhanh chóng điều chỉnh nó. Nói về các hoạt động tiêu chuẩn của ngành và anh ấy sẽ cảm thấy thoải mái vì bạn đang nói ngôn ngữ của mình. Nói về phần mềm theo các thuật ngữ chung của ngành và anh ấy sẽ bắt đầu hỏi những câu hỏi có liên quan để hiểu rõ hơn về những thách thức của bạn và kế hoạch của bạn để làm cho kết quả của các công ty tốt hơn.

Bạn sẽ không giành được mọi yêu cầu hỗ trợ theo cách này, có lẽ bạn sẽ nhận được ít giao diện trống hơn và nhiều chiến thắng hơn!

Chúc may mắn thưa ông!


0

Tất cả các đề xuất của bạn thực sự hợp lý và là cách để đi trong nhiều công ty. Nhưng họ không phải là phổ quát, đặc biệt là với các đội không có kinh nghiệm. Lý do họ không làm là vì họ yêu cầu một số lượng công việc để thiết lập và duy trì - thậm chí kiểm soát phiên bản - mà nhiều người cho rằng là cổ phần bảng cho bất kỳ dự án phần mềm nào. Bởi vì họ yêu cầu một số công việc, họ cũng cần cung cấp một số lợi ích. Và đó có thể là trường hợp cụ thể của bạn, họ không làm thế! Hoặc ít nhất là những người được giao nhiệm vụ đưa ra quyết định không thấy lợi ích!

Như những người khác đã chỉ ra, bạn cần phải:

  • Hãy thử áp dụng các thực hành lần lượt. Đừng thử tất cả chúng cùng một lúc vì nó sẽ áp đảo mọi người.
  • Bạn cần phải tìm ra một thứ tự tốt cho việc này. Tôi sẽ bắt đầu với kiểm soát phiên bản. Đi sau đó với những người dễ dàng hơn quá. Một khi mọi người bắt đầu tin tưởng rằng bạn đưa ra quyết định tốt và họ thấy lợi ích họ sẽ có nhiều khả năng chấp nhận thay đổi rủi ro hơn.
  • Xây dựng một trường hợp vững chắc cho lý do tại sao một cái gì đó cần phải được thực hiện. Với 2-3 nhà phát triển liên tục hiển thị tiến trình cho người dùng cuối, thật khó để biện minh cho việc áp dụng một phương pháp phát triển phức tạp hơn chẳng hạn. Bạn sẽ được coi là quá trình tập trung hơn là kết quả tập trung.
  • Có trong tâm trí những người bạn cần phải thuyết phục. Các nhà phát triển? Giám đốc điều hành?
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.