Làm thế nào để bạn xử lý công việc phi chức năng với Scrum trong các hệ thống nhúng?

Tôi có hai vấn đề với Scrum trong các hệ thống nhúng. Đầu tiên, có nhiều nhiệm vụ phải làm, đặc biệt là trong giai đoạn đầu, không thể chứng minh được. Chúng tôi bắt đầu với một bảng phát triển, không có hệ điều hành, không hiển thị, không giao tiếp nối tiếp, v.v. Chúng tôi không có màn hình cho sáu lần chạy nước rút.

Bốn lần chạy nước rút đầu tiên là:

• Bắt RTOS và chạy
• Tạo tác vụ viết trình điều khiển mạng và nối tiếp
• Viết các thói quen ngắt cho các nút, giao tiếp, vv
• Viết các lớp và phương thức cơ sở dữ liệu chính
• Viết một menu gỡ lỗi nối tiếp

Hầu hết các tác vụ này không phù hợp với câu chuyện của người dùng. Trên thực tế, giao diện duy nhất trong toàn bộ hệ thống là menu gỡ lỗi nối tiếp, được xây dựng trong lần chạy nước rút 3, vì vậy không có gì để chứng minh ở cuối các lần chạy nước rút. Ngay cả menu nối tiếp cũng có nghĩa là để sử dụng nội bộ và không phải là người dùng cuối. Tuy nhiên, tôi vẫn muốn theo dõi và quản lý các hoạt động phát triển này thông qua Scrum.

Cuối cùng chúng tôi đã viết các cụm từ "câu chuyện người dùng" như "Là nhà phát triển ...", điều mà tôi không hài lòng nhưng khi sử dụng Target Process (www.target Process.com), không có khái niệm về một mục tồn đọng một nhiệm vụ hoặc việc vặt.

Thứ hai, làm thế nào để bạn xử lý các bản phát hành và thử nghiệm? Đó là một nỗi đau thực sự đối với chúng tôi bởi vì những người thử nghiệm không có trình gỡ lỗi phần cứng, vì vậy chúng tôi phải xây dựng các phiên bản flash của mã và ghi chúng lên bảng phát triển của họ để kiểm tra. Những người thử nghiệm không có kỹ thuật sắc sảo như các nhà phát triển và thường yêu cầu rất nhiều hỗ trợ trong việc giúp mọi thứ hoạt động ở giai đoạn đầu (đặt lại bảng, kết nối giao tiếp nối tiếp, v.v.) hoặc thậm chí là hiểu đầu ra.

Cuối cùng, liên quan đến định nghĩa hoàn thành, một lần chạy nước rút không thể hoàn thành cho đến khi tất cả các câu chuyện hoàn tất. Tất cả các câu chuyện không hoàn thành cho đến khi được kiểm tra bởi người kiểm tra. Không có cách nào để tránh "cướp" thời gian của nhà phát triển để cung cấp cho người thử nghiệm. Nói cách khác, nếu ba câu chuyện người dùng cuối cùng trong lần chạy nước rút sẽ mất năm ngày để kiểm tra, thì chúng phải được mã hóa và đơn vị được kiểm tra năm ngày trước khi kết thúc cuộc chạy nước rút. Nhà phát triển phải làm gì? Ngừng hoạt động?

Tôi là người lãnh đạm, nhưng đó là một vấn đề thực sự khi cố gắng tuân thủ các quy tắc. Bây giờ, tôi ổn với việc bẻ cong các quy tắc, nhưng vấn đề tôi gặp phải là, nó làm hỏng tất cả các số liệu ban đầu của tôi nếu tôi không thể đánh dấu mọi thứ được thực hiện cho đến khi chúng được kiểm tra.

Tôi muốn nghe cách những người khác đã xử lý các tình huống này.

Bạn đang sử dụng một phương pháp luận trên một sản phẩm không tương thích IMHO.

Theo cách mà hầu hết mọi người định nghĩa nhanh nhẹn, tất cả các công việc đều có thể thương lượng dựa trên các ưu tiên thay đổi, có thể đặt hàng lại hoặc có thể thay thế.

Theo cách mà hầu hết mọi người định nghĩa thác nước là công trình được sắp xếp theo trình tự trước thời hạn từ một nỗ lực kiến ​​trúc quan trọng lúc ban đầu.

Các nhiệm vụ bạn liệt kê ở trên dường như rất thác đối với tôi. Họ phải theo một trật tự nhất định, và họ không thể thương lượng.

Tôi không nói rằng bạn phải tuân theo quan điểm của bất kỳ ai về bất kỳ quy trình nào, nhưng ít nhất là đối với những nhiệm vụ này, bạn dường như đang ở trong một dự án không nhanh nhẹn với tôi. Cố gắng đưa bash vào một quy trình nhanh sẽ trở nên phù hợp nhất.

Nếu phần còn lại của dự án phù hợp với sự nhanh nhẹn, tôi sẽ không lo lắng quá nhiều về việc thiết lập ban đầu là không phù hợp, nhưng việc bạn đề cập đến RTOS và các ban phát triển khiến tôi nghi ngờ toàn bộ điều này sẽ tốt hơn trong một điều gì đó như thác nước (một chuỗi dài các phụ thuộc bất động).

OK, vì vậy tôi không biết gì về việc xây dựng các hệ thống nhúng, nhưng từ những gì tôi có thể thấy thì không có gì có thể khiến Scrum không phù hợp để phát triển như vậy. Thật dễ dàng để bị bắt gặp lo lắng về việc không thực sự có chức năng đối mặt với người dùng vì vậy rất khó để viết "câu chuyện người dùng" với việc có người dùng. Ngoại trừ những câu chuyện của người dùng không thực sự là một phần của Scrum - chúng thường được sử dụng với Scrum - nhưng thực sự chỉ là một công cụ.

Phần của Scrum là ý tưởng cung cấp các tính năng hoàn chỉnh được kiểm tra đầy đủ và có khả năng triển khai trong môi trường trực tiếp mỗi Sprint. Khi bạn bắt đầu từ đầu vào một trong bất kỳ loại dự án nào, giá trị thực của bất kỳ loại chức năng nào bạn có thể cung cấp trong Sprint 1 là khá nhỏ. Đó là bởi vì mọi thứ nhỏ bé cần hàng tấn cơ sở hạ tầng được xây dựng để làm cho nó hoạt động. Nhưng vấn đề là bạn chỉ xây dựng đủ cơ sở hạ tầng để làm cho mỗi tính năng hoạt động. Và sau đó bạn xây dựng nó khi bạn thêm nhiều tính năng.

Ý tưởng là bạn đặc biệt KHÔNG dành nhiều tháng và tháng để xây dựng cơ sở hạ tầng mà không có cách nào bị phát hiện từ bên ngoài hệ thống. Tại sao? Bởi vì cho đến khi bạn xây dựng những thứ thực sự làm công cụ, bạn không biết chính xác cơ sở hạ tầng cần là gì. Đó là thứ bạn học được khi xây dựng các tính năng thực tế của hệ thống. Nếu bạn xây dựng cơ sở hạ tầng ngay từ đầu, thì bạn sẽ xây dựng nó khi bạn biết ít nhất về hệ thống.

Nếu bạn đã chết khi viết truyện người dùng, thì hãy nhớ rằng người dùng không phải là người. Vì vậy, bạn viết những thứ như, "Là một trình xử lý ngắt CMOS, tôi cần có khả năng phát hiện trạng thái của cờ điều chế ngăn xếp bẻ khóa khi máy nén fluxotronic báo hiệu một vòng nạp thụ động". Tuyệt đối không viết câu chuyện người dùng "Là nhà phát triển ...".

Bạn sử dụng Scrum trong một khu vực rất cụ thể và bạn vi phạm quy trình được cho là trên mỗi bước. Câu hỏi của bạn có lẽ nên là: Có một phương pháp nhanh nhẹn nào phù hợp hơn với môi trường của tôi không? Đơn giản, rất khó để giúp bạn làm Scrum tốt hơn nếu môi trường của bạn không cho phép điều đó. Những vấn đề tôi thấy trong mô tả của bạn:

• Không có nhiệm vụ rõ ràng nào có thể được coi là nhiệm vụ cơ sở hạ tầng. Nếu bạn cần một số lần chạy nước rút để làm một cái gì đó không được coi là giá trị doanh nghiệp thì câu chuyện người dùng của bạn có thể được xác định xấu. Nếu bạn cần xây dựng một công cụ hoặc bất cứ thứ gì khác để có thể cung cấp giá trị kinh doanh thì sản phẩm có thể được chia thành hai phần / bản phát hành - xây dựng một công cụ và xây dựng giá trị kinh doanh. Trong trường hợp như vậy, câu chuyện người dùng của bạn "Là nhà phát triển ..." sẽ hoàn toàn hợp lệ, bởi vì một công cụ được tạo cho các nhà phát triển.

  Vấn đề ở đây là làm thế nào để giao tiếp điều này với khách hàng, bởi vì sự tham gia của anh ấy / cô ấy trong phiên bản đầu tiên là bằng không. Nếu không có bất kỳ giá trị kinh doanh nào cho khách hàng, làm sao họ có thể tham gia? Làm thế nào chủ sở hữu sản phẩm có thể xác định ưu tiên kinh doanh?

  Tôi nghĩ rằng vấn đề chính ở đây là đây không phải là thứ phù hợp với Scrum. Scrum cố gắng cung cấp các tính năng kinh doanh quan trọng nhất trước tiên, nhưng bạn cần hai tháng để cung cấp tính năng đầu tiên. Scrum và toàn bộ nhanh nhẹn chấp nhận thay đổi - điều gì sẽ xảy ra nếu sau khi cung cấp các tính năng đầu tiên, khách hàng yêu cầu một số thay đổi quay trở lại qua tất cả các lần chạy nước rút ban đầu của bạn?

• Kiểm tra. Một thất bại khác vì một nhóm trong Scrum được coi là một nhóm các thành viên chức năng chéo. Điều đó có nghĩa là mọi người đều phát triển và thử nghiệm và do đó không có tình huống nào được mô tả trong điểm cuối cùng của bạn (hoặc ít nhất là không phải năm ngày). Điều đó không có nghĩa là không thể có QA riêng biệt để thực hiện một số thử nghiệm phức tạp và phức tạp hơn, nhưng nhóm phải cung cấp một tính năng đã được kiểm tra / xác minh. Trong trường hợp của bạn, có vẻ như Scrum không phải là thứ bạn cần. Bạn cần xử lý riêng phát triển và thử nghiệm và chuyển các tính năng giữa chúng.