Cách sử dụng Scrum với năng suất cao hơn và ít đau đớn hơn

Đối phó với Phát triển phần mềm không phải là điều dễ dàng và rõ ràng nhất. Nó bao gồm vô số vấn đề, kỹ thuật và phi kỹ thuật. Khía cạnh kỹ thuật chắc chắn phức tạp hơn nhiều và cần những kỹ năng cứng, nhưng đồng thời có thể được quản lý theo một cách nào đó bằng cách sử dụng các chiến thuật và công cụ phù hợp. Mặt khác, thế giới phi kỹ thuật có nhiều mức độ tự do hơn. Nó có tính hay thay đổi và không thể đoán trước giống như bản chất con người.

Như với bất kỳ quy trình sản xuất sản phẩm nào khác, một số phương pháp hay nhất đã được áp dụng và thử nghiệm từ những năm đầu của cuộc phiêu lưu phát triển phần mềm. Các phương pháp nhanh nhẹn là một tập hợp các cách khác nhau để đối phó chủ yếu với sự thay đổi lớn của các yêu cầu và cũng như sự thiếu tập trung vào các mục tiêu quan trọng nhất để cung cấp sản phẩm cuối cùng.

Đôi khi những phương pháp như vậy vượt ra ngoài mục đích ban đầu của chúng và kết quả cuối cùng không hề lý tưởng. Scrum là một trong những phương pháp này. Nó được mô tả nhiều hơn như là một khuôn khổ. Nó dựa trên một bộ nguyên tắc, quy tắc, sự kiện và vai trò cơ bản. Chúng tôi thảo luận trong bài viết này về cách sử dụng khuôn khổ này một cách thận trọng và linh hoạt, đồng thời tránh một số diễn giải nghiêm ngặt có thể không lý tưởng.

Giới thiệu rất ngắn gọn về Scrum

Các phương pháp Agile dựa trên các nguyên tắc chung sau đây, được định nghĩa trong cái gọi là "Tuyên ngôn Agile":

• "Cá nhân và tương tác hơn là 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"
• "Sự hợp tác của khách hàng hơn là đàm phán hợp đồng"
• "Đáp ứng với sự thay đổi bằng cách tuân theo một kế hoạch"

(Nguồn: Tuyên ngôn Agile )

Theo Tuyên ngôn Agile, trong các tuyên bố trên, trong khi các mục bên phải là quan trọng, thì các mục bên trái quan trọng hơn.

Từ quan điểm của quy trình phát triển, tất cả các phương pháp nhanh đều ngụ ý một quy trình lặp đi lặp lại và tăng dần thay vì mô hình Thác nước cổ điển: toàn bộ quá trình phát triển được tạo thành từ một số bước tăng dần và mỗi bước được tạo thành từ các giai đoạn giống nhau đặc trưng cho toàn bộ dự án thác nước: tập hợp các yêu cầu, phân tích, thiết kế và viết mã. Điều đó có nghĩa là, mỗi bước đại diện cho một bước tiến trong toàn bộ quá trình phát triển và bản thân nó có thể được coi là toàn bộ dự án.

Phương pháp Scrum có thể được coi là một sự suy giảm cụ thể của các nguyên tắc trên. Scrum là một khuôn khổ trong đó một nhóm có thể sử dụng các quy trình của riêng mình để phát triển một số sản phẩm phần mềm cụ thể. Về cơ bản, nó được đặc trưng bởi Vai trò , Sự kiện và Cổ vật .

Các vai trò là:

• Nhóm : nó có thể bao gồm các nhà phân tích, nhà phát triển, người thử nghiệm và nói chung là mọi loại chuyên gia tham gia vào dự án. Nó được cho là hoạt động theo cách tự tổ chức trong ranh giới của các phiên lập kế hoạch Scrum.

• Scrum Master : anh ấy/cô ấy điều phối tất cả các quy trình Scrum, tổ chức các cuộc họp, v.v.

• Chủ sở hữu sản phẩm : anh ấy / cô ấy chịu trách nhiệm về sản phẩm. Anh ấy/cô ấy quản lý cái gọi là Product Backlog , chứa tất cả các tính năng cần thiết được thể hiện một cách rõ ràng. Anh ấy/cô ấy có thể thảo luận về chúng với nhóm và nhận được sự giúp đỡ từ nhóm, nhưng anh ấy/cô ấy là người chịu trách nhiệm duy nhất.

  
  

Sự kiện là:

• Sprint : đại diện cho một bước gia tăng duy nhất trong quá trình phát triển lặp đi lặp lại. Nó thường kéo dài từ hai tuần đến một tháng.

• Lập kế hoạch Sprint : đó là cuộc họp có thời lượng tối đa là 4 giờ đối với Sprint hai tuần và tối đa tám giờ đối với Sprint một tháng. Nó được tổ chức và lên lịch bởi Scrum Master và bao gồm Nhóm và Chủ sở hữu sản phẩm. Trong cuộc họp này, một số tính năng của Product Backlog được chọn, đánh giá và thảo luận để phát triển trong Sprint hiện tại. Các tính năng được chọn dựa trên mức độ ưu tiên của chúng.

• Cuộc họp Scrum hàng ngày : đây là những cuộc họp hàng ngày không quá mười lăm phút. Chúng được lên lịch bởi Scrum Master. Trong các cuộc họp này, mỗi thành viên trong nhóm mô tả những gì họ đã làm để thực hiện các nhiệm vụ hiện tại, bất kỳ vấn đề nào xảy ra và cách khắc phục những khó khăn có thể xảy ra. Scrum master đảm nhiệm việc lên lịch và điều phối các cuộc họp này cũng như việc thực hiện chính xác chúng.

• Sơ kết Sprint : đó là một cuộc họp vào cuối mùa xuân hiện tại. Mất hai giờ cho Sprint hai tuần và bốn giờ cho Sprint một tháng. Nó được tổ chức bởi Scrum Master và những người tham gia là nhóm Scrum, Scrum Master, Product Owner và tất cả các bên liên quan bắt buộc theo quyết định của Product Owner. Sự gia tăng hiện tại được thảo luận. Điều gì diễn ra tốt đẹp và điều gì sai sót đều được vạch ra và cuối cùng, Product Backlog được cập nhật nếu cần.

• Cải tiến Sprint : đó là cuộc họp kéo dài một giờ đối với Sprint hai tuần và hai giờ đối với Sprint một tháng. Nó diễn ra ngay sau buổi sơ kết Sprint và trước buổi lập kế hoạch Sprint tiếp theo. Trong cuộc họp này, dựa trên kinh nghiệm của lần lặp lại trước, tất cả các hành động để cải thiện và nâng cao chất lượng cho sản phẩm cuối cùng sẽ được thảo luận và lên kế hoạch cho Sprint tiếp theo.

  
  

Hiện vật là:

• Product Backlog : đó là một tài liệu phát triển có chứa tất cả các yêu cầu của sản phẩm. Mỗi mục được gọi là Câu chuyện của người dùng và có các thuộc tính như mô tả, thứ tự, ước tính và giá trị. Các mục có thứ tự cao hơn rõ ràng và chi tiết hơn.
• Sprint Backlog : nó chứa các hạng mục Product Backlog được chọn cho Sprint tiếp theo kết hợp với việc lập kế hoạch cần thiết.
• User Story : như chúng tôi đã nói ở trên, User Story là một mục của Product Backlog. Câu chuyện của người dùng tuân theo một cấu trúc văn bản phổ biến: " Với tư cách là <người dùng loại os>, tôi muốn <thực hiện một số nhiệm vụ>, để <Tôi có thể đạt được một số mục tiêu>. Câu chuyện đó cũng phải có một số Tiêu chí chấp nhận, mỗi tiêu chí có giản đồ sau: Đưa ra <một số điều kiện>, Khi <người dùng thực hiện một số nhiệm vụ> Sau đó <một số thay đổi trạng thái hệ thống xảy ra>.
• Biểu đồ Burn-Down : đó là một biểu đồ trong đó trục hoành biểu thị thời gian và trục tung là lượng công việc còn lại phải hoàn thành cho từng bước trong thời gian. Lượng công việc có thể được đo lường bằng cái gọi là Điểm câu chuyện . Story Point là một đơn vị đo lường công việc có tính đến tất cả các biến có thể ảnh hưởng đến công việc phát triển, chẳng hạn như kỹ năng, độ phức tạp, công cụ, v.v.
• Số gia tăng : đó là tổng số gia tăng cho đến nay, tức là tổng của các hạng mục Product Backlog đã hoàn thành cho đến nay cộng với tất cả các hạng mục khác đã được hoàn thành trong các lần lặp lại trước đây.

Đừng nhầm lẫn Scrum với một số dạng học thuyết

Bạn có thể coi các mục được liệt kê ở trên là cơ sở để một nhóm chuyên gia có thể hoạt động. Chúng có thể được xem như một công cụ hữu ích nhưng điều thực sự mang lại sự gắn kết, giao tiếp và hiệu quả trong một dự án lại chính là con người. Thực tế là, ngay cả với tất cả các quy định được tuân thủ nghiêm ngặt và tất cả các cam kết của Scrum Master, một dự án có thể rơi vào tình trạng hỗn loạn và thất bại thảm hại.

Điều này là do mọi người thường nhầm lẫn giữa các quy tắc, phương pháp và khuôn khổ với một loại động cơ thần thánh nào đó được cho là sẽ đưa con người đến con đường đúng đắn. Đó là một lỗ hổng tâm lý phổ biến. Một cân nhắc rất quan trọng là thực tế khác với lý thuyết, và nó là một động vật rất phức tạp và hoang dã. Nếu bạn nghĩ rằng bạn có thể chế ngự nó bằng một danh sách các quy tắc và khuôn mẫu thì bạn sẽ thất bại.

Mục đích thực sự của Scrum là giảm thiểu lượng "tiếng ồn xung quanh" trong quá trình phát triển và cải thiện sự tập trung vào những điều quan trọng nhất. Nếu được sử dụng với sự linh hoạt và khiêm tốn phù hợp, nó có thể mang lại hiệu quả trong việc này.

Trong phần sau, tôi mô tả một trường hợp sử dụng thực tế, trong đó tôi đã thực hiện một cuộc hành trình vào thế giới của Scrum. Đó là hành trình của những người chưa có kinh nghiệm, bao gồm cả tôi, lần đầu tiên sẵn sàng chấp nhận các nguyên tắc linh hoạt một cách nhất quán. Nhiều dự án mà tôi đã làm việc trước đây được thực hiện theo cách lặp đi lặp lại nhưng không có toàn bộ nghi lễ của một khuôn khổ nhanh nhẹn thực sự.

Trường hợp sử dụng thực tế

Ở đây chúng ta nói về một trường hợp sử dụng thực tế, trong đó việc áp dụng khuôn khổ Scrum còn lâu mới được thực hiện. Dự án là về một hệ thống phần mềm nhằm theo dõi tất cả các hoạt động liên quan đến phòng thí nghiệm bệnh lý giải phẫu, từ việc thu thập các mẫu mô và xử lý chúng theo các bước khác nhau cho đến khi phân phối các phiến mô cuối cùng. Hệ thống này cũng được cho là sẽ được tích hợp trong các giai đoạn cụ thể với máy móc tự động hóa bên ngoài, bởi các trình điều khiển phần mềm cụ thể.

Tôi đã tham gia vào dự án này với tư cách là một kiến trúc sư phần mềm. Tôi đã phải hợp tác với người quản lý dự án để vạch ra những vấn đề chính và đưa ra một bản thiết kế kiến trúc cơ bản. Nếu bạn tuân theo các nguyên tắc Agile đến mức cực đoan, thì việc nghĩ đến kiến trúc trước đó không phải là điều tốt nhất. Ngay cả thiết kế kiến trúc cũng được nhìn thấy trong một kịch bản lặp đi lặp lại. Tuy nhiên, trong hầu hết các trường hợp, bạn vẫn cần một cơ sở để bắt đầu và bạn phải thảo luận về điều đó với tất cả các bên liên quan.

Tôi đã tiếp cận nghiên cứu kiến trúc sơ bộ này để cố gắng phân tách rõ ràng các bối cảnh, theo cách tiếp cận có cấu trúc dựa trên quan điểm , góc nhìn và quan điểm . Việc tuân theo cách tiếp cận như vậy là rất quan trọng để có sự phân tách rõ ràng các vấn đề và cũng để tùy chỉnh cuộc thảo luận dựa trên loại bên liên quan cụ thể.

Một phần của kiến trúc được thảo luận thực sự là giai đoạn phát triển và tổ chức của nó. Bản thân công ty vẫn chưa áp dụng bất kỳ phương pháp nhanh nhẹn nào. Tuy nhiên, theo thỏa thuận với người quản lý và những người khác có liên quan, chúng tôi muốn lấp đầy khoảng trống này và chúng tôi đã chọn lấy cảm hứng từ khung phương pháp Scrum.

Chúng tôi hoàn toàn không được đào tạo về Scrum, nhưng tất cả chúng tôi đều có ý thức về những điều cơ bản của nó. Các chỉ thị chính mà chúng tôi đã nghĩ đến cho dự án, cả về phương pháp và kỹ thuật, là:

• Một tập hợp các thực hành cơ bản để tuân theo, để tập trung vào mục tiêu một phần và tổng thể theo cách tiếp cận lặp đi lặp lại (Scrum trong quyết định cuối cùng của chúng tôi).
• Theo dõi hoạt động/nguồn bằng các công cụ tự động hóa.
• Phương pháp phát triển hướng hành vi kết hợp với thử nghiệm đơn vị và tích hợp .

Thực hành Scrum

Được thúc đẩy bởi nhu cầu thực thi một số khung phương pháp vững chắc nhưng lại bị ép buộc bởi việc thiếu các kỹ năng chuyên sâu, chúng tôi đã chọn áp dụng một số quy tắc chính của Scrum mà không đi quá xa. Trước hết, một cách tiếp cận lặp đi lặp lại thực sự quan trọng trong suy nghĩ của chúng tôi. Scrum đề cập đến điều này thông qua cái gọi là Sprint, mà chúng ta có thể coi là các đơn vị công việc lặp đi lặp lại. Mỗi Sprint được cho là bao gồm một số tính năng đã chọn từ hồ sơ tồn đọng và có một khoảng thời gian cụ thể.

Chúng tôi đã chọn hai tuần cho khoảng thời gian chạy nước rút của mình. Trước khi bắt đầu giao dịch thực sự, chúng tôi thiết lập Sprint số 0 thông thường trong một tuần để thực hiện các nhiệm vụ tổ chức và công việc sơ bộ. Trong Sprint sơ bộ này, chúng tôi cũng đã viết phiên bản đầu tiên của hồ sơ tồn đọng, với tất cả các tính năng được liệt kê theo mức độ ưu tiên. Chúng tôi không áp dụng một phương pháp cụ thể nào để đánh giá nỗ lực thực hiện nhiệm vụ, chỉ là một cuộc thảo luận bình thường giữa các thành viên trong nhóm.

Khi bắt đầu mỗi Sprint , đối với các quy tắc Scrum, chúng tôi sẽ thảo luận về công việc đã hoàn thành, đánh giá tất cả các vấn đề gặp phải và chọn các tính năng sẽ được triển khai trong Sprint tới.

Người quản lý dự án đóng vai trò là Chủ sở hữu sản phẩm, được hỗ trợ bởi một chuyên gia tên miền. Điều này có ý nghĩa trong tình huống cụ thể vì không có người quản lý sản phẩm thực sự tham gia và bản thân người quản lý dự án có tất cả kiến thức về các yêu cầu của khách hàng. Đối với Scrum Master, tôi đã làm điều đó một thời gian và sau đó chuyển giao vai trò đó cho một đồng nghiệp khác, ngay cả khi cả hai chúng tôi đều không được đào tạo đầy đủ về nó.

Nhóm của chúng tôi là một nhóm không đồng nhất với những người làm việc từ các thành phố khác nhau. Sau đó, chúng tôi buộc phải tổ chức một phiên bản ảo của các cuộc họp độc lập bằng cách lên lịch các cuộc gọi Skype hàng ngày vào cùng một giờ. Các cuộc họp kéo dài khoảng 15 phút. Một số thành viên trong nhóm có một số hình thức phản kháng coi điều này, có thể vì họ hiểu đó là một hình thức kiểm soát, điều này không phải vậy.

Chúng tôi đã dành thời gian để họ nhận thức được ý nghĩa thực sự của các cuộc họp hàng ngày: một cuộc thảo luận ngắn giữa các thành viên trong nhóm để tập trung vào các vấn đề chính, tăng cường giao tiếp và tìm cách cải thiện cũng như làm cho công việc trở nên dễ dàng hơn cho tất cả mọi người. Trong một thời gian, họ cứ nói rằng đó là một sự lãng phí thời gian và là nguồn gây xao nhãng công việc thực sự nhưng cuối cùng, chúng tôi đã thuyết phục được họ.

Theo dõi hoạt động/nguồn bằng công cụ tự động hóa

Bên cạnh các phương pháp thực hành, chúng tôi cũng cần các công cụ để giải quyết những mối quan tâm chính sau:

• Phiên bản mã, theo dõi các thay đổi của nó và chia sẻ chúng trong nhóm.

• Theo dõi các hoạt động và giải quyết lỗi: phải làm gì, ai được chỉ định làm gì và trạng thái của nó.

• Khớp các thay đổi mã nguồn với các hoạt động.

  
  

Luồng thông tin trong một dự án quá phức tạp để chỉ dựa vào các phương pháp thực hành để kiểm soát nó. Bạn cần một nền tảng vững chắc của các công cụ để làm cho công việc dễ dàng hơn. Càng tự động hóa nhiều nhiệm vụ, bạn càng có thể tập trung vào những việc quan trọng và tạo ra sản phẩm tốt hơn.

Đối với phiên bản mã, chúng tôi đã sử dụng Git vì đây là lựa chọn tự nhiên nhất. Git có thể được sử dụng theo nhiều cách khác nhau và cá nhân chúng tôi đã sử dụng Gitflow làm mẫu quy trình làm việc.

Để theo dõi các hoạt động, chúng tôi đã sử dụng Redmine , một nền tảng chung nhằm mục đích quản lý dự án.

Để giải quyết mối lo ngại thứ ba, chúng tôi đã tích hợp kho lưu trữ Git của mình với Redmine theo cách mà các cam kết Git có thể liên quan đến các vé Redmine cụ thể bằng cách sử dụng mã nhận dạng vấn đề trong nhận xét cam kết. Bằng cách này, chúng tôi đã có một ánh xạ đầy đủ giữa các hoạt động và các đơn vị công việc Git.

Phương pháp phát triển hướng hành vi kết hợp với thử nghiệm đơn vị và tích hợp

Chúng tôi rất sẵn lòng xây dựng quy trình phát triển của mình dựa trên phương pháp Tiếp cận theo định hướng hành vi. BDD rất phù hợp với Scrum và nói chung với các nguyên tắc Agile, đặc biệt là trong phần liên quan đến giao tiếp. Nó cho phép viết các kịch bản thử nghiệm ở định dạng mà những người không có kỹ thuật có thể hiểu được và với các công cụ phù hợp sẽ đưa ra một báo cáo trực quan về trạng thái hiện tại. Nó vạch ra các ranh giới hợp lý của sản phẩm và buộc công việc phát triển nằm trong các ranh giới đó.

Các bài kiểm tra chức năng BDD chỉ là lớp bên ngoài của toàn bộ thiết bị kiểm tra. Chúng tôi cũng đã sử dụng các bài kiểm tra đơn vị và tích hợp. Để không bị choáng ngợp bởi sự phức tạp của một môi trường phát triển như vậy, chúng tôi phải sử dụng các công cụ và tính năng tự động hóa phù hợp.

Các công nghệ chính liên quan là:

• Cucumber : được tích hợp vào ứng dụng Spring Boot với các dịch vụ REST

• Các công cụ kiểm tra khác: Thư viện JUnit , Mockito và Spring Boot để hỗ trợ kiểm tra tích hợp.

  
  

Bản đồ tinh thần sau đây cho thấy một bản tóm tắt về những điều được thảo luận ở trên:

cân nhắc

Liệu việc áp dụng Scrum, ngay cả khi theo một cách nhẹ nhàng và linh hoạt, có đáng không? Câu trả lời là có. Tuy nhiên, hãy nói rõ rằng, chúng ta không thể coi nó là giải pháp cho mọi vấn đề và nếu áp dụng mà không hiểu chính tinh thần của nó thì thậm chí có thể gây bất lợi. Bản chất của một phương pháp là đưa ra một sơ đồ tư duy tập thể để khiến mọi người làm việc cùng nhau với sự chia sẻ thông tin và cam kết tối đa, nhưng nếu mọi người tập trung vào việc tuân theo các quy tắc của một buổi lễ kỳ lạ thay vì công việc thực tế, thì mục đích ban đầu sẽ biến mất.

Tương tự thể thao

Bạn có thể hiểu rõ hơn những gì đã nói ở trên bằng phép loại suy trong thể thao. Không phải tất cả mọi người đều thích bóng đá, nhưng hầu hết mọi người đều có ít nhất một ý tưởng tối thiểu về cách thức hoạt động của nó. Trước hết, là trò chơi tập thể. Hai đội đối đầu với nhau trên sân thi đấu để cố gắng đưa bóng vào trong khung thành. Để thực hiện nhiệm vụ có vẻ đơn giản này, họ phải kết hợp các sáng kiến cá nhân với các chiến lược và chiến thuật tập thể. Những chiến lược và chiến thuật đó được huấn luyện viên dạy trước và chiếm một tỷ lệ lớn trong toàn bộ thời gian dành cho các buổi tập luyện.

Để thực sự hiệu quả, các quy tắc tập thể được mô tả ở trên mà các cầu thủ bóng đá tuân theo phải được thực hiện mà không cần nỗ lực và thậm chí không cần nghĩ rằng chúng tồn tại. Chúng phải tự động, chẳng hạn như các cử chỉ để lái xe ô tô. Yêu cầu cơ bản để đạt được mục tiêu này là chúng phải đủ đơn giản để được tất cả người chơi tiếp thu hoàn toàn trong khoảng thời gian giới hạn cần thiết để chuẩn bị cho chức vô địch.

Nếu bạn tập trung vào việc tuân theo nghi thức Scrum thay vì công việc thực tế thì cuối cùng bạn sẽ mang đến sự hỗn loạn thay vì trật tự. Mặt khác, nếu bạn theo một cách tiếp cận thực dụng hơn, linh hoạt và thậm chí loại bỏ tất cả những thứ mà theo kinh nghiệm cụ thể của chúng tôi không hiệu quả, thì bạn có thể tận dụng nó một cách tốt nhất. Bạn thậm chí có thể nghĩ đến việc trì hoãn một số cách tiếp cận Scrum nếu bạn thấy chúng khó theo dõi và sau đó cố gắng giới thiệu chúng trong giai đoạn sau.

Quản lý các nhà quản lý

Hãy nhấn mạnh một khái niệm: các phương pháp nhanh nhẹn và đặc biệt là Scrum, chỉ có thể hoạt động nếu mọi người trong nhóm sẵn sàng chấp nhận nó hoặc ít nhất là nhận thức được những lợi thế của nó. Nó không thể hoạt động nếu nó chỉ được giới thiệu bởi các nhà quản lý trong một công ty để chạy theo sự ồn ào chung chung và nói với thế giới bên ngoài: "Thấy chưa? Chúng tôi rất nhanh nhẹn!". Hãy làm rõ: nếu mục đích chỉ là tiếp thị thì tốt hơn hết là giả vờ làm theo các phương pháp đó. Không cần phải giới thiệu trong các quy trình nội bộ một gánh nặng chỉ có mục đích quảng cáo.

Đạo đức của câu chuyện: các phương pháp nhanh nhẹn chỉ có thể có một số tác động tích cực nếu được các kỹ sư cùng với các nhà quản lý áp dụng chứ không chỉ do các nhà quản lý áp đặt. Hầu hết các nhà quản lý, đặc biệt là những người không có nền tảng kỹ thuật, không biết gì về cách một phương pháp luận có thể tác động đến vòng đời của một dự án phần mềm, trong khi các kỹ sư thì có, đặc biệt là các kỹ sư cấp cao. Nhiều năm kinh nghiệm tốt hơn những cuốn sách hay nhất và những khóa học tốt nhất.

Hơn nữa, dựa trên kinh nghiệm kỳ lạ của tôi tại các công ty Ý, các tổ chức thường bị chi phối bởi một nền văn hóa dường như đến từ một số loại di sản thời trung cổ. Trong bối cảnh này, Scrum Master và thậm chí cả vai trò Chủ sở hữu sản phẩm có thể được coi đơn giản là một nguồn quyền lực trong con đường sự nghiệp, hơn là các vai trò điều hành.

Tôi đã thử nghiệm với thực tế khắc nghiệt này gần đây, để nói sự thật. Thông thường những người này không có chút ý tưởng nào về nguyên tắc của một phương pháp luận là gì, và tiếp tục quấy rối mọi người bằng những quy tắc mà họ thậm chí còn không hiểu.

Trong những môi trường khủng khiếp này, Extreme Programming và Scrum chỉ là những danh hiệu vô nghĩa. Trong những bối cảnh này, các nhà quản lý là nguồn entropy cần được giải quyết và để đạt được mức năng suất tốt, nhóm phải quản lý công việc của chính mình và thậm chí cả các nhà quản lý để giảm ảnh hưởng xấu của họ. Điều đó giải thích tiêu đề của phần này: "Quản lý các nhà quản lý".

Cân bằng giữa phương pháp luận, thực hành kiểm tra, hoạt động theo dõi và các công cụ liên quan

Trong trường hợp sử dụng được mô tả trong bài viết này, chúng tôi đã nói về phương pháp cũng như về các chiến lược thử nghiệm, hoạt động theo dõi và các công cụ được sử dụng để hỗ trợ chúng. Các khung phương pháp tốt nhất không thể tự giải quyết tất cả các vấn đề phức tạp liên quan đến phát triển phần mềm.

Trên thực tế, BDD, bao gồm kiểm tra chức năng, là một cách rất hiệu quả để chia sẻ kiến thức về logic của hệ thống phần mềm đang được phát triển. Nó xây dựng mối liên kết chặt chẽ giữa tất cả các thành viên trong nhóm và Chủ sở hữu sản phẩm, đồng thời cải thiện sự tập trung vào các khía cạnh quan trọng hơn của dự án. Vì vậy, nó bao gồm một phần các vấn đề mà Scrum phải giải quyết.

Mặt khác, kiểm thử đơn vị và kiểm thử tích hợp tham gia nhiều hơn vào các quy trình bên trong của nhà phát triển phần mềm, nhưng gián tiếp, chúng giúp xử lý các thay đổi dễ dàng hơn, kết hợp tốt với phương pháp lặp lại của Scrum.

Phần kết luận

Phát triển phần mềm là một vấn đề phức tạp ngay cả trong các dự án tối thiểu được xử lý bởi một nhà phát triển duy nhất. Nếu một dự án cần một nhóm được phát triển, một số vấn đề về tổ chức sẽ phát sinh. Các phương pháp nhanh nhẹn là một nỗ lực để giải quyết những vấn đề đó nhưng chúng sẽ chỉ thực sự hữu ích nếu được coi là muối bỏ bể và bằng cách tránh mọi hình thức phóng đại vô nghĩa.