Lập trình với một nhóm người tôi chưa từng gặp

Tôi đã được chỉ định một dự án nhóm từ lớp khoa học máy tính AP của tôi và tôi bắt buộc phải làm việc với ba người khác. Tôi chưa bao giờ nói chuyện với họ trước đây, tôi không biết trình độ kỹ năng của họ và tất cả những gì tôi có là địa chỉ email của họ. Nhiệm vụ, tóm tắt, là đây:

"Là một nhóm, bạn sẽ hoàn thành tối thiểu ba Mô-đun cho một Lớp ...."

Tôi sẽ cố gắng và trở thành "Đội trưởng" bởi vì không ai trong số họ đã cố gắng liên lạc với nhau nhưng tôi tò mò: làm thế nào để đi về vấn đề này? Tôi đã gửi email cho họ và hỏi họ xem có phương pháp giao tiếp nào họ thích hơn gửi email cho nhau không, nhưng một khi chúng tôi thực sự bắt đầu dự án, tôi sẽ phải tìm ra ai đang làm gì.

Tôi nên làm gì? Làm thế nào để tôi "chịu trách nhiệm" và lãnh đạo ba người mà tôi chưa từng gặp?

Đây là một đoạn trích của bài tập thực tế:

Do đó, bạn sẽ cần thảo luận về các vai trò khác nhau mà mỗi thành viên trong nhóm sẽ đảm nhận trong dự án này vào đầu tuần. Bạn có thể giao tiếp qua Pronto (hoặc Blackboard IM), email, wiki, nhóm google, blog hoặc bất kỳ phương pháp nào khác mà bạn thấy phù hợp. Nếu một thành viên trong nhóm không tham gia nhóm vào cuối tuần, hãy cho người hướng dẫn của bạn biết và họ sẽ cung cấp hướng dẫn bổ sung.
...
Ngoài ra, vào cuối dự án sẽ là một đánh giá nhóm, trong đó bạn sẽ đánh giá từng thành viên trong nhóm đóng góp cho việc hoàn thành dự án này cùng với một lớp được đề xuất.

Chỉnh sửa: Nhiều người đề nghị tôi gặp họ trong quán cà phê, hoặc đại loại như thế. Vấn đề duy nhất là, tất cả chúng ta đều ở các trạng thái khác nhau. Tôi cũng đã tìm ra một trong số họ không được phép sử dụng Facebook / Skype / twitter, vì vậy tôi phải dùng đến việc nhắn tin cho họ qua tin nhắn và email yahoo.

Người lãnh đạo của dự án này sẽ là người bước lên và chịu trách nhiệm ngay từ đầu.

Điều này áp dụng cho hầu hết mọi thứ trong cuộc sống - không chỉ phát triển phần mềm. Khi mọi người khác chạy xung quanh như những con gà không có đầu, người nghĩ mọi thứ, bước tới và nói, " Đây là những gì chúng ta sẽ làm và đây là cách chúng ta sẽ làm điều đó ." thường là người được xem là người lãnh đạo cho phần còn lại của dự án. Hãy nhớ rằng bằng cách này, bạn đang chịu trách nhiệm cho thành công hay thất bại cuối cùng của dự án.

Bạn muốn dẫn dắt dự án này? Đây là một vài điều bạn có thể bắt đầu thực hiện ngay để tạo ra ảnh hưởng lớn.

1. Sử dụng một công cụ quản lý dự án như Trello và gửi lời mời đến mọi người và bắt đầu giao các phần của dự án cho mọi người.
2. Tạo cơ sở dữ liệu lỗi và bắt đầu thêm các tác vụ và lỗi - một lần nữa, chỉ cần bắt đầu gán.
3. Thiết lập kho lưu trữ kiểm soát phiên bản và kiểm tra một đoạn mã ban đầu tốt mà mọi người có thể làm việc. Từ chối đối phó với bất kỳ hình thức kiểm soát mã nào khác.
4. Đề nghị giúp mọi người bắt đầu phát triển bằng cách chỉ cho họ cách sử dụng hệ thống kiểm soát phiên bản và cơ sở dữ liệu lỗi.
5. Gửi email hàng tuần chi tiết về tình trạng của dự án và tiến độ của tuần trước.

Không có bước nào trong số này đặc biệt khó khăn, hoặc tốn thời gian, nhưng chúng sẽ là những người tiết kiệm thời gian khổng lồ trên đường. Hơn nữa, nhóm của bạn sẽ nói chuyện với nhau và khiến họ quen với việc gặp bạn.

Câu trả lời của Jarrod Nettles tóm tắt khá nhiều điều tôi sẽ đề xuất, vì vậy tôi sẽ đưa vào một số điều làm việc trong những trải nghiệm gần đây của tôi trong một tình huống tương tự.

Tôi sẽ đề nghị tìm cách nào đó để nói chuyện với họ bằng giọng nói, thay vì qua email. Nếu bạn không ở cùng khu vực, hãy tải tất cả trên Skype. Nếu bạn đang ở trong khu vực, hãy gặp họ tại quán cà phê hoặc một cái gì đó. Nói chuyện trực tiếp trong các cuộc họp ban đầu sẽ dẫn đến việc bạn thực sự đưa ra quyết định và hoàn thành công việc sau đó; chuỗi email cho phép những người nhút nhát hoặc thường không ở máy tính của họ nắm bắt quy trình - tất cả chúng ta đều biết sinh viên lười biếng như thế nào!

Trong cuộc họp đầu tiên của bạn, tôi sẽ cố gắng làm quen với nhóm của bạn bằng cách cố gắng tiếp tục với dự án - nhưng đừng bỏ qua dự án! 10 hoặc 20 phút dành băng phá vỡ có lẽ là đủ cho 4 người.

Khi nói về dự án, tôi sẽ đề nghị chạy qua những gì bạn nghĩ rằng dự án liên quan. Tôi nghĩ điều quan trọng là bạn phải nói rõ đây là sự hiểu biết của bạn, và không phải là trường hợp bạn nói với họ chính xác phải làm gì. Mọi người nên có thể đưa những suy nghĩ và ý tưởng của họ vào vòng nếu họ có bất kỳ điều gì, và bạn nên rời khỏi cuộc họp ban đầu đó với một sự hiểu biết đủ về những gì bạn, như một nhóm, cảm thấy dự án đòi hỏi.

Trong các cuộc họp (thường xuyên) trong tương lai, bạn có thể bắt đầu xem xét các bit khác nhau của dự án chi tiết hơn; nhìn vào những gì cần làm chính xác, những tài nguyên nào và cần bao nhiêu thời gian và ai có thể làm những gì. Tách mảnh hơn nữa nếu cần thiết. Có lẽ thử đặt một số thời hạn mềm?

Có ai trong số các bạn có kinh nghiệm làm việc với một nhóm người bạn chưa từng gặp trực tuyến và bạn không được gặp họ trực tiếp mà phải cùng nhau hoàn thành một dự án?

Thêm vào việc định mức thấp, thời hạn vô lý và bị bán xuống sông bằng cách tiếp thị và điều này nghe có vẻ như khoảng 65% các dự án phát triển phần mềm trong thế giới thực.

Bạn có thể được phục vụ tốt nhất bằng cách khiến mọi người tình nguyện cho các bộ phận mà họ sẽ quan tâm hơn là chịu trách nhiệm đơn phương và giao nhiệm vụ. Có lẽ tất cả họ đang ngồi đó suy nghĩ về cách họ nên chịu trách nhiệm. Hoặc làm thế nào họ có thể có được một số sod nghèo, người quan tâm quá nhiều để làm tất cả các công việc nhóm để họ có thể đi trên lớp của mình.

Điều đầu tiên cần làm trong những trường hợp như thế này là thiết lập trình theo dõi vấn đề và tìm hiểu cách sử dụng nó.

Để có phần giới thiệu cơ bản hơn về cách xử lý sự phát triển như bạn mô tả, tài liệu tham khảo yêu thích của tôi dành cho bài viết của Martin Fowler Sử dụng Quy trình phần mềm Agile với Phát triển ngoài khơi . Bài viết này phác thảo những điều cơ bản và khái niệm nâng cao về thiết lập giao tiếp nhóm phân tán:

Use Continuous Integration to Avoid Integration Headaches
Have Each Site Send Ambassadors to the Other Sites
Use Contact Visits to build trust
Don't Underestimate the Culture Change
Use wikis to contain common information
Use Test Scripts to Help Understand the Requirements
Use Regular Builds to Get Feedback on Functionality
Use Regular Short Status Meetings
Use Short Iterations
Use an Iteration Planning Meeting that's Tailored for Remote Sites
When Moving a Code Base, Bug Fixing Makes a Good Start
Separate teams by functionality not activity
Expect to need more documents.
Get multiple communication modes working early

Đối với dự án của bạn, bạn chắc chắn sẽ không thể làm theo tất cả các mẹo và thủ thuật được đề cập ở đó (ví dụ: có thể không có Đại sứ cũng như Truy cập Liên hệ cho bạn :) nhưng dù sao cũng đáng để nghiên cứu.

• Đối với nhiều đội có tất cả những điều trên sẽ là quá mức cần thiết. Tuy nhiên, tôi thấy thật hữu ích khi có một danh sách kiểm tra toàn diện như thế - để các mục bị bỏ qua được kiểm tra và ghi lại rõ ràng lý do từ chối - chỉ để đảm bảo không có gì quan trọng bị bỏ qua.

Bạn đã không cho chúng tôi biết bạn có bao nhiêu thời gian cho việc này, hoặc ngôn ngữ bạn đang làm việc (tôi sẽ nói một lớp duy nhất rất nhỏ, nhưng có lẽ trong ngôn ngữ của bạn, nó tốt hơn nhiều).

Trước hết, có một sản phẩm làm việc bằng mọi giá.

Nếu dự án kéo dài hai tuần hoặc ít hơn, giả sử bạn sẽ là người duy nhất làm bất cứ điều gì và rất hài lòng về bất kỳ sự giúp đỡ nào bạn nhận được. Cố gắng lên lịch mọi thứ cho mọi người, nhưng hãy chắc chắn rằng nếu không ai làm gì, bạn vẫn sẽ có một sản phẩm hoạt động. Ngay cả khi ai đó làm điều gì đó, đừng dựa vào họ tiếp tục: hãy chuẩn bị cho bất cứ ai bỏ học bất cứ lúc nào.

Nếu bạn có nhiều hơn một tuần, hãy cân nhắc việc lên lịch cho một ngày trong tuần khi sản phẩm nên được đánh dấu là một cột mốc và bám sát vào đó càng nhiều càng tốt. Hãy chắc chắn rằng bạn có thứ gì đó bạn có thể đá xung quanh và kiểm tra những thiếu sót của: nếu điều tồi tệ nhất đến tồi tệ nhất, đây sẽ là thứ bạn nắm trong tay. Mỗi thứ bạn tạo ra, bạn sẽ thấy bạn có thể cải thiện mọi thứ như thế nào, điều này sẽ thúc đẩy bạn đi trên, bật. Đừng lên kế hoạch quá xa về phía trước: chắc chắn, bạn cần có ý tưởng về những gì bạn sẽ kết thúc, nhưng hãy giữ những kế hoạch cụ thể nhất của bạn trong thời gian ngắn.

Lưu ý rằng hai cái đó trùng nhau một chút: điều này là có chủ ý, vì theo tôi hai tuần là một vùng màu xám trong đó việc thực hiện hai lần lặp là khó, nhưng chỉ làm việc trong một lần lặp là rủi ro.

Tôi đang giả sử trường hợp xấu nhất, nơi bạn sẽ làm việc với những người rất mới để lập trình. Lời khuyên chung của tôi sẽ là:

• Giữ một danh sách các tính năng bạn muốn triển khai sớm và ai sẽ làm việc với chúng. Jarrod đề nghị Trello và tôi hoàn toàn ủng hộ rằng: nếu đồng đội của bạn không có nhiều kinh nghiệm, điều đó sẽ giúp ích rất nhiều. Bạn cũng có thể thử giữ các lỗi ở đó.
• Trong một nhóm bốn người, bạn cần kiểm soát phiên bản. Nó có thể khiến những người khác miễn cưỡng đóng góp hơn nếu họ không biết cách làm việc đó, nhưng nó đáng giá.
• Bất kỳ phụ thuộc bên ngoài có thể sợ người mới. Nếu bạn viết bài kiểm tra đơn vị, hãy nói với mọi người rằng họ không nên lo lắng về việc phá vỡ chúng. Nói với mọi người rằng họ không nên lo lắng về việc phá vỡ công trình, đặc biệt là lúc đầu. Thật khó để sửa những người không cam kết bất kỳ mã nào so với những người cam kết mã lỗi.
• Kiểm tra xem những điều được đề xuất ở đây thực sự áp dụng cho bạn. "Tích hợp liên tục" là một thuật ngữ thú vị - đối với một chương trình nhỏ, điều đó có thể có nghĩa là "chương trình này chạy và tất cả các tính năng có thể được sử dụng". Bạn thậm chí có trang web? Việc chia thành các nhóm có giúp bạn không?
• YAGNI, hơn một trăm lần. Nếu bạn thực sự phải làm, hãy viết những điều trước cho các tính năng bạn sẽ tự làm. Làm cho nó hoạt động, sau đó tái cấu trúc hoặc bạn sẽ không làm cho nó hoạt động.
• Cấu trúc lại. Khi nó hoạt động, hãy dành thời gian sửa nó. Đừng quên đồng đội của bạn cũng sẽ phải đọc mã của bạn: một ngày dành để sửa các phần xấu xí và thay thế các giải pháp đơn giản bằng các giải pháp tốt hơn không phải là một ngày lãng phí.
• Giữ một mắt trên tất cả các bộ phận. Đọc lướt các thay đổi và thỉnh thoảng đọc mã của người khác giúp đảm bảo rằng mọi thứ đều đạt tiêu chuẩn chất lượng mà bạn cảm thấy nên thực thi và đảm bảo sẽ không khó để lặn nếu người đó bỏ cuộc.
• Đừng ngần ngại làm việc trên điều quan trọng nhất, trái ngược với điều được chỉ định của bạn. Nếu ai đó bị tụt lại phía sau lịch trình, hãy viết một ghi chú về điều đó ở đâu đó và tự làm điều đó. Hỏi họ trước, nhưng hãy tiếp tục nếu họ không trả lời, hoặc nếu bạn hỏi một hoặc hai lần và sau đó cảm thấy như họ vẫn không làm điều đó.
• Tập trung vào việc làm một cái gì đó bạn tự hào. Ngay cả khi nó đi chệch khỏi nhiệm vụ. Ngay cả khi bạn phải cắt các tính năng lớn để làm cho những gì bạn có trơn tru hơn. Mỗi lần lặp lại nghĩ "Tôi có tự hào về điều này không?", Và trong lần lặp lại tiếp theo, hãy cố gắng sửa những điều đó.

Tôi đã có một dự án thất bại khủng khiếp gần đây; bạn có thể đọc suy nghĩ của tôi về lý do tại sao nó thất bại nếu bạn muốn, nhưng điều này tóm tắt cách tôi làm điều gì đó như thế này nếu tôi có cơ hội khác.

Câu trả lời của Jarrod Nettles là tốt. Tôi sẽ thêm điều này:

1. Hy vọng rằng ít nhất một trong ba người kia sẽ hoàn toàn vô dụng.
2. Chỉ cần chấp nhận rằng bạn sẽ cảm thấy như bạn đang làm hầu hết (hoặc tất cả) công việc, nhưng mọi người sẽ nhận được tín dụng như nhau. Bất kỳ nỗ lực nào để cố gắng làm cho mọi thứ "công bằng" sẽ chỉ gây ra xung đột không cần thiết và làm bạn chậm lại.
3. Giữ liên lạc với bất kỳ thành viên nhóm nào là tốt. Những người như vậy rất khó tìm, và bạn sẽ muốn làm việc với họ một lần nữa.

Tôi đã ở một vị trí tương tự một vài lần vì tôi chắc chắn có rất nhiều người. Mặc dù vậy, điều chính là cố gắng hết sức để giữ cho mọi người hài lòng và vui vẻ, vì vậy tôi nghĩ thật tốt khi bạn muốn nhận nhiệm vụ trưởng nhóm, tuy nhiên giống như ai đó đã đề cập ở trên - điều này cần phải được tiếp cận cẩn thận như một người khác có thể cảm thấy họ nên làm công việc thay thế.

Tôi biết bạn nói rằng không ai tự mình liên lạc với nhau nhưng đôi khi những tình huống này có thể gây khó khăn cho mọi người, như bạn nói bạn đang làm việc với những người bạn chưa từng gặp và có thể khó giao tiếp, v.v.

Tôi sẽ bắt đầu với một email chỉ cần giải quyết tất cả mọi người và cho họ biết bạn là ai bạn cảm thấy dự án nên được giải quyết như thế nào và biết rằng bạn muốn lãnh đạo dự án chịu trách nhiệm thiết lập vai trò, mục tiêu, thời hạn, thời gian giao tiếp, gặp gỡ ( nếu muốn / mong muốn) và cập nhật dự án.

Mặc dù bạn không thể hoàn toàn ảnh hưởng đến những người khác, bạn có thể theo dõi xem ai đang làm gì và ai không. Việc ủy ​​nhiệm cho phép công việc được phân chia đồng đều hoặc phù hợp với những người có bộ kỹ năng hoặc cấp độ khác nhau.

Bằng cách này nếu công việc nhất định không được thực hiện, bạn có thể tự mình phân chia công việc giữa những người thực sự muốn làm việc đó. Bằng cách này, bạn sẽ không kết thúc với một dự án thất bại vào cuối và bạn sẽ có hồ sơ về việc cố gắng truyền đạt ngày, thời gian và tất cả các thông tin liên quan bạn có thể hiển thị ở cuối nếu mọi thứ không ổn. Luôn luôn những điều khiến bạn giữ đúng nếu một số người không giảm cân.

Về các mẹo:

Cá nhân tôi thích một môi trường làm việc hợp tác được tìm thấy ở đây: https://docs.google.com/

Điều này cho phép bạn chia sẻ tài liệu từ, bảng tính, vv Đó là một cách tuyệt vời để làm việc cộng tác. Tôi không thể nhấn mạnh đôi khi điều này hữu ích. Tôi sử dụng nó với một số người tôi làm việc với những người không ở trong nước vào lúc này.

Hy vọng điều này đã giúp được ai đó, có rất nhiều khía cạnh trong việc dẫn dắt một dự án mà chúng ta có thể tiếp tục mãi mãi nhưng nó chỉ phụ thuộc vào rất nhiều thứ. Ít nhất đây là một chút nhỏ để giúp đỡ.