Trong quá trình phát triển Agile, ai là người sở hữu phần mềm, có các tính năng, và bạn quản lý sự phát triển như thế nào?

Một số nhóm phát triển trong công ty của tôi đang chuyển sang thực hành phát triển Agile và công việc của các nhà phát triển của họ dường như đang giảm dần để thảo luận và lập trình các chi tiết nhỏ về các tính năng phần mềm tầm thường vì chu kỳ lặp hai tuần. Và cũng vì tâm lý "bất kỳ nhà phát triển nào cũng có thể sửa bất kỳ lỗi nào". Gần đây tôi đã gia nhập một trong những đội đó, chuyển từ một đội khác trong cùng công ty ...

Tôi cảm thấy mạnh mẽ rằng các nhà phát triển nên sở hữu các tính năng phần mềm của họ từ đầu (thiết kế) đến kết thúc (thực hiện và thử nghiệm đơn vị). Agile dường như đang đi ngược lại với suy nghĩ này. Có bất kỳ sự thật nào đối với nhận thức của tôi hay tôi chỉ đang sống một triển khai xấu của Agile?

Trong hai lần lặp lại của chúng tôi, mọi người có thể tùy ý nhận các tính năng nhỏ và sửa lỗi mới, tùy thuộc vào khối lượng công việc của họ trong chu kỳ đó. Dường như không ai chịu trách nhiệm về các tính năng chính của phần mềm. Chúng tôi dành thời gian ngu ngốc cho những việc nhỏ nhặt, như thêm một nút duy nhất vào hộp thoại trong vòng lặp hai tuần, hoàn thành với một câu chuyện, scrums hàng ngày, đánh giá mã, v.v.

Vậy trong các dự án Agile, làm thế nào để quản lý các tính năng lớn hơn? Ai sở hữu trách nhiệm: nhà phát triển cá nhân hoặc toàn đội? Làm thế nào để một người trích xuất anh ấy / cô ấy từ minutia và tập trung vào các mục tiêu dài hạn? Bất kỳ thông tin phản hồi sẽ có giá trị.

Nếu bạn nghĩ rằng điều đó sẽ giúp ích cho nỗ lực của nhóm, bạn không nên ngần ngại làm dịu tâm lý "bất kỳ nhà phát triển nào cũng có thể khắc phục bất kỳ lỗi nào" mà bạn thấy là đang tạo ra vấn đề.

Việc thực hành Collective Code Ownership, đôi khi cũng được gọi Shared Codelà một nguyên tắc cơ bản trong nhiều hương vị của sự phát triển Agile và có lẽ đó là những gì bạn đang trải nghiệm:

Từ extremeprogramming.org :

Quyền sở hữu tập thể khuyến khích mọi người đóng góp ý tưởng mới cho tất cả các phân khúc của dự án. Bất kỳ nhà phát triển nào cũng có thể thay đổi bất kỳ dòng mã nào để thêm chức năng, sửa lỗi, cải thiện thiết kế hoặc cấu trúc lại. Không ai trở thành cổ chai cho những thay đổi.

Từ c2.com :

ExtremeProgramming coi mã thuộc về dự án, không thuộc về một kỹ sư riêng lẻ. Khi các kỹ sư phát triển chức năng cần thiết, họ có thể duyệt và sửa đổi bất kỳ lớp nào. Họ chịu trách nhiệm duy trì tất cả các UnitTests hoạt động (và viết những cái mới cho chức năng mới). Họ đảm nhận các nhiệm vụ bảo vệ tính toàn vẹn giống như chủ sở hữu lớp trong tình huống CodeOwnership.

Làm việc trong chế độ này cho phép một nhóm có trách nhiệm di chuyển nhanh chóng để thêm chức năng mới trong khi vẫn giữ trách nhiệm trong các đối tượng phù hợp. CodeOwnership tạo ra sự phụ thuộc và tắc nghẽn khi triển khai UserStories. Chúng tôi tránh quyền sở hữu mã, vì nó mâu thuẫn với cam kết từ PlanningGame. ("Mã là không có gì, câu chuyện là tất cả!")

Có một số lợi ích nhất định Collective Code Ownership. Tuy nhiên, bạn không phải là người đầu tiên ghi nhận những thiếu sót trong cách tiếp cận đó . Không ai khác ngoài Martin Fowler mô tả một cách tiếp cận nằm giữa các thái cực của Strong Code Ownership(nơi các cá nhân "sở hữu" các mô-đun của họ) và Collective Code Ownership. Ông mô tả đây là quyền sở hữu mã yếu :

Quyền sở hữu mã yếu tương tự [với Quyền sở hữu mã mạnh] ở chỗ các mô-đun được gán cho chủ sở hữu, nhưng khác ở chỗ các nhà phát triển được phép thay đổi các mô-đun do người khác sở hữu. Chủ sở hữu mô-đun dự kiến ​​sẽ chịu trách nhiệm về các mô-đun họ sở hữu và theo dõi những thay đổi do người khác thực hiện. Nếu bạn muốn thực hiện một thay đổi đáng kể cho mô-đun của người khác, trước tiên hãy nói chuyện với chủ sở hữu mô-đun.

Trong cùng một bài viết, ông tiếp tục nói:

Sự lựa chọn giữa sở hữu tập thể yếu và tập thể có liên quan nhiều hơn đến động lực xã hội của đội. Cả hai dường như làm việc, và thất bại, tốt như nhau. Cá nhân tôi thích sự năng động của một nhóm sở hữu mã tập thể - đặc biệt là trong bối cảnh Lập trình cực đoan.

Điểm mấu chốt là để thực sự tuân thủ các nguyên tắc Agile, nhóm nên làm những gì dẫn đến mã làm việc chất lượng tốt. Nếu điều đó có nghĩa là nới lỏng sự kìm kẹp Collective Code Ownership, thì không có gì sai (hoặc chống Agile) về điều đó.

Để trả lời câu hỏi của bạn, tôi sẽ thử và đưa ra một mô tả về cách chúng tôi xử lý các tình huống được đề cập trong câu hỏi của bạn:

Chúng tôi sử dụng khung Scrum trong Agile. Lập kế hoạch Sprint và các phiên chải chuốt tồn đọng hỗ trợ nhóm của chúng tôi chia nhỏ, những câu chuyện được xác định tương đối đúng.

Tất cả trong một nhóm nói chung chịu trách nhiệm về kết quả của các cam kết cho một lần chạy nước rút (tất cả các câu chuyện). Họ thành công hoặc thất bại như một đội. Do đó, toàn bộ nhóm sẽ ảnh hưởng đến cách quản lý công việc để hoàn thành công việc trong giai đoạn nước rút.

Thẻ câu chuyện được lấy bởi một nhà phát triển (trong phần nổi bật) trở thành trách nhiệm của nhà phát triển đó là hoàn thành và ký tắt, sẵn sàng để phát hành vào cuối giai đoạn nước rút. Tuy nhiên, nhóm nên sử dụng các bản dựng đứng hàng ngày để xem có ai đang vật lộn với câu chuyện của họ không và sau đó tiến hành hỗ trợ nhà phát triển hoàn thành nhiệm vụ xuất sắc của mình.

Trong trường hợp của chúng tôi, với Scrum, nếu bất cứ điều gì được trao cho chúng tôi mà không phải là một phần của cam kết chạy nước rút ban đầu, chúng tôi sẽ thêm vào đó là 'công việc không có kế hoạch' và chủ sở hữu sản phẩm của chúng tôi biết rằng nỗ lực không có kế hoạch được thêm vào có thể dẫn đến các cam kết ban đầu của chúng tôi không được đáp ứng. Chúng tôi cũng có một cấu trúc phẳng trong nhóm, để không ai phải đóng vai trò quản lý và mọi người sau đó có động lực để không để nhóm thất bại vì mọi người đều có trách nhiệm như nhau đối với công việc.

Chủ sở hữu sản phẩm sở hữu những gì . Anh ấy chịu trách nhiệm quyết định những mặt hàng nào của Product Backlog trước các mặt hàng khác và anh ấy có trách nhiệm giao sản phẩm dựa trên tổng tài nguyên có sẵn đúng hạn .

Scrum đội (bao gồm cả chủ sở hữu sản phẩm, và làm chủ scrum) chịu trách nhiệm như thế nào phần. Họ nên quyết định cách quản lý nhóm, chia sẻ kiến ​​thức, tự tổ chức, gặp gỡ hàng ngày (đứng lên hàng ngày), sửa đổi bản thân (cuộc họp hồi cứu), có các nguồn lực đa chức năng, v.v.

Ý tưởng này không phải là sở hữu một tính năng, vì các bên liên quan sở hữu các tính năng đó, không phải tôi và bạn.

Cách tôi làm, với mức độ đau đớn thấp, là để mỗi nhà phát triển chịu trách nhiệm về một thẻ trên bảng, từ khi nó được chọn từ danh sách TODO cho đến khi nó được chuyển sang DONE. Chủ sở hữu của tính năng, theo như những gì chức năng đi vào tính năng là Trưởng nhóm, SME và BA. Mỗi nhóm có một Trưởng nhóm (chuyên gia kỹ thuật và người ủng hộ), Chuyên gia về Chủ đề và Chuyên viên Phân tích Kinh doanh.

Thông thường, BA là anh chàng / cô gái đưa ra các câu hỏi từ nhà phát triển hiện đang làm việc trên thẻ. Tất cả chúng tôi đều làm việc trong cùng một phòng, vì vậy, nếu Trưởng nhóm (tôi), BA hoặc SME nghe thấy điều gì đó mà chúng tôi không đồng ý, chúng tôi sẽ nhảy vào và đưa nhà phát triển vào một phòng đột phá để thảo luận thêm. Thông thường, ba chúng tôi sẽ đưa các thành viên của ba người kia vào nếu chúng tôi cảm thấy họ có thể có giá trị cho cuộc thảo luận.

Phải thừa nhận rằng đôi khi nó dẫn đến lãng phí thời gian trong khi chúng ta thảo luận về một vấn đề, nhưng nhìn chung chúng ta nhanh chóng có được một giải pháp tốt.

Cuối cùng, Trưởng nhóm ký kết các mục tồn đọng là sẵn sàng để phát triển và chính nhóm trưởng có tiếng nói cuối cùng khi cần đưa ra quyết định và chịu trách nhiệm nếu việc thực hiện là "sai". (Đừng hỏi về trò chơi đổ lỗi "sai": /).

Bất kỳ nhà phát triển nào khác nghe cuộc trò chuyện đều được khuyến khích cung cấp đầu vào và tất cả các thành viên trong nhóm có đầu vào trong thời gian giới thiệu ở cuối giai đoạn nước rút, khi các tính năng mới được trình diễn.

tl; dr (đối với chúng tôi): Trưởng nhóm sở hữu các tính năng và một nhà phát triển cá nhân làm việc trên thẻ tính năng (hoặc lỗi, cải thiện, nợ kỹ thuật, v.v.) từ khi bắt đầu chấp nhận bởi nhóm thử nghiệm).

Vấn đề đầu tiên tôi thấy là quá trình ước tính sẽ hơi rộng. Có, các nhà phát triển nên có tiếng nói về số lượng công việc họ dự kiến ​​sẽ đảm nhận. Không, điều đó không có nghĩa là việc thêm một nút vào biểu mẫu web hiện là câu chuyện hai tuần của nhà phát triển (tuy nhiên nhiều điểm tương đương với quy trình ước tính của doanh nghiệp của bạn). Nếu đó là tình trạng hiện tại, thì bạn với tư cách là người quản lý dự án sẽ thực hiện một số phỏng đoán thứ hai.

Thứ hai, tôi nghe "từ bắt đầu (thiết kế) đến kết thúc (thực hiện và kiểm tra đơn vị)" và ý nghĩ đầu tiên xuất hiện trong đầu là "bạn đang làm sai". Các bài kiểm tra đơn vị của bạn là một phần trong công việc thiết kế của bạn với tư cách là nhóm phát triển / nhóm phát triển và nên xảy ra trước tiên; bạn thực hiện các yêu cầu cơ bản, chắt lọc chúng thành một "danh sách kiểm tra" đơn giản của "Nếu ... Khi ... Sau đó ..." - gõ các câu, sau đó chuyển đổi các câu đó thành một loạt các bài kiểm tra cơ bản khẳng định chương trình đáp ứng các câu đó khẳng định và do đó các yêu cầu. Điều đó xảy ra trước khi bạn viết một dòng mã sản xuất sẽ đáp ứng các xác nhận của các thử nghiệm. Nếu kiểm tra đơn vị của bạn đến lần cuối, sau khi bạn đã triển khai phần mềm, bạn sẽ mất một số khía cạnh chính của kiểm tra đơn vị; nói chung, các nhà phát triển của bạn không thể "lập trình thành màu xanh",

Theo như các nhà phát triển "sở hữu" các tính năng của họ, thì có và không có. Trước hết, một sự lột xác khá phổ biến từ "các đội tự tổ chức" là xu hướng các nhà phát triển đi theo cặp hoặc ba và làm việc trên những điều họ biết rõ nhất. Giả sử bạn có một bộ chuyên môn tốt về nhà phát triển để nhóm có thể bao quát tất cả các công việc phải hoàn thành trong mỗi lần lặp theo cách này, bạn chỉ cần để điều này xảy ra; đó là một điều tốt cho vận tốc, vì các nhà phát triển tập trung vào và làm quen với các lĩnh vực của cơ sở mã mà họ đã làm việc từ lần lặp đến lần lặp.

Tuy nhiên, một nhà phát triển sở hữu một tính năng cho cuộc sống là một suy nghĩ nguy hiểm, bởi vì nó làm giảm "số xe tải" của nhóm của bạn (được định nghĩa rất thẳng thắn là "có bao nhiêu người có thể bị xe tải đâm trước khi nhóm không thể hoạt động, vì Trường hợp xấu nhất của những người cụ thể bị ảnh hưởng và mất kiến ​​thức). Nếu một người mà bạn đã gán tính năng "Nhập tệp" cho phần mềm của bạn và đã sở hữu nó trong 2 năm, sẽ nghỉ phép trong ba tuần, nghỉ phép FMLA kéo dài, thay đổi công việc, hoặc cực kỳ, thực sự bị xe tải đâm chết, bây giờ bạn không có ai biết tính năng đó bởi vì khu vực đó của codebase đã là mục đích độc quyền của một chàng trai trong nhiều năm. với đoạn mã đặc biệt này,bạn sẽ mất đi vận tốc đáng kể, và bạn cũng sẽ mở ra cho mình thêm những vấn đề với khiếm khuyết, vì anh chàng mới chỉ quen với cách thức hoạt động của codebase bây giờ có thể vẫn không biết gì về những thứ anh ta có thể và không thể thay đổi trong đó .

Thay vào đó, bạn nên tìm cách nuôi dưỡng một bộ phận lao động giữ số lượng xe tải của bạn ít nhất là 2 hoặc cao hơn, và trong một đội lớn hơn (một tá hoặc nhiều hơn) gần hơn với 3 hoặc 4. Cách đó nếu một anh chàng không thể làm được việc , vì bất kỳ lý do gì, có một số người khác có thể nhảy vào. Đôi khi, các đội chỉ tự nhiên bắt đầu theo cách này, đặc biệt nếu bạn mang theo một vài kỹ thuật XP như lập trình theo cặp hoặc dojo (một anh chàng viết theo khẳng định mới theo các yêu cầu mà mã không đáp ứng, anh chàng tiếp theo mã sẽ vượt qua bài kiểm tra đó, sau đó thêm một xác nhận yêu cầu khác không thành công và vượt qua nó). Theo định nghĩa trong những tình huống này, bạn có nhiều con mắt nhìn vào mã, phát triển nó, làm quen với nó.

Nhìn chung, ý tưởng của Agile là thúc đẩy sự phát triển "nhẹ". Nhóm của bạn dường như bị sa lầy vào các quy trình và tài liệu nhỏ, khi trọng tâm chính, theo Tuyên ngôn Agile, nên tập trung vào các thành viên trong nhóm và các tương tác của họ, và tất nhiên là làm việc, mã chức năng. Các quy trình vốn có trong Agile là một phương tiện để kết thúc và không có cách nào để theo Agile; ngay cả các khung Agile chính như SCRUM cũng có thể linh hoạt dựa trên nhu cầu của bạn như một công ty, một nhóm và thậm chí từ ngày này sang ngày khác (chỉ cần đảm bảo giữ các ý tưởng cơ bản về các giá trị được cung cấp bởi các quy trình này khi thực hiện các thay đổi đó).

Quy trình Agile được xác định bởi nhóm cho nhóm theo hướng dẫn và nó có thể khác nhau từ nhóm này sang nhóm khác. Trong hầu hết các trường hợp, tôi đã không thấy hai đội khác nhau phản ánh cùng một quy trình trong kinh nghiệm chuyên môn của tôi. Về cơ bản, ý tưởng là để có sự phát triển hiệu quả nhất, trong một số trường hợp có nghĩa là những người khác nhau làm việc trên các tính năng trong cùng một cơ sở mã và trong các trường hợp khác, một người là chủ sở hữu tính năng từ đầu cho đến khi tính năng hoàn tất.

Về cơ bản các tính năng lớn hơn (hãy gọi chúng là các câu chuyện của người dùng) có thể được chia thành các câu chuyện người dùng nhỏ hơn và vẫn là một và cùng một người có thể là chủ sở hữu của tính năng truyền bá các câu chuyện người dùng đó qua nhiều lần chạy nước rút. Cũng theo đó, người đó có thể là chủ sở hữu tính năng và không thực hiện tất cả công việc cho tính năng đó. Ví dụ

Kịch bản:

• Tính năng lớn ước tính mất 6 tuần (3 lần chạy nước rút).
• Tính năng này được chia thành nhiều câu chuyện của người dùng, mỗi câu chuyện mất tới hai ngày.
• Các câu chuyện của người dùng bao gồm phát triển tính năng, kiểm tra đơn vị, kiểm tra tương tác, tích hợp (với các tính năng khác) và kiểm tra tích hợp

Nhóm về mặt kỹ thuật là chủ sở hữu tính năng nhưng nhà phát triển có thể hành động như một.

• Nhà phát triển viết chức năng
• Nhà phát triển viết bài kiểm tra đơn vị
• Một kỹ sư chất lượng viết tự động hóa
• Một nhà phát triển khác đảm bảo tích hợp

Trong kịch bản này, có ít nhất 3 người (chúng tôi có thể có nhiều hơn một QE đang làm nhiệm vụ) chịu trách nhiệm phân phối tính năng nhưng nhà phát triển đang sở hữu và theo nghĩa là điều khiển tính năng này. Tất nhiên, điều này đòi hỏi sự cống hiến nhiều hơn cho tính năng cụ thể này từ phía nhà phát triển nhưng không có ý nghĩa gì ngoài phạm vi Agile và đồng thời chúng tôi có chủ sở hữu tính năng duy nhất.