Scrum cho các thiết bị hệ thống nhúng

8

Trong công ty của chúng tôi, chúng tôi sẽ cung cấp một sản phẩm mới sẽ được sử dụng để thông báo đại chúng, vì vậy đây là một dự án phần mềm nhúng và chúng tôi sẽ sử dụng SCRUM làm khung cho sản phẩm.

Chúng tôi đã bắt đầu viết ra các sản phẩm tồn đọng. Dựa trên những gì tôi hiểu, tồn đọng sản phẩm sẽ phản ánh giá trị kinh doanh cho từng mặt hàng. Bản chất của phần mềm nhúng là nó có rất nhiều chi tiết kỹ thuật sẽ tiêu tốn một lượng lớn thời gian để tạo trình điều khiển cho các bộ vi điều khiển, như SPI, UART, ethernet, WIFI, v.v.

ví dụ: Hệ thống phát ra âm thanh bằng cách phát thông báo để thông báo, vì vậy khá rõ ràng rằng việc phát một tin nhắn là một giá trị kinh doanh nhưng để đạt được mục tiêu này, tôi phải viết ra những yêu cầu không phải như thế nào - đối với nhiều trình điều khiển như SPI, trình điều khiển chip giải mã MP3, trình điều khiển thẻ SD và cuối cùng là FAT, vì vậy tất cả các trình điều khiển trước đó đều có các yêu cầu phải được ghi trong hồ sơ tồn đọng của sản phẩm, sao cho các yêu cầu bắt đầu với một yêu cầu giá trị doanh nghiệp trong khi nó có nhiều kỹ thuật yêu cầu phụ.

Chúng không phản ánh giá trị kinh doanh cho khách hàng; ai đó có thể cho tôi biết làm thế nào tôi sẽ tạo ra sản phẩm tồn đọng của tôi?

scrum embedded-systems

— Mohamed Fawzy
nguồn

Bạn nên chia vấn đề của mình thành các bước nhỏ hơn, giống như bạn nên chia đoạn văn của mình thành nhiều câu. Nếu bạn không thể chia nhỏ vấn đề của mình thành các bước nhỏ hơn, thì có lẽ scrum không phải là hướng đi.

— Kevin Workman

1

Bạn có thể thấy rằng để phát triển nhúng, một số tác vụ (như các trình điều khiển đó) sẽ lớn hơn khuyến nghị thường thấy. Điều này đôi khi không thể tránh khỏi và bạn sẽ phải sống với nó.

— Bart van Ingen Schenau

1

Vấn đề là bạn đang tập trung vào cách bạn muốn đạt được kết quả. Điều này chỉ không hoạt động nhanh nhẹn. Tập trung vào những gì khách hàng của bạn muốn, bắt đầu từ những điều cơ bản, và sau đó cắt các tính năng này theo chiều dọc mà không chỉ định cách đạt được chúng. Vấn đề không phải là "viết một trình điều khiển" mà là "khách hàng của chúng tôi làm gì với một trình điều khiển".

— Sklivvz

1

Tôi có nghi ngờ nghiêm trọng rằng Scrum là cách tiếp cận tốt nhất cho các hệ thống nhúng. Bạn có thể làm nhanh nhẹn dựa trên scrum, không phải Scrum. Mối quan tâm chính của tôi là xung quanh các khái niệm Scrum va chạm với thế giới thực của thời gian và chu kỳ phát triển phần cứng. Bạn đã xem xét các phương pháp Agile khác chưa?

— mattnz

1

@Blrfl, vâng, vấn đề thể hiện rằng một cái gì đó là cần thiết để cung cấp giá trị kinh doanh, nhưng không, tự nó, đủ cho nó. Nhiều sản phẩm thực tế chỉ có giá trị như các wholes tích hợp, trong đó giá trị của chúng có thể được định lượng bằng thực tế của việc bán và vô giá trị (hoặc gần như vô giá trị) như là các bộ phận.

— Steve

11

Nơi tôi làm việc, chúng tôi tạo ra các hệ thống nhúng và cũng đang sử dụng scrum cho sự phát triển của chúng tôi. Bạn đang nhìn mọi thứ từ góc độ kỹ thuật , không phải là quan điểm tính năng .

Điều đầu tiên bạn nên hỏi là "Tại sao chúng ta cần thực hiện điều này?" Ví dụ: Tại sao bạn cần SPI? Nó sẽ được sử dụng cho EEPROM để bạn có thể lưu trữ số sê-ri? Hoặc có thể kết nối với bộ điều khiển hiển thị để người dùng có thể nhìn thấy các mục trên màn hình? Có rất nhiều lý do tốt để tạo trình điều khiển SPI, nhưng tạo ra nó chỉ để nó không phải là một trong những lý do đó.

Với Scrum, bạn nên áp dụng chính sách "Chúng tôi không cần đến khi chúng tôi cần " , nghĩa là bạn không nên lãng phí thời gian với SPI hoặc wifi hoặc bất cứ điều gì khác cho đến khi có nhu cầu kinh doanh đòi hỏi những công nghệ đó đạt được. Sau đó, nhu cầu kinh doanh đó trở thành câu chuyện.

Hãy thử "Thêm vào EEPROM để lưu trữ cấu hình" thay vì "Tạo mã SPI"

và "Tạo kết nối với máy chủ để quản lý từ xa" thay vì "Tìm tài liệu cho WIFI và triển khai"

— Ampt
nguồn

2

Bạn sẽ làm gì nếu (a) thêm mã xử lý SPI khá phức tạp (ví dụ: xung quanh càng nhiều điểm bạn có thể xử lý trong một lần chạy nước rút, thậm chí có thể nhiều hơn) và (b) có một số câu chuyện người dùng yêu cầu mã xử lý SPI?

— gièm pha

thực sự đây là mối quan tâm của tôi sẽ dẫn đến một loạt các yêu cầu kỹ thuật được kế thừa cho một yêu cầu giá trị kinh doanh. Vì vậy, cuối cùng, tồn đọng sản phẩm sẽ chứa rất nhiều yêu cầu kỹ thuật không phải là giá trị kinh doanh, Tôi có thể chấp nhận hay tôi vi phạm một trong những khái niệm nhanh?

— Mohamed Fawzy

Bạn không nên quá buồn với những người thuê nhà nhanh nhẹn. như Bryan đã nói, bạn không nên quá bận tâm đến giáo điều và chỉ làm những gì có ích cho bạn. Quan điểm chính của tôi ở đây là bạn chỉ nên cố gắng và giữ giá trị kinh doanh trong tâm trí. Những gì bạn làm có thể không thêm giá trị kinh doanh trực tiếp vào cuối câu chuyện, nhưng nó sẽ dẫn đến mục tiêu đó.

— Ampt

1

Ví dụ cực đoan khi chơi quỷ ủng hộ: Điều gì xảy ra nếu tôi không thực hiện giao diện SPI vì tôi không cần nó (giáo điều Scrum), rồi một ngày, tôi thực sự cần nó. Tôi thực hiện SPI và tìm thấy một lỗi phần cứng. Bỏ qua việc tôi có thể đã chuyển phần cứng rồi, thời gian chờ cho phần cứng cố định là 6 tháng (khá phổ biến) nhưng Scrum yêu cầu tôi thực hiện ngay trước khi tôi cần. Giải pháp Scrum cho vấn đề này là gì?

— mattnz

@mattnz Điều này hơi muộn, nhưng câu trả lời của scrum là bạn nên có mối quan tâm kinh doanh sớm trong việc loại bỏ các lỗi phần cứng và thực hiện giao diện SPI sớm sẽ có giá trị kinh doanh. Bạn phải chú ý đến nhu cầu thực tế của mình, đây không phải lúc nào cũng là một quá trình đơn giản. Như với tất cả các quy trình công việc, việc triển khai Scrum ngây thơ sẽ thất bại. Tương tự như vậy, việc triển khai EVMS ngây thơ hoặc bất kỳ cách tiếp cận từ trên xuống nặng nề nào khác cũng sẽ thất bại.

— Cort Ammon

5

Đừng bị treo lên trên giáo điều scrum. Scrum tồn tại để làm cho bạn nhanh nhẹn hơn. Bất cứ điều gì cản trở điều đó có thể được bỏ qua.

Đúng là bạn không nên làm công việc không mang lại giá trị kinh doanh, nhưng giá trị có nhiều dạng. Bạn có nhận được giá trị từ việc có trình điều khiển ethernet? Tôi nghi ngờ bạn làm thế, bởi vì không có nó, bạn không thể cung cấp các tính năng nhất định. "Là một nhà phát triển, tôi cần một trình điều khiển ethernet để tôi có thể triển khai các tính năng yêu cầu kết nối internet".

Vì vậy, đừng xem giá trị chỉ là các tính năng hiển thị của người dùng. Giá trị là bất cứ điều gì làm cho sản phẩm của bạn tốt hơn, ngay cả khi nó vô hình với người dùng cuối.

Một số người sẽ nói rằng đó không phải là một câu chuyện hợp lệ và các câu chuyện chỉ nên có các tính năng hiển thị của người dùng. Tôi nghĩ điều đó cũng ổn, cho đến khi nó gây ra cho bạn những vấn đề như thế này. Một lần nữa, mục tiêu của scrum là giúp bạn, và cải thiện sự tập trung và giao tiếp. Đừng để những gì bạn nghĩ là bạn phải làm theo cách bạn hoàn thành công việc. Hãy thực dụng, và trung thực. Nếu bạn nghĩ rằng bạn cần phát triển một điều gì đó, hãy trả lời câu hỏi "tại sao" và "đây là vì ai?". Câu trả lời không phải luôn luôn là cùng một người.

— Bryan Oakley
nguồn

Scrum giáo điều trong câu hỏi ban đầu là gì? Giải thích sai không phải là Giáo điều. Giáo điều sẽ là nếu Scrum có những thực hành không thể áp dụng được.

— Dave Hillier

3

Theo tôi, một trong những thách thức chính khi sử dụng Scrum với phát triển nhúng là các nhóm Scrum tốt nhất cung cấp các lát chức năng làm việc đầy đủ. Từ ruột sâu nhất đến tiếp xúc với người dùng. Điều này giữ cho các vấn đề tích hợp trong một nhóm và trong một lần chạy nước rút. Và nó chứng minh giá trị kinh doanh vì người dùng cuối có thể xem và thử kết quả.

Ngay cả đối với phần mềm thuần túy cũng có thể khó khăn để làm cho câu chuyện đủ mỏng ở mỗi cấp độ để toàn bộ câu chuyện có thể được xây dựng trong một hoặc hai lần chạy nước rút. Nhưng đối với nhúng, điều này có thể là không thể bởi vì ruột sâu nhất liên quan đến phần cứng không thích ứng nhanh như phần mềm vì nó có căn cứ trong thế giới vật lý.

Giải pháp lý tưởng là nâng cao khả năng phần cứng của bạn để chúng có thể quay vòng nhanh hơn ... với trình giả lập, chạy vòng quay nhanh, mô hình, v.v. Nhưng điều đó có thể tốn kém. Vì vậy, một thỏa hiệp thường được sử dụng, mà tôi nghĩ áp dụng cho tình huống của bạn, là để thư giãn khái niệm giá trị doanh nghiệp và để nó bao gồm các khả năng chung hơn mà người dùng cuối và ứng dụng của bạn yêu cầu.

Vì vậy, ví dụ, nếu bạn sẽ cần xây dựng WiFi, tốt hơn hết là có lý do người dùng cuối hoặc tại sao bạn lại làm như vậy. Tìm điều đó và đưa nó vào định nghĩa câu chuyện của người dùng, như câu chuyện này cho ô tô: "Cung cấp chức năng kiểm soát người sử dụng không dây, để đáp ứng nhu cầu của hành khách đồng thời giảm chi phí và tăng độ tin cậy và khả năng bảo trì."

— Bob
nguồn

Tôi không bao giờ nghĩ rằng sự tương tự sản xuất ô tô với phần mềm là rất thích hợp. Ô tô đã có một thiết kế khá ổn định trong một thế kỷ, và chỉ được xây dựng bởi các công ty lớn nhất tạo ra và giữ các chuyên gia giàu kinh nghiệm trong tất cả các lĩnh vực. Dù sao, xe hơi ngày nay chủ yếu là các tính năng bắt vít và các tinh chỉnh nhỏ, không được thiết kế và chế tạo từ dưới lên, và thay đổi thiết kế vẫn phải mất nhiều năm. Phát triển phần mềm thực sự ít liên quan đến kinh doanh xe hơi.

— Steve

1

@Steve anh ấy không làm điều tương tự. Anh ấy đưa ra một ví dụ về một câu chuyện mà bạn có thể tìm thấy trong hồ sơ tồn đọng của một đội ô tô.

— RubberDuck

@RubberDuck, tôi nghĩ rằng anh ta phải ngầm hiểu (và có ý định cho người đọc nhận thức) một số tương tự với quá trình sản xuất ô tô hoặc quy trình sản xuất tương tự - chính xác là những gì tương tự được coi là không thể nói và chưa được định nghĩa, nhưng điều đó không có nghĩa đây không phải là thời điểm thích hợp để nhận xét và bác bỏ sự tương tự, và cách các quy trình được sử dụng trong sản xuất được sử dụng trong các trường hợp và điều kiện hoàn toàn khác nhau so với tồn tại để phát triển phần mềm.

— Steve

1

Tôi đã tìm thấy liên kết này trong số những điều khác nói về câu chuyện của người dùng trong phát triển nhúng (đảm bảo bạn cuộn xuống để đến phần Câu chuyện)

Những câu chuyện

Chúng ta sẽ phải xem xét các câu chuyện sâu hơn vì một trong những thách thức lớn của phát triển Agile là phá vỡ hệ thống thành các câu chuyện cho phép tiến triển rõ rệt và rõ ràng trên sản phẩm. Phát triển nhanh được nhúng thậm chí còn có nhiều thách thức hơn trong việc xác định các câu chuyện vì sự phức tạp thêm của các tương tác phần cứng / phần mềm.

Câu chuyện thường được gọi là Câu chuyện người dùng. Tôi thích gọi chúng là Câu chuyện sản phẩm. Thông thường công việc chúng tôi làm trong phát triển nhúng không hiển thị cho người dùng cuối. Cái tên Product Story có vẻ phù hợp hơn.

Một câu chuyện sản phẩm mang lại giá trị, cho thấy sự tiến bộ hoặc giảm một số rủi ro và có thể được hoàn thành trong một lần lặp.

— jramirez
nguồn