Làm thế nào để phát triển phần mềm xuất sắc với các phương pháp nhanh?

Các mô hình Kano của sự hài lòng của khách hàng định nghĩa lớp khác nhau của tính năng sản phẩm. Trong số đó là

1. Những phẩm chất phải có: Nếu những điều này không được thực hiện, khách hàng sẽ không chấp nhận sản phẩm.

2. Phẩm chất hấp dẫn (người thích thú): Các tính năng mà khách hàng thường không mong đợi ngay từ đầu nhưng lại gây hứng thú và thích thú khi được khám phá.

Chất lượng hấp dẫn rõ ràng có rất nhiều giá trị kinh doanh. Họ khiến mọi người mua một chiếc Ferrari với giá 500.000 khi một chiếc Fiat đã qua sử dụng với giá dưới 5.000 sẽ đáp ứng tất cả các yêu cầu bắt buộc.

Tuy nhiên, tất cả các quy trình nhanh mà tôi biết rất ủng hộ các yêu cầu phải có. Những điều này luôn luôn được ưu tiên cao nhất. Thậm chí dường như không có một nơi nào cho những phẩm chất hấp dẫn nhanh nhẹn.

Tôi tin rằng các quy trình nhanh là rất hữu ích trong việc phát triển phần mềm. Nhưng làm thế nào chúng có thể được áp dụng để tạo ra các sản phẩm phần mềm chất lượng cao thú vị và không chỉ ở mức tối thiểu mà hầu như không đáp ứng các yêu cầu bắt buộc phải có?

Phụ lục: Như hai câu trả lời đầu tiên đã chỉ ra, sẽ rất hợp lý khi đưa ra các yêu cầu phải là ưu tiên cao nhất. Nhưng chúng ta (và khách hàng) có thực sự luôn biết trước những yêu cầu bắt buộc phải là gì không. Tôi đã thực hiện một vài lần rằng các yêu cầu được ưu tiên cao ngay từ đầu, hóa ra lại ít quan trọng hơn, nếu không nói là vô dụng, sau này. Vì vậy, tôi tin rằng người ta không nên tập trung vào những yêu cầu bắt buộc.

Câu trả lời chính thức là bạn hiểu lầm nhanh nhẹn, nhanh nhẹn không ra lệnh yêu cầu, các bên liên quan làm. Cốt lõi của nhanh nhẹn không phải là khắc những yêu cầu của bạn thành đá mà là để chúng nổi lên khi bạn đi, tiếp xúc gần gũi với khách hàng của bạn, được hưởng lợi từ những hiểu biết tiến bộ.

Nhưng đó là tất cả lý thuyết. Những gì bạn đã chứng kiến ​​thực sự là một đặc điểm chung của nhiều dây chuyền sản xuất phần mềm đã áp dụng một cách làm việc nhanh nhẹn.

Vấn đề là, lắng nghe khách hàng và nhanh chóng đáp ứng nhu cầu của khách hàng thường sớm kết thúc trong việc không suy nghĩ gì về sản phẩm hoặc thực hiện bất kỳ thiết kế nào cả. Những gì từng là một quá trình chủ động được nuôi dưỡng bởi tầm nhìn và chuyên môn có thể và thường sẽ biến thành một quá trình thụ động, hoàn toàn phản ứng được nuôi dưỡng bởi mong muốn của khách hàng. Điều này sẽ dẫn đến việc chỉ đưa ra những nhu cầu thiết yếu là "sẽ thực hiện công việc".

Ô tô sẽ không bao giờ được phát minh nếu các nhà sản xuất vào thời điểm đó sẽ "nhanh nhẹn" bởi vì tất cả các khách hàng đang yêu cầu là một con ngựa nhanh hơn.

Điều này không làm cho xấu nhanh mặc dù. Nó hơi giống chủ nghĩa cộng sản. Một ý tưởng tuyệt vời mà hầu như không bao giờ thực hiện tốt bởi vì mọi người chỉ là con người, làm mọi việc. Và phương pháp / ý thức hệ / tôn giáo đưa họ vào ý tưởng rằng họ đang làm tốt miễn là họ đang trải qua các chuyển động và / hoặc tuân theo các quy tắc.

[biên tập]

Slebetman:

Thật là mỉa mai khi Agile phát triển ra khỏi ngành công nghiệp tự động (cụ thể là Toyota).

Ghi nhớ nguyên tắc vàng của tự động hóa? "Đầu tiên tổ chức, sau đó tự động hóa". Nếu bạn tự động hóa một quy trình bị hỏng, điều tốt nhất có thể xảy ra là bạn tăng tốc mọi thứ sai. Những người ở Toyota không phải là kẻ ngốc.

Lý do điển hình cho việc áp dụng bất kỳ phương pháp mới nào là mọi thứ sẽ không được tốt. Quản lý thừa nhận nó, nhưng họ có thể không hiểu các vấn đề cốt lõi. Vì vậy, họ thuê guru này đưa ra một bài phát biểu kiên cường về Agile và Scrum. Và mọi người đều thích nó. Vì lý do riêng của họ.

Các nhà phát triển có thể nghĩ "Này, điều này có thể hoạt động. Chúng tôi sẽ liên quan nhiều hơn đến các vấn đề kinh doanh và chúng tôi có thể cung cấp đầu vào để lấp đầy hồ sơ tồn đọng này. Đây có thể là một cơ hội để bán hàng và dịch vụ khách hàng hiểu những gì chúng tôi làm, tại sao cần thiết, và chúng ta sẽ lấy chúng ra khỏi tóc trong khi chúng ta đang đốt cháy những gì chúng ta đã đồng ý. " Không còn "dừng những gì bạn đang làm, điều này cần phải được thực hiện ngay bây giờ" bởi một số anh chàng bạn không muốn tắt bật lên tại bàn của bạn.

Mặt khác, bán hàng, dịch vụ khách hàng hoặc chủ sở hữu có thể coi đó là một cách để giành quyền kiểm soát (trở lại) đối với hộp đen này của một bộ phận có lẽ đang làm những việc cần thiết. Họ không nhìn thấy những gì đang xảy ra ở đó nhưng họ khá chắc chắn rằng cốt lõi của vấn đề được chôn giấu ở đâu đó trong đó. Vì vậy, họ giới thiệu Scrum, cài đặt một chủ sở hữu sản phẩm theo lựa chọn của họ và đột nhiên họ có toàn quyền kiểm soát, tất cả các chuỗi đều nằm trong tay họ. Giờ thì sao? ... Ehrr ...

Vấn đề thực sự thường là cửa hàng không được tổ chức tốt ngay từ đầu và điều này không thay đổi. Mọi người đã được chỉ định trách nhiệm mà họ không thể xử lý, hoặc có lẽ họ có thể nhưng ông Boss liên tục can thiệp và phá hỏng những gì họ đã làm, hoặc (thường là theo kinh nghiệm của tôi), trách nhiệm quan trọng chưa được công nhận hoặc giao cho bất kỳ ai.

Đôi khi theo thời gian, một tổ chức không chính thức sẽ xuất hiện ở giữa các dòng chính thức. Điều này sau đó có thể bù đắp một phần cho việc thiếu một cấu trúc chính thức. Một số người cuối cùng chỉ làm những gì họ giỏi, cho dù họ có danh thiếp để chứng minh điều đó hay không. Việc giới thiệu thẳng thừng của Agile / Scrum có thể phá hỏng điều đó ngay lập tức. Bởi vì mọi người bây giờ dự kiến ​​sẽ chơi theo luật. Họ cảm thấy những gì họ từng làm không được đánh giá cao, thay vào đó họ nhận được những tờ giấy nhỏ màu vàng với những câu chuyện nhỏ trên đó, thông điệp sẽ là: "bất cứ điều gì bạn đang làm, không ai quan tâm". Không cần phải nói điều này sẽ không đặc biệt thúc đẩy những cá nhân đó. Họ sẽ bắt đầu chờ đợi đơn đặt hàng và không chủ động nữa.

Vì vậy, mọi thứ trở nên tồi tệ hơn và kết luận sẽ là Agile hút.

Agile không hút, nó rất tốt cho các dự án bảo trì và thậm chí có thể tốt cho các phát triển mới nếu được áp dụng cẩn thận nhưng nếu những người sai không hiểu nó hoặc chấp nhận nó vì những lý do sai lầm, nó có thể phá hủy nhất.

Thậm chí dường như không có nơi nào có phẩm chất hấp dẫn nhanh nhẹn.

Bạn đang so sánh táo với cam. Trong thác nước truyền thống, nếu các yêu cầu của bạn nói rằng bạn cần những người phải đến, bạn sẽ có được một Fiat. Nếu các yêu cầu nói rằng nó phải là đỉnh cao, bạn sẽ có được một chiếc Ferrari.

Điều tương tự cũng xảy ra ở Agile. Nếu yêu cầu của bạn dừng lại ở những nơi phải đến, bạn sẽ nhận được Fiat. Nếu bạn có những câu chuyện xuất sắc, bạn sẽ có được một chiếc Ferrari. Tất cả những gì nhanh nhẹn thực sự thực thi là bạn phải làm trước tiên . Không xây dựng một spoiler siêu mát mẻ trong hai năm và sau đó bỏ lỡ thời hạn cho động cơ.

Câu chuyện dài quá ngắn: bạn có được những gì bạn yêu cầu. Nếu bạn có kế hoạch cho một chiếc xe thể thao, bạn có được một chiếc xe thể thao. Agile không thay đổi điều đó cả. Nếu quy trình nhanh của bạn đưa ra các yêu cầu cho một Fiat, đừng đổ lỗi cho nhanh nhẹn, hãy đổ lỗi cho những người chỉ yêu cầu Fiat.

Tuy nhiên, tất cả các quy trình nhanh mà tôi biết rất ủng hộ các yêu cầu phải có. Những điều này luôn luôn được ưu tiên cao nhất.

Vì họ nên - nhìn lại mô hình Kano của bạn: nếu các yêu cầu bắt buộc không được thỏa mãn, khách hàng sẽ không chấp nhận sản phẩm. Và sau đó niềm vui của bạn không quan trọng.

Thậm chí dường như không có nơi nào có phẩm chất hấp dẫn nhanh nhẹn.

Không gì có thể hơn được sự thật.

Các quy trình Agile thường nhấn mạnh những điểm sau:

• Giao hàng thường xuyên của một sản phẩm làm việc mà bạn có thể nhận được thông tin phản hồi.
• Chia các tính năng thành các phần nhỏ có thể được hoàn thành trong một thời gian ngắn.
• Thực hiện các phần theo thứ tự ưu tiên.

Không có gì ngăn cản bạn đưa ra các tính năng "thỏa thích" ưu tiên cao. Nó hoàn toàn phụ thuộc vào những người chịu trách nhiệm xác định các ưu tiên.

Bây giờ đúng là nhiều người như vậy không thích mạo hiểm và do đó có thể không ưu tiên cao cho "những người thích thú". Nhưng trong một dự án không nhanh nhẹn vẫn sẽ như vậy.

Agile không nói gì về những gì nên làm trước tiên, chỉ có mã đó nên được viết tăng dần và giữ ở trạng thái có thể tin cậy thường xuyên nhất có thể, thay vì được lên kế hoạch để không thể sử dụng trong nhiều tháng cho đến trạng thái đáng tin cậy tiếp theo.

Tôi đã làm việc theo cả quy trình Agile và BDUF (Big Design Up Front) và trong khi bạn chắc chắn có thể nhận được các tính năng hấp dẫn, sáng tạo từ cả hai quy trình, trong BDUF, không ngạc nhiên, bạn phải lên kế hoạch cho chúng trước. Điều đó có nghĩa là những đổi mới thường phải được đề xuất hoặc ít nhất là được tài trợ bởi những người có tầm ảnh hưởng trong quá trình thiết kế.

Điều này là do bạn có sáu tháng (hoặc bất cứ điều gì) cho đến lần phát hành tiếp theo và các nhà quản lý dự án bị căng thẳng về những gì sẽ xảy ra trong phiên bản đó, bởi vì nếu tính năng của họ không được đưa vào, thì sẽ còn sáu tháng nữa cho đến lần tiếp theo . Vì vậy, có một danh sách các tính năng bị kẹt trong lịch trình bị kẹt và nếu thứ hạng và tệp thấp bị bắt làm việc trong hai hoặc ba ngày đối với một thứ gì đó tuyệt vời, họ chỉ nghĩ rằng khách hàng sẽ thích, và nó không phải là danh sách, họ có nguy cơ toàn bộ lịch trình và sẽ có địa ngục để trả.

Trong một quy trình Agile, chúng tôi cố gắng giữ phần mềm ở trạng thái có thể tin cậy được và các nhà quản lý dự án sẽ ít căng thẳng hơn vì nếu tính năng của họ bị trượt, họ có thể nhận được phần mềm trong hai tuần. Vì vậy, nếu một nhà phát triển quay trở lại từ một cuộc hội thảo với một ý tưởng tuyệt vời và dành một vài ngày cho một cái gì đó, họ sẽ không đặt lịch trình viết trong máu sáu tháng trong tình trạng nguy hiểm.

Về cơ bản, bạn gặt những gì bạn gieo. Nếu bạn khuyến khích đổi mới và cung cấp cho các nhóm đủ tự chủ để cung cấp, bạn sẽ nhận được nó. Nếu bạn liên tục yêu cầu cắt góc để đáp ứng thời hạn, bạn sẽ có được phần mềm phù hợp, bất kể phương pháp của bạn.

Phần mềm tuyệt vời đến từ hai điều:

• Cung cấp cho khách hàng những gì họ yêu cầu

• Là một chuyên gia

Có tất cả các loại nguyên tắc cần tuân thủ khi phát triển phần mềm. DRY, có thể đọc, RẮN, vv không liên quan đến yêu cầu của khách hàng. Khách hàng yêu cầu một chiếc xe thể thao. Nếu khách hàng hiểu những gì nó cần để làm cho một chiếc xe thể thao tuyệt vời, họ sẽ không cần bạn. Nó phụ thuộc vào bạn để tìm ra những gì khác là quan trọng.

Một phần công việc của chúng tôi là duy trì các tiêu chuẩn mà khách hàng không bao giờ trải qua trừ khi mọi thứ trở nên tồi tệ.

Nếu bạn đang làm đúng thì nhanh nhẹn chỉ hướng về fiat khi đó là điều khách hàng thực sự muốn. Không phải khi đó là những gì họ nghĩ họ phải giải quyết.

Thác nước là khác nhau bởi vì một khi sự hiểu lầm về một yêu cầu xe thể thao cao cấp đã giải quyết trong nó có xu hướng dính xung quanh. Agile có thể đối phó với thông tin mới và thích nghi nếu nó chỉ ra thứ họ thực sự cần là một chiếc xe đạp đạn.

Thác nước vẫn còn được sử dụng ở nhiều cửa hàng cho đến ngày nay. Các cửa hàng này thành công vì yêu cầu của họ thay đổi ít hơn 2% trong một năm.

Công việc của bạn không chỉ là cung cấp cho khách hàng những gì họ muốn. Đó cũng là để chăm sóc những thứ bạn biết bạn sẽ không nhận được bất kỳ tín dụng nào cả. Những điều khách hàng sẽ không bao giờ đưa ra trừ khi bạn để mọi thứ trở nên tồi tệ. Những thứ này tốt hơn nên được lựa chọn hoặc bạn sẽ mất rất nhiều thời gian để lãng phí thời gian cho chúng.

Bất kỳ kẻ ngốc nào cũng có thể xây dựng một cây cầu với ngân sách không giới hạn. Một chuyên gia xây dựng một cây cầu mà hầu như không bao giờ rơi xuống.

Vì vậy, tôi tin rằng người ta không nên tập trung vào những yêu cầu bắt buộc.

Chắc chắn bạn nên. Ngoại trừ khi ước tính thời gian của bạn. Bởi vì những yêu cầu phải là không phải là sự cân nhắc duy nhất.

Đồng ý,

Trong Agile, lập trình viên có thể tạo ra phần mềm, nhưng cuối cùng, đó là chủ sở hữu sản phẩm tạo ra sản phẩm. (bằng cách sử dụng các nhà phát triển phần mềm.)

Vì vậy, về "phẩm chất hấp dẫn", điều đó tùy thuộc vào chủ sản phẩm.

Nếu chủ sở hữu sản phẩm bắt buộc "thiết kế gợi cảm", điều đó có thể được yêu cầu. Nhà phát triển không nên lo lắng về những lựa chọn này.

Ngoài ra, phần mềm rất khác so với các sản phẩm vật lý thực tế mà tôi nghĩ rằng rất nhiều mô hình Kano không áp dụng. Chẳng hạn, tại sao tôi lại vào facebook? Chỉ có lý do: bởi vì bạn bè của tôi làm. Làm thế nào để đưa nó vào lần chạy nước rút tiếp theo ........ Và, một trong những phẩm chất hấp dẫn nhất trong phần mềm, là nó thực sự làm những gì nó phải làm. (Và đó là nơi nhanh nhẹn giúp rất nhiều: P)

Kinh nghiệm của tôi đồng ý với các ý kiến ​​trên - không có gì vốn có trong Agile ngăn cản sự phát triển của phần mềm xuất sắc - tuy nhiên có một số khía cạnh về cách Agile thường được thực hành dẫn đến phần mềm chỉ "đủ tốt" . "

• Agile nhấn mạnh vào việc làm cho một cái gì đó hoạt động càng sớm càng tốt; tuy nhiên, điều này có nghĩa là thực hiện đơn giản hóa các giả định và các góc cắt, đặc biệt là trong cơ sở hạ tầng không nhìn thấy được của người dùng. Không có gì sai về điều này, nếu chi phí sửa chữa các giả định đơn giản hóa là thấp; tuy nhiên, tất cả quá thường xuyên "khoản nợ kỹ thuật" này không bị xóa trước khi sản phẩm đi vào sản xuất;
• Agile giảng rằng vào cuối giai đoạn nước rút, bạn phải luôn có thứ gì đó gần với khả năng có thể chuyển được, để những người nắm giữ cổ phần và quản lý dự án có thể quyết định rằng "những gì họ có" là đủ tốt để đưa vào sản xuất. Một lần nữa, không có gì sai với điều này, nếubạn đã xóa tất cả "nợ kỹ thuật" của mình (hoặc đã làm cho bạn yên tâm với số tiền bạn có và ở đâu.) Tuy nhiên, theo kinh nghiệm của tôi, có quá nhiều nợ kỹ thuật được đưa ra với lời hứa của người quản lý rằng "chúng tôi" Sẽ làm sạch nó một khi áp lực tàu được tắt ", điều này nhanh chóng biến thành" nó đang được sản xuất, chúng ta phải rất cẩn thận về những gì chúng ta thay đổi bây giờ ", cuối cùng biến thành" Bạn chưa bao giờ nói với tôi rằng chúng ta đã tiếp xúc! Lần tới chúng ta phải làm một công việc tốt hơn! " Bài học của Ben Frankin về "Sự cay đắng của chất lượng kém vẫn còn lâu sau khi vị ngọt của giá thấp bị lãng quên, dường như không bao giờ được học;
• Tuy nhiên, ngay cả với các nhà quản lý đáng tin cậy và các nhà phát triển có kỷ luật tốt, có một vấn đề phổ biến là chỉ có quá ít phân tích, thiết kế và đánh giá thiết kế phù hợp xảy ra trước khi bắt đầu chạy nước rút trong đó việc triển khai dự kiến ​​sẽ được bắt đầu và hoàn thành. Thất bại trong việc cân nhắc thay thếCác ẩn dụ và thiết kế giao diện người dùng rất lớn - thường rất tốn kém khi điều chỉnh lại đáng kể điều này sau khi một dự án được bắt đầu; việc các đội thiếu niên nghiên cứu kỹ các sản phẩm của đối thủ cạnh tranh hoặc ưu tiên định nghĩa và triển khai các công nghệ cơ sở hạ tầng như I18N, khung thông báo, ghi nhật ký, bảo mật và chiến lược phiên bản API (ví dụ) có nghĩa là cuối cùng họ sẽ có lỗi cao hơn, năng suất thấp hơn và sẽ tích lũy nhiều nợ kỹ thuật hơn so với việc họ vừa trải qua 2-5 lần chạy nước rút đầu tiên để thực hiện đào tạo, phân tích, thiết kế và tạo mẫu cần thiết. Nói tóm lại, các đội Agile phải chống lại giấy phép để hack;
• Tôi đã có một người quản lý cấp hai (trong số hơn 100 nhà phát triển), người không khuyến khích các nhà phát triển của mình dành thời gian để viết ra các thiết kế theo kế hoạch của họ, ngay cả ở cấp độ cơ bản nhất. Lý luận của anh ấy - "Tôi muốn mọi người nói chuyện với nhau" - thật mỉa mai vì họ ở 5 múi giờ khác nhau và 3 quốc gia. Không cần phải nói, có rất nhiều ý kiến ​​chỉ ra rằng nhóm nào sẽ phải làm việc nhiều đêm và cuối tuần trong dự án một khi họ nhận ra rằng mọi người đều nghĩ rằng anh chàng kia chịu trách nhiệm thực hiện một số chức năng (hoặc triển khai lại vì thiết kế của nhà cung cấp và người tiêu dùng không kết nối.)

Tất cả thực sự tập trung vào việc người quản lý dự án và người nắm giữ cổ phần có muốn cung cấp một sản phẩm chất lượng cao hay không. Nếu họ cam kết làm như vậy, Agile sẽ kích hoạt nó. OTOH, vì Agile đặt lịch trình ra quyết định chỉ trong tay của người nắm giữ cổ phần và người quản lý dự án, Agile gây khó khăn cho nhóm phát triển để đưa ra một dự án xuất sắc mà không có sự hỗ trợ đó. Nói tóm lại: trách nhiệm đối với chất lượng sản phẩm hầu như chỉ nằm dưới chân người quản lý dự án.

TL; DR

Trên thực tế, phát triển nhanh giúp bạn tăng chất lượng phần mềm, giữ cho khách hàng hài lòng và cung cấp một sản phẩm có giá trị cao.

Phát triển Agile được một số kẻ thông minh giới thiệu để giải quyết các vấn đề mà nhiều dự án phần mềm gặp phải trong các quy trình truyền thống.

Các giá trị chính của phát triển nhanh như được định nghĩa bởi tuyên ngôn nhanh (1) là,

• Cá nhân và tương tác qua các quy trình và công cụ
• Phần mềm làm việc trên tài liệu toàn diện
• Hợp tác khách hàng đàm phán hợp đồng
• Đáp ứng để thay đổi theo kế hoạch

Do đó, phát triển nhanh không ngăn cản bạn tạo phần mềm chất lượng cao. Phát triển Agile hỗ trợ bạn cung cấp phần mềm chất lượng cao.

Nhưng chúng ta (và khách hàng) có thực sự luôn biết trước những yêu cầu bắt buộc phải là gì không.

Đó là toàn bộ vấn đề. Bằng cách tập trung vào các cá nhân, khách hàng, phần mềm làm việc và thay đổi yêu cầu phát triển nhanh giúp bạn tìm ra những gì khách hàng muốn trước khi sản phẩm cuối cùng được giao.

Đó là lý do tại sao các khung nhanh như Scrum có chu kỳ lặp ngắn mà kết quả là sản phẩm hoạt động. Bạn đã có thể xác nhận công việc của mình ở giai đoạn đầu so với mong đợi của khách hàng và điều chỉnh các mục tiêu / yêu cầu theo yêu cầu. Một sự phát triển nhanh giúp bạn đảm bảo nhận ra chất lượng phải có của một sản phẩm.

Trước đây - điều đó vẫn đúng cho đến ngày nay - nhiều dự án phần mềm được phát triển theo cách tiếp cận truyền thống đã thất bại, không thành công hoặc khiến khách hàng không hài lòng vì chất lượng phải đạt được.

Hơn nữa, phát triển nhanh cũng giúp bạn đạt được Chất lượng hấp dẫn . Phản ánh sản phẩm sau mỗi lần lặp sẽ làm sáng tỏ những yêu cầu mới mà khách hàng không quan tâm khi bắt đầu dự án (những phẩm chất hấp dẫn). Điều này giữ cho khách hàng hài lòng.

Tôi cũng muốn đề cập đến Chất lượng ngược - các thuộc tính dẫn đến sự không hài lòng - của mô hình Kano.

Trong mỗi dự án đều có những yêu cầu có vẻ là ý tưởng tốt khi bắt đầu dự án. Sau một thời gian họ đổi sang hướng ngược lại và gây thất vọng.

Trong quy trình phát triển phần mềm truyền thống, bạn sẽ nhận ra các yêu cầu như vậy trong sản phẩm cuối cùng sau một quá trình dài dự án. Quá muộn để tránh sự thất vọng của khách hàng và để thay đổi họ một dự án tiếp theo là cần thiết.

Phát triển nhanh nhẹn giúp bạn xác định sớm các yêu cầu không hoạt động hoặc không hài lòng và thay đổi chúng trong dự án.

Như tôi đã nói, phát triển nhanh giúp bạn tăng chất lượng phần mềm, giữ cho khách hàng hài lòng và cung cấp một sản phẩm có giá trị cao.

Tôi đến bữa tiệc này khá muộn, nhưng tôi muốn chia sẻ một góc nhìn khác về chủ đề này:

Nhưng làm thế nào chúng có thể được áp dụng để tạo ra các sản phẩm phần mềm chất lượng cao thú vị và không chỉ ở mức tối thiểu mà hầu như không đáp ứng các yêu cầu bắt buộc phải có?

Có một khía cạnh tạm thời trong phát triển phần mềm nhanh, kết quả từ cách tiếp cận lặp lại và xem xét phản hồi của khách hàng , đó là hai yếu tố quan trọng của phương pháp nhanh. Ví dụ: Các tính năng được xác định là chất lượng hấp dẫn trong lần lặp t có thể trở thành chất lượng bắt buộc phải có trong lần lặp tiếp theo t + 1.

Áp dụng các phương thức nhanh có thể thay đổi linh hoạt danh mục chất lượng của một tính năng. Nếu bạn so sánh các tính năng được lên kế hoạch của lần lặp t với các tính năng đã hoàn thành của một số lần lặp sau t + n, bạn sẽ trải nghiệm chính xác những gì bạn đã đề cập:

Tôi đã thực hiện một vài lần rằng các yêu cầu được ưu tiên cao ngay từ đầu, hóa ra lại ít quan trọng hơn, nếu không nói là vô dụng, sau này.

Với khía cạnh tạm thời này, điều hợp lý là các phương pháp nhanh có thể tạo ra các sản phẩm phần mềm chất lượng cao thú vị trong khi tập trung ở mức tối thiểu . Cách tiếp cận lặp đi lặp lại kết hợp với phản hồi của khách hàng sẽ thay đổi luật chơi theo thời gian.

Phần kết luận

Làm thế nào để phát triển phần mềm xuất sắc với các phương pháp nhanh?

Áp dụng một cách tiếp cận lặp đi lặp lại và lắng nghe phản hồi của khách hàng . Bỏ một trong những yếu tố này và bạn sẽ có được một hình thức phát triển phần mềm linh hoạt ít thành công hơn.

   > How to develop excellent software with agile methods?

• Khi sản xuất một phần mềm riêng cho khách hàng :
  • tìm một khách hàng nơi chi phí không thành vấn đề vì tính năng "thú vị" sẽ tốn thêm tiền và khách hàng phải quyết định xem anh ta có muốn trả tiền cho việc này không.
• Khi sản xuất Softwarep sinh sản :
  • Các tính năng "thú vị" rất tốt để thu hút khách hàng mới và chi phí để thực hiện tính năng "thú vị" không quá quan trọng nếu sản phẩm được bán hơn 1000 lần.
• Trong một môi trường mà "đủ tốt (rẻ nhất) là tốt nhất", bạn sẽ không có tiền để thực hiện các tính năng "thú vị"

Trong nhóm Scrum, Chủ sở hữu sản phẩm có trách nhiệm chọn các tính năng sẽ triển khai. Vì vậy, tùy thuộc vào anh ấy (và tùy thuộc vào ngân sách của anh ấy) để xác định phần mềm "đủ tốt" hoặc "xuất sắc"

Bạn nêu lên một số điểm tốt. Nhưng tôi không tin rằng những vấn đề này bị giới hạn trong các quy trình / phương pháp nhanh.

Có nhiều ý kiến ​​khác nhau về những gì là thiết yếu so với các tính năng không thiết yếu. Để sử dụng ví dụ của bạn, ai đó mua ô tô có thể coi việc thu hút sự chú ý là một tính năng thiết yếu và do đó coi Fiat là không đáp ứng yêu cầu bắt buộc này.
Thực tế hơn, một sản phẩm phần mềm có thể cần phải có chức năng nhất định để đáp ứng nhu cầu của người dùng cuối thực sự của nó ... nhưng nó cũng có thể cần phải có một số tính năng khác để được bán. Bởi vì người ủy quyền mua hàng thường không phải là người dùng cuối.
Vì vậy, một tính năng "không thiết yếu" đối với người dùng cuối có thể là điều cần thiết để bán sản phẩm ... và do đó cũng rất cần thiết cho công ty tạo ra sản phẩm.

Tất cả chỉ tập trung vào thực tế rằng điều quan trọng là phải có một nhóm phát triển sản phẩm tốt để đặt ra các yêu cầu và ưu tiên phù hợp. Nhưng điều đó không chỉ đúng với các cửa hàng nhanh nhẹn.

Điều quan trọng nữa là phải có (các) chủ sở hữu sản phẩm / các bên liên quan được ủy quyền đưa ra quyết định. Nếu quyết định của chủ sở hữu sản phẩm của bạn liên tục bị người khác ghi đè, tôi sẽ là người đầu tiên đồng ý rằng đó là một vấn đề, nhưng một lần nữa, đó không phải là vấn đề với nhanh nhẹn.

Có những điều khác mà bạn muốn ở (các) chủ sở hữu sản phẩm của mình ... một mô tả mà tôi đã nghe là "CRACK" (hợp tác, đại diện, ủy quyền, cam kết và hiểu biết). Một chủ sở hữu sản phẩm thiếu trong bất kỳ lĩnh vực nào trong số này có thể đánh vần rắc rối cho một dự án. Nhưng lần đầu tiên tôi nghe thấy từ viết tắt này trong môi trường thác nước, vì vậy rõ ràng nỗi đau của khách hàng / chủ sở hữu sản phẩm xấu không bị hạn chế ở các cửa hàng nhanh nhẹn.

Những gì nhanh nhẹn có thể (giúp đỡ) làm là đưa một số vấn đề này lên bề mặt.

Ví dụ, tài liệu XP là IIRC khá rõ ràng về việc "khách hàng" có thể hiểu biết, có thể truy cập được vào nhóm và được ủy quyền để đưa ra quyết định. Thuật ngữ "chủ sở hữu sản phẩm" ngụ ý một số mức độ kiến ​​thức, cam kết và quyền hạn.

Nếu bạn thấy mình trong một tình huống mà hầu hết các chức năng được phân phối bao gồm các tính năng thích hợp thay vì các tính năng bắt buộc, thì việc đưa ra vấn đề đó sẽ dễ dàng hơn nhiều (và dễ dàng hơn nhiều để xác định nguyên nhân) khi bạn cung cấp phần mềm làm việc hoặc gần như làm việc 2-3 tuần so với khi giao hàng cách nhau vài tháng hoặc nhiều năm.

Nếu bạn đang làm việc trong các vòng lặp nhỏ - và thường xuyên xem xét các hồ sơ tồn đọng (bao gồm xem xét lại mức độ ưu tiên) - điều đó mang lại cho nhóm cơ hội học hỏi từ những sai lầm trước đây. "Điều này cảm thấy như bây giờ nó thực sự quan trọng, nhưng hãy nhớ điều hướng động mà chúng tôi chắc chắn rằng chúng tôi cần mà cuối cùng chúng tôi không sử dụng?" Như những người khác đã chỉ ra, những cuộc thảo luận đó ít có khả năng hơn nếu mọi thứ đã được lên kế hoạch từ trước.

Ngược lại, phương pháp thiết kế phía trước giả định (theo mặc định) rằng sự hiểu biết về sản phẩm và tính năng là tĩnh. Đó không phải là kinh nghiệm của tôi: có một cái gì đó hữu hình để làm việc với hầu như luôn thay đổi sự hiểu biết của người kinh doanh về vấn đề. Do đó nhấn mạnh vào phản hồi nhanh chóng. (Sự hiểu biết của các nhà phát triển cũng thay đổi, nhưng điều đó sẽ không ảnh hưởng đến các ưu tiên.)

Trì hoãn một số kế hoạch cũng cho phép bạn đáp ứng những thay đổi trong nhu cầu kinh doanh. "Bạn biết rằng trang web bạn đang xây dựng? Chúng tôi thực sự cần đó là một ứng dụng di động, có khả năng ngắt kết nối hoạt động." Đây không phải là điều được hỏi cụ thể ... nhưng bạn có muốn quá trình của mình có khả năng đáp ứng với những thay đổi trong bối cảnh kinh doanh (ít nhất là trên lý thuyết) không?

Agile không nói "không xây dựng các tính năng không thiết yếu". Nó nói "cho phép doanh nghiệp quyết định xây dựng các tính năng (không)".
... Và (không kém phần quan trọng) "cho phép các kỹ thuật viên cho bạn biết thời gian bạn muốn xây dựng một tính năng".

1. Must-be qualitiesthường khó xác định. Người ta có chúng trong tiềm thức. Lặp đi lặp lại nhanh và sự tham gia của khách hàng giúp tìm ra hầu hết những thứ phải có. Đó là sức mạnh của sự nhanh nhẹn và thật ngu ngốc khi bỏ bê nó .
2. One-dimensional qualitiesđiều đó có nghĩa là những lời hứa phải được thực hiện, được thác nước hỗ trợ, cho đến khi chúng không thay đổi. Ở đây nhanh nhẹn chỉ giúp, nhưng không mạnh mẽ như vậy.
3. Attractive qualitieslà những tính năng tốt đẹp. Họ có thể trở thành phải là thế hệ tiếp theo. Nhưng trong thế hệ hiện tại, họ thậm chí không có trong thỏa thuận - nếu không họ sẽ là những phẩm chất Một chiều. Những phương pháp nhanh nhẹn cho rằng sự tham gia của đại diện khách hàng hỗ trợ rất tốt cho những phẩm chất này. Vì chúng ta có thể thay đổi phạm vi nhẹ trong quá trình làm việc. Chúng tôi có thể mặc cả để cải thiện một nơi cho một số bồi thường ở một nơi khác. Trong thác nước nó thực tế là không thể. Nếu không có sự chậm trễ lớn về tổ chức, chúng tôi chỉ có thể THÊM các tính năng miễn phí. Có thể, nếu một số thời gian thêm trước đây được đưa vào ngân sách.

Vì vậy, các quy trình nhanh có thể hỗ trợ mô hình Kano, một số trong số chúng làm điều đó rất nhiều, và chắc chắn tốt hơn nhiều so với các dự án thác nước tốt nhất.

Để làm điều đó theo sự hiểu biết của bạn, bạn nên thiết lập các quy trình nhanh với người tham gia đại diện khách hàng có trách nhiệm.