Cách hiệu quả để giới thiệu Agile vào nơi làm việc?

Theo kinh nghiệm của bạn (giai thoại hoặc cách khác), một số cách hiệu quả để giới thiệu Agile vào một tổ chức hoặc công ty không phải là Agile là gì?

CẬP NHẬT: Bất cứ ai cũng có thể nói chuyện với các trường hợp bạn đã cố gắng giới thiệu Agile nhưng bạn đã bị "bắn hạ"? Ngoài ra, bây giờ bạn có hiểu lại tại sao bạn bị "bắn hạ" không?

NÓ CỨNG NHƯNG KHÔNG TÁC DỤNG. Trừ khi bạn sống ở thiên đường. Đối với các bước cụ thể bạn có thể thực hiện, tôi hết lòng khuyên bạn nên chọn một bản sao của Thay đổi không sợ hãi

• Đầu tiên nhận được sự hỗ trợ quản lý . Nếu bạn không có gì khác sẽ bù đắp cho điều này .. Nếu cấp trên là tất cả 'Hạn chót là ngày hôm qua ..', 'Cuối tuần làm việc trong 3 tháng tới', 'Tại sao bạn nên viết bài kiểm tra khi bạn nên mã hóa? .. chúng ta có thể kiểm tra sau. ' Con dodo đơn giản là không bay.
• Xem văn hóa của tổ chức của bạn có phù hợp với nhanh nhẹn không. Đây là điều tôi đã bỏ lỡ .. Để mượn một dòng từ cuốn sách .. Quá trình sẽ dễ dàng hơn - nhanh hơn nếu văn hóa hỗ trợ và nuôi dưỡng những ý tưởng mới, cho phép mọi người học hỏi và làm những điều mới, đủ kiên nhẫn để hỗ trợ đổi mới lợi ích lâu dài và không coi thất bại là bản án tử hình
• Người dân : Xác định những người đổi mới: người chấp nhận sớm: đa số sớm: đa số muộn: tỷ lệ tụt hậu. 3 người đầu tiên là đối tượng mục tiêu của bạn ban đầu .. nên ở khoảng 30-40% .. điều đó mang lại cho bạn khối lượng quan trọng để bắt đầu. Vấn đề là Agile biến ánh sáng của những con voi trong phòng .. những thiếu sót và vấn đề trở nên dễ thấy .. nếu bạn sống ở một nơi có "Vụ nổ Bozo" (để trích dẫn thuật ngữ của Guy Kawasaki) , sự thay đổi sẽ thực sự chậm và đau .. nếu có. Chúng tôi có xu hướng cho rằng nếu một ý tưởng là tốt, nó sẽ được chấp nhận. Không đúng. Rất nhiều lý do xã hội học ngẩng cao đầu.
• Tiếp theo đừng thử quá nhiều thứ cùng một lúc. Hãy chậm lại .. làm cho nó dễ dàng . Bí quyết là sử dụng cách tiếp cận giống như mã tái cấu trúc. Tìm những vết thương nhỏ ở đây và ở đó và vá chúng bằng một miếng băng nhanh nhẹn. Hãy chắc chắn rằng mọi người hiểu thực tiễn và lợi ích và họ nên áp dụng chúng theo thời gian. Không phải mọi thứ sẽ gắn bó nhưng nó sẽ sớm trở nên tốt hơn trên toàn bộ. Thời gian sớm phụ thuộc vào một số biến số trong số đó nằm ngoài tầm kiểm soát của bạn.
• Đó là một khoản đầu tư cá nhân lớn để thực hiện điều này . Kiểm tra lại nếu bạn sẵn sàng thực hiện cam kết này và trải qua những thăng trầm mà nó mang lại. Ngoài ra, bạn có thể phải trao dùi cui cho người khác hoặc cao hơn .. Hãy sẵn sàng từ bỏ quyền sở hữu thay đổi vì lợi ích lớn hơn. Đừng rơi vào hội chứng 'Đó là con tôi'.
• Agile là khác nhau đối với mỗi nhóm, mỗi tổ chức .. Không phải mọi thứ bạn đọc / đề xuất sẽ hoạt động .. hãy để sự chấp nhận hướng dẫn bạn hướng tới những điều sẽ phù hợp với kịch bản của bạn. Tìm những cách khác bù đắp cho những thực tiễn không bén rễ.

Hy vọng điều đó có ý nghĩa .. như bạn có thể đoán tôi đã ở đây một thời gian :)

Lắng nghe nhóm, quản lý, các bên liên quan và lắng nghe manh mối. Họ có khả năng cảm thấy đau ở một số khu vực mà Agile trực tiếp giải quyết.

Bám sát những gợi ý có thể trực tiếp làm giảm bớt những cơn đau đó. "Bạn không thể chữa lành những gì bạn không thể cảm thấy" - có thể nói như vậy.

Điều này mất một thời gian dài, nhưng việc xây dựng niềm tin là vô cùng quan trọng. Với những thành công trong quá khứ và có được sự tin tưởng của cả nhóm của bạn và người quản lý của bạn, họ sẽ tìm đến bạn khi đến lúc đưa ra quyết định.

Tôi đã thấy điều đó xảy ra bằng chính mắt mình, sau nhiều năm thất vọng khi cố gắng khiến mọi người thay đổi cách chúng tôi cung cấp phần mềm. Và trong khi tôi đang có những thành công bây giờ, tôi không có nơi nào gần hoàn thành. Có TẤN các lĩnh vực để cải thiện và hiện tôi đang thành công nhất với việc giới thiệu những thay đổi nhỏ trực tiếp giải quyết một số loại đau mà chúng ta đang cảm thấy.

Cuối cùng tôi chỉ muốn nói là rất đồng cảm. Tôi đã phạm sai lầm khi loại bỏ hầu hết các ý tưởng trước khi tôi thực sự nghĩ đến chúng bởi vì tôi đã không đọc về nó trong "cuốn sách nhanh XYZ". Lắng nghe nhóm của bạn và cố gắng thực hiện một số đề xuất của họ sẽ đi một chặng đường dài.

Chúc may mắn!

Bỏ qua kỹ thuật, chúng tôi đã phát hiện ra rằng việc tìm một nhóm trong tổ chức có thể mua các phương pháp Agile và cung cấp 'giường thử nghiệm' là rất quan trọng. Chúng tôi có nhiều người ở công ty chúng tôi không hiểu các thuật ngữ Agile khác nhau, bị nhầm lẫn bởi các điều khoản và quy trình, và có nỗi sợ chung.

Nhóm nghiên cứu của tôi rất quan tâm đến việc cố gắng làm cho Scrum hoạt động (cùng với một số phương pháp loại Agile khác). Sự quan tâm của chúng tôi cho phép chúng tôi tạo thành một giường thử nghiệm trong công ty để thử các yếu tố khác nhau. Chúng tôi đã giảng dạy rất nhiều trước tiên - nói chuyện với mọi người, thuyết trình cho các giám đốc điều hành của công ty, v.v. Chúng tôi đã không thúc đẩy mạnh mẽ - chúng tôi đã giáo dục. Sau đó, chúng tôi đã xin phép chỉ để thử nó với nhóm của chúng tôi.

Sẽ có rất nhiều câu trả lời về việc thực nghiệm cho thấy những thứ như lập trình cặp, phát triển dựa trên thử nghiệm, Scrum, v.v ... đều có thể tiết kiệm thời gian, nhưng vào cuối ngày tôi cảm thấy rằng bằng chứng cần phải đến từ công ty của bạn. Tìm một nhóm mà bạn có thể sử dụng làm giường thử nghiệm và khiến họ thực sự làm điều đó. Không có gì sẽ làm giảm bớt nỗi sợ hãi tốt hơn là cho thấy rằng nhóm của bạn làm cho nó xảy ra.

Nhét nó xuống cổ họng của họ, nhưng không nhận ra họ;)

Tôi đã dần dần cố gắng thực hiện các nguyên tắc nhanh nhẹn (chủ yếu là scrum) vào nơi làm việc của tôi trong hơn 6 tháng qua. Lần đầu tiên tôi giới thiệu các hoạt động đứng hàng ngày, điều này đã quen với mọi người, nhưng nó hoạt động khá tốt. Vì tất cả chúng ta đều làm việc trên các chương trình khác nhau, tất cả đều là một phần của một hệ thống, nên theo định nghĩa thì hơi khó để theo dõi scrum. Bước tiếp theo của tôi là bắt đầu các cuộc họp chạy nước rút để theo dõi từng bản phát hành của chúng tôi. Chúng tôi đã đi một chu kỳ dài một tháng rồi, vì vậy độ dài nước rút không phải là vấn đề. Tôi cũng có kế hoạch tuân thủ đầy đủ các nguyên tắc scrum trong dự án lớn tiếp theo của chúng tôi. Tôi là một trong hai nhà phát triển trong nhóm cho dự án, và anh ấy là tất cả để cải tiến liên tục. Hy vọng của tôi là quản lý sẽ thấy được lợi ích của những gì tôi đang cố gắng thực hiện.

Tôi nghĩ rằng chìa khóa là để làm cho nó chậm. Những người đã ở vị trí tương tự trong nhiều năm thường chống lại sự thay đổi xâm nhập, nhưng nếu bạn có thể lén lút từng mảnh một, họ không nên chú ý. Bắt đầu với các cuộc họp nhỏ thường xuyên lúc đầu là tốt. Bằng cách giữ cho chúng ngắn, quản lý không nên xem nó là một sự lãng phí thời gian.

Hướng phát triển thử nghiệm. Trình diễn cách kiểm tra đơn vị có thể tăng tốc độ dev của bạn. thời gian trong khi đồng thời làm cho mã ổn định hơn là bước đầu tiên tuyệt vời để uống Kool-Aid nhanh nhẹn.

Cải thiện bản thân trước. Có thật không. Ví dụ là cách mạnh mẽ để nói về nhanh nhẹn. Hơn nữa, như ai đó đã nói, tránh các định nghĩa kỹ thuật và chỉ sử dụng các thuật ngữ mà người quản lý và người điều hành có thể hiểu. Hai tuần thay vì Sprint; Lập kế hoạch thay vì Lập kế hoạch hoặc Trò chơi lập kế hoạch Sprint; Quản lý sản phẩm thay vì Chủ sở hữu sản phẩm và như vậy. Michele Sliger đã có một bài thuyết trình tuyệt vời về Agile trong Waterfall Enterprise . Thực sự phải xem video. Bạn cũng có thể quan tâm đến một video khác về việc áp dụng nhanh .

Nơi tôi đang làm việc, tôi biết rằng Scrum là một cách tốt để bắt đầu nhanh nhẹn vì quản lý hiểu nó nhanh. Nó là đơn giản và có một cái tên đẹp. Latter, khi thực hiện Retrospectives, bạn có thể đề xuất các thực tiễn XP là cải tiến và sẽ khá dễ dàng để mọi người chấp nhận ít nhất là thử chúng.

Trân trọng

Chúng tôi đã giới thiệu nó vào các nhiệm vụ 'Bảo trì' (lỗi, thay đổi tác động thấp, v.v.) dưới dạng nước rút 2 tuần. Vì vậy, các nhà phát triển đang làm việc trên các dự án dài hạn vẫn như cũ, nhưng chúng tôi đã có một cuộc chạy nước rút Bảo trì luân phiên. Vì vậy, mọi người đều có cơ hội sử dụng các biểu đồ chi tiết và ước tính poker trong khi không làm gián đoạn các dự án lớn.

Sau đó, khi mỗi dự án lớn kết thúc, chúng tôi bắt đầu dự án tiếp theo bằng cách sử dụng nước rút 2 tuần nhanh nhẹn. Toàn bộ quá trình này mất vài tháng trước khi mọi người chạy nước rút, nhưng điều đó có nghĩa là ít bị gián đoạn hơn và mọi người đều có thể 'dễ dàng' tham gia vào quá trình

Trong nhóm phát triển, giới thiệu Agile là một thứ gì đó mà bạn có một số mức độ kiểm soát.

Tuy nhiên, tôi thấy vấn đề chính là Agile yêu cầu phản hồi liên tục từ "khách hàng" hoặc đại diện khách hàng của bạn.

Do đó, bạn thực sự cần tập trung vào khía cạnh giáo dục cho những người bên ngoài nhóm phát triển trực tiếp của mình, vì họ có thể cần phải thay đổi cách họ làm việc theo một cách nào đó (nghĩa là tiếp xúc nhiều hơn với nhóm phát triển).

Cách tốt nhất tôi muốn nói là tập trung vào các lợi ích không hiệu quả của việc tiếp nhận một quy trình Agile và truyền đạt những điều này rõ ràng cho khách hàng của bạn. Tất nhiên nếu bạn có một khu vực bán hàng / tài khoản trong công ty của bạn, điều tương tự cũng áp dụng ở đó.

Bước 1: đảm bảo dự án của bạn tồn đọng và đảm bảo rằng nó được ưu tiên

Bước 2: giới thiệu các thực hành SCRUM (lặp lại có thể quản lý, đứng lên hàng ngày, scrum-master, chủ sở hữu sản phẩm, biểu đồ phát sinh)

Bước 3: mỗi lần lặp lại kết quả của đội hiện tại với kết quả cuối cùng

sau đó ...
triển khai TDD / BDD, lập trình cặp, đánh giá mã (tất cả đều rất nhẹ nhàng) và nếu bạn có một nhóm đủ tốt, hãy nhờ mọi người cùng đặt (một phòng nhóm nếu có thể).

Trên hết, hiểu rằng sẽ có sự kháng cự (S BE ĐƯỢC), vì vậy hãy sẵn sàng để quản lý điều đó.

Một điều cần nhớ là nếu bạn là thành viên của một tổ chức (lớn hay nhỏ) mà toàn bộ sẽ không tuân theo những thực tiễn tốt nhất này thì có thể sẽ mất một lúc (nếu có) để cảm thấy như bạn đang tiến bộ.

Mọi người luôn chống lại sự thay đổi, và chuyển sang scrum là một điều khá lớn. Động lực và định hướng là chìa khóa.

Bước đầu tiên là khiến mọi người có động lực để tạo cơ hội cho Scrum. Tôi thấy rằng Google Tech Talk của Ken Schwaber rất hữu ích trong việc giúp mọi người nhận ra lợi ích của scrum trong khi cung cấp một giới thiệu tốt. Bắt đầu với những người mà bạn cảm thấy sẽ chấp nhận thay đổi cho dù họ là nhà phát triển hay người quản lý, vì vậy bạn có thể xây dựng một số động lực. Có được những người quản lý về phía bạn sẽ là một điều cần thiết vào một lúc nào đó, nhưng cách bạn xử lý điều đó phụ thuộc vào môi trường của bạn.

Sau đó, mọi người cần được đào tạo, cho dù điều đó có nghĩa là đọc một cuốn sách hoặc có một chuỗi bài giảng. Trừ khi mọi người biết cách hoạt động của scrum, bạn không thể bắt đầu thử thực hiện quy trình.

Một khi mọi người có động lực và có ý tưởng về những gì họ cần làm, bạn cần có cuộc họp lập kế hoạch đầu tiên của bạn và thiết lập các phần cần thiết của scrum (người kiểm tra, cuộc họp hàng ngày, v.v.).

Tôi hy vọng rằng cuộc họp lập kế hoạch đầu tiên sẽ không diễn ra suôn sẻ, và sẽ là một kinh nghiệm học tập cho mọi người. Ngoài ra một vài lần chạy nước rút đầu tiên sẽ rất nhiều đá, và có thể chậm tiến độ. Phần quan trọng bây giờ là kỷ luật và kiên trì. Đừng để các cuộc họp hàng ngày diễn ra quá lâu, hãy duy trì các cuộc họp lập kế hoạch và đảm bảo mọi người đều thực hiện đúng vai trò của mình.

Tôi nghĩ rằng những người có khả năng chống chịu cao nhất là những người đã phát triển phần mềm trong một thời gian dài hoặc những người cảm thấy rằng bằng cách chuyển sang scrum, họ thừa nhận rằng họ đã làm sai điều gì đó trước đây. Đó là một trở ngại khó khăn để vượt qua, nhưng tôi nghĩ bằng cách cho họ thấy những lợi ích mà bạn có thể từ từ thuyết phục họ. Nó chỉ cần thời gian. Theo kinh nghiệm của tôi, các nhà quản lý sản phẩm thực sự chống đối vì điều đó buộc họ phải rõ ràng hơn về yêu cầu của họ và những gì họ muốn. Nhưng một khi họ thấy quá trình nhanh nhẹn mang lại lợi ích cho họ như thế nào và làm cho cuộc sống của họ dễ dàng hơn, họ lên tàu khá nhanh.

Chúc may mắn!

• Chứng minh thành công - xem câu trả lời của mark
• Đặc biệt chú ý đến các nguyên tắc / kỹ thuật sẽ gây ra tác động cao nhất trong công ty
• Hãy nhớ rằng đó là về các nguyên tắc nhanh, và không phải là một danh sách kiểm tra quy trình

Trước khi nghĩ về việc giới thiệu phát triển nhanh, trước tiên hãy khám phá cái nào phù hợp nhất cho tổ chức / dự án của bạn. Ví dụ, nếu bạn đang xem xét scrum, hãy xem xét liệu bạn có sử dụng nó một cách nghiêm ngặt hay nếu một hình thức scrum lỏng lẻo hơn, hoặc thậm chí một phương pháp khác hoàn toàn có thể phù hợp hơn. Câu trả lời của tôi sau đó là trên scrum như phương pháp nhanh của bạn.

Scrum là tuyệt vời cho các dự án đòi hỏi sự đổi mới, nơi ít được biết đến và nơi cần thử nghiệm. Nó không phù hợp nhất để làm những việc như bảo trì các sản phẩm hiện có hoặc xử lý công việc bảo trì định kỳ. May mắn thay, scrum là một khung lỏng lẻo và bạn có thể sử dụng nó theo cách tốt nhất có thể.

Đối với công việc bảo trì, Kanban có thể tốt hơn cho bạn hoặc bạn có thể thử chỉ một vài yếu tố scrum để quản lý chạy nước rút và thực hiện những việc như đứng lên hàng ngày. Tôi gọi đây là "scrum-but", "vâng, chúng tôi làm scrum trong công ty của chúng tôi nhưng ...". Điều đó tốt, đừng cảm thấy tồi tệ về điều đó.

Để giới thiệu scrum thích hợp trong tổ chức của bạn, bạn cần có sự tham gia của chủ sở hữu sản phẩm và chủ sở hữu cổ phần. Nếu bạn là một công ty nhỏ, anh chàng đó có thể là một người, ông chủ và trong một công ty lớn hơn là giám đốc sản phẩm và trưởng phòng / sếp. Tôi muốn đề xuất hai tuyến giới thiệu scrum:

1) bạn có thể bắt đầu sử dụng scrum ở dạng hơi lỏng hơn để quản lý hàng đợi công việc hiện tại ngay lập tức. Nhưng nhìn vào Kanban quá.

2) bắt đầu sử dụng scrum ở dạng nghiêm ngặt hơn đối với một số dự án mới sẽ yêu cầu đổi mới, phản hồi sớm và nơi chưa biết nhiều. Bạn có thể đề xuất với ông chủ / chủ sở hữu sản phẩm rằng scrum sẽ là lý tưởng cho dự án mới này.

Nhưng hãy nhớ! Đây không chỉ là về mã, chủ sở hữu sản phẩm có một phần quan trọng và phải hiểu và hoàn thành vai trò của mình. Điều đó có nghĩa là ví dụ không viết tất cả các thông số kỹ thuật lên phía trước, thay vào đó bắt đầu với mức tối thiểu, lặp lại nhanh chóng, nhận phản hồi, học hỏi và cho ăn trở lại. Cố gắng làm việc với một người quản lý sản phẩm, người sẵn sàng giới thiệu scrum như bạn nhưng từ phía chủ sở hữu sản phẩm, và lý tưởng là anh ấy / cô ấy nên đủ cứng rắn để chống lại các yêu cầu quản lý và bảo vệ nước rút.

Sẽ cần nỗ lực thống nhất từ ​​phát triển và quản lý sản phẩm để giới thiệu scrum.

Trong một dự án mới như vậy, hãy thử và đưa nhóm mới chuyển đến một phòng riêng và sử dụng các ghi chú sau đó để trực quan hóa công việc ở các trạng thái khác nhau như tồn đọng, đang tiến hành, v.v. Đừng để bị sa lầy vào các công cụ điện tử ở giai đoạn này , giữ mọi thứ đơn giản nhất có thể. Đừng cảm thấy ngớ ngẩn khi lập kế hoạch chơi bài với những lá bài khi bạn bắt đầu, khi nhóm của bạn tăng tốc, bạn có thể sẽ không sử dụng chúng chỉ bằng cách nói những con số.

Theo kinh nghiệm của tôi, việc giới thiệu scrum ở dạng thuần túy trước tiên dễ dàng hơn sau đó dễ dàng sử dụng nó cho hàng đợi công việc kiểu bảo trì nhiều hơn. Cách khác là khó hơn.

Nhận xét cuối cùng của tôi là hãy cẩn thận khi nghĩ rằng scrum là một loại thuốc chữa bách bệnh phát triển, không phải vậy. Scrum là một khung hữu ích và đơn giản để đổi mới sản phẩm nhưng khám phá các phương pháp khác kết hợp khi doanh nghiệp của bạn yêu cầu và không cảm thấy tồi tệ về nó.

Vài năm trước, tôi là cố vấn trong một công ty rất lớn (gần 20.000 nhân viên) đang điều hành nhiều dự án phần mềm doanh nghiệp lớn. Tôi đã ở trên một trong số họ. Một điều khá quan trọng.

Chúng tôi đã phải đối mặt với nhiều vấn đề và áp lực đã đè nặng lên chúng tôi, nhóm phát triển. Các vấn đề chỉ phổ biến đối với ngành công nghiệp phần mềm, nhưng ban quản lý có trải nghiệm định hướng cơ sở hạ tầng nhiều hơn và rất ít kinh nghiệm định hướng phần mềm. Vì vậy, mọi thứ đã tập trung vào chúng tôi. Tôi nghĩ rằng sẽ là một ý tưởng tuyệt vời để nói với ban quản lý về Scrum.

Tôi đã phải đối mặt với sự miễn cưỡng mạnh mẽ, vì vậy tôi đã bỏ ý tưởng trong một thời gian. Nhưng các vấn đề vẫn tiếp tục gia tăng nên với nhà tài trợ của trưởng nhóm, cuối cùng chúng tôi đã quyết định tạo Scrum bằng mọi cách, bởi ourselve.

Bất cứ ai, kể cả tôi, đã có bất kỳ kinh nghiệm nào với Scrum. Vì vậy, chúng tôi đã phát hiện ra khuôn khổ bằng cách làm ...

Ngày nay, Scrum được khái quát cho toàn doanh nghiệp thông qua một chương trình được quản lý bởi một huấn luyện viên được chứng nhận. Tôi không biết nếu sáng kiến ​​của chúng tôi là kích hoạt. Điều đó nói rằng, tôi biết rằng đó là một cuộc cách mạng thực sự trong công ty khá cứng nhắc.

Tôi nghĩ để giới thiệu một cái gì đó vào một doanh nghiệp như vậy, bạn phải tôn trọng các nguyên tắc sau:

• Nó phải thay đổi là cần thiết . Nếu không có lý do thuyết phục rằng thay đổi phải được thực hiện, không có lý do tại sao các đội quản lý tại chỗ phải chấp nhận rủi ro.

• Chúng ta phải tập trung vào các vấn đề của quản lý và không đề cập đến các vấn đề của các nhà phát triển, trừ khi chúng là một phần của mối quan tâm quản lý. Nói cách khác, bạn phải đi kèm với một giải pháp cho họ, không phải cho bạn. Đặt mình vào vị trí của ban quản lý. Mối quan tâm của họ là gì?

• Bạn không nên đề xuất thay đổi toàn bộ tổ chức cùng một lúc . Bạn phải đề xuất một dự án thí điểm mà bạn sẽ chịu trách nhiệm. Tôi khuyên bạn nên đưa ra các mục tiêu thực tế, chẳng hạn như sự gia tăng đáng kể về khả năng hiển thị về những gì đang diễn ra trong dự án. IMHO, đóng góp chính của Scrum trong quản lý phần mềm. Nó cho phép ý thức chung của con người hoạt động và do đó tiến về phía trước.

• Cuối cùng, điều bắt buộc là phải đảm bảo rằng những người có kinh nghiệm kiểm soát phần giới thiệu này. Đừng chỉ đọc một hoặc hai cuốn sách. Bạn phải đi đào tạo và tôi sẽ nói rằng nó là khá cần thiết để sử dụng một huấn luyện viên có kinh nghiệm. Rõ ràng, nó có thể được thực hiện mà không có, nhưng nó sẽ bị đau :)

Nếu bạn làm theo các nguyên tắc và đi kèm với sự thật, nó sẽ hoạt động. Về sự thật, bạn sẽ tìm thấy nhiều trong cuốn sách Phần mềm trong 30 ngày: Làm thế nào các nhà quản lý nhanh nhẹn đánh bại các tỷ lệ cược, làm hài lòng khách hàng của họ và để các đối thủ cạnh tranh trong bụi . Đây là cuốn sách mới nhất của những người sáng tạo Scrum, Ken Schwaber và Jeff Sutherland .

Trong một bài đăng trên blog của Ken về cuốn sách bạn có thể đọc:

Jeff Sutherland và tôi đã làm điều đó. Chúng tôi đã viết một cuốn sách cùng nhau, bài viết chung đầu tiên của chúng tôi kể từ lần xuất bản đầu tiên của Scrum vào năm 1995. Điều gì đã thúc đẩy chúng tôi? Câu hỏi mà chúng tôi thường được hỏi:

Làm thế nào để chúng tôi bán Scrum cho quản lý của chúng tôi?

Tôi luôn bối rối trước câu hỏi này. Tại sao bạn phải bán nhiều dự đoán, năng suất, chất lượng, giá trị, kiểm soát rủi ro, khách hàng hài lòng, nhân viên tham gia và ít lãng phí hơn cho bất kỳ ai trong quản lý? Tuy nhiên, tôi đã nói chuyện với Jeff và chúng tôi đã tìm ra rằng nơi nào có khói thì phải có lửa.

Chúng tôi đã dành nửa cuối năm 2011 để viết cuốn sách. Bất kỳ người quản lý, từ trên xuống dưới, có thể dễ dàng chọn và đọc cuốn sách này.

[...]

Chúng tôi thấy nó tất cả các thời gian. (công bố đầy đủ: Tôi đang phát triển một ứng dụng quản lý dự án). Vấn đề là các phương pháp nhanh nhẹn đưa một sự căng thẳng vốn có vào các tổ chức được quản lý theo truyền thống. Thông thường, quản lý cấp trên muốn có thể lên kế hoạch trước. Họ muốn kế hoạch 3 năm; họ muốn các dự án ước tính đúng; họ muốn có khả năng ngân sách tuyển dụng người mới; họ muốn có thể cam kết với các mốc quan trọng khi nói đến đối tác / khách hàng.

Nhưng sau đó bộ phận R & D quyết định sẽ đi nhanh. Nó không còn là về kế hoạch trước trong hai tháng trước khi viết mã. Nước rút sẽ ngắn và vượt quá nước rút, bạn có được ước tính độ phân giải rất thấp của nội dung tồn đọng trong lộ trình tồn đọng / lộ trình. R & D nhận ra rằng các yêu cầu thay đổi quá thường xuyên để thác nước cổ điển có hiệu quả, nhưng các nhà quản lý sản phẩm muốn có một tầm nhìn rõ ràng, chu đáo và được ngân sách tốt về sản phẩm sẽ trông như thế nào trong 12 tháng.

Vấn đề, sau đó, là để hòa giải hai. Như tôi đã nói, chúng tôi thấy điều này mọi lúc xảy ra với khách hàng của chúng tôi. Do đó, giải pháp của chúng tôi là thống nhất các công cụ được sử dụng để thực hiện cả chạy nước rút và lập kế hoạch dài hạn. Được rồi, bây giờ đến phần cắm không biết xấu hổ, vì vậy hãy thoải mái mang nó với một hạt muối. Một trong những tính năng độc đáo của chúng tôi là chúng tôi sử dụng giao diện người dùng có thể phóng to để quản lý các tác vụ. Có nghĩa là rất dễ dàng để đi sâu vào một số câu chuyện / tác vụ người dùng và giải thích chi tiết về nó. (bạn có thể thấy nó trông như thế nào ở đây ). Thực sự không có khái niệm nào về một "dự án" trong hệ thống của chúng tôi cả. Đó là tất cả các nhiệm vụ có chứa các nhiệm vụ khác, liên kết với các nhiệm vụ khác (một fractal, thực sự). Điều này tạo ra một vệt mờ đẹp giữa câu chuyện của người dùng, nhiệm vụ, dự án, sử thi, v.v.

Trong thực tế, điều mà nhiều người dùng của chúng tôi thực hành các phương pháp nhanh nhẹn làm là tạo ra một kế hoạch kính thiên văn hợp nhất bản đồ đường dài hạn (hoặc tồn đọng) với việc quản lý các lần chạy nước rút ngắn (hoặc lặp lại). Các nhà quản lý vẫn có thể thấy một bản đồ ước tính đẹp về các tính năng chính đang chờ được thêm vào và các nhà phát triển chỉ cần phóng to sâu hơn và xử lý các tác vụ công việc thực tế. Một lợi thế này là nó làm giảm số lượng "mặc cả" diễn ra khi các nhà quản lý xem xét kế hoạch làm việc. Thay vì nhóm phát triển chỉ cung cấp các ước tính rất sơ bộ (ví dụ: "4 - 6 tuần!"), Họ có cơ hội phóng to từng câu chuyện của người dùng trong câu hỏi và chia nó thành các phần nhỏ hơn. Khi bạn làm điều đó đột nhiên có ít chỗ hơn để mặc cả. Bạn dành 10 phút để chia nhỏ câu chuyện người dùng 5 tuần thành các phần có kích thước khoảng 1 ngày, và đột nhiên cuộc tranh luận không phải là "không, bạn có thể làm điều đó nhanh hơn. không, chúng tôi không thể. vâng, bạn có thể." nhưng "đây là những gì đi vào nỗ lực này, bao gồm tất cả các công việc ẩn mà ước tính ban đầu không xem xét. Bạn đề nghị chúng tôi loại bỏ gì? Đảm bảo chất lượng? Kiểm tra? Đào tạo anh chàng mới? Thiết lập môi trường xây dựng?".

Cách tiếp cận này hoạt động miễn là bạn đang sử dụng một công cụ cho phép bạn thay đổi kế hoạch nhanh như ban đầu bạn phác thảo chúng. Đó là lý do thực sự khiến mọi người ngày nay ghét thác nước. Hầu hết các hệ thống làm cho nó cực kỳ khó khăn để làm lại hoàn toàn các kế hoạch hiện có và mọi người rất hợp lý từ chối lãng phí thời gian cho hoạt động này.

Được rồi, tôi cảm thấy như điều này đang biến thành một mục đích bán hàng, vì vậy tôi sẽ dừng ngay bây giờ. :)