Scrum có ý nghĩa khi thực hiện một phụ trợ trình biên dịch mới không?

Tôi có một ngôn ngữ hiện có mà tôi cần chuyển sang một nền tảng mới. Có lẽ tôi sẽ thử điều này bằng cách thay đổi phần phụ trợ của trình biên dịch hiện có.

Đó là một lượng công việc đáng kể để viết lại phần phụ trợ. Tôi không thể thấy một cách chia nhỏ điều này thành những câu chuyện hợp lý mà không vi phạm các tiêu chí ĐẦU TƯ.

Tôi không thể thấy làm thế nào mỗi câu chuyện có thể được Thỏa thuận - tất cả chúng đều cần thiết cho một trình biên dịch làm việc. Các câu chuyện đều có mức độ ưu tiên như nhau và không có vấn đề gì khi tôi giao chúng. Tôi cần phải làm tất cả.

Có một số phần của phần mềm tôi đang triển khai có mức độ ưu tiên thấp hơn các phần mềm khác và tôi có thể thấy rằng chúng tôi có thể phân phối tăng dần. Tuy nhiên, có một cốt lõi quan trọng là Phải có .

Tôi dự định cố gắng theo Scrum, nhưng tôi chỉ đang trải qua những chuyển động?

Có thực hành khuyến nghị cho loại dự án này?

Hãy nhớ rằng lý do chính khiến các quy trình Agile được tạo ra là để đối phó với các yêu cầu thay đổi. Nếu các yêu cầu được đặt ra (các yêu cầu thực sự cố định là rất hiếm nhưng tôi sẽ nói với bạn ở đây!) Thì một số thực tiễn tốt nhất để xử lý các yêu cầu thay đổi - ví dụ như các câu chuyện Thỏa thuận - trở nên không liên quan. Điều đó nói rằng, theo một quy trình làm việc Scrum vẫn có rất nhiều giá trị tiềm năng về mặt lập lịch và cung cấp các sản phẩm giao. Ngay cả khi các sản phẩm của bạn sẽ không tạo thành một sản phẩm hoàn toàn có thể sử dụng được trong một thời gian, vẫn có điều gì đó để nói về khả năng chứng minh sự tiến bộ cho khách hàng của bạn (và nhóm!).

Hãy xem xét rằng tất cả những câu chuyện 'phải có' bao gồm một bản anh hùng ca: "Có thể biên dịch trên nền tảng X". Trong trường hợp này, toàn bộ sử thi cần phải được hoàn thành trước khi bất kỳ giá trị nào được gửi đến người dùng, nhưng điều này thường xảy ra khi bắt đầu các dự án lớn. Bắt đầu với một câu chuyện để biên dịch chương trình đơn giản nhất có thể, sau đó tạo thêm các câu chuyện để hỗ trợ ngày càng nhiều tính năng ngôn ngữ.

Trên hết, đừng quá nôn nao khi cố gắng ép buộc mọi tình huống phù hợp với cách tiếp cận mang tính khái quát cao. Agile được cho là làm việc cho bạn, không phải cách khác!

Tất nhiên Scrum là hữu ích. Đó là một phương pháp thực hiện hai điều cho bạn:

1. Nó cho phép dự án của bạn thích ứng với thay đổi và
2. Nó cho phép bạn theo dõi tiến trình và biết được khi nào nó sẽ hoàn thành

Vì vậy, có một số giá trị trong việc sử dụng nó.

Tôi nghĩ rằng một số điều kiện tiên quyết của bạn là không chính xác và đó là nơi bạn đang bị lạc.

Tôi không thể thấy làm thế nào mỗi câu chuyện có thể được Thỏa thuận - tất cả chúng đều cần thiết cho một trình biên dịch làm việc

Đây không phải là sự thật. Bạn có thể hỗ trợ một tập hợp con của ngôn ngữ và vẫn có trình biên dịch hoạt động trong các điều kiện nhất định. Chắc chắn ít giá trị hơn một trình biên dịch đầy đủ, nhưng vẫn có giá trị.

Ngoài ra, bạn hiểu sai "Thỏa thuận" nghĩa là gì: nó không nhất thiết có nghĩa là "Tùy chọn" và không có yêu cầu nào là câu chuyện là tùy chọn trong ĐẦU TƯ. Một câu chuyện là một mục tiêu có giá trị và cuộc đàm phán là làm thế nào để đạt được mục tiêu đó. Chắc chắn sẽ có nhiều hơn cách thực hiện phụ trợ của từng tính năng ngôn ngữ. Có nơi bạn cần đàm phán.

Các câu chuyện đều có mức độ ưu tiên như nhau và không có vấn đề gì khi tôi giao chúng.

Điều này là không chính xác, như bạn nói dưới đây rằng một số câu chuyện không phải là "phải có", vì vậy chắc chắn một số câu chuyện ít có giá trị. Nhưng ngay cả trong danh mục "phải có": một số tính năng ngôn ngữ cơ bản hơn nhiều so với các tính năng khác và có thể đo lường được như vậy.

Một cách để đo lường điều này là "chúng ta có thể biên dịch thêm bao nhiêu dòng mã trên một cơ sở mã hiện tại" hoặc "có bao nhiêu bài kiểm tra nữa" nếu bạn có một bộ kiểm tra được xác định trước.

Ngoài ra còn có các lựa chọn khác. Nếu bạn đang biên dịch một ngôn ngữ giống như C, nói đúng ra bạn chỉ cần một ifvà gotolặp để có một ngôn ngữ chức năng (hầu như) và bạn có thể thực hiện while, forvà repeatnhư các macro. Giả sử thật dễ dàng để viết một trình biên dịch sử dụng, bạn có thể có một giải pháp ngăn chặn giá rẻ (hey, chúng ta đang đàm phán? :-)

Về khả năng thích ứng, hỗ trợ một ngôn ngữ là một tập hợp các yêu cầu khá tĩnh, nhưng ngôn ngữ cũng thay đổi và kiến thức về nhu cầu của bạn cũng thay đổi. Bạn có cần phải thực hiện mọi thứ? Có những thứ bạn không cần đặc biệt cho mục tiêu của bạn? Một trong những người thuê cơ bản của nhanh nhẹn là kiến ​​thức về việc có kiến ​​thức không đầy đủ, bạn có thể tận dụng nó không?

Tóm lại, để trả lời câu hỏi của bạn trực tiếp hơn: bạn có cần các quy trình nhanh khi yêu cầu của bạn không thể thay đổi? Chắc chắn không phải! Họ có thể sử dụng? Chắc là đúng! Họ có giá trị thời gian của bạn? Có lẽ là không - nhưng yêu cầu của bạn là không thể thay đổi? Theo kinh nghiệm trước đây của tôi, "yêu cầu không thể thay đổi" => "chủ sở hữu sản phẩm lười biếng" - không phải là một quy tắc, nhưng đáng ghi nhớ.

TL; DR

Tất cả các điều khiển quản lý dự án thêm chi phí. Đừng thêm chi phí bạn không cần.

Scrum là Búa sai ở đây (Đừng là một cái đinh)

Scrum là một khung quản lý dự án chứ không phải là một tập hợp các thực tiễn phát triển phù hợp cho một nhà phát triển cá nhân. Trừ khi bạn đang làm quản lý dự án, Scrum có lẽ là lựa chọn sai.

Ngoài ra, khi bạn nói:

Các câu chuyện đều có mức độ ưu tiên như nhau và không có vấn đề gì khi tôi giao chúng. Tôi cần phải làm tất cả.

bạn đang ám chỉ một vài điều:

1. Dự án không có giá trị trừ khi tất cả các câu chuyện đã hoàn thành 100%.
2. Những câu chuyện không phụ thuộc vào nhau.

Nếu cả hai tuyên bố này đều đúng, thì thực sự không có điểm nào trong việc sử dụng khung hoặc thực tiễn được thiết kế để ưu tiên công việc theo giá trị hoặc thứ tự phụ thuộc.

Đề xuất thay thế

Bất kỳ dự án phát triển có thể có khả năng hưởng lợi từ một số thực hành nhanh. Đặc biệt, trong trường hợp cụ thể của bạn, tôi muốn giới thiệu:

1. Đảm bảo tất cả các câu chuyện của bạn có "định nghĩa hoàn thành" bao gồm kiểm tra đơn vị và chấp nhận.
2. Tích hợp và tái cấu trúc thường xuyên; đừng để lại cho mình một nhiệm vụ tích hợp khổng lồ vào cuối dự án.

Ngoài ra, ngay cả khi sản phẩm của bạn thực sự có giá trị bằng 0 trừ khi tất cả các câu chuyện được thực hiện, tôi sẽ dành thời gian để nhóm các câu chuyện thành các chủ đề mà bạn có thể coi là các mốc hoàn thành. Có thể nói "Tôi đã hoàn thành tính năng foo" thường hữu ích hơn so với việc nói "Tôi đã hoàn thành 23/117 câu chuyện ngẫu nhiên". YMMV.

Tôi hiểu mối quan tâm của bạn, nhưng tôi tin rằng vẫn còn giá trị cho bạn trong việc sử dụng scrum.

Phải thừa nhận rằng các câu chuyện của người dùng cố định hơn nhiều so với trong một ứng dụng mà người tiêu dùng phải đối mặt. Vì vậy, khía cạnh của scrum sẽ cung cấp ít giá trị hơn.

Nơi tôi nghĩ bạn sẽ nhận được giá trị là từ các bản phát hành lặp đi lặp lại và thường xuyên . Có một sản phẩm có khả năng phát hành vào cuối mỗi lần chạy nước rút buộc bạn phải giữ chất lượng mã cao và nợ kỹ thuật thấp. Đó cũng là một cách tuyệt vời để tìm ra khuyết điểm sớm.

Tôi nghĩ bạn cũng sẽ được lợi từ việc biết vận tốc của mình . Sau vài lần chạy nước rút, bạn có thể thấy nhóm của mình đang hoàn thành bao nhiêu điểm. Điều này cung cấp cho bạn một số liệu khách quan để giúp xác định ngày giao hàng của bạn.

Trên hết, hãy nhớ rằng nhanh nhẹn là tính từ . Vào cuối mỗi lần chạy nước rút, bạn nên tổ chức một cuộc họp hồi cứu và sau đó điều chỉnh quy trình của bạn theo nhu cầu của bạn. Nếu có một phần của quy trình scrum không áp dụng cho phát triển trình biên dịch, hãy xóa nó. Nếu có một số yếu tố quy trình khác có lợi cho bạn, hãy thêm nó. Theo tôi, phần quan trọng nhất của sự nhanh nhẹn là nhận thức được quá trình của bạn và không ngừng cải thiện cho tình huống cụ thể của bạn.

(Xin lưu ý, tôi chưa bao giờ thực hiện scrum trong dự án biên dịch; hãy nghe lời khuyên của tôi với một hạt muối.)

Đúng vậy, miễn là bạn nhớ rằng Scrum không phải là một bộ quy tắc nghiêm ngặt phải tuân theo. Bạn có thể điều chỉnh nó cho dự án của bạn. Chạy nước rút, đứng lên, scrums hàng tuần sẽ vẫn hữu ích để thúc đẩy giao tiếp tốt hơn giữa các thành viên trong nhóm và để đảm bảo dự án tiếp tục theo hướng đã được dự định.

Tất cả các câu chuyện dường như có một ưu tiên như nhau, nhưng bạn cần tính đến những khó khăn tương đối khi thực hiện chúng. Bạn không muốn giữ những vật phẩm khó nhất của mình cho đến khi kết thúc dự án. Bạn sẽ muốn bắt đầu làm việc với họ càng sớm càng tốt.