Lập trình cặp với Scrum

Tôi thuộc nhóm hiện đang sử dụng Scrum và chúng tôi đang xem xét thêm lập trình cặp để giúp cải thiện các kỹ năng đa chức năng của nhóm, cũng như giúp giảm khuyết điểm với triết lý "hai đầu tốt hơn một".

Trong nhóm của chúng tôi, mỗi thành viên trong nhóm thường đăng ký một khối lượng công việc đầy đủ trong kế hoạch chạy nước rút (với "đầy đủ" là một số ít hơn 40 giờ một tuần, cho phép các cuộc họp, hợp tác, v.v.), với một chủ sở hữu chuyên dụng duy nhất cho mỗi công việc. Tôi tin rằng điều này khá phổ biến trong các nhóm Scrum nhưng có thể không nhất thiết phải bằng cuốn sách.

Đặc biệt, tôi đang tìm cách tránh tình huống các thành viên trong nhóm ngần ngại ghép đôi vì họ có nhiệm vụ riêng để giải quyết, điều mà tôi sợ có thể xảy ra nếu nhóm chỉ đơn giản là tự tổ chức mà không dành thời gian để ghép nối .

Vì điều này, cách tốt nhất để tính điểm nỗ lực / giờ / điểm câu chuyện trong kịch bản ghép nối là gì, để đảm bảo chúng tôi đã phân bổ thời gian thích hợp cho việc ghép nối?

Một số tùy chọn được xem xét là:

1. Cho phép hai người đăng ký cho mỗi nhiệm vụ và (gấp đôi) số giờ ước tính
2. Chỉ thành viên nhóm "trên bàn phím" đăng ký cho mỗi nhiệm vụ, được ước tính dựa trên số giờ ước tính của người đó. Bất cứ ai trong nhóm sẽ hỗ trợ ghép đôi sẽ đăng ký ít nhiệm vụ hơn trong lần chạy nước rút để có thời gian hỗ trợ ghép nối.

Tùy chọn phổ biến nhất mà tôi đã thấy khi lập trình cặp được sử dụng trong scrum là tăng gấp đôi các ước tính phát triển.

Nghĩa là, nếu nhiệm vụ ước tính mất 3 giờ cho một người, thời gian được phân bổ sẽ là 6 giờ cho cặp.

Thay thế giờ cho điểm nếu điều đó làm bạn cảm thấy sạch sẽ hơn;)

Tôi nghĩ rằng những người khác đã cung cấp câu trả lời tốt nhưng tôi sẽ chỉ thêm câu trả lời của tôi vì tôi nghĩ rằng nhóm của bạn mới chuyển sang Scrum và bây giờ các bạn ở vị trí rất giống chúng tôi khi chúng tôi bắt đầu.

Trước hết, phần giới thiệu của chúng tôi về Agile và cụ thể hơn là Scrum không được suôn sẻ cho lắm. Về cơ bản quản lý đã xuống và nói, từ ngày này trở đi, bạn sẽ làm Scrum và đây là một quá trình tất cả các bạn sẽ làm theo. Quá nhiều cho những người qua quá trình .

Quá trình ban đầu chúng tôi tuân theo (một cách mù quáng, tôi có thể thêm) kết thúc rất giống với cách bạn mô tả. Mọi người được giao nhiệm vụ, mọi người được đặt trước và tất cả chúng tôi quay trở lại bàn của chúng tôi và cắm đi. Sau đó, chúng tôi có một cuộc họp độc lập nhàm chán mỗi ngày.

Chìa khóa để nhận ra là Agile và Scrum bao gồm, thực sự là về con người. Khi nhóm đi vào lập kế hoạch lặp lại, đừng để chủ Scrum của bạn (có lẽ là người quản lý của bạn) phân công cho bạn giờ, câu chuyện và nhiệm vụ. Nó hoàn toàn LÊN TỚI NHÓM. Tôi nghĩ rằng đối với nhiều người, đây là một khái niệm rất khó để vượt qua bởi vì trong nhiều năm trước khi họ đi làm và họ sẽ có một ông chủ (quản lý, lãnh đạo kỹ thuật ...) chỉ đơn giản là giao việc. Họ lao vào Scrum nhưng tất cả mọi người (kể cả chính ông chủ Scrum) vẫn tiếp tục hoạt động trong cùng một chế độ.

Một ngày nào đó, bạn sẽ phát ốm vì điều này, vì vậy bạn sẽ bắt đầu đọc sách, blog và tiếp tục đặt câu hỏi như thế này trên trao đổi ngăn xếp. Nhận thức mà bạn sẽ nhận được là bạn với tư cách là nhà phát triển và đồng đội của bạn sẽ là động lực thúc đẩy các câu chuyện và phân công nhiệm vụ. Nếu các bạn cảm thấy bạn sẽ được hưởng lợi từ lập trình cặp, bằng mọi cách, hãy tạo 2 nhiệm vụ cho mỗi kỹ sư và chỉ định cả hai giờ. Điều duy nhất mà bậc thầy scrum nên làm là đo vận tốc đối với những câu chuyện đã hoàn thành mà bạn đã gửi NHƯ MỘT NHÓM trong lần lặp trước.

Ngoài ra, một điều nữa làm tôi khó chịu là cách mọi người nói rằng năng lực của họ LUÔN 75% tổng số giờ, vì vậy đó là những gì họ cam kết và sau đó trong toàn bộ thời gian lặp đi lặp lại, họ phàn nàn rằng a) họ không thể giúp bạn hoặc b) họ không thể làm điều đúng vì họ đã được chỉ định quá nhiều giờ. Mọi người không nên nói bao nhiêu giờ để cam kết và họ chắc chắn nên đẩy lùi nếu chủ scrum đang cố gắng kéo một cái gì đó như thế này! Mọi người nên cam kết chính xác những gì họ cảm thấy thoải mái. Ví dụ: tôi là trưởng nhóm và thường xuyên kết thúc cuộc thảo luận thiết kế không có kế hoạch ngẫu nhiên hoặc giúp ai đó viết mã hoặc khắc phục sự cố những thứ kỳ lạ, vì vậy khả năng của tôi không bao giờ vượt quá 50%.

Phải mất 4 chu kỳ phát hành nhóm của chúng tôi để học cách không làm những điều tôi vừa đề cập và mặc dù chúng tôi chắc chắn đã tiến bộ, nếu bạn hỏi các chuyên gia, chúng tôi thậm chí không nhanh nhẹn một nửa. Vì vậy, vẫn còn rất nhiều việc để làm.

Cập nhật 1: Phản hồi bình luận của Cliff Vâng, bạn đã đưa ra đôi tai của mình vì vậy đây là ...

Bạn nói đúng, sự thay đổi văn hóa là chìa khóa, nhưng sự thay đổi này không cần phải xảy ra ở cấp điều hành. Quản lý nhóm của riêng bạn có thể thay đổi văn hóa trong nhóm của bạn và cách ly các bạn khỏi BS công ty mà anh ta phải đối phó. Những gì bạn đang mô tả là CHÍNH XÁC chúng tôi về từ năm 2007 đến năm 2010. Nhóm của chúng tôi (và các đội khác cũng vậy) đã phát hành sau khi phát hành. Trong một trong những bản phát hành sử dụng "quy trình nhanh nhẹn" của ban quản lý, chúng tôi quản lý để có 9 người tạo ra công việc thường sẽ được thực hiện bởi một người và chúng tôi đã mất gấp đôi thời gian. Tôi đã có rất nhiều thời gian rảnh, thậm chí tôi còn cập nhật sơ yếu lý lịch của mình.

Sau đó, tôi đã có một cuộc trò chuyện với sếp của tôi và giải thích tất cả những điều này cho anh ấy về sự nhanh nhẹn của mọi người và nếu bạn muốn chúng tôi quan tâm đến sản phẩm, hãy để chúng tôi đưa ra quyết định ảnh hưởng đến cách chúng tôi làm việc và giao sản phẩm. Tôi nghĩ anh ấy đã quyết định biến nó thành một thử nghiệm từ nó, anh ấy đã thực hiện mọi thay đổi duy nhất chúng tôi ... tốt, chủ yếu là bản thân tôi, nhưng tôi nói chuyện với phần còn lại của đội rất nhiều, do đó 50% khả năng :) ... đề xuất. Có thể anh ta nhận ra rằng nếu anh ta thực hiện tất cả những thay đổi mà chúng tôi đang yêu cầu và chúng tôi vẫn thất bại, anh ta sẽ trở lại với một chiến thắng "Tôi đã nói với bạn như vậy".

Vì vậy, trong 12 tháng qua, chúng tôi đã loại bỏ rất nhiều "sự ngu ngốc", điều đó thậm chí không buồn cười. Các cuộc họp độc lập của chúng tôi thực sự có ý nghĩa bởi vì chúng tôi làm việc cùng nhau, không phải trong sự cô lập. Chúng tôi vẫn có quyền sở hữu (ít nhất là bây giờ) đối với các bộ phận cụ thể của sản phẩm, nhưng chúng tôi cũng rất thường xuyên chuyển sang mã của nhau. Chúng tôi liên tục thực hiện đánh giá mã để không chỉ các thành viên trong nhóm học mã khác mà còn học các kỹ thuật thiết kế và mã hóa tốt hơn. Chúng tôi đã chia nhóm nguyên khối, "nhanh nhẹn" thành 3 nhóm khác nhau nên kế hoạch và các cuộc họp khác ngắn hơn nhiều và mọi người thực sự quan tâm đến họ vì họ không ngồi lại và lắng nghe những điều họ không quan tâm. TÔI' Đã thấy đêm khi 4 trong số 5 người của chúng tôi (một trong các đội) sẽ trực tuyến vào lúc 11 giờ tối vào ban đêm và không ai thực sự nói với chúng tôi rằng chúng tôi phải làm việc chăm chỉ hoặc gây áp lực cho chúng tôi để làm việc hơn 40 giờ. Những người không thể quan tâm ít hơn nửa năm trước, đột nhiên tham gia và hào hứng với công việc họ đang làm. Và tất cả những gì người quản lý của chúng tôi làm là nói, "các bạn quyết định điều gì là đúng và làm những gì bạn cần làm và tôi sẽ giữ BS của công ty ra khỏi đội nhiều nhất có thể."

Nó bắt đầu như một thử nghiệm (sự nghi ngờ của tôi, anh ấy không bao giờ nói với tôi điều đó), nhưng bây giờ nhóm của chúng tôi đang đá mông so với các nhóm phát triển khác trong bộ phận và chúng tôi thậm chí còn có những nhà phát triển khác đang cố gắng đến và tham gia cùng chúng tôi.

Rào cản lớn nhất đối với chúng tôi kể từ khi thay đổi này xảy ra (và vẫn còn là một vấn đề ngày nay) là việc các kỹ sư trong môi trường công ty bình thường giống như những con chuột thí nghiệm trong chuồng. Ngay cả khi người quản lý của bạn quyết định thực sự "nhanh nhẹn" và tháo lồng, mọi người đã ở trong chuồng đó quá lâu, họ thậm chí không nhận ra họ đang rảnh. Vì vậy, ngay cả với tất cả sự tự do, họ vẫn tiếp tục hành động như thể họ vẫn bị hạn chế. Tôi nghĩ những gì sẽ giúp là có ít nhất vài người trong nhóm (chẳng hạn như chính bạn), những người đi ra ngoài ranh giới của nhóm và tìm kiếm những cách tốt hơn để làm việc. Sau đó quay trở lại vào nhóm đó và khuấy động lên một chút.

Trong trường hợp của bạn, có thể lập trình được ghép nối không phải là một giải pháp nếu bạn đang tìm kiếm một lực lượng bên ngoài khác để xuống đội và cho họ biết cách làm việc. Thay vào đó, hãy vứt bỏ các quy tắc, ngồi xuống với họ, không cần quản lý và hỏi họ muốn làm gì? Điều gì sẽ làm cho họ hạnh phúc? Năng suất? Xác định các vấn đề lớn nhất và sau đó hỏi NHÓM họ nghĩ giải pháp nên là gì.

Scrum không bắt buộc các nhiệm vụ được giao cho các cá nhân - cách xa nó. Trách nhiệm cho các nhiệm vụ phải hoàn thành thuộc về toàn đội. Nếu nhóm muốn lập trình cặp, trong đó mỗi cặp chọn một nhiệm vụ, chắc chắn họ nên làm như vậy.

Từ Hướng dẫn Scrum :

Nhóm phát triển thường bắt đầu bằng cách thiết kế hệ thống và công việc cần thiết để chuyển đổi Product Backlog thành gia tăng sản phẩm hoạt động. Công việc có thể có kích thước khác nhau, hoặc nỗ lực ước tính. Tuy nhiên, đủ công việc được lên kế hoạch trong cuộc họp Lập kế hoạch Sprint cho Nhóm phát triển để dự báo những gì họ tin rằng họ có thể làm trong Sprint sắp tới. Công việc được lên kế hoạch cho những ngày đầu tiên của Sprint bởi Nhóm phát triển được phân tách thành các đơn vị từ một ngày trở xuống vào cuối cuộc họp này. Nhóm Phát triển tự tổ chức để thực hiện công việc trong Sprint Backlog , cả trong Cuộc họp Lập kế hoạch Sprint và khi cần trong suốt Sprint.

Phân công nhiệm vụ trong cuộc họp lập kế hoạch là chính xác những gì đi ngược lại với quyết định thời gian và trao quyền cho nhóm. Nó cũng đi ngược lại sự nhanh nhẹn của nước rút bởi vì từ ngày đầu tiên trong cuộc đua nước rút, mọi nhà phát triển đã căn chỉnh chính xác những gì anh ta nên làm. Điều đó cũng có nghĩa là mọi nhiệm vụ phải được ước tính rất chính xác, điều gần như không bao giờ xảy ra.

Nhiệm vụ ước tính Imho là dư thừa. Bạn đã cam kết tập hợp các câu chuyện và lên kế hoạch cho cuộc họp 2 chỉ đủ thời gian để chia những câu chuyện đó thành các nhiệm vụ và tạo thẻ cho các nhiệm vụ đó (hoặc điền chúng vào một số hệ thống). Không có đủ thời gian để ước tính từng nhiệm vụ và những ước tính này không nên tiêu tốn thời gian để phát triển thực sự.

Tại sao? Ước tính là một rác. Làm thế nào nó có thể là một rác? Bởi vì ước tính nhiều hơn sẽ không mang lại nhiều giá trị kinh doanh hơn = đó là rác và nên được giảm đến mức tối thiểu cần thiết. Tối thiểu là ước tính / định cỡ các câu chuyện giúp bạn thực hiện cam kết. Khi bạn đã thực hiện một cam kết, bạn không cần bất kỳ ước tính nào khác. Bạn chỉ cần biết rằng bạn có ngày cố định để cung cấp một cái gì đó bạn đã cam kết. Bạn sẽ có thể cung cấp những câu chuyện cam kết hoặc không. Ước tính nhiệm vụ sẽ không giúp bạn trong việc giao hàng đó.

Bỏ qua ước tính nhiệm vụ sẽ không ảnh hưởng đến khả năng hiển thị trong tiến trình nước rút bởi vì phép đo thực sự duy nhất của tiến trình là số lượng câu chuyện đã hoàn thành (điểm câu chuyện) và điều đó vẫn có thể được hiển thị trong biểu đồ đốt nước rút.

Chỉ để làm cho nó rõ ràng. Cam kết có nghĩa là = Chúng tôi sẽ làm điều đó . Không phải chúng tôi sẽ cố gắng để làm điều đó hoặc bất cứ điều gì khác. Có, bạn có thể không cung cấp những gì bạn đã cam kết nhưng cam kết của bạn nên dựa trên niềm tin của bạn rằng với kiến ​​thức hiện tại của bạn, bạn sẽ cung cấp các câu chuyện được chọn. Nếu bạn có niềm tin này, bạn không cần một ước tính khác.

Tôi luôn sử dụng Scrum theo cách mà nhà phát triển chọn một nhiệm vụ mới sau khi anh ta hoàn thành nhiệm vụ cuối cùng. Các nhà phát triển thường nói rằng họ sẽ chọn cái nào trong cuộc họp độc lập. Nói chung không có quy tắc nào anh nên chọn. Tùy thuộc vào việc tự tổ chức nhóm và thảo luận giữa các thành viên trong nhóm (bên ngoài cuộc họp độc lập). Đó là hoãn quyết định đến điểm mới nhất có thể, nơi bạn có thể phản ứng về một số thay đổi và vấn đề mà không ảnh hưởng đến kế hoạch tưởng tượng của bạn. Bản thân tác vụ thậm chí có thể thay đổi chủ sở hữu nếu ai đó có một số vấn đề cần hoàn thành - thay vào đó, nhiệm vụ đó có thể được phát triển theo cặp.

Làm thế nào để lập trình cặp có thể tham gia vào điều này? Dễ dàng. Nhóm thực hiện cam kết và nhóm phải thực hiện theo cách tạo không gian cho tất cả các kỹ thuật phát triển cần thiết để cung cấp mức tăng làm việc của sản phẩm. Bạn có ước tính một nhiệm vụ hoặc phát triển nhiệm vụ và kiểm tra nhiệm vụ? Cách tiếp cận thứ hai là hoàn toàn sai. Việc kiểm tra là một phần của sự phát triển và theo cách tương tự, việc xem xét hoặc ghép mã là một phần của sự phát triển nếu cần.

Thực hiện lập trình cặp sẽ giúp hoàn thành nhiệm vụ nhanh hơn với số lượng lỗi nhỏ hơn và chất lượng mã tốt hơn. Nó sẽ không nhanh gấp đôi vì vậy vẫn sẽ có một số chi phí nhưng tác động thực sự đối với cam kết gây ra bởi việc ghép đôi thường xuyên là rất nhỏ. Đây không phải là một trường hợp để cố vấn hoặc giảng dạy. Nếu bạn có nhà phát triển như vậy cần được cố vấn hoặc dạy, bạn không nên lập kế hoạch cho năng lực của anh ấy để chạy nước rút, nơi anh ấy học cơ sở mã của sản phẩm hoặc một số công nghệ.