Những gì hầu hết các "chuyên gia" Agile hiểu sai về phát triển phần cứng

Phương pháp linh hoạt (Agile), bắt nguồn từ thế giới phát triển phần mềm, đã được ca ngợi là một lực lượng biến đổi trong ngành công nghệ. Tuy nhiên, khi chúng ta tiến vào lĩnh vực phát triển phần cứng và điện tử, sự thích nghi dường như trơn tru của các nguyên tắc Agile gặp phải một mê cung của thách thức và hiểu lầm. Trong phần đầu tiên của loạt bài khám phá ba phần này, chúng tôi đã phân tích những thách thức Agile phát sinh từ sự khác biệt giữa phát triển phần cứng và phần mềm. Trong bài viết này, chúng tôi xem xét những huyền thoại được lan truyền bởi các "guru" Agile.

Trước khi chúng ta đi sâu vào những phức tạp của Agile trong phát triển phần cứng điện tử, điều quan trọng là phải làm rõ rằng mục đích của chúng tôi không phải là để chỉ trích các huấn luyện viên và tư vấn viên Agile. Chúng tôi nhận ra và đánh giá cao ý định tốt và sự nhiệt tình của họ trong việc giúp khách hàng thu được lợi ích từ các phương pháp Agile. Mặc dù một số phê bình có thể phát sinh từ sự hiểu biết hạn chế về những điểm tinh tế của phần cứng, mục đích không phải là chỉ trích mà là để thích nghi các nguyên tắc Agile một cách hiệu quả để đáp ứng các yêu cầu cụ thể của phát triển phần cứng. Chúng tôi tập trung vào việc điều chỉnh các chiến thuật Agile để khai thác lợi ích của nó trong bối cảnh độc đáo này, thay đổi cách tiếp cận nhưng giữ nguyên các nguyên tắc.

Mê lầm #1: Bạn Phải Luôn Linh Hoạt và Thích Nghi

Các chuyên gia Agile đúng khi ca ngợi những đức tính của việc thực hiện lặp đi lặp lại, vòng lặp phản hồi, và khả năng thích nghi nhanh chóng đã phát triển mạnh mẽ trong lĩnh vực số hóa của phần mềm. Tuy nhiên, việc chuyển giao những nguyên tắc này sang lĩnh vực hữu hình của phần cứng và điện tử giới thiệu một tầng phức tạp không tìm thấy trong phạm vi thuần túy số hóa. Các giải pháp vật lý, không giống như các đối tác phần mềm của chúng, cần phải "hoàn thành" để đặt hàng phần, chế tạo khuôn, và đáp ứng nhu cầu sản xuất khắt khe. Lời kêu gọi thay đổi liên tục của Agile va chạm với bản chất không khoan nhượng của hiệu ứng gợn sóng của phần cứng khi những thay đổi nhỏ được yêu cầu vào phút chót.

Để phản hồi, việc điều chỉnh Agile cho phát triển phần cứng đòi hỏi một sự thay đổi tư duy. Điều này không phải là về những thay đổi không ngừng nghỉ mà là những điều chỉnh chiến lược được thông báo trước và chế tạo mẫu. Những điều này dựa trên các chu kỳ học hỏi và thực thi nhanh chóng nhằm tối đa hóa giá trị trong các ràng buộc về thời gian, ngân sách và nguồn lực. Sự kết hợp giữa sự linh hoạt của Agile và yêu cầu về tính chất cuối cùng của sản phẩm vật lý đòi hỏi sự lập kế hoạch lặp lại cẩn thận hơn và một cam kết sâu sắc với việc giảm rủi ro trong suốt dự án.

Mê tín #2: Bạn Phải Phát Triển Một Mẫu Làm Việc Mỗi Sprint

Trong khi việc phát triển một nguyên mẫu hoàn chỉnh mỗi hai đến ba tuần "sprint" thường được những người ủng hộ phương pháp Agile tuyên bố là một "phải" chung để trở nên linh hoạt, tính khả thi thực tế của cách tiếp cận này bị sụp đổ trước thực tế phát triển phần cứng và điện tử (và ngân sách). Ý tưởng xây dựng một cái gì đó, thể hiện tiến độ, và sử dụng kết quả này để thu được phản hồi kỹ thuật và thương mại quý báu để thông báo cho lần lặp tiếp theo của bạn là đúng. Tuy nhiên, mỗi dự án phần cứng là một thực thể riêng biệt với mục tiêu, sự phụ thuộc, ràng buộc thời gian dẫn, lĩnh vực cần đổi mới, và rủi ro của riêng nó. Và mỗi dự án xứng đáng có một cách tiếp cận độc đáo của riêng mình đối với việc tạo mẫu và học hỏi.

Để thực sự áp dụng phát triển sản phẩm phần cứng linh hoạt, các nhóm cần phải từ bỏ tư duy áp dụng một kích cỡ cho tất cả. Thay vào đó, họ cần phải xem xét kỹ lưỡng nhu cầu của dự án và sau đó hợp tác để đưa ra một chiến lược sáng tạo, học hỏi và tạo mẫu. Điều quan trọng là phải nhận ra rằng "mẫu" có thể là bất kỳ sản phẩm có thể trình bày được từ một tờ rơi sơ bộ đến một mô hình bằng bọt (như mô hình iPod nổi tiếng của Steve Jobs vừa "1000 bài hát trong túi của bạn"), và thậm chí bao gồm cả các mẫu hoạt động một phần hoặc hoàn toàn.

Mê tín #3: Thêm Câu Chuyện vào Danh Sách Công Việc và Chỉ Cần Bắt Đầu

Một điểm mạnh cố hữu của các phương pháp Agile nằm ở khả năng khởi động một dự án nhanh chóng hơn nhiều so với các phương pháp truyền thống theo mô hình thác nước. Thực tế, đối với các dự án điện tử phần cứng Agile, chúng tôi đã thấy sự giảm đáng kể trong khoảng thời gian từ khi xác định ý tưởng đến khi bắt đầu phát triển. Khoảng thời gian này, thường kéo dài nhiều tháng hoặc thậm chí nhiều năm dưới cách tiếp cận theo giai đoạn truyền thống, đã được rút ngắn còn vài tuần hoặc vài ngày với các phương pháp Agile. Tất nhiên, một phần của kết quả ấn tượng này là cách chúng ta định nghĩa "khởi đầu phát triển".

Đối với phần mềm, điều này khá đơn giản. Các chuyên gia Agile ủng hộ việc viết Câu chuyện Người dùng để định nghĩa các tính năng phần mềm, ưu tiên chúng vào danh sách công việc cần làm, và bắt đầu một Sprint. Tuy nhiên, trong lĩnh vực phần cứng, ít nhất cũng cần một kế hoạch ban đầu tối thiểu để hướng dẫn dự án đi đúng hướng với sự hiểu biết về kiến trúc, các thuộc tính mong muốn chính, ràng buộc, và các yếu tố khác. Nỗ lực ban đầu này có vẻ như mâu thuẫn với các nguyên tắc Agile là "phần mềm hoạt động là thước đo chính của tiến độ" và "chào đón sự thay đổi yêu cầu, ngay cả trong giai đoạn muộn của quá trình phát triển."

Giải pháp nằm ở việc tìm ra sự cân bằng bằng cách điều chỉnh các chiến thuật Agile được hiểu rộng rãi cho giai đoạn đầu của quá trình phát triển sản phẩm. Quản lý dự án Agile cho phần cứng cho phép khởi đầu nhanh chóng bằng cách điều chỉnh theo ý định chiến lược của dự án và chấp nhận nhiều điều không biết hơn so với các phương pháp truyền thống. Các nhóm sau đó có thể hợp tác sử dụng việc học lặp lại của Agile để định nghĩa giải pháp tối ưu, kết hợp với tư duy mở cửa với các thay đổi chiến lược giúp tăng giá trị sản phẩm trong khi vẫn giữ vững lịch trình và ràng buộc về nguồn lực.

Mê tín #4: Định nghĩa Tất cả Công việc của Bạn dưới dạng Câu chuyện Người dùng

Một chỉ dẫn quan trọng mà nhiều chuyên gia Agile khuyên bảo là tất cả công việc phát triển nên được định nghĩa dưới dạng Câu chuyện Người dùng. Lời khuyên tiếp tục nói rằng các thành phần hệ thống, giao diện, các kỹ sư khác, v.v., nên được xem như là "Người dùng". Lời khuyên này khiến hầu hết các nhà phát triển điện tử và phần cứng bối rối và gặp khó khăn trong việc tuân thủ.

Một lý do chính khiến các đội ngũ phần mềm đã nhanh chóng áp dụng các phương pháp Agile là bởi vì việc tài liệu hóa nhu cầu của khách hàng bằng các tài liệu yêu cầu truyền thống và các trường hợp sử dụng chi tiết đã rất lãng phí và không thêm giá trị gì cho đội ngũ. Tại sao không chỉ đơn giản khai báo những gì người dùng đang cố gắng làm, viết một Câu chuyện Người dùng để tài liệu hóa tính năng, và sau đó xem đó như một nhiệm vụ phát triển? Nó không chỉ tự tài liệu hóa, mà nếu những câu chuyện này được ưu tiên và xác thực với khách hàng một cách nhất quán, chúng ta có hệ thống khép kín hoàn hảo để phản hồi với sự thay đổi và tối ưu hóa giá trị. Tuyệt vời!

Nỗ lực viết Câu chuyện Người dùng trực tiếp như các công việc cho việc phát triển phần cứng trong khi liên kết chúng với các kết quả có giá trị cho khách hàng thường là điểm gãy của phương pháp Agile đối với nhiều đội ngũ phát triển phần cứng. Định nghĩa phần cứng hoàn toàn khác biệt so với định nghĩa phần mềm. Tài liệu Yêu cầu Sản phẩm (PRDs) truyền thống và các đặc tả chức năng không chỉ mang lại sự thoải mái cho các nhà phát triển phần cứng mà còn cung cấp các chi tiết cần thiết để phân chia và thực hiện công việc của họ. Yêu cầu các nhà phát triển viết một Câu chuyện Người dùng như: "Là một đơn vị xử lý, tôi cần điều chỉnh điện áp để đảm bảo nguồn vào sạch sẽ..." làm mất đi mục đích của việc nắm bắt giá trị cho khách hàng thông qua Câu chuyện Người dùng và thêm vào sự lãng phí không giá trị mà các nhà phát triển phần mềm đã rất muốn loại bỏ với các nguyên tắc Agile.

Như Mike Cohn, một nhà tư duy tiên phong trong Agile cho phần mềm, đã định nghĩa: "Một Câu chuyện Người dùng là một mô tả ngắn gọn, đơn giản về một tính năng được kể từ góc nhìn của người đó." Từ khóa ở đây là "người". Agile cho các đội ngũ phát triển phần cứng có thể nhận được giá trị đáng kể từ việc viết Câu chuyện Người dùng nhưng phải sử dụng chúng để nắm bắt nhu cầu của khách hàng từ con người, không phải định nghĩa các công việc. Những câu chuyện này sau đó phải được dịch thành các thuộc tính sản phẩm và các công việc liên quan mà thỏa mãn các kết quả mong muốn với các kỹ thuật phù hợp cho các nhà phát triển phần cứng.

Mê tín #5: Bạn Phải Có Thành Viên Trong Nhóm Chuyên Dụng

Một cuộc thăm dò trên LinkedIn do Vitality Chicago thực hiện cho thấy 54% người thực hành Agile nói rằng việc có một đội ngũ Scrum hoặc Agile chuyên biệt (tức là các thành viên đội ngũ chuyên biệt) là một quy tắc thiết yếu của Agile. Mặc dù trong Bản Tuyên ngôn Agile không thảo luận về đội ngũ chuyên biệt, các chuyên gia Agile thường coi đây là một quy tắc, và khó có thể phản bác rằng việc có các thành viên đội ngũ tập trung 100% vào một dự án sẽ mang lại nhiều lợi ích. Sẽ có ít lý do để không đạt được cam kết, không có gì để làm phân tâm thành công, và không ai nói: "Dự án khác này có ưu tiên cao hơn trong tuần này!"

Tuy nhiên, nếu bạn từng làm việc trong môi trường phát triển phần cứng, bạn sẽ biết rằng việc có các thành viên trong nhóm chuyên dụng là một đặc quyền mà ít tổ chức nào có thể chi trả được. Bản chất của việc phát triển phần cứng là các kiến trúc sư, nhà thiết kế chính và các chuyên gia về chủ đề (SMEs) thường xuyên cần tham gia vào nhiều dự án. Một công ty có thể có một chuyên gia về tần số vô tuyến được gọi đến khi cần đến kiến thức chuyên môn của họ, một chuyên gia về bố trí được cần vào những thời điểm quan trọng, v.v. Các nhóm phát triển phần cứng vẫn có thể áp dụng và tận dụng phương pháp Agile, nhưng việc có các thành viên chuyên dụng thường không phải là một lựa chọn. Do đó, việc có một phương pháp quản lý nguồn lực hỗ trợ Agile là rất quan trọng để thành công lâu dài với Agile.

#Huyền thoại 6: Agile Là Tổng Hợp Của Các Vai Trò, Nghi Lễ, Lễ Tổ Chức và Vốn Từ Được Định Nghĩa

Hai nhóm đang làm việc cạnh nhau trong một công ty: một nhóm phần cứng sử dụng phương pháp truyền thống waterfall và một nhóm phần mềm sử dụng phương pháp Scrum. Một nhà phát triển phần cứng đi ngang qua phòng họp nơi các nhà phát triển phần mềm đang tập trung thành một vòng tròn và nghe thấy, "Ok, chào mừng đến với cuộc họp đứng của chúng ta. Trong sprint cuối cùng, chúng ta gặp khó khăn với việc ước lượng điểm câu chuyện người dùng và tiêu chí chấp nhận. Scrum master của chúng ta đã chia sẻ bảng burn-up mới nhất và tổ chức một cuộc họp tổng kết để giải quyết các vấn đề trong việc chăm sóc backlog của chúng ta để chúng ta có thể tăng tốc độ. Hãy đưa ra ý kiến từ một đến năm về cảm nhận của chúng ta về những thay đổi." Một loạt các cấu hình nắm đấm và ngón tay nhanh chóng xuất hiện.

Nhà phát triển phần cứng, mặc dù tò mò, không thể không cảm thấy một chút bối rối trước nghi lễ kỳ lạ này và sự phong phú của các thuật ngữ không quen thuộc, tự hỏi làm thế nào những phương pháp linh hoạt này có thể được áp dụng vào thế giới phát triển phần cứng hữu hình của mình. "Liệu tôi có vô tình bước vào một giáo phái không?!" anh tự hỏi.

Thường thì, các chuyên gia Agile quá đắm chìm trong ngôn ngữ và văn hóa của Agile dành cho phần mềm đến mức họ tin rằng các đội ngũ phần cứng cũng phải áp dụng chính xác những nghi thức, vai trò, công cụ, và ngôn ngữ giống hệt để thực sự "trở nên Agile." Một cách trớ trêu, nguyên tắc đầu tiên trong Bản Tuyên Ngôn Agile nói rằng, "Cá nhân và tương tác lên trên quy trình và công cụ." Tôi nghĩ chúng ta có thể xây dựng thêm vào điều này và khẳng định rằng, "Cá nhân và tương tác lên trên quy trình, công cụ, nghi thức, và giáo điều." Mặc dù việc đồng thuận về ngôn ngữ, định dạng cuộc họp, và các hoạt động cụ thể để xây dựng tư duy Agile và cách làm việc có hệ thống là tất cả quan trọng cho sự thành công, việc áp dụng các nghi thức và từ vựng cụ thể của Scrum hay Agile dành cho phần mềm không phải là điều cần thiết. Các đội ngũ phần cứng phải xem xét mục đích và ý định của từng yếu tố Agile, nghi thức, và vai trò để xác định cái nào và làm thế nào mỗi cái có thể đáp ứng tốt nhất nhu cầu của họ.

Lấp Lại Khoảng Cách Agile-Phần Cứng

Khi bạn cân nhắc liệu phương pháp Agile có phù hợp với nỗ lực phát triển phần cứng và điện tử của mình không, "tri thức" thông thường được truyền bá bởi những chuyên gia Agile tốt ý thường không đủ để hướng dẫn một cách tiếp cận linh hoạt, thích ứng cần thiết cho việc phát triển sản phẩm vật lý. Con đường đến với việc triển khai Agile thành công trong lĩnh vực phần cứng bao gồm sự kết hợp suy nghĩ của sự linh hoạt, chuẩn bị trước, lập kế hoạch lặp đi lặp lại, và một cách tiếp cận có ý thức để hội tụ vào giải pháp có giá trị nhất có thể trong thời gian ngắn nhất.

Trong phần kết luận của loạt bài ba phần của chúng tôi, chúng tôi sẽ đi sâu hơn vào việc khai thác những lợi ích của Agile được điều chỉnh cho phát triển phần cứng điện tử, tất cả trong khi vẫn giữ vững các nguyên tắc cốt lõi của phương pháp Agile. Bạn có quan tâm đến việc khám phá chủ đề này chi tiết hơn không? Xem webinar!