Tôi làm việc cho một công ty nhỏ dựa trên sản phẩm. Chúng tôi sắp viết lại sản phẩm hiện tại của chúng tôi từ đầu. Chúng tôi đang lên kế hoạch áp dụng phương pháp Agile cho sự phát triển của chúng tôi. Bây giờ câu hỏi của tôi là khi chúng tôi có tất cả các yêu cầu ngay cả trước khi bắt đầu dự án (vì chúng tôi đang viết lại sản phẩm hiện có), có đáng để đi sâu vào thế giới Agile không? Không nhanh nhẹn hơn hữu ích khi bạn không có tất cả các yêu cầu trả trước và bạn nhận được yêu cầu của mình theo từng giai đoạn?

Thứ hai, giả sử nếu chúng ta nhảy vào Agile, cách tốt nhất để thiết kế cơ sở dữ liệu là gì? Giả sử trong lần lặp đầu tiên của chúng tôi, chúng tôi chỉ cần tạo một hệ thống đăng nhập (người dùng có thể đăng nhập, đăng xuất, v.v.). Chúng ta chỉ cần tạo bảng Người dùng mà không phải lo lắng về các bảng khác? Và các bảng khác sẽ được phát triển như sản phẩm của chúng tôi sẽ tiến bộ?

Có đáng để đi sâu vào thế giới Agile không?

Đúng.

Không nhanh nhẹn hơn hữu ích khi bạn không có tất cả các yêu cầu trả trước và bạn nhận được yêu cầu của mình theo từng giai đoạn ??

Sai.

Khi bạn không có tất cả các yêu cầu, đó là cách duy nhất để đạt được tiến bộ. Bất cứ điều gì khác đòi hỏi những giả định huyền ảo mà cuối cùng sẽ được chứng minh là sai. Agile chỉ đơn giản là làm cho ít giả định huyền ảo hơn.

Khi bạn có tất cả các yêu cầu, bạn vẫn phải tuân theo tất cả các nguyên tắc Agile.

Đọc phần này trước khi tiếp tục: http://agilemanifesto.org/

Tất cả những điểm này là đúng cho dù bạn biết bao nhiêu yêu cầu.

Bạn vẫn được hưởng lợi từ việc sử dụng phương thức Agile như Scrum, vì bạn sẽ có những kỳ vọng thực tế hơn.

thực hành tốt nhất để thiết kế cơ sở dữ liệu là gì? Giả sử trong lần lặp đầu tiên của chúng tôi, chúng tôi chỉ cần tạo một hệ thống đăng nhập (người dùng có thể đăng nhập, đăng xuất, v.v.).

Thật là một lần lặp đầu tiên khủng khiếp.

Chúng ta chỉ cần tạo bảng Người dùng mà không phải lo lắng về các bảng khác? Và các bảng khác sẽ được phát triển như sản phẩm của chúng tôi sẽ tiến bộ?

Đúng. Bạn tạo cơ sở dữ liệu tăng dần.

Bạn làm mọi thứ tăng dần.

Bạn ưu tiên dựa trên những gì tạo ra giá trị nhất cho người dùng . Không phải là huyền ảo (và ngớ ngẩn) xem xét kỹ thuật.

Bây giờ câu hỏi của tôi là khi chúng tôi có tất cả các yêu cầu ngay cả trước khi bắt đầu dự án (vì chúng tôi đang viết lại sản phẩm hiện có), có đáng để đi sâu vào thế giới Agile không?

Có, mặc dù tôi tưởng tượng có nhiều khả năng sẽ có nhiều thay đổi về cách ứng dụng hiện được thiết kế vì đây sẽ là lúc để xóa các khoản nợ kỹ thuật khác nhau trong việc có một thiết kế sạch hơn với thông tin được biết hiện nay.

Không nhanh nhẹn hơn hữu ích khi bạn không có tất cả các yêu cầu trả trước và bạn nhận được yêu cầu của mình theo từng giai đoạn ??

Bạn tự tin đến mức nào khi những yêu cầu đó sẽ không thay đổi khi bạn xây dựng lại ứng dụng? Bạn có chắc chắn rằng thiết kế được thực hiện sẽ không bao giờ được tái cấu trúc?

Thứ hai, giả sử nếu chúng ta nhảy vào Agile, cách tốt nhất để thiết kế cơ sở dữ liệu là gì? Giả sử trong lần lặp đầu tiên của chúng tôi, chúng tôi chỉ cần tạo một hệ thống đăng nhập (người dùng có thể đăng nhập, đăng xuất, v.v.). Chúng ta chỉ cần tạo bảng Người dùng mà không phải lo lắng về các bảng khác? Và các bảng khác sẽ được phát triển như sản phẩm của chúng tôi sẽ tiến bộ?

Có rất nhiều lựa chọn khác nhau ở đây. Làm vừa đủ để làm cho nó hoạt động. Nếu bảng Người dùng là tất cả những gì cần thiết, thật tuyệt. Nếu có một vài bảng khác mà ai đó muốn có để DB ở dạng bình thường hơn, thì điều đó có thể làm điều đó tốt hơn để làm điều đó. Bạn sẽ không hoàn hảo ngay lần đầu tiên và Agile hoàn toàn là về phương pháp thử và sửa lỗi vì một khi bạn cho thấy những gì bạn có, người dùng sẽ thường có phản hồi, đó là điều khiến Agile tiếp tục và đi ... (Cũng là nơi mới yêu cầu sẽ đến vì mọi người sau đó cũng có thể bắt đầu yêu cầu công cụ)

Tôi làm việc cho một công ty nhỏ dựa trên sản phẩm. Chúng tôi sắp viết lại sản phẩm hiện tại của chúng tôi từ đầu. Chúng tôi đang lên kế hoạch áp dụng phương pháp Agile cho sự phát triển của chúng tôi. Bây giờ câu hỏi của tôi là khi chúng tôi có tất cả các yêu cầu ngay cả trước khi bắt đầu dự án (vì chúng tôi đang viết lại sản phẩm hiện có), có đáng để đi sâu vào thế giới Agile không?

Một công ty nhỏ (quản lý) đang có kế hoạch sử dụng các thực hành nhanh nhẹn đang ở vị trí khởi đầu tuyệt vời vì các nhà phát triển điển hình của nó thúc đẩy việc áp dụng. Tôi sẽ khuyên bạn nên xác định các nhà lãnh đạo sẵn sàng tiếp tục thúc đẩy việc áp dụng ở cấp độ nhóm (Đào tạo, thể chế hóa, v.v.)

Với các yêu cầu trong tay, hãy hỏi người dùng của bạn những gì họ muốn thấy trong một lần lặp. Sau đó, giao nó. Làm lại lần nữa và lần lặp lại. Người dùng có thể chạm vào công việc của bạn sớm sẽ giúp tinh chỉnh các yêu cầu khi bạn đi. Nếu bạn không có quy trình tự động tại chỗ ngay bây giờ hoặc nhóm không hiểu được sự phát triển liên tục thì hãy sắp xếp thời gian để đảm bảo họ thực hiện.

Agile có thể áp dụng cho bất kỳ dự án phát triển nào và không dành riêng cho các dự án xanh hoàn chỉnh chưa có bất kỳ yêu cầu nào được chỉ định. Quản lý dự án Agile làm cho dự án của bạn tự học và tự cải thiện bằng cách thực hiện các bước nhỏ, thường xuyên xem xét các bước của bạn và cải thiện các bước tiếp theo của bạn. Có rất nhiều blog trên Agile xung quanh. Google là bạn của bạn ...

Về câu hỏi cụ thể của bạn về phát triển cơ sở dữ liệu Agile, bạn đang đi đúng hướng. Bạn có thể phát triển quản lý người dùng mà không cần quan tâm đến phần còn lại lúc đầu. Điều đó có thể sẽ kết thúc trong một số lần làm lại khi bạn tiến xa hơn trong dự án, nhưng đó có thể được coi là một chi phí để thực hiện việc lặp lại tập trung nhỏ. Một số cách tiếp cận giữa đường sẽ điều tra mô hình cơ sở dữ liệu của bạn thẳng hơn một chút và tạo ra một số thiết kế có thể hoạt động trong một vài lần chạy nước rút phía trước. Bằng cách đó, bạn sẽ có ít làm lại.

Thứ hai, giả sử nếu chúng ta nhảy vào Agile, cách tốt nhất để thiết kế cơ sở dữ liệu là gì? Giả sử trong lần lặp đầu tiên của chúng tôi, chúng tôi chỉ cần tạo một hệ thống đăng nhập (người dùng có thể đăng nhập, đăng xuất, v.v.). Chúng ta chỉ cần tạo bảng Người dùng mà không phải lo lắng về các bảng khác? Và các bảng khác sẽ được phát triển như sản phẩm của chúng tôi sẽ tiến bộ?

Hãy cẩn thận về việc làm quá mức phương pháp này. Nó có thể giống như xây dựng một ngôi nhà và cố gắng hoàn thành một phòng tắm hoàn toàn trong khi nền tảng vẫn đang thiết lập. Điều lạ lùng là bạn sẽ phải làm lại hoàn toàn các phần quan trọng trong công việc nếu nền tảng của ứng dụng, cơ sở dữ liệu và mô hình đối tượng cơ bản, không đủ chín chắn hoặc ổn định để hỗ trợ cấu trúc.

Ngoài ra, hãy nhớ rằng bạn đang sử dụng Agile / Scrum không cho phép bạn sử dụng các thực hành kỹ thuật phần mềm tốt như kiểm tra đơn vị phù hợp và cơ sở dữ liệu vững chắc và thiết kế đối tượng. Khi Agile bị áp dụng sai, nó có thể dễ dàng rơi vào một mã và sửa chữa dự án xoắn ốc chết chóc có thể rất đau đớn hoặc thậm chí không thể phục hồi.

Agile là tất cả về năng suất và tính linh hoạt hơn . Tại sao bạn viết lại ứng dụng của bạn? Lý do có thể là:

1. Thay đổi nền tảng (từ Windows sang Linux chẳng hạn)
2. Thay đổi ngôn ngữ (ví dụ: từ ASP.NET sang PHP)
3. Số tiền tái cấu trúc rất cao, điều đó làm cho việc viết lại một tùy chọn tiết kiệm chi phí
4. Kinh doanh đã thay đổi rất nhiều, vì vậy, bạn thực sự đang tạo một ứng dụng mới (một bài hát mới, dựa trên cùng một chủ đề, nếu bạn muốn)

Trong bất kỳ lý do nào trong số những lý do này, bạn sẽ không giao sản phẩm của mình qua đêm và tất nhiên sẽ mất thời gian.

Có một sản phẩm tồn đọng chỉ là một trong những mục khuyến nghị nhanh nhẹn. Những gì bạn nói về việc biết toàn bộ doanh nghiệp có nghĩa là bạn đã có rất nhiều PBI trong hồ sơ tồn đọng sản phẩm của bạn.

Nhưng không phải tốt hơn là bạn cung cấp các bộ phận của sản phẩm mới vào cuối mỗi lần chạy nước rút sao? Nó sẽ không làm cho bạn nhanh nhẹn hơn và phản ứng với các thay đổi. Ví dụ, hãy tưởng tượng rằng bạn đang cố gắng làm cho ứng dụng mới trở nên đẹp hơn. Có phải chỉ là xấu khi biết sau 10 tháng rằng thiết kế mới của bạn không được chấp nhận? Sẽ không phải là một thực hành tốt nếu bạn nói sau 2-3 tuần về điều đó?

Câu trả lời của tôi cho câu hỏi của bạn là:

Phát triển Agile chắc chắn có nhiều thứ để cung cấp, ngay cả đối với các ứng dụng được viết lại.

Có đáng để đi sâu vào thế giới Agile không?

Có lẽ. Thử bất cứ điều gì mới có thể có rủi ro, đặc biệt là nếu nó mới đối với mọi người. Cá nhân tôi thấy Agile có ích khi được thực hiện đúng .

Không nhanh nhẹn hơn hữu ích khi bạn không có tất cả các yêu cầu trả trước và bạn nhận được yêu cầu của mình theo từng giai đoạn ??

Nó có thể hữu ích trong việc giúp thúc đẩy các yêu cầu nếu bạn chưa có chúng. Tuy nhiên, điều đó không có nghĩa là tiện ích của nó chỉ giới hạn ở các yêu cầu lái xe.

thực hành tốt nhất để thiết kế cơ sở dữ liệu là gì?

Lặp đi lặp lại. Sử dụng di chuyển cơ sở dữ liệu.

Gợi ý

• Nếu bạn muốn làm Agile thì thật tuyệt. Tôi sẽ cố gắng và nhờ ai đó đã làm điều đó trước đây để giúp bạn trong suốt quá trình.

• Mọi người thường bỏ qua bước tái cấu trúc khi lần đầu tiên thử Agile. Đừng. Nó sẽ giết chết dự án.

• Hãy suy nghĩ trong các lát dọc (tính năng) thay vì các lớp. Thực hiện các lát cắt dọc để bạn có một hệ thống làm việc sau khi thẻ tính năng đầu tiên được thực hiện. Khi nó hoạt động, giữ cho nó hoạt động và chỉ cần thêm với mỗi thẻ tính năng.

Chúng tôi đã sử dụng Agile trong một dự án đòi hỏi phải chuyển từ một ứng dụng cũ sang một bộ ứng dụng mới và một kiến ​​trúc mới. Tình hình của chúng tôi có một chút khác biệt ở chỗ chúng tôi đang cố gắng không chỉ làm lại ứng dụng hiện có (được sử dụng nội bộ bởi các bộ phận bán hàng, tài chính, tìm nguồn cung ứng và kho), mà chúng tôi đang cố gắng cải thiện kinh nghiệm của từng bộ phận trên đường đi. Một thách thức mà chúng tôi đã thấy khi sử dụng nhanh là giá trị doanh nghiệp cho việc di chuyển các bộ phận của chức năng cho một đơn vị kinh doanh nhất định là cao, nhưng các bộ phận khác thì thấp. Do đó, chúng tôi thấy mình tạo ra các ứng dụng mới và giữ cho ứng dụng cũ chạy trong khi chúng tôi chuyển đổi. Chúng tôi đang gặp khó khăn khi doanh nghiệp thấy được giá trị trong việc tập trung chuyển một "khách hàng" sang một ứng dụng hoàn toàn mới. Tuy nhiên, chúng tôi đang nhận được rất nhiều câu chuyện có giá trị cao vào giai đoạn nước rút của chúng tôi. Tôi nghĩ rằng chúng ta sẽ sớm đạt được một pint, khi chúng ta phải thuyết phục doanh nghiệp rằng chúng ta cần tập trung vào một đơn vị tại một thời điểm.

Vì vậy, để trả lời câu hỏi ban đầu, có nhanh nhẹn là một cách tốt để đi. Hãy chuẩn bị cho một số phụ thuộc để cắt xén và hướng dẫn một số quyết định của đội trên đường đi.

Điều quan trọng nhất là quy trình scrum sẽ hữu ích với bạn. Ý tôi là nếu công việc của bạn sẽ tốt hơn, chỉ cần lấy nó. Nhưng bạn sẽ không bao giờ biết trừ khi bạn thử nó.

Một điểm khác là không cần phải thực hiện quy trình scrum của cuốn sách. Chỉ cần lấy những thứ sẽ làm việc cho bạn. Ví dụ, nhóm của chúng tôi không có bảng scrum. Bởi vì chúng tôi không cần nó.

Đối với thiết kế, bạn nên cố gắng thiết kế theo cách mà những thay đổi trong tương lai sẽ không mất nhiều thời gian. Hệ thống của bạn phải mạnh mẽ.