Cách tốt nhất để phân chia công việc giữa các nhà phát triển là gì

Nhóm của tôi và tôi đang xây dựng lại một trang web mà chúng tôi đã phát triển khoảng mười năm trước và chúng tôi muốn làm điều đó ở Agile.

Vì vậy, sau khi tôi dành nhiều thời gian để đọc (có lẽ là không đủ), tôi gặp rắc rối với câu hỏi làm thế nào để phân chia công việc giữa các nhà phát triển.

Tôi sẽ cụ thể hơn và nói rằng trang web được chia thành các mô-đun riêng biệt không có nhiều tích hợp với nhau.

Cách tốt nhất / được chấp nhận nhất để phân chia công việc giữa các nhà phát triển là gì?

• Cung cấp cho mỗi người một mô-đun khác nhau để làm việc.
• Chỉ định tất cả các nhà phát triển cho cùng một mô-đun và phân chia công việc theo các phần khác nhau của mô-đun (UnitTesting, DAL và Mapping, Logics, UI)
• Chỉ định tất cả các nhà phát triển cho cùng một mô-đun và phân chia công việc theo các logic khác nhau (Ví dụ: mỗi nhà phát triển chịu trách nhiệm về một logic cụ thể (có thể là một phương thức trong BL) và Đó là UnitTesting, DAL và Mapping và UI ...

Hoặc có thể một cái gì đó hoàn toàn khác nhau?

Hiện tại nhóm của tôi đã cố gắng "nhanh nhẹn" trong một vài bản phát hành, nhưng việc trở thành một phần của một tập đoàn lớn không thực sự dễ dàng. Tôi sẽ không giả vờ như tôi có câu trả lời, nhưng tôi có thể chia sẻ một số quan sát của mình.

• Phân chia nhà phát triển cho mỗi mô-đun:

  • Bạn cần cẩn thận vì nếu mọi người làm việc quá cô lập, nhóm của bạn không được hưởng lợi từ việc chia sẻ chéo các kỹ năng và kiến ​​thức
  • Lập kế hoạch các cuộc họp và đứng lên hàng ngày có thể trở nên vô cùng buồn tẻ đối với mọi người nếu mọi người tập trung quá nhiều vào các mô-đun của riêng họ và không nhìn thấy bức tranh lớn hơn. Một khi mọi người cảm thấy buồn chán, họ bắt đầu kiểm tra và bạn sẽ mất rất nhiều lợi ích nhanh nhẹn mang lại cho bàn
  • Bạn có thể kết thúc với một số thành phần được viết rất tốt, và các thành phần khác, cũng ... không quá nhiều. Nếu mọi người làm việc trong sự cô lập, những người đàn anh của bạn sẽ không thể đào tạo những người đàn em.

• Mọi người đều làm việc trên cùng một mô-đun cùng một lúc

  • Chúng tôi đã thử rằng trong một lần phát hành, khi quản lý quyết định họ sẽ áp đặt nhanh nhẹn cho toàn đội và nó sẽ hoàn toàn theo cách của họ. Nó như một con tàu đắm tuyệt đối. Chúng tôi đã có một nhóm gồm 9 nhà phát triển phân phối trong một năm, điều mà thông thường sẽ được thực hiện bởi 1 nhà phát triển. (Tôi có thể phóng đại ở đây nhưng không nhiều lắm).
  • Không ai cảm thấy như có bất kỳ phòng thở. Những người không quan tâm đến phần mềm, cảm thấy như ở nhà vì là một phần của gói lớn hơn, họ chỉ bị pha loãng trong nhóm. Những người trong chúng ta có niềm đam mê với phần mềm, cảm thấy hoàn toàn ngột ngạt vì không có tự do để di chuyển hoặc đi ra ngoài giới hạn những gì 9 người đã đồng ý.
  • Tất cả các cuộc họp đã đi mãi đến một điểm tôi muốn tự bắn mình. Quá nhiều người có ý kiến ​​trong cùng một phòng buộc phải làm việc trên cùng một DLL của freakin. Kinh dị.
• Trong phiên bản trước, chúng tôi đã quyết định thử một cái gì đó khác biệt
  • Đầu tiên và quan trọng nhất, chia nhóm phát triển thành các nhóm nhỏ hơn gồm 3-4 nhà phát triển. Mỗi nhóm làm việc trong sự cô lập tương đối với nhau nhưng trong nhóm mọi người làm việc gắn kết hơn nhiều
  • Với phương pháp này, việc đứng lên rất nhanh và lên kế hoạch cho các cuộc họp mất 1-2 giờ so với 4 giờ đồng hồ.
  • Mọi người đều cảm thấy gắn bó vì mỗi đội chỉ thảo luận về những gì các nhà phát triển trong nhóm đó quan tâm.
  • Lãnh đạo công nghệ từ mỗi nhóm nói chuyện với các lãnh đạo công nghệ khác định kỳ để đảm bảo dự án tổng thể đang đi đúng hướng.
  • Thay vì làm cho mọi người trở thành "chủ sở hữu" của một mô-đun cụ thể, chúng tôi đã chỉ định các lĩnh vực chuyên môn cho mọi người, vì vậy khi chúng tôi mới bắt đầu dự án, có cảm giác như mọi người có mô-đun riêng của họ, nhưng sau vài tháng, các nhà phát triển sẽ bắt đầu xem xét mã của nhau như các khu vực bắt đầu chồng chéo.
  • Mã đánh giá là rất cần thiết. Đây là phiên bản thứ hai nơi chúng tôi có chính sách đánh giá mã nghiêm ngặt và mọi người trong nhóm đều yêu thích chúng. Chuyên gia của một khu vực cụ thể luôn luôn xem xét mã khi có người khác sửa đổi mã đó.
  • Với các đánh giá mã, chúng tôi có rất nhiều chia sẻ kiến ​​thức và bạn có thể thấy sự cải thiện chung về chất lượng mã của các nhóm của chúng tôi. Ngoài ra vì mã được xem xét rất thường xuyên, khi mọi người đi vào lĩnh vực chuyên môn của người khác, rất có thể họ đã nhìn thấy mã ít nhất vài lần rồi.
  • Phần lớn hơn của mỗi nhóm được đưa vào các cuộc họp đánh giá thiết kế, vì vậy ngay cả khi họ chưa bao giờ nhìn thấy mã, mọi người đều quen thuộc với dòng chảy chung của tất cả các mô-đun mà nhóm của họ chịu trách nhiệm.
  • Chúng tôi đã thực hiện điều này trong khoảng 10 tháng và có cảm giác như chúng tôi đã bắt đầu với phương pháp mô-đun bị cô lập và biến mọi người làm việc trên mọi thứ. Nhưng đồng thời, không ai cảm thấy như họ bị tù túng hoặc hạn chế. Và để chắc chắn rằng các chàng trai vẫn có ý thức về một số người có thẩm quyền, chúng tôi đã để họ làm chuyên gia trong khu vực, mặc dù điều đó chủ yếu là hình thức bây giờ.

Chúng tôi đã làm điều cuối cùng, và mặc dù có rất nhiều cơ hội để cải thiện, nhưng toàn bộ đội ngũ của chúng tôi đã rất hạnh phúc và điều đó nói lên rất nhiều, khi chúng tôi là một phần của tập đoàn khổng lồ.

Một điều quan trọng mà chúng tôi đã sai trong 3 lần đầu tiên chúng tôi "đi nhanh nhẹn", đó là mỗi lần mọi người được cho biết cách làm việc và họ được cho biết phải làm gì. Đó là cách số một để nhóm của bạn hoàn toàn mất hứng thú với dự án và sau đó bạn gặp rắc rối thực sự.

Thay vào đó, hãy thử ngược lại. Nói với nhóm, họ có thể làm bất cứ điều gì họ muốn và với tư cách là người quản lý / lãnh đạo (nếu bạn là một, nếu không khiến người quản lý của bạn lặp lại những lời này), công việc của bạn là đảm bảo họ làm việc hiệu quả và vui vẻ nhất có thể. Quá trình không phải là một điều xấu, nhưng quá trình nên có để giúp nhóm của bạn khi nhận ra rằng nó cần một thứ chứ không phải theo cách khác.

Nếu một số thành viên trong nhóm của bạn thích làm việc riêng rẽ, hãy để họ (ở một mức độ). Nếu họ thích làm việc theo cặp, hãy để họ làm điều đó. Hãy chắc chắn để cho người của bạn chọn công việc của họ nhiều nhất có thể.

Cuối cùng, và điều này rất quan trọng và luôn bị bỏ qua. BẠN S GET KHÔNG CÓ QUYỀN NÀY (trừ khi bạn là siêu nhân, hoặc ít nhất là người dơi). Có các cuộc họp hồi cứu thường xuyên là vô cùng quan trọng. Khi chúng tôi đưa ra các hồi tưởng, chúng đã được thực hiện bởi cuốn sách và nó có cảm giác như một quá trình khác mà bạn phải ngồi qua. Đó không phải là những gì hồi tưởng dành cho. Đó là để lắng nghe nhóm của bạn, xác định các khu vực gây đau đớn nhất và khắc phục chúng để mọi người có thể tiếp tục với công việc của họ. Rõ ràng các kỹ sư phần mềm nói chung thích phân phối các sản phẩm và tính năng và cuộc họp hồi cứu thông điệp quan trọng nhất cần liên lạc, đó là chỉ vì lợi ích của họ. Bạn muốn xác định và giải quyết những trở ngại, bắt đầu với những cái lớn nhất (hoặc dễ nhất, ở đó '

Có một cuộc họp với nhóm, cho họ xem danh sách việc cần làm và hỏi ai muốn làm gì.

Đừng suy nghĩ trong các mô-đun. Hãy suy nghĩ trong các yếu tố chức năng. Mô tả các yếu tố chức năng đó bằng các câu chuyện của người dùng (hoặc theo cách khác) và đừng quên mô tả các tiêu chí chấp nhận (có thể được xác định bởi ứng dụng hiện tại của bạn và thay đổi mong đợi của doanh nghiệp). Đặt các yếu tố chức năng của bạn vào tồn đọng. Sau đó, hãy để doanh nghiệp ưu tiên chức năng nào phải được phân phối trước (bạn sẽ làm việc tăng dần và lặp lại và ưu tiên sẽ cho bạn biết những gì phải được thực hiện trước).

Một khi bạn có điều này ít nhất là một phần của ứng dụng ban đầu của bạn, bạn đã sẵn sàng để phát triển. Điều gì xảy ra tiếp theo phụ thuộc vào phương pháp nhanh được chọn của bạn. Phần quan trọng là mỗi chức năng thường có thể được chia thành nhiều nhiệm vụ và các thành viên trong nhóm sẽ chọn những nhiệm vụ họ muốn làm - đó gọi là tự tổ chức. Khi bạn bắt đầu với sự nhanh nhẹn, tự tổ chức có thể cần một số trợ giúp trong đó ai đó sẽ đảm bảo rằng các nhiệm vụ không phổ biến và phổ biến được chia sẻ như nhau bởi nhóm. Khi nhóm trưởng thành hơn, các nhà phát triển sẽ không ngần ngại nói lên sự bất đồng của họ với tổ chức tự hiện tại và điều này sẽ được xử lý tự động trong nhóm.

Suy nghĩ trong các mô-đun từ đầu không phải là một cách tốt. Bạn đang viết lại ứng dụng vì một số lý do và có thể kiến ​​trúc ứng dụng hiện tại dựa trên phân tách mô-đun không chính xác là một trong những lý do ẩn đằng sau các vấn đề có thể nhìn thấy. Ngoài ra, bạn có thể thấy rằng một số chức năng từ các mô-đun hiện có sẽ được xác định lại hoàn toàn và chuyển đi nơi khác.

Mặc dù tôi đồng ý với câu trả lời của David, tôi cảm thấy nó có thể thu lợi từ một số chi tiết:

• Agile có nghĩa là, bạn không đưa ra những quyết định này và đẩy chúng vào nhóm. Không có người quản lý dự án / lãnh đạo như thế. Chỉ có đội.
• Những người hiểu rõ nhất, cách phân chia công việc là chính các thành viên trong nhóm.
• Thảo luận về tồn đọng của bạn và tìm hiểu những gì bạn muốn nhận ra trong lần lặp / chạy nước rút tiếp theo.
• Sử dụng lập kế hoạch chơi bài hoặc các phương pháp tương tự để có ý tưởng về việc bạn sẽ phân chia bao nhiêu công việc, và chỉ sau đó bắt đầu chia các gói công việc thực tế với nhau .

Về cơ bản, điểm mấu chốt là: Không ai ở đây trên SE có thể trả lời câu hỏi đó cho bạn, cũng không có nhiều điểm cho nó, bởi vì sẽ tốt hơn nhiều nếu bạn đưa ra câu trả lời với tư cách là một đội.

Cách tiếp cận đơn giản nhất thường là tốt nhất.

Tôi sẽ tránh chia các nhiệm vụ thành các nhóm như kiểm tra / log / UI / etc trừ khi bạn có thể xác định một số lý do rất tốt và rõ ràng để làm việc đó. Lý do của tôi là khi bạn cho phép các lập trình viên làm việc bên ngoài các lĩnh vực chuyên môn thông thường của họ, nó có thể giữ cho mọi thứ thú vị và thách thức hơn đối với họ, và cho phép họ phát triển và phát triển trong lĩnh vực của họ. Nếu bạn cảm thấy rằng các hạn chế về thời gian yêu cầu bạn phân chia công việc dựa trên chuyên môn, thì ở mức tối thiểu, đảm bảo rằng mỗi nhà phát triển vẫn phải thực hiện kiểm tra đơn vị của riêng họ và sử dụng kiểm tra mã và kiểm tra chấp nhận để xử lý các vấn đề. Viết bài kiểm tra của riêng bạn là rất nhanh nhẹn và chờ đợi thời gian của người kiểm tra có sẵn có thể rất lãng phí.

Khi gặp phải vấn đề nan giải tương tự, tôi đã sử dụng cách tiếp cận sau:

• Phạm vi dự án. Cung cấp cho bạn một ý tưởng về những gì bạn đang tham gia và phát triển một danh sách các tính năng bằng cách chia dự án thành một loạt các nhiệm vụ.

• Ưu tiên các tính năng. Quyết định các tính năng phải được hoàn thành sớm và sẽ cung cấp giá trị ngay lập tức cho khách hàng của bạn. Đừng lo lắng nếu các nhà phát triển của bạn kết thúc làm việc trên cùng các mô-đun, nhưng hãy đảm bảo rằng bạn có một quy trình và công cụ tốt để quản lý việc hợp nhất mã.

• Để nhóm của bạn tham gia và yêu cầu các nhà phát triển của bạn hỗ trợ bạn chia nhỏ các tính năng thành một danh sách các nhiệm vụ dễ quản lý hơn. Xem lại như một nhóm và điều chỉnh các nhiệm vụ khi cần thiết để chúng có thể được ước tính dễ dàng hơn.

• Yêu cầu mỗi nhà phát triển chọn một nhiệm vụ để thực hiện - hoặc một nhóm các nhiệm vụ tùy thuộc vào cách lặp của bạn sẽ chạy - từ đầu hàng đợi ưu tiên, mà nhà phát triển muốn làm việc.

• Yêu cầu mỗi nhà phát triển chỉ làm một việc cho đến khi hoàn thành trước khi chuyển sang chọn mục tiếp theo từ đầu hàng đợi ưu tiên. Bạn có thể thỉnh thoảng muốn người của bạn thay đổi nhiệm vụ, tuy nhiên điều này sẽ dẫn đến lãng phí về thời gian của nhà phát triển. Nếu bạn thấy mình bị tắc nghẽn phụ thuộc, bạn sẽ cần điều chỉnh mức độ ưu tiên của nhiệm vụ và giảm thiểu lãng phí.

• Đừng sợ để các nhà phát triển chạy với các lần lặp chồng chéo và quản lý các bản phát hành của bạn tương ứng. Điều này sẽ giúp giảm thiểu thời gian lãng phí giữa các bản phát hành chờ nhiệm vụ hoàn thành.

Cuối cùng, trở thành Agile là tìm kiếm một giải pháp phù hợp với nhóm của bạn, công ty và khách hàng của bạn. Tùy thuộc vào bạn để điều chỉnh quy trình của mình bằng cách tìm sự cân bằng của các hoạt động sẽ phù hợp nhất với bạn. Làm thế nào để phân chia nhiệm vụ của bạn sẽ là một phần rất quan trọng của một quy trình lớn hơn nhiều, nhưng nên được giữ đơn giản như bạn có thể làm để khuyến khích sự tham gia sẵn sàng và để tránh khó giải quyết các vấn đề liên quan đến quá trình phát triển sau này.

Không có cuộc thảo luận tổ chức nhóm phát triển nào sẽ được hoàn thành mà không đề cập đến Nhóm phẫu thuật của Tiến sĩ Fred Brooks .

Công thức cơ bản là: một nhóm phẫu thuật cho mỗi đơn vị công việc

Xác định một đội phẫu thuật

Khái niệm về đội ngũ phẫu thuật dựa trên hai ý tưởng cơ bản:

1. Ít nhà phát triển tốt hơn trên mỗi đơn vị công việc vì nói chuyện chéo giết chết năng suất.
2. Các nhà phát triển đầu ra cao thực hiện các nhà phát triển đầu ra thấp (và theo Brooks, không có nhà phát triển đầu ra trung bình nào), vì vậy bạn nên giao cho họ công việc quan trọng nhất và hạn chế sự phân tâm của họ.

Một nhóm phẫu thuật bao gồm 3-10 nhà phát triển:

1. Một lập trình viên trưởng. Một nhà phát triển sản lượng cao, người thực hiện hầu hết các chương trình thực tế.
2. Một phi công phụ. Một nhà phát triển sản lượng cao khác, người thực hiện một số chương trình, nhưng cũng có một số nhiệm vụ quản trị, như tham dự các cuộc họp và thu thập các yêu cầu.
3. 1 - 8 trợ lý. Brooks mô tả những người này là nhà phát triển chịu trách nhiệm cho những thứ như tài liệu, dọn mã, nghiên cứu, viết công cụ / thuật toán, thử nghiệm, v.v. Quay lại thập niên 60 Brooks đề xuất chính xác 8 vai trò, nhưng với các công cụ hiện đại bạn có thể cần ít nhất là 1 hoặc 2, và có lẽ nên được chỉ định dựa trên nhu cầu của dự án của bạn.

Xác định đơn vị công việc

Vậy bây giờ chúng ta có thể tập hợp một đội, chúng ta sẽ phân công họ làm gì?

• Nếu dự án rất nhỏ , điều này là dễ dàng. Bạn chỉ định một nhóm phẫu thuật cho toàn bộ dự án.
• Mặt khác, sau đó bạn sẽ cần bắt đầu với một người hoặc nhóm chịu trách nhiệm về toàn bộ kiến trúc của dự án . Công việc của họ là mô đun hóa phần mềm một cách thích hợp để công việc có thể được phân chia giữa các nhóm phụ bổ sung. Nhóm ach architecture cũng có thể đảm nhận công việc khác, để không lan rộng các nhà phát triển quá mỏng.

Bạn sẽ thấy ba mẫu cơ bản, có thể chấp nhận được xuất hiện:

1. Chính xác 1 nhóm phụ cho mỗi lớp (UI, DAL, v.v.)
2. Chính xác 1 nhóm phụ cho mỗi mô-đun (Trang chủ, Trang web hỗ trợ, Cửa hàng)
3. Kết hợp cả hai (nhóm khung mức thấp và nhóm tập trung vào giao diện người dùng cho mỗi mô-đun)

Tùy thuộc vào số lượng nhà phát triển và mô-đun (và thời gian) tôi thường yêu cầu các nhà phát triển của mình chọn một mô-đun thú vị (cho họ) và một mô-đun đầy thách thức (tốt nhất là một cái gì đó họ chưa làm) và phần còn lại tôi chia ra theo cấp độ kỹ năng và hạn chế thời gian. Tôi thấy điều này mang lại cho các nhà phát triển của tôi một cái gì đó mà họ muốn làm việc và một cái gì đó để thúc đẩy họ.

Tất nhiên điều này không phải lúc nào cũng hoạt động ...

Đây là những gì tôi sẽ làm:

Nếu tất cả các mô-đun là nhỏ, thì bạn có thể cung cấp cho mỗi mô-đun để làm việc. Nếu không, hãy làm điều này:

1. Xác định từng kích thước mô-đun, độ phức tạp, kỹ năng cần thiết để làm điều đó.
2. Xác định kỹ năng từng thành viên trong nhóm.
3. Xác định những người làm việc tốt với nhau và những người không làm việc tốt với những người khác.
4. Chỉ định các mô-đun lớn cho các nhóm người phối hợp tốt dựa trên các yêu cầu kỹ năng mô-đun và kỹ năng nhóm.
5. Chỉ định các mô-đun còn lại cho những người không thể làm việc tốt với những người khác dựa trên yêu cầu kỹ năng mô-đun và kỹ năng nhóm.

Những điều trên sẽ không hiệu quả nếu những người không thích làm việc với người khác là những người thành thạo nhất và đây là trường hợp phổ biến, do đó, hãy tạo một ngoại lệ cho 4 và 5 tương ứng