Phương pháp vòng đời phần mềm cho các nhóm một người [đã đóng]


15

Tôi đang xây dựng một hệ thống phần mềm cho dự án thạc sĩ của mình và đang tìm kiếm lời khuyên về các phương pháp cụ thể phù hợp với "một nhóm một người" ...


1
Tôi rất vui vì bạn đã hỏi câu hỏi này, tôi đang ở trong một tình huống như vậy tại thời điểm này. Tôi đã tiếp quản một nhóm hai người không có quy trình và kiểm soát nguồn gốc, tích hợp liên tục, phát triển theo hướng thử nghiệm và nhiều nhóm khác. Bản thân tôi tự hỏi về những gì tôi có thể làm để cải thiện hiệu quả và làm thế nào để chuẩn bị tốt nhất khi cuối cùng tôi được phép thuê người dưới quyền.
maple_shaft

Câu trả lời:


11

Tôi kiếm sống bằng nghề "thuê súng phần mềm" một người, người làm việc chủ yếu ở nhà, vì vậy tôi rất muốn nghe người khác nói gì về điều này.

Dưới đây là một vài điều tôi thấy quan trọng:

  • Như Denis nói, kiểm soát nguồn là quan trọng - nhưng SVN không phải là lựa chọn duy nhất. Tôi chủ yếu sử dụng Perforce và git là một lựa chọn tốt. Tôi thích một mô hình phát triển "tuyến chính"; cho phép tôi thực hiện các thử nghiệm trong các nhánh mã, hợp nhất chúng vào dòng chính khi chúng hoạt động và bỏ rác chúng nếu chúng không hoạt động.
  • Tôi sử dụng một máy tính xách tay để ghi chú một chương trình để theo dõi các nhiệm vụ. Hiện tại tôi sử dụng Redmine cho cái sau; Trước đó, tôi đã sử dụng Fogormsz. Tôi cũng thích Redmine vì nó có wiki tích hợp thực sự tốt, tôi có thể sử dụng cho các ghi chú và liên kết liên tục đến các trang web quan trọng.
  • Điều quan trọng nữa là theo dõi những gì tôi đang hoàn thành và đặt cho mình một số giới hạn hợp lý để tôi hoàn thành đủ việc mà không bị kiệt sức - xem bên dưới.

Các kỹ thuật khác của tôi đã phát triển qua nhiều năm và tôi điều chỉnh chúng tùy thuộc vào dự án và khách hàng. Mọi người trả tiền cho tôi để làm việc với mã, không bị lừa bởi quy trình, vì vậy tôi cố gắng giữ quy trình gọn nhẹ và tránh xa khuôn mặt của khách hàng. Nhưng tôi thấy một số kỹ thuật Agile hoạt động thực sự tốt với tôi:

  • Một trong những khách hàng hiện tại của tôi có xu hướng bỏ các tính năng lớn để tôi triển khai và không làm phiền tôi cho đến khi họ hoàn thành. Vì vậy, tôi thấy làm việc trên những người trong nước rút Scrum là tuyệt vời. Tôi đoán là có thể làm việc cho một dự án của một bậc thầy trừ khi cố vấn nghiên cứu của bạn là một người thích kiểm soát.
  • Khách hàng hiện tại khác của tôi có xu hướng có nhiều trường hợp khẩn cấp hơn về loại "ngừng làm việc này và sửa lỗi đó". Tôi đã thử làm điều đó với Scrum và bỏ cuộc sau một lần chạy nước rút. Vì vậy, tôi đang làm điều đó bằng cách sử dụng Kanban và nó hoạt động tốt hơn rất nhiều.

Một vấn đề khác khi bạn tự làm việc là bạn không có ai nói cho bạn biết phải làm gì hoặc khi nào, hoặc nếu bạn đã hoàn thành công việc hoặc khi nào nên nghỉ việc vì bạn đã làm đủ - vì vậy bạn phải làm điều đó cho chính mình Cá nhân tôi thích Scrum vì tôi có thể theo dõi cách tôi thực hiện các mục tiêu chạy nước rút của mình. Đối với các dự án Kanban, tôi chỉ có thể theo dõi thời gian tôi đặt vào, nhưng tôi không thích điều đó cũng như một cái gì đó dựa trên mục tiêu hơn.

Một số người bạn của tôi thề với Pomodoro như một cách để giữ họ tập trung vào các nhiệm vụ và theo dõi hiệu quả cá nhân, và tôi đang nghĩ đến việc thử nó.

Tôi cũng có một quy trình chính thức để phát hành mã cho khách hàng của mình để đảm bảo những gì họ nhận được là "đúng", nhưng điều đó có thể nằm ngoài phạm vi của những gì bạn đang hỏi về.


3

Sử dụng SVN ở trên, phiên bản mọi thứ. Để theo dõi, máy tính xách tay sẽ làm cho các dự án đơn giản hơn, nếu cần bạn có nhiều ứng dụng theo dõi lỗi / nhiệm vụ miễn phí (Redmine rất tuyệt). Theo tôi, Agile / XP / Tích hợp liên tục / những người khác sẽ hơi quá mức cần thiết.


3

Ngoài Quy trình phần mềm cá nhân , tôi không thấy nhiều về các mô hình quy trình chính thức được thiết kế để sử dụng bởi một nhà phát triển. PSP khá nặng về tài liệu và giấy tờ (dù ở dạng thô), không cần nói nhiều về các kỹ thuật cụ thể trong thực hiện công việc (thay vào đó, PSP tập trung vào thu thập dữ liệu để tìm các khu vực cần cải thiện), nhưng đó là một sự khởi đầu điểm để phát triển một quy trình cá nhân mà bạn có thể sử dụng cho các dự án vừa và nhỏ.

Tôi nghĩ rằng cách hành động tốt nhất sẽ chỉ đơn giản là tuân theo một số lựa chọn phù hợp (dựa trên nhu cầu của bạn và dự án) được chấp nhận rộng rãi từ các mô hình quy trình. Hãy xem các phương pháp để theo dõi công việc đã hoàn thành / công việc còn lại, yêu cầu quản lý, kiểm soát phiên bản, kiểm tra (đặc biệt là kiểm tra đơn vị và kiểm tra chấp nhận), tích hợp liên tục, tiêu chuẩn mã hóa, You Ain't Gonna Need It, v.v. Nếu bạn chưa, tôi khuyên bạn nên đọc Code CompleteLập trình viên thực dụng và thực hành các mẹo của họ.

Điều lớn nhất khi làm việc cá nhân là, ngoài bất kỳ hạn chế nào đặt ra cho bạn bởi các lực lượng bên ngoài, tất cả tùy thuộc vào bạn. Bạn không cần phải hỗ trợ bất kỳ ai khác làm việc bên cạnh bạn, vì vậy việc chọn các kỹ thuật cho phép bạn làm việc theo cách hiệu quả nhất có thể sẽ dễ dàng hơn. Trong những năm qua, có lẽ bạn đã tìm ra cách bạn làm việc tốt nhất, vì vậy đó sẽ là một điểm khởi đầu tốt. Sau đó áp dụng "thực hành tốt nhất" được biết đến trên đó để tăng cường khả năng và kỹ thuật của bạn.


1

Anh chàng đang hỏi về phương pháp cụ thể và mọi người đang trả lời "sử dụng phần mềm X / Y". KHÔNG phải là vấn đề của các công cụ, thực sự có nhiều phương pháp và dường như chưa có báo cáo xác nhận nào cho chúng: Agile, Iterative, xoắn ốc, Waterfall, XP, V-Model, TDD.


Điều này là hầu hết các nghiên cứu đã được đưa vào làm việc với các nhóm. Theo hiểu biết tốt nhất của tôi, chỉ PSP đã được thiết kế để sử dụng bởi một kỹ sư duy nhất. Và ngay cả trong đó, PSP tập trung vào việc chỉ định cách theo dõi dữ liệu để xác định các khu vực cần cải thiện và chỉ cung cấp một số nhiệm vụ cấp cao có thể giúp cải thiện chất lượng phần mềm, không có chi tiết cụ thể về cách thực hiện các tác vụ đó.
Thomas Owens
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.