Làm thế nào chúng ta có thể làm cho nhanh nhẹn thú vị cho các nhà phát triển thích cá nhân, độc lập sở hữu khối lớn từ đầu đến cuối

Chúng ta đang ở giữa chừng trong quá trình chuyển đổi từ thác nước sang nhanh nhẹn bằng cách sử dụng scrum; chúng tôi đã thay đổi từ các đội lớn trong các silo công nghệ / kỷ luật sang các nhóm chức năng chéo nhỏ hơn.

Như mong đợi, sự thay đổi thành nhanh nhẹn không phù hợp với tất cả mọi người. Có một số nhà phát triển đang gặp khó khăn trong việc điều chỉnh để nhanh nhẹn. Tôi thực sự muốn giữ cho họ tham gia và thử thách, và cuối cùng thích đến làm việc mỗi ngày. Đây là những người thông minh, vui vẻ, có động lực mà tôi tôn trọng ở cả mức độ cá nhân và chuyên nghiệp.

Vấn đề cơ bản là: Một số nhà phát triển chủ yếu được thúc đẩy bởi niềm vui khi nhận được một phần công việc khó khăn, suy nghĩ thông qua thiết kế, suy nghĩ thông qua các vấn đề tiềm năng, sau đó giải quyết vấn đề từng mảnh, chỉ với sự tương tác tối thiểu với những người khác, qua một phần mở rộng khoảng thời gian. Họ thường hoàn thành công việc với chất lượng cao và kịp thời; công việc của họ là duy trì và phù hợp với kiến ​​trúc tổng thể. Chuyển sang một nhóm đa chức năng coi trọng sự tương tác và chia sẻ trách nhiệm trong công việc và phân phối chức năng làm việc trong khoảng thời gian ngắn hơn, các nhóm phát triển sao cho toàn bộ nhóm giải quyết vấn đề khó khăn đó. Nhiều người thấy đây là một thay đổi tích cực; ai đó thích đưa ra một vấn đề và sở hữu nó một cách độc lập từ đầu đến cuối sẽ mất cơ hội làm việc như thế.

Đây không phải là một vấn đề với những người cởi mở để thay đổi. Chắc chắn chúng tôi đã thấy một vài người không thích thay đổi, nhưng trong trường hợp tôi quan tâm, các cá nhân là những người thực hiện tốt, thực sự cởi mở để thay đổi, họ nỗ lực, họ thấy phần còn lại của đội là như thế nào thay đổi và họ muốn hòa nhập. Đó không phải là trường hợp ai đó khó tính hay cản trở, hoặc muốn tích trữ công việc ngon nhất. Họ không tìm thấy niềm vui trong công việc như trước đây.

Tôi chắc rằng chúng ta không thể là nơi duy nhất không gặp phải vấn đề này. Làm thế nào những người khác đã tiếp cận điều này? Nếu bạn là một nhà phát triển được thúc đẩy bằng cách sở hữu cá nhân một khối lượng lớn công việc từ đầu đến cuối và bạn đã điều chỉnh theo một cách làm việc khác, thì điều đó đã giúp gì cho bạn?

Tôi sẽ nói rằng có rất ít cửa hàng phần mềm may mắn có được sự khác biệt hiếm có trong đó Agile thực sự không có ý nghĩa như một phương pháp. Nếu toàn bộ nhóm của bạn bao gồm các nhà phát triển phần mềm thực sự đặc biệt với sự hiểu biết sâu sắc về các khía cạnh của doanh nghiệp và tuổi thọ với công ty và nhau, và nếu các yêu cầu kinh doanh và nhu cầu khách hàng của bạn thường luôn giống nhau và hiếm khi thay đổi ở giữa phát hành sau đó bạn may mắn được làm việc trong một môi trường hiếm hoi như vậy, nơi Agile có thể thực sự HURT.

Nó được thiết kế để trở thành phương pháp hiệu quả nhất trong bối cảnh hỗn loạn và liên tục thay đổi yêu cầu kinh doanh và nhu cầu của khách hàng, phát triển hoặc thay đổi nguồn lực dự án, và thời hạn chặt chẽ hoặc thay đổi. Một môi trường như vậy sẽ tạo ra một số phận nhất định cho sự phát triển thác nước điển hình vì nó dễ bị tổn thương khi nhóm thay đổi dự án giữa, dễ bị thay đổi yêu cầu và cực kỳ dễ bị thay đổi.

Tôi cảm thấy các thành viên trong nhóm có giá trị của bạn, những người không tìm thấy niềm vui trong công việc của họ nữa. Họ rất có thể là những người tài năng đặc biệt, họ mải mê với công việc nhưng cuối cùng, một số yếu tố ngoài tầm kiểm soát tốt nhất của họ vẫn có thể giết chết dự án. Cách tốt nhất để tiếp cận phát triển tính năng là cho họ đánh mất thái độ và biểu hiện cá nhân và suy nghĩ theo cách tiếp cận nhóm.

Nếu bạn thấy rằng điều này sẽ không làm việc cho họ thì bạn có thể tìm thấy sử dụng đặc biệt cho họ. Nếu họ đặc biệt tài năng và có kinh nghiệm, hãy xem liệu họ có hứng thú với vai trò kiến ​​trúc, đưa ra các thiết kế cấp cao, phương pháp tiếp cận, thử nghiệm các công nghệ mới và phát triển các thực tiễn tốt nhất. Có những người này kiểm soát và xem xét tài liệu thiết kế.

Nếu điều này vẫn không phù hợp với họ thì có lẽ họ đã làm việc riêng biệt với các phép tái cấu trúc kỹ thuật cực kỳ phức tạp trên một nhánh riêng biệt, các nguyên mẫu liên quan và bằng chứng về các khái niệm, hoặc công việc theo dõi khác đôi khi cần phải được thực hiện nhưng không phù hợp với phạm vi của một dự án hoặc phát hành.

Họ không tìm thấy niềm vui trong công việc như trước đây.

Chính xác.

Đó là một triệu chứng lớn mà bạn đang làm sai.

Agile không nên áp đặt một trật tự mới xấu cho mọi người.

Agile nên cho phép nhóm tự tổ chức theo cách làm cho nó hiệu quả nhất.

Tự tổ chức có nghĩa là quản lý không áp đặt các quy tắc kỳ lạ. Nó không áp đặt lịch trình xấu và nó không áp đặt tương tác không cần thiết.

Một số nhà phát triển chủ yếu được thúc đẩy bởi niềm vui khi nhận một phần công việc khó khăn, suy nghĩ thông qua thiết kế, suy nghĩ thông qua các vấn đề tiềm ẩn, sau đó giải quyết vấn đề từng mảnh, chỉ với sự tương tác tối thiểu với những người khác, trong một khoảng thời gian dài

Tại sao họ không thể tiếp tục làm điều này?

Tại sao thay đổi chúng?

Xin vui lòng đọc Tuyên ngôn Agile một vài lần.

Tuyên ngôn Agile nói

Các cá nhân và tương tác qua các quy trình và công cụ

Nó không nói buộc mọi người phải làm việc theo cách không thoải mái và không hiệu quả.

Nếu bạn buộc mọi người tham gia quá nhiều "tương tác" có giá trị thấp, thì bạn đã đi quá xa.

Phần mềm làm việc trên tài liệu toàn diện.

Họ đang làm điều này? Sau đó để chúng một mình.

Hợp tác khách hàng qua đàm phán hợp đồng.

Bạn đã làm điều này? Vậy thì đừng thay đổi.

Đáp ứng để thay đổi theo một kế hoạch.

Trường hợp những người này đã có thể đáp ứng để thay đổi? Nếu vậy, thì họ đã nhanh nhẹn. Họ không cần phải thay đổi.

công ty của tôi đã cố gắng (và vẫn cố gắng sau nhiều năm cố gắng) để thực hiện quá trình chuyển đổi tương tự và cho đến nay, cá nhân tôi đã không thấy nhiều thành công với nó. Trong quá trình chuyển đổi này, tôi đã đọc rất nhiều về phát triển nhanh và các cách / khía cạnh / mối quan tâm / kỹ thuật khác nhau và một điều tôi rất đồng ý là phát triển nhanh nhẹn thuần túy là phù hợp nhất khi toàn bộ nhóm bao gồm những người cao cấp, chất lượng cao (hoặc ít nhất là tất cả những người cùng cấp).

Lần phát hành trước tôi đã ở trong một nhóm "nhanh nhẹn" có IMHO quá nhiều nhà phát triển với trình độ kỹ năng ở khắp mọi nơi và chúng tôi đã cố gắng để mọi người tham gia vào cùng một dự án. Đó là một thảm họa. Chúng tôi đã nói chuyện / tranh luận nhiều hơn là làm việc, và cuối cùng, những gì nhóm tạo ra là một công việc trung bình (đọc Tháng người dùng hoặc Tháng huyền thoại về việc lấy trung bình). Hãy quên đi các mẫu thiết kế, quên đi việc ghép thấp hoặc ngắt mã thành các lớp và phương thức nhỏ. Quên về việc cố gắng làm cho mọi thứ trở nên thú vị bởi vì a) không thể được giải thích và hiểu bởi tất cả các thành viên trong nhóm (ít nhất là không đúng lúc) và b) vì chúng tôi nhanh nhẹn, bất cứ điều gì tôi bắt đầu lặp đi lặp lại, một người khác hoàn toàn không hiểu sẽ tiếp tục trong lần lặp lại tiếp theo. Cá nhân,

Tôi hoàn toàn ghét việc tôi không thể làm bất cứ điều gì với các mẫu C ++, hoặc viết một số thư viện khung mức thấp (nhưng hơi phức tạp) sẽ giúp cuộc sống của chúng tôi dễ dàng hơn rất nhiều. Làm thế nào điều đó có thể được thực hiện khi không ai khác trong nhóm thậm chí có khả năng đọc các tệp tiêu đề STL nhưng tất cả chúng ta đều phải làm việc một lúc. Toàn bộ dự án cuối cùng đã trở thành tính năng bắt buộc bởi tính năng bởi vì đó là những gì nhanh nhẹn dường như nhấn mạnh.

Đồng thời, có rất ít (rất ít) người trong công ty của tôi mà tôi hoàn toàn thích làm việc cùng nhau và chia sẻ tất cả mã của tôi.

Nhưng bây giờ bạn phải đối mặt với một sự lựa chọn. A) Lấy tất cả các nhà phát triển cấp cao, giỏi của bạn, những người sản xuất mã chất lượng cao và đưa chúng vào nhóm riêng của họ và đưa phần còn lại vào một nhóm riêng. Hoặc B) cố gắng cân bằng các đội và đặt những đội tốt với những đội không tốt. Trong (A) vấn đề là một trong những đội của bạn sẽ hoạt động kém và sẽ không nhận được những kỹ năng / thói quen tốt từ những người tốt. Trong (B) những người tốt của bạn (trong môi trường nhanh nhẹn thuần khiết) sẽ cảm thấy thất vọng và sẽ bắt đầu làm việc trên sơ yếu lý lịch của họ. Của tôi là cập nhật.

Vậy bạn định làm gì?

Tôi không biết đây có phải là giải pháp đúng đắn không. Hỏi lại tôi sau khoảng một năm nữa. Nhưng điều gì sẽ xảy ra nếu thay vì "nhanh nhẹn", bạn đã thành lập một nhóm, nhưng xác định rõ ràng người nào có ảnh hưởng hơn (thiết kế, đánh giá mã ...) và đảm bảo rằng người đó hiểu điều đó và được khen thưởng thêm trách nhiệm. Khi các thành viên trong nhóm bắt đầu làm việc cùng nhau, hãy xác định những người đang chọn thói quen / thực hành tốt và nâng họ lên ngang hàng với những người tốt của bạn. Hy vọng khi mọi người dành một hoặc hai bản phát hành cùng nhau, họ sẽ tìm hiểu người kia nghĩ gì và cách họ làm việc, vì vậy họ sẽ tương thích hơn để làm việc trong cùng một mã cùng một lúc. Nhưng cho đến khi điều đó xảy ra, nếu bạn ném mọi người vào một dự án, nó sẽ chẳng là gì ngoài sự thất vọng (một lần nữa, chỉ là ý kiến ​​của tôi).

Một số suy nghĩ của tôi dựa trên cách tôi bắt đầu chuyên nghiệp trong phần mềm. Khi tôi là một đồng nghiệp, tôi đã làm việc với một người là người cố vấn của tôi. Anh ấy dạy tôi mọi thứ, từ đạo đức mã hóa đến thiết kế tốt đến đọc hàng ngàn hàng ngàn dòng mã bạn không viết. Ban đầu, chúng tôi không ở gần cùng cấp độ và sẽ thật buồn cười nếu chúng tôi được đưa vào một đội nhanh nhẹn và nói rằng chúng tôi có thể làm việc với mã của nhau. Nhưng theo thời gian (vài năm), chúng tôi bắt đầu suy nghĩ rất giống nhau. Tôi có thể hiểu mã của anh ta bằng một cái nhìn đơn giản và anh ta nói với tôi nhiều lần rằng anh ta hoàn toàn không gặp vấn đề gì (và bị bất ngờ bởi điều đó) điều hướng mã của tôi mà anh ta chưa từng thấy trước đây. Điều này mất nhiều năm, không phải là một cái gì đó đã xảy ra qua đêm. Sau khi trải qua thảm họa sau thảm họa trong môi trường nhanh nhẹn trong vài năm qua,

Đây không thực sự là một câu trả lời nhưng nó tổng hợp kinh nghiệm / quan sát của tôi. Tôi muốn xem những gì người khác sẽ nói về điều này.

Nhanh nhẹn là gì?

Là nó:

• một tập hợp các quy tắc mà bạn phải tuân theo để đạt được những gì các quy tắc dự định?

• một cách tiếp cận dự đoán tốt nhất để hoàn thành công việc trong những điểm mạnh, yêu cầu và hạn chế cụ thể của bạn?

Nếu bạn nghĩ Agile là người đầu tiên và bạn luôn tuân thủ mọi quy tắc Scrum và luôn lo lắng liệu bạn có làm đúng hay không, có lẽ liên kết này sẽ khai sáng cho bạn một chút.

Nếu bạn nghĩ nhiều hơn về thứ hai, thì xin chúc mừng - bạn 'nhận được' Agile. Bất kỳ phương pháp Agile nào cũng chỉ có thể là một gợi ý về cách hoàn thành công việc. Nếu bất kỳ khía cạnh nào của phương thức nhanh được chọn của bạn không phù hợp với bạn, thì bạn có nghĩa vụ ngừng sử dụng nó, thay đổi nó hoặc nếu không thì phải nhanh nhẹnvề nó. Điều quan trọng là bạn đạt được điều gì đó, mà bạn không bị kìm hãm bởi những ràng buộc giả tạo - không chỉ những điều mà tất cả chúng ta đều biết và yêu thích từ những thác nước cũ của chúng ta, nơi Thủ tướng sẽ làm phiền bạn về những sơ đồ được ghi chép đầy đủ mà không ai có thể làm được đọc chỉ vì "đó là những gì quy trình nói phải làm", nhưng cũng từ những ràng buộc của việc bạn đang sử dụng. Nếu một scrum hàng ngày cảm thấy như là một hạn chế thì đừng chớp mắt! Để mù quáng có chúng bởi vì các quy tắc nói như vậy không nhanh nhẹn hơn các cách cũ.

Bây giờ nếu bạn có một số kẻ hoàn thành công việc bằng cách bị nhốt trong một căn phòng chỉ với một gallon cola và một cái bánh cho pizza, thì hãy tận dụng thực tế đó. Cung cấp cho họ một phần của hệ thống chủ yếu là khép kín và khóa chúng đi. Khi hoàn thành, bạn nên yêu cầu họ tích hợp công việc đó (hoặc nhờ người khác làm việc đó nếu họ thích) với phần còn lại của hệ thống.

Alistair Cockburn đã mô tả điều này trong các phương pháp của mình. Nếu bạn có "học viên cấp 3", thì phương pháp nhanh nhẹn hoàn toàn hợp lệ như sau:

Tiết kiệm Đặt 4 - 6 người trong một phòng với máy trạm và bảng trắng và quyền truy cập cho người dùng. Yêu cầu họ cung cấp phần mềm đang chạy, đã được kiểm tra cho người dùng cứ sau một hoặc hai tháng, và nếu không thì hãy để họ yên

Khi bạn có sự kết hợp của nhiều người, bạn cần tìm ra cách để họ làm việc cùng nhau một cách xây dựng và điều đó có nghĩa là cách tiếp cận 1 kích thước phù hợp với tất cả các phương pháp có lẽ sẽ không hiệu quả. Vì vậy, bạn cần phân chia các nhiệm vụ lên, đồng thời đảm bảo rằng mục tiêu chung được nhấn mạnh. Bạn có thể gửi mã cho những kẻ đó, nhưng họ phải nhận thức được công cụ của họ sẽ là một phần không thể thiếu trong công việc của nhóm và việc không đạt được đó là thất bại của bất cứ thứ gì họ đang sản xuất . Một khi họ hiểu rằng (nghĩa là họ không thể làm bất cứ điều gì họ muốn và cung cấp thứ gì đó không sử dụng được) thì công việc của bạn đã hoàn thành.

Hãy nói rằng agile không dành cho tất cả mọi người và agile không dành cho mọi dự án. Đồng thời, agile là thuật ngữ rất rộng và Scrum chỉ là một triển khai của một quy trình nhanh - tôi có thể nói bằng cách nào đó có thể thực hiện với các ràng buộc nhất có thể cố gắng thiết lập quy trình chuẩn với các bước đã biết.

Một lĩnh vực khác để suy nghĩ là mục đích của nhanh nhẹn là gì? Nhanh nhẹn về cách làm việc của các nhà phát triển? Có lẽ - một số phương pháp thực sự đi theo hướng đó. Nhưng chính Agile bao gồm các khu vực bên ngoài sự phát triển. Agile tập trung vào việc điều khiển toàn bộ quá trình, cách thức tương tác hoạt động, cách bạn phân phối sản phẩm làm việc với các tính năng quan trọng nhất về thời gian và cách bạn kiểm soát tài nguyên, cách bạn nhìn thấy nơi bạn đang ở trong dự án, Vân vân.

Có những phương pháp không cố gắng thay đổi bất cứ điều gì từ quá trình phát triển của bạn - Scrum không phải là phương pháp. Tất cả các phương pháp nhanh nhẹn nhấn mạnh cải tiến liên tục. Bạn sẽ phát hiện một số bước không hiệu quả trong quy trình của mình và bạn sẽ cố gắng cải thiện nó / thay đổi nó - đó là cách nhanh nhẹn. Kiểm tra một phương pháp nhanh phổ biến khác - Kanban.

Bạn / Công ty của bạn đã quyết định sử dụng Scrum và điều đó có thể dẫn đến việc một số người sẽ không thích nó và rời đi. Bạn nên đối phó với từng nhà phát triển của bạn một cách riêng biệt. Bạn nên nói về điều đó với từng người và bạn nên cố gắng tìm một số sở thích cho phép họ thưởng thức công việc một lần nữa.

Họ có thể có vai trò của người cố vấn, họ có thể dạy người khác, chỉ cho họ cách cấu trúc lại mã để kiến ​​trúc tốt hơn khi làm việc lặp lại. Họ có thể cùng nhau hình thành một số đồ án kiến ​​trúc toàn cầu sử dụng trên các dự án. Họ cũng có thể làm việc dựa trên bằng chứng về các khái niệm, tham gia RFI (yêu cầu thông tin) khi khách hàng đưa ra yêu cầu để suy nghĩ về tính khả thi của các yêu cầu. Họ có thể làm việc theo cặp với các nhà phát triển kém kỹ năng hơn và thực hiện các nhiệm vụ phức tạp cùng nhau, v.v. Giá trị chính của họ nên là sử dụng các kỹ năng của họ và cho phép người khác học hỏi từ họ.

Scrum và nhanh nhẹn trên toàn cầu thực sự bằng cách nào đó giữ các cá nhân và ưu tiên các nhóm - các nhóm cung cấp ứng dụng, không phải các cá nhân. Ý tưởng này dựa trên thực tế là bạn sẽ không bao giờ có một đội mà mọi người đều có kỹ năng và kinh nghiệm giống nhau.

Nếu quá trình chuyển đổi sang Scrum của bạn thành công, họ sẽ thấy rằng quy trình tổng thể đã được cải thiện, thời gian giao hàng giảm, chất lượng được cải thiện và khách hàng hài lòng hơn. Họ vẫn có thể tin rằng bản thân các ứng dụng được phát triển còn tệ hơn nhiều nhưng đó là điểm chính - khách hàng không muốn mã tốt nhất từng được viết. Khách hàng muốn mã làm việc tối thiểu / rẻ nhất / được phát triển nhanh nhất đáp ứng yêu cầu của họ. Nếu sức mạnh vũ phu là đủ cho điều đó thì hãy là nó. Đây là điều có thể gây ra vấn đề cho các nhà phát triển có tay nghề cao nhưng đó không phải là sự thất bại của sự nhanh nhẹn, đó là nơi mà nhu cầu kinh doanh và sự cầu toàn đi ngược lại với nhau.

Nó sẽ có lợi cho toàn bộ nhóm nếu bạn xử lý một số vấn đề lớn và giao chúng cho một nhà phát triển tuyệt vời. Mọi người đều có thể tăng tốc sau đó và học được điều gì đó trong quá trình này. Chỉ cần không xây dựng toàn bộ ứng dụng theo cách này.

Bạn không hạ mã xuống mẫu số chung thấp nhất. Bạn làm cho những người thiếu kinh nghiệm bắt kịp các nhà phát triển tốt hơn.

Đã có rất nhiều cuộc thảo luận về những gì là hoặc không "nhanh nhẹn" và rất nhiều cảm xúc, kinh nghiệm cá nhân và những hiểu lầm về quá trình nhanh nhẹn được chia sẻ ở đây, nhưng tôi thực sự không thấy câu trả lời thực sự cho câu hỏi. Câu hỏi ban đầu là làm thế nào để giữ cho các nhà phát triển hàng đầu của bạn có động lực khi họ nhìn thấy mã của họ mà họ đã viết ở mức độ thuần túy, và đầu tư mồ hôi và máu của họ vào, bị người khác tấn công và "làm hỏng". Lưu ý rằng, dù nhanh hay không, điều này sẽ xảy ra vào một lúc nào đó, bây giờ nó chỉ rõ hơn vì họ vẫn đang làm việc với mã cùng lúc với những người khác, thay vì có sự hỗ trợ điển hình để hỗ trợ, tại thời điểm đó họ sẽ không thấy những thay đổi đó được thực hiện.

Những gì tôi sẽ thấy là chìa khóa ở đây là mở rộng trách nhiệm của các nhà phát triển này và giúp họ thay đổi trọng tâm của họ sang bức tranh lớn hơn. Có lẽ điều đó có nghĩa là một tiêu đề mới, như Kiến trúc sư phần mềm, hoặc Trưởng nhóm hoặc Kỹ sư phần mềm cao cấp. Sau đó cho họ thấy rằng đây là một cơ hội để có tác động lớn hơn, không chỉ đối với một dự án tại một thời điểm, mà trên nhiều dự án. Ý thức về quyền sở hữu vẫn có thể ở đó, nhưng trọng tâm của họ không còn là việc cung cấp một dự án tuyệt vời duy nhất, mà là giúp thiết lập thanh cho TẤT CẢdự án. Giúp họ nắm bắt được mong muốn mạnh mẽ của họ để xây dựng một cái gì đó tuyệt vời, nhưng chuyển trọng tâm sang xây dựng các thực hành kỹ thuật phần mềm của công ty bạn và các nhà phát triển khác. Thay vì suy nghĩ về việc đồng nghiệp của họ hack mã của họ thành từng mảnh, đây có thể là cơ hội để họ bước lên cấp độ tiếp theo và cố vấn cho đồng đội của họ và đưa họ lên cấp độ của họ.

Tôi sẽ cố gắng minh họa một số khía cạnh chưa được giải quyết bằng các câu trả lời khác và rằng, IMO, rất quan trọng.

Vấn đề cơ bản là: Một số nhà phát triển chủ yếu được thúc đẩy bởi niềm vui khi nhận được một phần công việc khó khăn, suy nghĩ thông qua thiết kế, suy nghĩ thông qua các vấn đề tiềm năng, sau đó giải quyết vấn đề từng mảnh, chỉ với sự tương tác tối thiểu với những người khác, qua một phần mở rộng khoảng thời gian. Họ thường hoàn thành công việc với chất lượng cao và kịp thời; công việc của họ là duy trì và phù hợp với kiến ​​trúc tổng thể.

Loại nhà phát triển này có thể khó thích nghi với môi trường nhanh nhẹn và thái độ của họ thường bị coi là "không muốn thay đổi", có thể liên quan đến bản ngã hoặc bị lỗi thời.

Điều thường bị bỏ qua là để giải quyết các vấn đề phức tạp, người ta cần xử lý nhiều thông tin, và điều này có thể cần nhiều phân tích, suy nghĩ, cố gắng, phác thảo một giải pháp, vứt bỏ nó, thử một cách khác. Một vấn đề phức tạp như vậy có thể cần từ vài giờ đến vài tuần làm việc tập trung cho đến khi bạn có một giải pháp hoàn thành.

Một cách tiếp cận là nhà phát triển lấy đặc tả vấn đề, đến phòng của cô ấy và quay lại hai hoặc ba tuần sau với một giải pháp. Bất cứ lúc nào (khi cần), nhà phát triển có thể bắt đầu một số tương tác với các thành viên khác trong nhóm hoặc với các bên liên quan (đặt câu hỏi về các vấn đề cụ thể) nhưng hầu hết các công việc được thực hiện bởi nhà phát triển được giao nhiệm vụ.

Điều gì xảy ra trong một kịch bản nhanh? Nhóm nghiên cứu chia vấn đề thành các phần nhỏ (câu chuyện của người dùng) sau khi phân tích nhanh (chải chuốt). Hy vọng là các câu chuyện của người dùng độc lập với nhau nhưng thường thì không phải vậy: để chia nhỏ một vấn đề phức tạp thành các phần độc lập thực sự, bạn sẽ cần một kiến ​​thức mà bạn thường chỉ có được sau khi làm việc trong vài ngày. Nói cách khác, nếu bạn có thể chia một vấn đề phức tạp thành các phần độc lập nhỏ, điều đó có nghĩa là về cơ bản bạn đã giải quyết nó và bạn chỉ còn công việc cần mẫn. Đối với một vấn đề đòi hỏi, giả sử, ba tuần làm việc, điều này có thể sẽ xảy ra trong tuần thứ hai, không phải sau vài giờ chải chuốt được thực hiện ngay từ đầu nước rút.

Vì vậy, sau khi một cuộc chạy nước rút đã được lên kế hoạch, nhóm nghiên cứu làm việc trên các phần khác nhau của một vấn đề có thể có sự phụ thuộc lẫn nhau. Điều này tạo ra rất nhiều chi phí truyền thông cố gắng tích hợp các giải pháp khác nhau có thể tốt như nhau nhưng tốt, khác biệt với nhau. Về cơ bản, công việc thử và sai được phân phối trên tất cả các thành viên trong nhóm có liên quan, với một chi phí liên lạc bổ sung (tăng theo phương trình bậc hai). Tôi nghĩ rằng một số vấn đề được minh họa rất tốt trong bài viết này của Paul Graham, đặc biệt là điểm 7.

Tất nhiên, chia sẻ công việc giữa các thành viên trong nhóm giúp giảm rủi ro liên quan đến một thành viên trong nhóm rời khỏi dự án. Mặt khác, kiến ​​thức về mã có thể được truyền đạt theo những cách khác, ví dụ như sử dụng đánh giá mã hoặc thuyết trình kỹ thuật cho các đồng nghiệp. Về mặt này, tôi không nghĩ rằng có một viên đạn bạc hợp lệ cho tất cả các tình huống: quyền sở hữu mã được chia sẻ và lập trình cặp không phải là lựa chọn duy nhất.

Hơn nữa, "phân phối chức năng làm việc trong khoảng thời gian ngắn hơn" dẫn đến gián đoạn dòng công việc. Điều này có thể ổn nếu đoạn chức năng là "thêm nút hủy trong trang đăng nhập" có thể được hoàn thành sau khi chạy nước rút, nhưng khi bạn đang thực hiện một nhiệm vụ phức tạp, bạn không muốn bị gián đoạn như vậy: nó giống như cố gắng lái xe 100 km nhanh nhất có thể và dừng lại cứ sau 5 phút để kiểm tra xem bạn đã đi được bao xa. Điều này sẽ chỉ làm bạn chậm lại.

Tất nhiên, việc có các điểm kiểm tra thường xuyên có nghĩa là làm cho dự án trở nên dễ đoán hơn, nhưng trong một số trường hợp, sự gián đoạn có thể rất khó chịu: người ta hầu như không thể đạt được tốc độ mà đã đến lúc phải dừng lại và trình bày một cái gì đó.

Vì vậy, tôi không nghĩ rằng thái độ được mô tả trong câu hỏi chỉ liên quan đến bản ngã hoặc sự chống lại sự thay đổi. Cũng có thể một số nhà phát triển xem xét phương pháp giải quyết vấn đề được mô tả ở trên hiệu quả hơn vì nó cho phép họ hiểu rõ hơn về các vấn đề họ đang giải quyết và về mã họ đang viết. Buộc các nhà phát triển như vậy làm việc theo một cách khác có thể dẫn đến giảm năng suất của họ.

Ngoài ra, tôi không nghĩ rằng việc một số thành viên trong nhóm làm việc riêng rẽ trong các vấn đề cụ thể, khó khăn là chống lại các giá trị nhanh. Rốt cuộc, các đội nên tự tổ chức và sử dụng quy trình mà họ thấy là hiệu quả nhất trong những năm qua.

Chỉ 2 xu của tôi.

Some developers are primarily motivated by the joy of taking a piece of difficult 
work, thinking through a design, thinking through potential issues, then solving
the problem piece by piece, with only minimal interaction with others, over an 
extended period of time

Có vẻ như họ là "Lone Rangers". Trong Scrum chính tắc, những người này không thể phù hợp với Nhóm (họ bỏ lỡ bit "tương tác").

Nếu họ không phải là "Lone Rangers", thì có hy vọng. Nếu bạn đang thực hiện Scrum đúng cách, họ phải là một phần của thiết kế tính năng mà họ sẽ làm việc (trong Kế hoạch Sprint). Đây là khoảng thời gian duy nhất họ cần để tương tác với người khác. Bạn thậm chí có thể "gán" tất cả các câu chuyện liên quan đến một tính năng đó cho chúng.

Trong Sprint, họ sẽ chỉ bị "làm phiền" bởi Scrum hàng ngày ... cho đến khi bạn có thể chứng minh cho họ (bằng hành động chứ không phải bằng lời nói) rằng sẽ chỉ mất 15 phút thời gian của họ và chỉ để đảm bảo rằng mọi thứ đang chạy thông suốt. Theo sát ba câu hỏi và hầu hết mọi người sẽ ngừng tuân thủ.

Trong nhóm của chúng tôi, chúng tôi có một nhóm đặc biệt chỉ để cải tiến hiệu suất. Chúng ta không nhìn thấy chúng rất nhiều, chỉ khi bắt đầu nước rút để nói về những thay đổi sẽ được thực hiện, và cuối cùng là hồi tưởng. Họ có "thủ lĩnh scrum" riêng báo cáo cho nhóm Scrum of Scrum. Tôi có thể nói với bạn, họ đang tận hưởng chính mình.

Nếu Joe (nhà phát triển Hero của bạn) linh hoạt một chút, thì tôi không thấy vấn đề gì:

Như đã nói ở trên, hãy để nhóm tự tổ chức: Nếu một số vấn đề được giải quyết tốt nhất bằng cách để Joe tự mình nhai nó, thì bạn sẽ mong đợi một nhóm tự tổ chức cởi mở sẽ tự mình đi đến kết luận đó.

Những thách thức duy nhất còn lại trong một vài hạn chế mà Scrum đặt ra:

1. Cung cấp chức năng theo định kỳ: Nếu bạn để Joe giải quyết vấn đề trong nhiều tháng, không có gì để hiển thị cho đến khi kết thúc, thì Joe thực sự không nhanh nhẹn: Anh ta bắt con tin chủ sở hữu sản phẩm và không cho anh ta cơ hội để xác định lại đó là một phần của sản phẩm. Với thực tế này cũng có nguy cơ anh ta đi muộn, và không ai nhận ra điều đó. (Nhưng theo mô tả của bạn không có khả năng như vậy). Biện pháp khắc phục: Sẽ là quá nhiều khi yêu cầu Joe, ngồi lại với PO, chia tay câu chuyện người dùng và đồng ý về các sản phẩm trung gian, tốt nhất là (nhưng không nhất thiết) với giá trị người dùng?

2. Tôn trọng các ưu tiên do chủ sở hữu sản phẩm đặt ra: Nếu các phần mã được sở hữu bởi các chuyên gia, thì bạn có nguy cơ xảy ra tình trạng tiến hóa của sản phẩm được xác định bởi tính khả dụng của từng chuyên gia, thay vì các ưu tiên thương mại: Phần còn lại của nhóm có thể đang làm việc trên các tính năng ít quan trọng hơn, trong khi 3 tính năng hàng đầu đang bị đình trệ vì "chỉ Joe mới có thể làm được". Thật tồi tệ. Tại thời điểm đó, nhóm nên (tạm thời) thay đổi thói quen của họ và phân chia công việc của Joe cho nhiều thành viên trong nhóm hơn.

Tóm lại: Nếu Joe, nhà phát triển anh hùng, đồng ý với PO về cách anh ta sẽ thể hiện tiến trình mỗi lần chạy nước rút, thì nhóm có thể gán một số câu chuyện nhất định cho anh ta và để anh ta yên. Nhưng nếu PO có quá nhiều công việc cho Joe, và không đủ cho nhóm (hoặc ngược lại), thì Joe và nhóm phải thích nghi chứ không phải PO.

Các quy tắc cho một nhóm nhanh nhẹn nên được tùy chỉnh để phù hợp với nhóm - đây có thể là tùy chỉnh thực sự cá nhân; Ví dụ, tôi đã làm việc trong một nhóm trong đó quy tắc là:

Tất cả các Mã phải được viết bởi một cặp, ngoại trừ David có thể viết mã một mình.

David là một nhà phát triển / kiến ​​trúc sư cao cấp, người đã làm việc chủ yếu về công cụ mà những người khác sẽ sử dụng trong mã của riêng họ. Anh ấy rất sở hữu mã mà anh ấy đã viết. Nó có thể được duy trì và thử nghiệm, và mọi người trong nhóm biết rằng anh ta có lẽ là người viết mã giỏi nhất ở đó, và nhóm sẽ được phục vụ tốt nhất bằng cách cho anh ta xây dựng các phần khung nhất định và trình bày chúng hoàn chỉnh cho nhóm.

Tôi không có câu trả lời cho những người hướng nội trong vườn, nhưng đối với những người hướng nội đặc biệt, nhóm sẽ vui vẻ thực hiện các quy tắc khác nhau để nhận được lợi ích.