Làm thế nào để tạo mẫu nhanh phù hợp với một phương pháp nhanh?

Tôi làm việc cho một công ty lớn, nơi chỉ đạo việc sử dụng các quy trình nhanh. Ví dụ: đối với các dự án của chúng tôi, chúng tôi sử dụng các dịch vụ dựa trên đám mây được nhắm mục tiêu cụ thể để quản lý phát triển nhanh.

Nhóm kỹ thuật cụ thể mà tôi làm việc không có phần mềm phát triển truyền thống (thay vào đó chúng tôi giúp thúc đẩy các dự án từ quan điểm chim mắt hơn nhiều), nhưng điều đó đang thay đổi. Chúng tôi có một loạt các dự án phần mềm sắp tới / được lên kế hoạch chủ yếu tập trung vào dữ liệu - ví dụ: chúng tôi sẽ thực hiện giám sát dữ liệu, thu thập, tổng hợp và báo cáo. Các nhiệm vụ khác liên quan đến tự động hóa với phần cứng chuyên dụng và các loại kiến ​​trúc máy khách / máy chủ (đa nhiệm). Tôi sẽ hỗ trợ trong quá trình thuê nhiều người và xây dựng nhiều kế hoạch của chúng tôi để tiến lên phía trước.

Câu hỏi của tôi là liệu việc tạo mẫu nhanh (mã vứt bỏ) có phù hợp với triết lý nhanh hay không. Ví dụ, tôi yêu Python và một loạt các gói. Tôi thấy khả năng thực hiện nhiều ý tưởng của chúng tôi rất nhanh với quy trình làm việc dựa trên Python. Tuy nhiên, tôi nghĩ rằng sẽ có rất nhiều nhận thức rằng Python không phải là "chất lượng doanh nghiệp" và phần lớn công việc này sẽ cần phải được viết lại bằng Java hoặc có thể là C ++.

Tuy nhiên, việc tạo các nguyên mẫu Python sẽ mang lại cho chúng ta rất nhiều lợi ích trong việc giúp chúng ta nhanh chóng cung cấp kết quả thực sự.

Bạn đã có thể kết hợp tạo mẫu nhanh - hy vọng trong Python - vào một quy trình làm việc nhanh nhẹn vững chắc trong môi trường doanh nghiệp chưa?

Khái niệm "tạo mẫu", như dự định trong RAD , hơi xa lạ với sự phát triển nhanh. Điều này không có nghĩa là nó không thể được thực hiện, nhưng nó không bình thường.

Có nhiều trường hợp khác nhau cần được khám phá:

1. Nguyên mẫu có phải là "vỏ rỗng", mô phỏng hoặc bản demo, được xây dựng để đưa ra ý tưởng về một sản phẩm sẽ trông như thế nào không? Bạn chắc chắn có thể làm điều đó với một hoặc nhiều câu chuyện - tuy nhiên bạn đang xây dựng một cái gì đó ngoài sức tưởng tượng của riêng bạn, không xây dựng một sản phẩm từ phản hồi thực. Mọi người không đánh giá một bản demo như họ đánh giá một sản phẩm. Ví dụ, xem phản hồi về nguyên mẫu thanh trên cùng của chúng tôi so với triển khai thanh trên cùng thực sự của chúng tôi .

2. Là nguyên mẫu một cái gì đó cần phải được xây dựng để hiểu rõ hơn không gian vấn đề? Sau đó, nó phải được bao phủ như một mũi nhọn và chỉ giữ kết quả của nó (mã nguồn là nhất thời).

3. Nguyên mẫu có phải là phiên bản 0.x không? Một sản phẩm khả thi tối thiểu ? Sau đó sử dụng quy trình nhanh của sự lựa chọn của bạn cho nó. Nếu bạn cần xây dựng lại nó bằng ngôn ngữ khác, bạn có thể sẽ tốt hơn nếu bạn đối xử với một sản phẩm khác. Lưu ý rằng đôi khi điều này được coi là một cách viết tắt một thông số ("nó nên làm giống như nguyên mẫu!"). Đó là một cách thực sự kém để ghi lại một sản phẩm, nhưng điều này có lẽ được giải thích tốt hơn dưới dạng một câu hỏi và câu trả lời riêng biệt :-)

Không phải là tạo mẫu nhanh (tức là phát triển lặp và tăng dần) của toàn bộ điểm của Agile?

Có vẻ như bạn đang gặp vấn đề với "nhận thức là thực tế" tại tổ chức của mình. Bạn có thể muốn nhắc nhở mọi người rằng Agile không có nghĩa là "loại bỏ tất cả các kế hoạch", bất kỳ điều gì ngoài Phát triển dựa trên thử nghiệm có nghĩa là "loại bỏ tất cả kiến ​​trúc".

Và Python không phải là ngôn ngữ đồ chơi. NASA và các nhà thầu của nó sử dụng Python và nếu nó đủ tốt cho họ, thì nó đủ tốt cho tôi.

Có một thực tiễn khá vững chắc trong Lập trình cực đoan được gọi là Spike . Điều này có nghĩa là nó là mã vứt đi. Không có gì đặc biệt trong đó. Nó chỉ là một Sprint trong đó kết quả mong đợi là kiến ​​thức về mã ném.

Các liên kết trên có đủ thông tin về các thực hành tốt, cạm bẫy của gai.

Trường hợp sử dụng cụ thể của bạn có vẻ là một ví dụ tốt: có thể hữu ích khi thiết kế giao diện, xác thực tiện ích và hiển thị cho một số người dùng.

Bạn sẽ vứt mã đi và không đưa nó vào sản xuất (làm cho nó hoàn toàn rõ ràng với MỌI NGƯỜI), vì vậy việc nhanh nhẹn hay không thực sự không quan trọng. Bất kỳ thực hành nhanh nào hoàn toàn là tùy chọn cho các nguyên mẫu: chạy nước rút, ghi lại, thử nghiệm, lập trình cặp hoặc bất cứ điều gì khác mà bạn dự định sử dụng.

Nếu bạn chủ yếu xây dựng các mô hình chức năng trong Python để giúp chủ sở hữu sản phẩm và những người ra quyết định khác khái niệm hóa dự án, bạn không cần phải sẵn sàng cho doanh nghiệp. Tuy nhiên, nếu bạn đang tạo bằng chứng về khái niệm hoặc cố gắng xem liệu bạn có thể xử lý các mức hiệu suất nhất định hay không, có lẽ bạn nên tuân theo ngôn ngữ sản xuất. Điều đó không có nghĩa là bạn không thể thử nó trong Python.

Bất kể, bạn sẽ vứt mã đi, nhưng có kiến ​​thức về việc có thể thực hiện công việc này cùng với ý thức tốt hơn về những gì chủ sở hữu muốn. Bây giờ bạn có thể sử dụng bất kỳ phương pháp nào bạn muốn.

Tôi muốn thêm rằng các nguyên mẫu rất quan trọng cho việc học và cả tinh thần Agile. Nếu nguyên mẫu cho phép bạn tìm hiểu, đặc biệt là trong các chu kỳ phản hồi nhanh hơn, thì hãy tìm nó. Đó là tất cả về tối đa hóa việc học và chia sẻ học tập với nhóm.

Về mặt học tập, tôi muốn thêm rằng việc tạo mẫu sẽ giúp bạn học nhanh hơn. Bằng cách đó, bạn có thể xác thực xem mọi người thậm chí có quan tâm đến vấn đề bạn đang cố gắng giải quyết hay không - và liệu giải pháp bạn có là tất cả những gì họ đang tìm kiếm - mà không lãng phí nhiều thời gian để xây dựng một giải pháp đầy đủ có thể , cuối cùng, không giải quyết một vấn đề đủ đau đớn hoặc không giải quyết nó đúng cách.

Tinh thần thực sự của Agile là về sự tương tác và giao tiếp. Tôi sẽ nói nếu nguyên mẫu hoạt động tốt như một công cụ giúp giao tiếp, thì không có gì sai khi sử dụng nó trong thế giới Agile. Trong nhóm của chúng tôi (chúng tôi đã thực hành Agile hơn 5 năm), chúng tôi đã sử dụng nó theo thời gian. Và có một số lợi ích tôi có thể thấy từ đó

1) Hỗ trợ liên lạc

2) Đưa người dùng vào các cuộc phỏng vấn giải pháp và nhận phản hồi sớm

Hãy cẩn thận:

Giao tiếp trực tiếp giữa UX và các kỹ sư KHÔNG BAO GIỜ được thay thế bởi bất kỳ tạo tác tạo mẫu nào. Nếu có thể, việc ghép đôi với kỹ sư hoạt động tốt hơn nhiều so với giao tiếp thông qua một người hòa giải (nguyên mẫu).

Những người khác đã đề cập đến mục đích học tập của gai. Điều còn thiếu là nguyên tắc nhanh nhẹn cơ bản của nó là thất bại nhanh chóng .

Một trong những trụ cột trong phát triển nhanh là nhận ra các phần cứng và tìm bằng chứng về các khái niệm, xem bạn có thể làm điều đó không. Cách thức cổ điển để thực hiện theo cách của bạn thông qua tất cả các nhiệm vụ theo thứ tự "hợp lý" có thể thực sự tốn kém nếu bạn thấy bạn không thể làm điều gì đó muộn trong dự án. Tất cả mọi thứ được thực hiện cho đến nay có thể là một sự lãng phí.

Nếu nó phải kết thúc theo cách đó bạn muốn biết càng nhanh càng tốt. Sau đó, các bên liên quan có thể chọn ngừng đốt tiền trong khi chưa có nhiều tiền bị cháy và chấp nhận những gì họ muốn là không khả thi hoặc thử một cách tiếp cận hoàn toàn khác với vấn đề sẽ có cơ hội thành công mới. Nếu các nguyên mẫu của bạn đang phục vụ mục đích này thì chúng thực sự nhanh nhẹn nhất.