Tại sao tôi cần SCRUM so với quy trình nhẹ hơn, trang trọng hơn cho nhóm của mình?

Tôi muốn bắt đầu câu hỏi của mình bằng cách nói rằng tôi hiểu rằng SCRUM hoặc một số dẫn xuất của nó có lẽ là một cách tốt để quản lý phát triển phần mềm. Dường như tất cả các công ty lớn và các nhà quản lý của tôi sử dụng nó hoặc đã sử dụng nó và tôi thực sự không thể tranh luận với tất cả kinh nghiệm đó. Tuy nhiên, tôi đang đấu tranh để hiểu "cá nhân" và tất cả việc đọc và thậm chí đào tạo SCRUM chính thức của tôi tại nơi làm việc không làm việc cho tôi. Đó chỉ là tất cả những lời hoa mỹ. Vì vậy, tôi đến đây để tìm kiếm câu trả lời.

Cho đến bây giờ, tôi đã phát triển trong các nhóm 4-5 thành viên rất hiệu quả, hoàn toàn tự tổ chức và không cần bất kỳ đào tạo, phương pháp hoặc phần mềm đặc biệt nào. Chỉ cần thảo luận trong các hình khối, các cuộc họp đặc biệt và đánh giá mã một-một. Bây giờ tôi đang ở một vị trí trong công việc nơi chúng tôi được thông báo SCRUM là con đường để đi và mọi thứ đi kèm với nó. Khi họ mô tả SCRUM cho tôi, tôi đọc những thứ như thế này:

• Các 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 qua đàm phán hợp đồng
• Đáp ứng để thay đổi theo kế hoạch

Điều đó thật tuyệt, nhưng tất cả dường như là lẽ thường với tôi. Tại sao điều này cần được mã hóa? Sau đó, tôi nói với phương pháp giúp chúng ta phản ứng với sự thay đổi. Cụ thể là gìcác khía cạnh của SCRUM đang cho phép tôi linh hoạt đến mức mà trước đây tôi không đạt được với các cuộc họp quảng cáo, thảo luận khối và các cuộc họp lập kế hoạch dành cho nhà phát triển? Họ giải thích sự cần thiết phải có một công việc có thể giao hàng hai tuần một lần, hoặc chạy nước rút. Trong dự án cụ thể của tôi, không có "khách hàng", phần mềm sẽ không được hoàn thành trong một năm hoặc hơn và trong khi đó, tôi có thể sẽ chỉ giới thiệu cho quản lý cấp trên mỗi tháng hoặc ít hơn. Vậy tại sao nhu cầu rõ ràng về việc giao hàng mỗi tuần? Họ nhấn mạnh tầm quan trọng của cuộc họp lập kế hoạch nước rút trong đó toàn bộ nhóm đưa ra những câu chuyện và nhiệm vụ cho lần chạy nước rút tiếp theo. Điều này không khác gì các cuộc họp lập kế hoạch ngẫu hứng mà tôi đã có trong quá khứ. Tại sao nó phải xảy ra vào mỗi thứ Hai khác, và tại sao toàn bộ đội phải tham gia? Tôi hiểu khái niệm của mọi thành viên "sở hữu" sản phẩm, nhưng thực tế là, chỉ có một vài cá nhân có thể thực sự đóng góp để chia từng câu chuyện thành nhiệm vụ, trong khi những người còn lại chỉ xem nhàn rỗi.

Một lần nữa, tôi hiểu rằng phần lớn mọi người đứng sau quá trình này, và vì vậy nó phải hoạt động, và tôi cần phải lên tàu. Tôi chỉ muốn hiểu tại sao. Có phải vấn đề của tôi là tôi đã thực hành những điều này và chỉ không thích mã hóa chúng một cách không cần thiết? Hoặc có lẽ tôi chưa thấy những lợi thế của các kỹ thuật này vì chúng được thực hiện không đúng cách? Bất kỳ thông tin thực tế , thông tin cá nhân hoặc lời khuyên nào về vấn đề này, trái ngược với thông tin mà tôi từng nhận được, sẽ được đánh giá rất cao.

Tôi nghĩ có hai khía cạnh để trả lời câu hỏi của bạn, nhưng hãy để tôi bắt đầu chúc mừng bạn vì đã làm việc với những người có vẻ thông minh và đủ năng lực để có thể làm việc khá nhiều mà không cần một quy trình mạnh mẽ mà vẫn cung cấp sản phẩm. Thật không may, đây không phải là trường hợp trong tất cả các nhóm phần mềm, vì vậy có thể một trong những vấn đề của bạn với Scrum có thể là bạn và đồng nghiệp của bạn thực sự không cần một quy trình đổ vào bạn để giúp bạn hiệu quả hơn. Bạn có thể đã có hiệu quả.

Các đội khác không và cần một quy trình được xác định chặt chẽ hơn và một số hướng dẫn để khiến họ hoàn thành công việc. Điều này không có nghĩa là các đội này ngu ngốc hơn hoặc kém khả năng hơn, điều đó chỉ có nghĩa là có thể họ gặp vấn đề trong việc tự tổ chức hoặc làm việc với kỷ luật như một đội. Đây cũng có thể là một kinh nghiệm học tập đơn giản khi đến từ một nơi mà mọi người làm việc chủ yếu một mình để làm việc cùng nhau như một đội. Scrum có thể giúp đạt được điều đó, bởi vì nó cung cấp một vài hướng dẫn vừa đủ dễ hiểu và làm theo, nhưng đủ hiệu quả để gây áp lực lên nhóm để bắt đầu kết hợp nó.

Vì Scrum không nói gì về cách phát triển phần mềm nên nó cũng khiến nhóm có quyền tự do quyết định (ví dụ: bạn vẫn có thể chạy nước rút áp dụng phương pháp thác nước khá bảo thủ miễn là bạn hoàn thành kết thúc nước rút).

Vì vậy, nhóm là một vấn đề. Vấn đề còn lại là quản lý và ủy thác quản lý. Ở đây, Scrum có thể tốt vì nó minh bạch và cho phép bất kỳ bên liên quan nào nhìn thấy tiến trình mà nhóm thực hiện trong các chu kỳ xác định. Vì vậy, đó không phải là "chúng tôi đang tiến bộ, tiếc là chúng tôi không thể cho bạn thấy bất cứ điều gì ngay bây giờ, nhưng hãy tin chúng tôi, chúng tôi sẽ hoàn thành đúng hạn". Điều này thậm chí có thể đúng, nhưng có thể yên tâm cho bất kỳ nhà quản lý nào thực sự có một bản demo thông thường nơi họ có thể thấy rằng tiến trình đã thực sự xảy ra.

Scrum không phải là viên đạn bạc. Nó có thể không hoạt động đối với một số nhóm vì nhiều lý do, có thể đối với một số nhóm tự tổ chức không hoạt động. Có thể đối với bạn đó là cách khác và có vẻ như một quá trình đổ vào một đội ngũ đã có năng suất và có tổ chức.

Khi nghi ngờ tôi sẽ đề nghị bạn thử nó và xem. Nếu nó không hoạt động và phần lớn hơn của nhóm không thích làm việc theo cách đó, đừng làm điều đó. Tuy nhiên, hãy kiểm tra nó trong một vài tháng (tôi nói là một vài tháng, vì một vài lần chạy nước rút đầu tiên sẽ rất khó xử và bạn cần thời gian để điều chỉnh các chi tiết) và sau đó đánh giá lại.

Có thể gây tranh cãi, nhưng Scrum là tốt nhất để giảm bớt nỗi sợ quản lý của Agile hoặc sử dụng với một nhóm đã hoạt động kém. Nếu nhóm của bạn đang hoạt động tốt, đạt được mục tiêu, kiếm tiền và hạnh phúc, Scrum sẽ không mua cho bạn bất cứ điều gì vì tất cả những gì sẽ làm là làm mất cân bằng tốt các hoạt động mà bạn làm (và làm cho nhóm của bạn thành công). Scrum không phải là viên đạn bạc. Theo kinh nghiệm của tôi với nó, nó chỉ giúp các đội có dự toán và giao tiếp kém bắt đầu. Một nhóm làm việc với các ước tính thực tế trong một môi trường giao tiếp hiệu quả chỉ bị cản trở bởi quá trình hoạt động của Scrum.

Dù bạn có tin hay không, các nhóm phần mềm tốt đã tồn tại trước khi Scrum xuất hiện. Scrum giúp những người xấu trở nên tốt hơn.

Hầu hết các câu trả lời ở đây đã liệt kê lý do, mặc dù có một chút gián tiếp. Câu trả lời của Anne đặc biệt sáng tỏ khi cô chạm vào sự minh bạch. Đó là, cho phép các nhà quản lý để xem những gì đang xảy ra. Và câu trả lời của Schultz cũng chạm vào điều này khi ông nói về việc mọi người không thể che giấu sự thật rằng họ đang chùn bước.

Vì vậy, tôi muốn nói những gì người khác đã nói nhưng bằng ngôn ngữ trực tiếp hơn: mục tiêu chính của SCRUM không phải là quản lý phát triển phần mềm, mục tiêu chính của SCRUM là đo lường sự phát triển phần mềm.

Các hệ thống khác đã thử trước đây và mọi người đã đề xuất vô số số liệu để thử và đo lường sự phát triển phần mềm nhưng đã thất bại. SCRUM đặt vấn đề lên đầu và chuyển gánh nặng đo lường ra khỏi các nhà quản lý và lên chính các nhà phát triển. Logic rất đơn giản: ai tốt hơn để ước tính mất bao lâu để làm một việc gì đó hơn những người tự làm công việc đó?

Bây giờ, vấn đề với điều này là các lập trình viên nổi tiếng là quá lạc quan. Hỏi một lập trình viên mất bao lâu để làm một việc gì đó và anh ta thường sẽ đánh giá thấp mức độ khó của nhiệm vụ thực sự. SCRUM cung cấp các công cụ để kiểm soát điều này:

• các cuộc họp hàng ngày để đánh giá tiến độ và có được cái nhìn toàn cảnh về dự án
• ước tính được thực hiện theo "điểm" thay vì giờ / ngày để trừu tượng hóa thời gian
• biểu đồ ghi điểm và biểu đồ tra tấn / thỏ để hình dung vận tốc của các điểm
• những câu chuyện và nhiệm vụ trên một bảng để có cái nhìn tổng thể về khối lượng công việc
• chạy nước rút và lặp đi lặp lại để làm thời hạn để chúng tôi có thể đo lường tiến độ
• vai trò cụ thể của chủ scrum, chủ sở hữu và thành viên nhóm để tránh sự cám dỗ gian lận

v.v.

Bạn có thể nhận thấy rằng tất cả những điều trên chủ yếu làm hai việc:

1. Họ đo lường công việc. Hoặc là công việc phải hoàn thành hoặc công việc đang hoàn thành hoặc công việc đã hoàn thành.
2. Họ cố gắng hết sức để tránh vấn đề của lập trình viên quá mức để có được ước tính tốt hơn, thực tế hơn.

Bạn thực hiện SCRUM càng lâu thì bạn càng thấy chính xác ước tính của mình. Trên thực tế, cá nhân tôi tin rằng việc chạy nước rút + tồn đọng + biểu đồ ghi chú là đủ để chữa cho hầu hết các lập trình viên về việc ước tính xấu về thời gian cần thiết để làm một việc gì đó.

Cá nhân tôi nghĩ rằng mục đích của SCRUM là để đáp ứng các tổ chức cũ, nơi quản lý cấp trên không thể hoặc sẽ không nhận được đằng sau một quy trình tinh gọn hơn. Tôi đã làm việc như một kiến ​​trúc sư (Gà) trong khoảng một năm trong một bộ phận sử dụng nhiều SCRUM. Nền tảng trước đây của tôi là các công ty khởi nghiệp ở Thung lũng Silicon, hầu hết trong số đó sử dụng quy trình tập trung nhiều lần, đặc biệt và lặp đi lặp lại nhiều lần (đôi khi hàng tuần hoặc thậm chí hàng ngày). Tôi tìm thấy SCRUM, ít nhất là cách chúng tôi triển khai nó quá mức về mặt quy trình (và về mặt nào đó nặng hơn thác nước (ít nhất là từ góc độ nhà phát triển). sai lệch là chủ sở hữu sản phẩm của chúng tôi thực sự giống với các nhà phân tích yêu cầu trong tổ chức CNTT. Kết quả là họ có xu hướng làm mờ thông tin đến từ doanh nghiệp và tệ hơn là khiến doanh nghiệp không thể đếm được cho nhóm phát triển (đòi hỏi phải truyền liên tục các câu chuyện của người dùng). Tuy nhiên, trong khởi nghiệp tương lai của tôi, tôi sẽ không sử dụng SCRUM. Có lẽ tôi chỉ sử dụng nó trong trường hợp quản lý yêu cầu thêm chi phí.

Tôi sẽ không nói từ quan điểm của một người theo chủ nghĩa thuần túy. Tôi cảm thấy rằng bạn có thể thực hiện nó theo cách tương tự như những gì Scrum nói. Tuy nhiên, điểm chính là khả năng chạy chương trình của bạn. Điều gì sẽ xảy ra nếu bạn đang đi nghỉ trong một tháng?

Tôi thấy scrum là cơ chế để hợp lý hóa tất cả những gì bạn đã làm và đặt một số khía cạnh được xác định vào đó. Vì vậy, khi bạn vắng mặt, người khác cũng có thể sao chép nó và có thể sao chép nó sang các dự án khác. Tuy nhiên scrum không phải là viên đạn bạc. Tôi đã thấy nhiều người mới bắt đầu sử dụng Scrum (vì nó là thời trang) và bị đánh đập nặng nề vì họ không hiểu bản chất của nó.

PS: Scrum không bắt buộc chạy nước rút của bạn phải kéo dài hai tuần. Nó có thể là tháng dài (trường hợp của bạn).

Xin vui lòng xem ý kiến ​​của tôi cho câu hỏi đầu tiên.

SCRUM là một mô hình phát triển phần mềm nhanh nhẹn. Như vậy, nó nhanh nhẹn. Nó không cho rằng bạn phải theo mô hình cổ điển của nó. Và tôi nghi ngờ nếu có ai thực sự làm. Tôi đã từng làm việc trong một số tổ chức và mỗi nhóm điều chỉnh nó theo nhu cầu của họ. Không có gì lạ khi không có khách hàng / người tiêu dùng khi phát hành một số sản phẩm / thư viện / API công cộng. Tôi chưa bao giờ có một. Trong trường hợp của tôi, GM của chúng tôi hoạt động như một, mà IMO giống như không có.

Có 2 tuần nước rút là khó khăn. Rất khó khăn. 3 tuần là tốt hơn nhưng thực sự là dành cho người có kinh nghiệm và quen thuộc với nhóm quy trình. Chúng tôi đã có 4 tuần hoặc một tháng. Điều đó đã cho chúng tôi đủ thời gian để "giải quyết" để nói chuyện ngay từ đầu và tự tin hơn vào cuối do có nhiều thử nghiệm hơn. Tôi thích điều đó và tôi sẽ gắn bó ít nhất 3 tuần.

Đội khác mà tôi đang cộng tác, không có gì ngoài việc tồn đọng. Họ sẽ gặp nhau, báo cáo về tình trạng và những gì tiếp theo và đó là điều đó. Một khi mọi thứ đã xong, họ sẽ đưa ra một hồ sơ tồn đọng khác. Họ biết đó không phải là SCRUM nhưng nó hiệu quả với họ và đó là điều quan trọng.

Có nhẹ hơn không? Nó chắc chắn là như vậy. Nhưng nó không phải là SCRUM. Những gì tôi thích về SCRUM là nó thúc đẩy kỷ luật. Mọi người cảm thấy áp lực của việc cung cấp một cái gì đó hàng ngày. Mọi người đều biết những gì người khác làm và anh ta thất bại, mọi người sẽ biết điều đó. Ngay cả khi một người cố gắng che đậy điều đó (đọc lời nói dối), nó sẽ trở nên rõ ràng sớm hơn nhiều so với các quy trình khác. Vì vậy, khi bạn phân kỳ và đơn giản hóa như với nhóm đó, bạn phải chắc chắn rằng bạn làm điều đó với đúng người. Nếu không, nó có thể sụp đổ thực sự nhanh chóng xuống cấp đến các cuộc họp tình trạng vô nghĩa, nơi mọi người sẽ ở lại và nghĩ "tôi phải làm gì ở đây? Tôi biết tôi cần phải làm gì vậy?"

Đó là hai xu của tôi. Tôi thực hiện SCRUM của riêng mình như phát triển: lập kế hoạch công việc, phân chia thành các nhiệm vụ, ước tính chúng, quan sát tiến trình. Nó thực sự giúp tôi đứng đầu mọi thứ. Tôi đã áp dụng một số thứ từ SCRUM cho các dự án mà tôi thuê ngoài và nó rất hiệu quả đối với tôi.

Chỉ cần ... nhanh nhẹn ;-)

Tôi khuyên bạn nên bỏ qua scrum. Trong một vài năm, một mốt mới sẽ xuất hiện, và bạn sẽ bớt hoài nghi hơn và vẫn có thể ôm ấp nó hết lòng. Trong thực tế, bạn có thể nhanh chóng trở thành một chuyên gia. Sau đó, bạn có thể kiếm được nhiều tiền bằng cách viết một cuốn sách về nó và phát biểu tại các hội nghị.

Vì rất nhiều thứ có tính chu kỳ, rất có thể mốt mới này sẽ là một quá trình nặng nề tương tự như RUP. Những gì sẽ xảy ra mà bạn thấy là mọi người sẽ tuân theo các quy trình nhanh nhẹn trọng lượng nhẹ, và những điều này sẽ bị đổ lỗi cho những thất bại trong dự án của họ. Vì vậy, tất nhiên giải pháp hợp lý là cần có thêm kế hoạch và thiết kế phía trước!

Nghiêm túc mà nói, tôi không nghĩ bạn cần Scrum. Không có gì trong scrum tốt hơn các quy trình nhanh nhẹn cạnh tranh khác. Ngoài ra nó có rất nhiều tên ngu ngốc cho mọi thứ.

Điều đó thật tuyệt, nhưng tất cả dường như là lẽ thường với tôi. Tại sao điều này cần được mã hóa?

Scrum thường được so sánh với các phương pháp cũ hơn, nặng hơn. Các phương pháp đã cố gắng làm cho thác nước không có phản hồi hoạt động bằng cách thực thi nhiều tài liệu hơn, đăng xuất nhiều hơn và lên kế hoạch trước nhiều hơn. Bản tuyên ngôn Agile (mà bạn đang trích dẫn) là một sự đảo ngược của những ý tưởng đó.

Sau đó, tôi nói với phương pháp giúp chúng ta phản ứng với sự thay đổi. Những khía cạnh cụ thể nào của SCRUM đang cho phép tôi linh hoạt đến mức mà trước đây tôi không đạt được với các cuộc họp quảng cáo, thảo luận khối và các cuộc họp lập kế hoạch cho nhà phát triển?

Có vẻ như bạn có một cấu trúc nhanh nhẹn. Nếu bạn đã phản ứng với thay đổi tốt, thì rõ ràng bạn không cần giúp đỡ. Một số quy trình trở nên quá phức tạp với quy trình sửa lỗi đòi hỏi phải có giai đoạn phân tích đầy đủ và thiết kế chức năng và không thể sớm tham gia dự án cho đến năm sau.

Họ giải thích sự cần thiết phải có một công việc có thể giao hàng hai tuần một lần, hoặc chạy nước rút. Trong dự án cụ thể của tôi, không có "khách hàng", phần mềm sẽ không được hoàn thành trong một năm hoặc hơn và trong khi đó, tôi có thể sẽ chỉ giới thiệu cho quản lý cấp trên mỗi tháng hoặc ít hơn. Vậy tại sao nhu cầu rõ ràng về việc giao hàng mỗi tuần?

Scrum gốc quy định nước rút kéo dài một tháng. Có một xu hướng khó chịu đối với Agile machismo trong việc rút ngắn nước rút. ("Vâng, chạy nước rút của chúng tôi chỉ một ngày ...") Khách hàng / Khách hàng là bất cứ ai có thẩm quyền để nói rằng dự án là tốt để đi, hoặc cần nhiều công việc hơn. Nếu bạn đang giới thiệu với quản lý cấp trên mỗi tháng, họ có thể là khách hàng của bạn và có lẽ bạn đã rất thân với Scrum.

Dựa trên mô tả của bạn về những gì nhóm của bạn đang làm, Scrum có lẽ không khác nhiều. Bạn có thể nhận được một số giá trị từ việc tiêu chuẩn hóa, bởi vì sẽ dễ giải thích hơn cho người ngoài về những gì đang xảy ra nếu bạn sử dụng các thuật ngữ Scrum. Ngoài ra, Scrum có thể được sử dụng một lá chắn; ví dụ, Scrum quy định rằng các quyết định kỹ thuật nên được đưa ra bởi nhóm - chỉ ra nguyên tắc này có thể là một cách tốt để có được giá trị kỹ thuật khó bán (ví dụ như lập trình cặp.)

Scrum về cơ bản là một giao diện mà nhóm của bạn có thể thực hiện. Nếu bạn làm như vậy, thì bạn có một ý tưởng tốt về cách giao tiếp với những người bên ngoài nhóm, và họ có một ý tưởng tốt về cách giao tiếp với bạn. Chỉ bạn có thể biết nếu nhóm của bạn cần điều này.

Chúng tôi không sử dụng Scrum tại nơi làm việc. Chúng tôi sử dụng một phương pháp được thành lập ở Agile và Lean tương tự nhau ở nhiều khía cạnh. Tôi đã sử dụng quy trình này trong các nhóm khác nhau về quy mô giữa 3-5 người bao gồm cả người dẫn đầu. Mặc dù có những khác biệt nhưng tôi nghĩ bạn có thể giúp bạn tìm ra liệu Scrum có hữu ích cho tình huống của bạn không.

Làm cho phương pháp giải thích

Chúng tôi làm cho quy trình của chúng tôi rõ ràng bởi vì chúng tôi xem xét quy trình của chúng tôi với mỗi lần chạy nước rút / xem xét. Một phần của kết thúc / đánh giá là xác định các hoạt động không phù hợp với chúng tôi. Chúng tôi cũng thảo luận về các hoạt động mà chúng tôi nghĩ sẽ làm việc cho chúng tôi và nếu có đủ thỏa thuận, chúng tôi sẽ thử. Chúng tôi sẽ không thể làm điều này nếu không mã hóa phương pháp của chúng tôi.

Đăng xuất

Đây là đặc điểm cho quá trình của chúng tôi. Điều này đảm bảo những gì chúng tôi viết là những gì cần thiết. Khi chúng tôi nhận được một tính năng cụ thể, chúng tôi đi đến khách hàng của chúng tôi. Khách hàng là bất cứ ai sẽ sử dụng những gì bạn viết. Trong một số trường hợp, bạn phải ủy quyền khách hàng với người đại diện cho khách hàng (như quản lý sản phẩm). Đây là các bước của chúng tôi và cho đến khi bước cuối cùng hoàn thành, tính năng không được thực hiện.

• Nhận tính năng từ bảng, theo dõi, vv
• Nói chuyện với khách hàng và hiểu những gì họ đang tìm kiếm trước khi viết bất cứ điều gì.
• Thực hiện các tính năng.
• Hiển thị cho khách hàng tính năng làm việc ở dạng cuối cùng để khách hàng đăng xuất khi tính năng được hoàn tất.

Lát dọc

Chúng tôi làm tất cả sự phát triển của chúng tôi trong các lát dọc. Điều này hỗ trợ khả năng đăng xuất với tính năng đã hoàn thành cũng như những lý do khác.

• Khấu hao các vấn đề tích hợp bằng cách đưa chúng vào với từng tính năng. Giúp loại bỏ thời gian khủng hoảng khi kết thúc dự án.
• Cho phép chúng tôi cắt bỏ các tính năng một cách dễ dàng vì chúng tôi loại bỏ rất nhiều phụ thuộc chéo.
• Cho phép chúng tôi cắt đứt sự phát triển nếu chúng tôi cần thay đổi hướng.
• Chúng tôi có thể phát hành lặp đi lặp lại , cung cấp cho khách hàng chức năng sớm.

Chấp nhận TDD

Chúng tôi tận dụng các khung kiểm tra đơn vị cho tdd chấp nhận. Điều này mang lại cho chúng ta nhiều lợi ích.

• Tái cấu trúc lớn không tốn nhiều thời gian làm lại bài kiểm tra.
• Chúng tôi đảm bảo chức năng của khách hàng.
• Chúng tôi bao gồm tích hợp mã.
• Hỗ trợ thực hành phát triển Slice dọc.

Bản dựng luôn luôn đáng tin cậy

Sau mỗi lần đẩy, mã sẽ được giải phóng. Ngay cả khi tính năng không đầy đủ, không có gì nên bị phá vỡ. Tất cả các bài kiểm tra nên chạy, và tất cả các chức năng trước đó nên có mặt. Đây thực sự là một phần mở rộng của sự phát triển lát dọc của chúng tôi. Vì vậy, nó chia sẻ nhiều lợi ích tương tự.

• Cho phép chúng tôi cắt bỏ các tính năng một cách dễ dàng vì chúng tôi loại bỏ rất nhiều phụ thuộc chéo.
• Cho phép chúng tôi cắt đứt sự phát triển nếu chúng tôi cần thay đổi hướng.
• Chúng tôi có thể phát hành lặp đi lặp lại , cung cấp cho khách hàng chức năng sớm.

Hội nhập liên tục

Mỗi lần đẩy tạo ra một bản dựng thông qua máy chủ xây dựng CI của chúng tôi. Máy chủ xây dựng kiểm tra mã, chạy qua toàn bộ bộ kiểm tra, gắn thẻ mã và đóng gói để triển khai. Củng cố chính sách của chúng tôi rằng việc xây dựng luôn luôn có thể giải phóng được.

Ước tính điểm cho thẻ

Mọi lỗi, tính năng và tác vụ đều trở thành "thẻ". Thẻ là đơn vị công việc logic nhỏ nhất có một số lợi ích của khách hàng. Chúng tôi chỉ ra những điều này theo quy mô của chúng tôi. Bất kỳ vượt quá giá trị điểm tối đa của chúng tôi hoặc chia nhỏ hơn nữa. Chúng tôi đã tìm thấy giá trị điểm càng lớn, càng có nhiều độ lệch trong thời gian hoàn thành, do đó phá vỡ các thẻ lớn hơn nữa. Nếu thẻ có đủ sự mơ hồ, thẻ sẽ được làm tròn đến giá trị điểm tiếp theo trong thang đo. Mỗi thẻ phải được ký tắt trước khi có thể được coi là hoàn thành. Ước tính đúng hỗ trợ khả năng của chúng tôi để tính toán Vận tốc.

Vận tốc

Chúng tôi có nước rút dài tuần. Mỗi thứ sáu, chúng tôi lên kế hoạch làm việc và ưu tiên công việc cho tuần tới. Dựa trên vận tốc của chúng tôi, chúng tôi có một ý tưởng tốt về số lượng "công việc" chúng tôi có thể hoàn thành trong tuần. Vận tốc của chúng tôi là giá trị trung bình và trung bình của tổng số điểm hoàn thành trong tuần. Sự gia tăng độ lệch chuẩn được phân tích cho các ước tính xấu (luôn cố gắng cải thiện) hoặc tăng sự gián đoạn (mà tôi nói chuyện với người quản lý). Vận tốc cũng có thể được sử dụng để ước tính ngày hoàn thành chính xác cho một dự án, nhưng chỉ khi đó là dự án duy nhất đang được thực hiện.

Thiết kế và cải tiến tăng dần

Chúng tôi cũng có chính sách để lại mã ở trạng thái tốt hơn một chút so với cách bạn tìm thấy mã. Tái cấu trúc / thiết kế lại mã ở đầu thẻ. Mục tiêu là để tính đến sự tăng trưởng hữu cơ có thể phổ biến với sự phát triển gia tăng. Chúng tôi cũng tái cấu trúc vào cuối mỗi bình thường.

Đối với hầu hết các phần này là các quy tắc chúng tôi tuân theo và tại sao chúng tôi tuân theo chúng.

Nghe có vẻ như bạn đang ở trong một đội ngũ rất giàu kinh nghiệm, hoạt động tốt. Xin chúc mừng, Scrum / Agile về cơ bản là chính thức hóa những gì nhóm của bạn đã trực giác trong thời gian này.

Tôi nghĩ những gì có thể có lợi cho công ty (toàn bộ) của bạn là chấp nhận Scrum như một "điểm chung", không phải giữa các thành viên trong nhóm phát triển của bạn, mà là giữa nhóm phát triển của bạn và bộ phận kinh doanh nói chung .

Trong khi Scrum Sprints được tính thời gian, các nhóm có thể chọn giữa các đề xuất từ ​​hai tuần đến 1 tháng. Bất kỳ ít hơn và sẽ có quá nhiều Đánh giá và Hồi tưởng, và bất kỳ điều gì nữa có thể cản trở khả năng thay đổi hướng của doanh nghiệp trong vòng một năm. Có vẻ như bạn đã tìm thấy điểm ngọt ngào của bạn trong 1 tháng, vì vậy hãy cố gắng vì điều đó.

Có rất nhiều thời gian để bạn điều chỉnh các thông số Scrum và tôi chắc chắn rằng bạn có thể giải thích cho doanh nghiệp của mình rằng bạn vẫn đang thực hiện Scrum đúng cách. Một nhược điểm là nếu bạn gặp nửa chừng kinh doanh, sự tham gia của họ có thể mang lại sự hỗ trợ tích cực.