Có phải mọi thành viên của một nhóm nhanh nhẹn cần phải là một nhà phát triển phần mềm?

Gần đây chúng tôi đã bắt đầu sử dụng các phương pháp nhanh tại công ty của tôi. Bởi vì tôi còn khá mới với agile, tôi tự hỏi liệu cách thực hiện của chúng tôi có đúng theo các nguyên tắc cơ bản của agile không.

Trước đây, chúng tôi có các vai trò như nhà phân tích kinh doanh, người kiểm tra QA và nhà phát triển phần mềm. Nhưng bây giờ quản lý đã quyết định rằng những vai trò này nên được loại bỏ và mọi người sẽ làm việc như một nhà phát triển phần mềm.

Trong thực tế, điều này có nghĩa là một nhà phát triển phần mềm sẽ có trách nhiệm giống như ba vai trò riêng biệt trước đây đã làm (tức là một nhà phân tích kinh doanh, một người kiểm tra QA và một nhà phát triển phần mềm).

Họ biện minh cho sự thay đổi với thực tế là điều này nhanh nhẹn. Đây có phải là cách các công ty khác cũng thực hiện nhanh nhẹn?

Không. Điều này chắc chắn không nhanh nhẹn. Cũng không phải là một ý tưởng tốt.

Các nhóm chức năng chéo, tức là các nhóm bao gồm mọi vai trò (nhà phân tích, quản trị viên máy chủ, quản trị viên cơ sở dữ liệu, nhà thiết kế UX, người kiểm tra QA, nhà văn kỹ thuật, nhà thiết kế đồ họa) cần thiết để cung cấp thành công phần mềm, là một yếu tố chính của nhiều phương pháp nhanh. Trên thực tế, trong nhiều phương pháp, bản thân khách hàng cũng được coi là một phần của nhóm.

Trên thực tế, đây là trực giao để nhanh nhẹn, mặc dù. Các nhóm chức năng chéo đơn giản là một ý tưởng tốt, bất kể bạn có làm nhanh hay không.

Có gì là đúng, tuy nhiên, là với sự gia tăng liên tục của kiểm tra tự động, thử nghiệm phát triển, thử nghiệm điều khiển và phát triển hành vi điều khiển trên một mặt, và cơ sở hạ tầng phần mềm xác định trước, tự động hóa cao vận hành, cấu hình và triển khai, DevOps, và lưu trữ đám mây, một số khối lượng công việc có thể đã chuyển từ quản trị viên sang kỹ sư DevOps và từ QA sang phát triển. Điều đó không , tuy nhiên, có nghĩa là những vai trò là đã tuyệt chủng. Điều đó chỉ có nghĩa là QA có nhiều lỗi thú vị hơn để theo đuổi vì tất cả những lỗi nhỏ đã được tìm thấy bởi thử nghiệm của nhà phát triển và quản trị viên tập trung nhiều hơn vào việc cho phép DevOps quản lý cơ sở hạ tầng bằng các công cụ tự động hơn là tự quản lý.

Có một bài kiểm tra dễ dàng để kiểm tra xem có thứ gì đó nhanh nhẹn hay không: khi ai đó nói "bạn làm điều này vì nó nhanh nhẹn", thì nó không nhanh nhẹn. Agile là tất cả về các nhóm tự quản lý liên tục phản ánh về các quy trình của họ và điều chỉnh chúng. Bất cứ khi nào ai đó nói "bạn làm điều này", thì nó không nhanh nhẹn. Nó chỉ nhanh nhẹn khi nhóm nói " chúng tôi làm điều này, bởi vì sau khi phản ánh những kinh nghiệm trong quá khứ của chúng tôi, chúng tôi đã xác định rằng nó hoạt động, và chúng tôi sẽ tiếp tục phản ánh về nó và ngừng làm điều đó ngay khi chúng tôi xác định nó không xảy ra."

Đây có phải là cách các công ty khác cũng thực hiện nhanh nhẹn?

Không may là đúng vậy. Có rất nhiều công ty mà Agile bị quản lý áp đặt, hoặc ít nhất những gì họ nghĩ là Agile (tất nhiên là không).

Nếu bạn xem trong hướng dẫn Scrum , có lẽ là từ nơi quản lý của bạn chọn ra ý tưởng, bạn sẽ tìm thấy điều này:

Scrum nhận ra không có tiêu đề nào cho các thành viên của Nhóm phát triển ngoài Nhà phát triển, bất kể công việc đang được thực hiện bởi người đó

Nhưng ý tưởng với tất cả mọi người trong nhóm là "nhà phát triển" là không có vai trò nào của họ (QA, lập trình viên, nhà thiết kế, v.v.), tất cả đều góp phần vào sự phát triển của ứng dụng, cùng với những nỗ lực như nhau, và khả năng đáp ứng và trách nhiệm như nhau . Lập trình viên không quan trọng hơn người kiểm thử chỉ vì cô ấy viết mã và người kiểm tra chỉ kiểm tra nó, người thiết kế không tạo ra các khung lưới sau đó biến mất trong khi các nhà phát triển giao diện người dùng thực hiện chúng. Mọi người đều quan trọng. Mọi người cùng đóng góp. Vì vậy, tất cả mọi người là như nhau từ vấn đề này. Chức danh công việc không quan trọng. Vì vậy, đó là lý do tại sao mọi người là một "nhà phát triển".

Nhưng điều đó không có nghĩa là đột nhiên nhà thiết kế bắt đầu thực hiện kiến ​​trúc của ứng dụng hoặc viết mã. Và trên cùng một dòng suy nghĩ, chỉ vì bây giờ bạn là tất cả "nhà phát triển" bởi vì ban quản lý đã nói như vậy, điều đó không có nghĩa là bạn đang làm Agile.

Những gì họ đang làm là vô nghĩa. Ví dụ: nếu bạn khiến nhà phát triển phần mềm đảm nhận vai trò QA:

Thứ nhất, nhà phát triển phần mềm không có kinh nghiệm cần thiết. Đó là tất cả những điều có thể học được, nhưng cá nhân tôi sẽ bắt đầu như một kỹ sư QA cơ sở, kém hiệu quả hơn nhiều so với làm công việc phát triển phần mềm.

Hai, mọi người có tài năng khác nhau và đi vào vị trí mà tài năng của họ được tính. Mọi người trở thành nhà phát triển phần mềm vì họ có tài năng về nó và những người khác trở thành kỹ sư QA vì họ có tài năng về điều đó. Và cả hai sẽ kém tốt hơn trong công việc khác.

Thứ ba, nếu cùng một người thực hiện cả phát triển phần mềm và QA, họ sẽ bị xung đột. QA tìm thấy các vấn đề khiến các nhà phát triển phần mềm làm việc nhiều hơn. Các nhà phát triển phần mềm, giống như mọi người, không thích làm việc nhiều hơn. Vì vậy, bạn mong đợi một nhà phát triển phần mềm làm việc như QA sẽ làm gì?

Mặc dù nguồn gốc của Agile nằm trong lĩnh vực phát triển phần mềm, các cách tiếp cận lặp lại để phát triển đã có từ cuối những năm 50 và được sử dụng trong những ngày đầu của NASA (xem https://en.wikipedia.org/wiki/Iterative_and_incremental_development ). Các đội này rõ ràng chỉ là các kỹ sư phần mềm.

Chúng tôi đã sử dụng thành công các cách tiếp cận Agile khác nhau tại các công ty của tôi và cho đội robot chế tạo mà tôi cố vấn. Khái niệm chạy nước rút, gai và thiết kế lặp với sử thi bao trùm đã được chứng minh là rất thành công trên toàn bộ nhóm - phần mềm, phần cứng, CAD, tiếp thị, v.v. Đối với điều này, chúng tôi không có cơ sở hạ tầng "DevOps" nào nguyên mẫu rõ ràng và trình diễn các bài học của họ trên nước rút hai tuần. Quyết định về cách tiến hành được thực hiện từ đó, nhưng cốt lõi là một robot đang dần tốt hơn mỗi lần chạy nước rút. Vai trò khôn ngoan, điều này bao gồm "nhà phát triển phần mềm", "anh chàng CAD", "người xây dựng" và "tiếp cận cộng đồng". Phần lớn nhóm này KHÔNG tham gia trực tiếp vào phần mềm mã hóa.

Đối với các công ty phần mềm của tôi, nhóm thường bao gồm các nhà phát triển, người thử nghiệm, người phát triển, nhà thiết kế và hỗ trợ.

Nói chung, Agile không phải là một thứ và có nhiều cách tiếp cận để thực hiện triết lý. Nhưng cốt lõi của nó là ý tưởng phát triển lặp lại, chia nhỏ công việc thành các nhiệm vụ ngắn và đánh giá lại liên tục. Những thứ như các cuộc họp scrum hàng ngày, tồn đọng, câu chuyện của người dùng, v.v ... thường được sử dụng nhưng không phải theo bất kỳ cách nào được yêu cầu là "Agile". Agile là về việc thích nghi liên tục và điều đó bao gồm cách một nhóm cụ thể thực hiện chính Agile.

Vì vậy, câu trả lời ngắn gọn - nhóm quản lý của bạn không hiểu Agile là gì hoặc sử dụng điều này như một cách biện minh nào đó để loại bỏ những thứ họ cảm thấy là lãng phí tiền bạc. Nó có thể được biện minh để thực hiện các thay đổi, nhưng không phải vì Agile chỉ dành cho lập trình viên.