Bạn cung cấp gì trong vài lần lặp đầu tiên trong Agile?

Theo tôi hiểu, ý tưởng với các phương pháp của Agile là bạn cung cấp một cái gì đó có chức năng và bạn cung cấp nó thường xuyên. Ứng dụng được gia tăng hình dạng cuối cùng sau khi tăng.

Nhưng trong các lần lặp đầu tiên, bạn có thể xây dựng khung hoặc nền tảng mà ứng dụng sẽ đứng để nó là thứ gì đó quan trọng nhưng không hiển thị cho người dùng.

Điều gì được giao cho khách hàng trong các lần lặp đầu tiên này? Làm thế nào để bạn hiển thị tiến độ đúng hướng khi bạn xây dựng mã giàn giáo?

Nó là điển hình để có nước rút 2 tuần.

Đối với tôi, lần chạy nước rút đầu tiên hoặc 2 có thể sẽ có ít tính năng "hiển thị" hơn so với lần chạy nước rút sau vì lý do chính xác này (đối với một số mô tả khó hiểu về "ít").

Điều đó đang được nói, chắc chắn bạn sẽ không mất 2 tuần để xây dựng toàn bộ giàn giáo của mình và không có gì trong giao diện người dùng hiển thị để hiển thị cho nó.

Có thể bạn không bỏ qua mọi mục trong giàn giáo trong lần chạy nước rút đầu tiên hoặc 2. Có thể các bộ phận có thể chờ và được thêm vào sau.

Có thể lần chạy nước rút đầu tiên của bạn có "Tạo trang web X với dữ liệu giả" để bạn có thể có được thứ gì đó sáng bóng để hiển thị cho khách hàng của mình. Và sau đó lần chạy nước rút tiếp theo có "Thay đổi trang web X để sử dụng dữ liệu từ cơ sở dữ liệu".

Tuyên ngôn Agile cho rằng Phần mềm làm việc có giá trị hơn tài liệu toàn diện và khung Scrum lấy ý tưởng này để đề xuất rằng việc cung cấp phần mềm làm việc được thử nghiệm có giá trị kinh doanh là một yêu cầu mỗi lần chạy nước rút.

Tại sao? Chà, trong số những thứ khác, các nhà thiết kế và nhà phát triển thường trở thành nạn nhân của việc dành nhiều thời gian cho các mục YNNI (bạn sẽ không bao giờ cần đến nó). Thật không may, những khuôn khổ mà bạn đang nói đến thường là một trách nhiệm lớn trong lĩnh vực này. Các nhà phát triển bắt đầu xây dựng tất cả những thứ mà khung MIGHT phải hỗ trợ và đột nhiên bạn được 3 tháng và không có bất cứ thứ gì có giá trị kinh doanh để hiển thị cho nó. Sau đó, hóa ra khuôn khổ thậm chí không thực sự hỗ trợ những gì họ cần.

Vì vậy, cách tiếp cận được đề xuất là chỉ xây dựng những gì thực sự cần thiết bây giờ và cung cấp ngay bây giờ.

Điều này KHÔNG có nghĩa là bạn không thể xây dựng các bộ phận có thể tái sử dụng và tương tự, bạn chỉ luôn làm điều đó để hỗ trợ xây dựng nhu cầu hiện tại. Hơn nữa, điều đó không có nghĩa là bạn phải hoàn toàn mặc đồ che mắt cho những gì sắp xảy ra - đừng xây dựng mọi thứ để không thể thay đổi / nâng cao chúng sau này. Nhưng điều quan trọng là luôn luôn mang lại giá trị kinh doanh.

Thường có một số điều quan trọng cần được thiết lập trước khi mọi thứ có thể được gửi, chẳng hạn như thiết lập môi trường và những thứ tương tự. Đối với những điều này, rất nhiều đội thấy hữu ích khi có "Sprint 0" trong đó nền tảng được đặt. Sprint 0 có thể dài hơn một chút so với các lần chạy nước rút khác của bạn, ở chỗ nó không được áp dụng cho sản phẩm tồn đọng hoặc bị hỏng, nhưng nó vẫn phải được đặt trong một khoảng thời gian hợp lý.

Điều gì được giao cho khách hàng trong các lần lặp đầu tiên này?

Những gì có giá trị kinh doanh cao nhất cho người dùng. Ví dụ: nếu các ứng dụng có các quy tắc kinh doanh phức tạp, (các) lần lặp đầu tiên sẽ chỉ chứa các quy tắc kinh doanh được mã hóa dưới dạng mã. Khách hàng nên hài lòng miễn là bạn có mã cho các quy tắc kinh doanh đó. (Vấn đề thực sự thuyết phục khách hàng chấp nhận một điều như vậy là vấn đề hoàn toàn khác.) Ví dụ: bạn có thể cho các chuyên gia kinh doanh của khách hàng kiểm tra đơn vị / chấp nhận của bạn thể hiện những gì tên miền nên làm và mã đó vượt qua kết quả xanh. Hoặc thậm chí tốt hơn, làm cho các chuyên gia kinh doanh giúp tạo ra các thử nghiệm.

Ngoài ra còn có câu hỏi về

bạn có thể xây dựng khung hoặc nền tảng

Mà tôi tin là quan trọng hơn nhiều so với những gì thực sự được giao. Có một điều lớn đối với Thiết kế tiến hóa , trong đó nói rằng, bạn nên tạo kiến ​​trúc theo thời gian thay vì cố gắng tạo ra nó ngay từ đầu. Đối với nền tảng, điều này thường có nghĩa là một số loại cơ sở dữ liệu hoặc khung UI. Trong trường hợp đó, có ý tưởng về " Kiến trúc tốt là một trong đó cho phép bạn hoãn các quyết định quan trọng ." Và chọn cơ sở dữ liệu hoặc giao diện người dùng là một quyết định quan trọng. Ví dụ, bạn có thể ổn với việc chỉ lưu trữ trong bộ nhớ cho dữ liệu thay vì cố gắng sử dụng DB từ lần lặp đầu tiên.

Những gì chúng tôi cố gắng làm là phân phối trong các lần lặp đầu tiên, ứng dụng đơn giản nhất có thể (phiên bản thế giới xin chào của những gì chúng tôi đang phân phối). Chúng tôi thấy 3 lợi ích quan trọng trong việc này:

• Thiết lập quy trình phân phối (luôn là một trong những phần khó nhất imho) (có được môi trường, máy chủ tại chỗ, cập nhật bảo mật cho môi trường này). Vì chúng tôi sẽ giao hàng thường xuyên, điều quan trọng là phải làm điều này càng sớm càng tốt.
• Cung cấp cho người dùng cái nhìn thoáng qua đầu tiên về cách ứng dụng sẽ trông như thế nào. Điều này giúp người dùng và nhà phát triển hiểu được họ thực sự muốn gì và cần gì.
• Có một ý tưởng cơ bản về cách kiến ​​trúc của ứng dụng sẽ trông như thế nào (ứng dụng sẽ bao gồm các 'lớp' cơ bản hoặc các thành phần của ứng dụng).

Nhưng trong các lần lặp đầu tiên, bạn có thể xây dựng khung hoặc nền tảng mà ứng dụng sẽ đứng để nó là thứ gì đó quan trọng nhưng không hiển thị cho người dùng.

Điều này là sai, vì bạn không cần phải xây dựng một khung mà bạn có thể sử dụng trong tương lai. Ý tưởng là chỉ xây dựng những gì cần thiết (xem thêm YAGNI ).

Trong nước rút số không, bạn cần chuẩn bị cho công việc thực sự. Rất nhiều người tranh luận những gì nên được thực hiện trong lần chạy nước rút này, nhưng theo tôi, nó đã kết thúc khi bạn có thể bắt đầu làm việc với các mục trong hồ sơ tồn đọng. Bước này bao gồm cài đặt PC, thiết lập quy trình xây dựng, chọn khung, v.v.

Khi bạn hoàn thành với sprint zero (hoặc lặp 0), bạn có thể bắt đầu làm việc trên ứng dụng của mình. Lấy các mục từ tồn đọng, và hoàn thành từng cái một. Sau khi bạn hoàn thành việc lặp lại một, bạn sẽ có một cái gì đó hữu ích. Lặp lại đầu tiên thường bao gồm một số tính năng quan trọng nhất.

Điều gì được giao cho khách hàng trong các lần lặp đầu tiên này? Làm thế nào để bạn hiển thị tiến độ đúng hướng khi bạn xây dựng mã giàn giáo?

Sau khi lặp lại số 0, rõ ràng bạn không có gì để cung cấp. Việc giao hàng đến sau khi lặp lại một. Nó chứa các tính năng mà bạn thiết lập cho lần lặp.

Nếu câu hỏi của bạn là "làm thế nào để chọn những gì đi vào vòng lặp X?", Thì hãy xem các đoạn băng video này (video cho phép lặp 0 A và một phần của B).

Bạn có thể cung cấp khá nhiều bất cứ điều gì bạn muốn. Việc xây dựng ý tưởng cơ sở hạ tầng chỉ đơn giản là sai / không nhanh nhẹn / không bền vững.

Ví dụ: xây dựng một ứng dụng Hello World đầy đủ chức năng có thể được xây dựng trong vài giờ. Đưa lên một máy chủ (thậm chí tạm thời) trong đám mây hoặc dưới dạng VM có thể được thực hiện trong vài giờ.

Những điều này là đủ để bắt đầu phát triển . Sau đó, nếu bạn cần CI, bạn có thể thêm một câu chuyện CI, nếu bạn đã nhận được một máy chủ vật lý, chắc chắn, hãy thêm một câu chuyện cho điều đó.

Nhưng bắt đầu giao hàng vào ngày 1 và không bao giờ dừng lại!

Lặp lại sớm, đặc biệt là lần đầu tiên, sẽ chứa hoặc ít nhất nên lập kế hoạch cho các đột biến kiến ​​trúc, bao gồm một lượng thời gian khám phá nhất định và có thể một số nguyên mẫu kiến ​​trúc.

Giống như bạn đã nói, nói chung, có các yêu cầu cấu trúc có thể không có ý nghĩa nhiều đối với các bên liên quan / khách hàng, nhưng được yêu cầu để hình thành một nền tảng hoặc định hướng mẫu mạnh mẽ. Bạn không thể giải quyết vấn đề này vì bạn không thể bắt đầu xây dựng B cho đến khi A hoàn thành.

Một phần của cách tiếp cận Agile là để khách hàng gần gũi vì vậy không cần tài liệu vì tất cả những gì bạn cần làm là nhấc điện thoại / gửi email, và điều đó được mong đợi. Các kỳ vọng của khách hàng nên được đặt một cách thích hợp và bất kỳ công việc nào được hoàn thành nên rất ngắn gọn và CẦN THIẾT . Không mạ vàng, không "Bạn có thể cần nó", v.v. Xây dựng những gì bạn cần trong A để chuyển lên B.

Tùy thuộc vào cách bạn tấn công dự án, bạn chỉ có thể xây dựng nền tảng cần thiết để hoàn thành một mô-đun nhất định, vì vậy trong cuộc họp lập kế hoạch nước rút, bạn sẽ đưa ra các kế hoạch cho lần chạy nước rút hiện tại dựa trên các ưu tiên được đặt ra bởi khách hàng, tùy thuộc vào những gì cần thiết cho lần chạy nước rút đó, có thể có một số yêu cầu cơ bản, vì vậy đó là những gì diễn ra trong giai đoạn nước rút 1. Sau khi lần chạy nước rút đầu tiên hoàn thành và A đã được xây dựng và sau đó lên kế hoạch hoàn thành B.

Nếu bạn đã đồng ý về dòng thời gian với khách hàng, miễn là bạn sẽ đáp ứng thỏa thuận đó, khách hàng có thể sẽ không quan tâm bạn làm gì thứ 1 hay thứ 2. Bạn luôn có thể hiển thị cho họ kết quả kiểm tra đơn vị, nhưng nếu bạn nói rằng chúng tôi sẽ có thứ gì đó để bạn xem sau khi chạy nước rút 2 (hoặc 3), và bạn cung cấp, nó sẽ được ưu tiên. Khách hàng được kỳ vọng sẽ hợp lý nhiều như các nhà phát triển và cả hai đều đang làm việc hướng tới cùng một mục tiêu. Một dự án hoàn thành đáp ứng nhu cầu của khách hàng và hoạt động như mong đợi. Thật đáng lo ngại khi không có gì để xem sau khi chạy nước rút 1 là một điểm cần thiết bởi vì khách hàng chỉ muốn đảm bảo rằng sau khi chạy nước rút 20, dự án sẽ được thực hiện (-ish).