Ngo Nhat Thi

Khi nói đến vai trò quản lý dự án Agile, hầu hết các quy trình Agile – đặc biệt là Scrum – không bao gồm người quản lý dự án (PM). Vai trò và trách nhiệm của Người quản lý …

Mời bạn tham gia khóa học thi chứng chỉ PMP và PMI-ACP ÁP DỤNG PMP EXAM OUTLINE MỚI CHO CÁC KỲ THI PMP TRONG NĂM 2021 Wishlist Read More Ngo Nhat Thi MTHi Bootcamp for PMP Exam Ngo Nhat Thi …

Scrum Master là ai? Scrum Master là những người tạo điều kiện cho scrum framework, một khuôn khổ quản lý dự án linh hoạt với trọng tâm là các vòng lặp có thời gian cố định được gọi là sprint. …

Phát triển được dẫn dắt bởi kiểm thử nghiệp vụ Yêu cầu vs user story Khơi gợi ra yêu cầu Giao tiếp với khách hàng Chia thành lát mỏng, làm từng phần nhỏ Khi nào chúng ta xong việc? Kiểm …

Các kiểm thử kỹ thuật hỗ trợ Developmet Team tạo thành nền tảng của phát triển và kiểm thử agile. Nội dung Quadrant 1 không chỉ là về kiểm thử. Các bài unit test và component test mà chúng ta nói đến trong Quadrant 1 không phải là bài kiểm thử đầu tiên được viết cho mỗi user story, nhưng chúng giúp định hướng thiết kế và phát triển. Nếu không có nền tảng về test-driven design (thiết kế được dẫn dắt bởi kiểm thử), các unit test và component test tự động cũng như quy trình continuous integration (tích hợp code liên tục) để chạy kiểm thử, thì thật khó để cung cấp giá trị một cách kịp thời. Tất cả các kiểm thử ở các Quadrant khác không thể bù đắp cho những bất cập trong phần này. Team cần các công cụ và quy trình phù hợp để tạo và thực hiện các bài kiểm thử kỹ thuật dẫn dắt quá trình phát triển.

Hình vẽ ở trên là sơ đồ của các Quadrant kiểm thử agile (Agile Testing Quadrants) cho thấy cách thức của từng loại trong bốn Quadrant phản ánh những lý do khác nhau mà chúng ta kiểm tra. Trên một trục, chúng ta chia thành các bài kiểm thử hỗ trợ development team và các bài kiểm thử đánh giá sản phẩm. Trục còn lại chia thành nhóm các bài kiểm thử về nghiệp vụ và về công nghệ. Thứ tự mà chúng ta đã đánh số các Quadrant này không liên quan đến thời điểm các loại thử nghiệm khác nhau được thực hiện. Ví dụ: phát triển agile bắt đầu bằng các bài kiểm thử của khách hàng, các bài kiểm thử này sẽ cho team biết phải viết code gì. Thời gian của các loại thử nghiệm khác nhau tùy thuộc vào rủi ro của từng dự án, mục tiêu của khách hàng đối với sản phẩm, team đang làm việc với code kế thừa hay dự án hoàn toàn mới, và khi nào có sẵn nguồn lực để thực hiện thử nghiệm.

Tester Trong nhiều năm, cách tiếp cận phổ biến để thử nghiệm đã dựa trên định nghĩa khung về chất lượng của Philip Crosby: chất lượng là mức độ phù hợp với các yêu cầu. Nếu chất lượng là mức …

Trong các dự án truyền thống, các analyst thường trở thành người trung gian để qua đó các thành viên khác trong team và product owner giao tiếp. Trong một dự án Scrum, analyst sẽ trở thành người hỗ trợ thảo luận (facilitator) giữa product owner với team hơn là một người trung gian. Các thành viên trong nhóm và product owner cần nói chuyện trực tiếp. Thay vì là kênh truyễn dẫn cho tất cả các cuộc trò chuyện, analyst của một dự án agile tập trung vào việc đảm bảo các cuộc hội thoại đó có hiệu quả nhất có thể.

Trong quá trình phát triển, development team tạo ra một release của hệ thống sau khoảng từ 6 đến 8 tuần. Trong trường hợp tốt nhất, công tác phân tích và phát triển tiến hành song song và hỗ trợ lẫn nhau. Cách tiếp cận của XP nhấn mạnh đến sự tham gia và thử nghiệm của khách hàng: Khách hàng liên hệ với nhóm phát triển XP để bắt đầu một dự án. Nhóm lập trình yêu cầu khách hàng ngồi với nhóm của họ trong quá trình phát triển. Một dự án XP có ba giai đoạn.

ScrumMaster tương tự như một hướng dẫn viên thể lực giúp bạn gắn bó với chế độ tập thể thao và thực hiện tất cả các bài tập đúng cách. Một hướng dẫn viên thể lực giỏi sẽ tạo động lực đồng thời đảm bảo bạn không thể bỏ qua một bài tập khó. Quyền hạn của hướng dẫn viên thể lực là hạn chế và không thể bắt bạn thực hiện một bài tập mà bạn không muốn làm. Thay vào đó, hướng dẫn viên cần nhắc nhở bạn về các mục tiêu và phương pháp luyện tập bạn đã chọn để hoàn thành các mục tiêu đó

Theo nguyên tắc INVEST của một user story tốt (Independent, Negotiable, Valuable, Estimatable, Small, Testable) yêu cầu đối với một user story là nó phải có kích thước nhỏ, hoặc có kích thước phù hợp. Một user story phải đủ nhỏ để có thể được thực hiện trong một iteration. Tất nhiên điều này cũng phụ thuộc vào velocity của development team. Để đạt được mục tiêu này về nguyên tắc, một user story lớn phải được phân chia thành vài user story nhỏ hơn.

Trong một dự án lý tưởng, chúng ta sẽ có một người duy nhất sắp xếp thứ tự ưu tiên làm việc cho các developer, trả lời một cách khéo léo câu hỏi của họ, người sẽ sử dụng phần mềm khi nó kết thúc và viết tất cả các user story. Điều này hầu như luôn luôn là một hy vọng phi thực tế, vì vậy chúng ta sẽ thành lập một customer team thay vì chỉ dựa vào một người duy nhất. Customer team bao gồm những người đảm bảo rằng phần mềm sẽ đáp ứng nhu cầu của end user thực. Điều này có nghĩa là customer team có thể bao gồm người kiểm thử phần mềm (tester), người quản lý sản phẩm (product owner/product manager), vài end user thực sự và người thiết kế tương tác (interaction designer/UX-UI designer)

Một trong những thực hành gây tranh cãi nhất của XP là pair programming. Pair programming là việc hai programmer chia sẻ một bàn phím và một màn hình nhưng sử dụng hai bộ não của họ để viết code. Trong khi một programmer đang gõ bàn phím (và suy nghĩ về một vài dòng trong code của mình), thì programmer thứ hai đang xem code phát triển và suy nghĩ rộng hơn về nơi code có thể dẫn đến và vấn đề gì có thể gặp phải. Cặp đôi programmer sẽ chuyển đổi vai trò cho nhau thường xuyên

Nếu bạn nhìn vào cách các programmer viết code theo cách phát triển truyền thống, bạn sẽ thấy rằng họ thường chọn một phần của chương trình để làm, viết code, cố gắng biên dịch code, sửa tất cả các lỗi biên dịch, duyệt code trong một trình gỡ lỗi, và sau đó lặp lại chu trình. Quá trình truyền thống này rất khác với phương pháp test-driven development (TDD). Một programmer thực hiện test-driven development trong các chu kỳ rất ngắn để xác định và tự động hóa một thử nghiệm thất bại, viết code vừa đủ để vượt qua thử nghiệm đó, sau đó làm sạch code theo bất kỳ cách cần thiết nào trước khi bắt đầu lại. Chu kỳ này được lặp lại cứ sau vài phút, thay vì sau vài giờ.

Chúng ta giữ code đơn giản mọi lúc. Chúng ta giữ lại sự linh hoạt cần thiết thông qua refactoring. Refactoring là quá trình cải thiện cấu trúc của code trong khi bảo tồn chức năng của nó. Ngay cả …

Feature Driven Deleivery (FDD) , Phát triển dựa trên tính năng, là một quy trình phát triển phần mềm trong số các phương pháp Agile. FDD pha trộn một số best practice đã được công nhận trong ngành thành một phương pháp nhất quán. Những thực hành này được vận dụng từ quan điểm xây dựng các tính năng cung cấp giá trị cho khách hàng. Mục đích chính của FDD là cung cấp một phần mềm hoạt động được thông qua các iteration và được bàn giao một cách kịp thời – phù hợp với các Nguyên tắc củaTuyên ngôn Agile

Bất cứ khi nào một programmer thực hiện thay đổi code mà cần được refactor, anh ta được yêu cầu làm refactor. Programmer không chỉ được khuyến khích refactoring mà anh ta được yêu cầu bắt buộc phải làm refactor. Nhờ cách này code tránh được sự chậm chạp, tránh được những khiếm khuyết (decay) đôi khi khó phát hiện mà vì điều này cuối cùng sẽ dẫn đến lỗi. Refactoring là một trong những kỹ thuật được XP sử dụng để thay thế cho việc làm thiết kế trước (upfront design). Thay vì dành thời gian suy nghĩ về một hệ thống trước khi coding, và do đó buộc phải phán đoán một số khía cạnh trong hành vi của hệ thống, các hệ thống làm theo phương pháp XP được liên tục refactoring và nhờ đó duy trì một trạng thái đáp ứng hoàn hảo các yêu cầu đã biết.

Tại sao nên viết user stories và lưu giữ những cuộc trò chuyện về nó? Tại sao chúng ta không cần phải tiếp tục cách tiếp cận truyền thống là viết tài liệu mô tả yêu cầu (URD user requirements documents & FSD functional specifications documents) hoặc sử dụng sơ đồ use case?

Trở thành một Product Owner giỏi là điều khó khăn. Bạn phải dành thời gian nhìn về phía khách hàng, người dùng, đối thủ cạnh tranh, xu hướng trong ngành của bạn và hơn thế nữa. Nhưng bạn cũng phải dành thời gian quan tâm đến Team, làm việc với họ và trả lời câu hỏi của họ. Nếu bạn thực hiện sáu điều được liệt kê ở đây, thời gian bạn dành cho Team sẽ giúp họ trở thành Team tốt nhất dành cho bạn.

Extreme Programming (XP) là một framework phát triển phần mềm kiểu Agile nhằm tạo ra phần mềm chất lượng cao hơn và chất lượng cuộc sống cao hơn cho nhóm phát triển. XP là framework cụ thể nhất (the most specific framework) trong các phương pháp Agile về các thực hành kỹ thuật phù hợp để phát triển phần mềm. Theo Don Wells mô tả trên www.extremeprogramming.org thì điều kiện thích hợp cho ứng dụng phương pháp XP là: (i) Yêu cầu của khách hàng đối với phần mềm được dự báo sẽ thay đổi nhanh, linh hoạt; (ii) Rủi ro gây ra bởi việc áp dụng phương pháp làm dự án thời gian cố định với công nghệ mới; (iii) Nhóm phát triển qui mô nhỏ và có cùng một văn phòng làm việc vật lý; (iv) Công nghệ lập trình nhóm phát triển đang sử dụng cho phép làm unit test và functional test một cách tự động.

Agile Manifesto: “(i) Con người và sự tương tác với nhau quan trọng hơn quá trình và công cụ. (ii) Phần mềm hoạt động được quan trọng hơn là viết tài liệu đầy đủ. (iii) Hợp tác với khách hàng quan trọng hơn là đàm phán hợp đồng. (iv) Đáp ứng với thay đổi quan trọng hơn là làm theo kế hoạch. Mặc dầu các nội dung vế bên phải cũng có ý nghĩa, chúng tôi coi trọng các giá trị ở vế bên trái hơn.”

Definition of Scrum: A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is: Lightweight; Simple to understand; Difficult to master. Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

Continuous integration là một thông lệ được các nhà phát triển phần mềm sử dụng để thường xuyên kết hợp mã mới và thay đổi vào kho lưu trữ mã [code repository] dự án của họ. Điều này giúp giảm thiểu các vấn đề tích hợp do nhiều người thực hiện các thay đổi không tương thích với cùng một cơ sở mã. Thông thường nếu chúng ta thực hiện các check in mã càng thường xuyên, số lượng mã cần thay đổi càng nhỏ để cho phép bản dựng [builds] (hoặc phiên bản version) mới của phần mềm biên dịch thành công.

Tùy thuộc vào kịch bản cụ thể của từng dự án mà bạn phải cân nhắc lựa chọn giữa phương pháp quản lý dự án truyền thống (waterfall, plan-driven) hoặc chọn các phương pháp Agile để có thể mang lại khả năng thành công cao hơn cho các dự án. Điều gì phải cân nhắc để đưa ra quyết định chọn phương pháp truyền thống hay chọn phương pháp Agile? Các yếu tố cần xem xét khi lựa chọn phương pháp quản lý dự án đáp ứng tốt nhất nhu cầu của tổ chức là gì?

Chúng ta biết rằng các dự án công việc trí óc, ví dụ phát triển phần mềm hoặc nghiên cứu & phát triển ( R&D) có đặc điểm là mức độ không chắc chắn cao hơn so với các dự …

Được gọi là “Adaptive Planning”, lập kế hoạch trong dự án Agile ứng dụng 9 nguyên tắc sau đây: Lập kế hoạch ở nhiều cấp độ. Ở mức high-level planning chúng ta xác định phạm vi tổng thể dự án và định nghĩa các tiêu chí thành công của cả dự án. Tiếp đến ở mức release planning kế hoạch được làm chi tiết hơn: vẽ ra user story maps và product roadmap, tức là xác định các feature gì cần được phát triển, và sẽ được bàn giao khi nào.

Definition of Done là một danh sách tất cả các dấu hiệu phải thỏa mãn trước khi một product increment, hoặc một user story, được coi là hoàn thành.  Chừng nào một trong những dấu hiệu đó còn chưa đáp …

Đêm Giáng sinh 2019 ông già Noel tên là PMI tặng quà sớm. PMI-ACP certificate arrived!

Phương pháp Kanban có nguồn gốc từ Hệ thống sản xuất tinh gọn [Lean production system] do hãng Toyota phát triển. “Kanban” tiếng Nhật có nghĩa là “Biển chỉ dẫn” [Signboard]. Kanban board, tức Biển chỉ dẫn, đóng vai trò quan trọng trong phương pháp Kanban. Kanban board thể hiện các hạng mục công việc [work item] ở từng công đoạn của quá trình phát triển.

Sponsors các dự án agile muốn biết những thông tin cơ bản như của các dự án truyền thống – đó là khi nào dự án sẽ hoàn thành, và chi phí dự án là bao nhiêu. Trong mô hình tam giác ngược Agile (the inverted agile triangle) chúng ta biết rằng thời gian và chi phí của dự án có thể fix cố định nếu như phạm vi được phép thay đổi.

Nhân sự tham gia: Product owner, key stakeholder, Development team members. Các bên liên quan khác như user, customer nếu bạn thấy cần tham gia thảo luận về MVP/MMF. Chuẩnt bị sẵn nhiều bút bi, bút viết bảng, giấy khổ lớn, bảng. Index cards hoặc sticky notes có nhiều màu khác nhau càng tốt.

Khi một agile team cần ước lượng số story points của các user story thì phương pháp phổ biến nhất là một trò chơi tập thể có tên là Planning Poker. Planning Poker được thiết kế để trở thành một quá trình ước lượng hiệu quả vì mang tính vòng lặp, tính thích ứng, tính cộng tác và đủ mức độ ẩn danh cần thiết để giảm thiểu sự thiên vị.

Iteration planning là quá trình được bắt đầu bằng một buổi họp (workshop) có sự tham gia của Delivery team, Product Owner và có thể mời thêm các chuyên gia hoặc nhân sự liên quan khác. Công tác lập kế hoạch trong workshop này cần làm rất chi tiết và căn bản do Delivery team chủ trì và xây dựng kế hoạch. Đại diện khách hàng nếu được mời tham dự thường có nhiệm vụ trả lời các câu hỏi để giúp Delivery team hiểu rõ và hiểu đúng được các yêu cầu.

Story Point nên được ước lượng được theo dải. Khi ước lượng kích thước user story đa số các agile team sử dụng một bộ số không liên tiếp. Ví dụ dãy các số chẵn (1, 2, 4, 8, 16,…), hoặc dãy số Fibonacci (1, 2, 3, 5, 8, 13, …). Không dùng dãy số liên tiếp sẽ giúp team tránh được việc phải cân nhắc chọn ví dụ 15 hay 16.

Mike Cohn đã tóm lược các nguyên tắc cơ bản của lập kế hoạch dự án agile như sau: Công việc được thực hiện qua các iteration (vòng lặp), trong mỗi iteration có một nhóm các feature được chọn ra phải hoàn thành và có thể trở thành một increment được bàn giao cho khách hàng; Lập kế hoạch dự án ở 2 cấp độ riêng biệt, là iteration planning và release planning.

4 Giá trị Agile: (i) Con người và sự tương tác với nhau quan trọng hơn quá trình và công cụ; (ii) Phần mềm hoạt động được quan trọng hơn viết tài liệu đầy đủ; (iii) Hợp tác với khách hàng quan trọng hơn đàm phán hợp đồng; (iv) Đáp ứng với thay đổi quan trọng hơn làm theo kế hoạch.

Trong Scrum, Product Backlog là một danh sách sắp xếp theo thứ tự ưu tiên các feature, chứa đựng mô tả ngắn gọn tất cả chức năng mong muốn của sản phẩm. Thực hành theo Scrum bạn không đòi hỏi bắt đầu dự án với một danh mục dài dằng dặc và viết tài liệu đầy đủ tất cả các yêu cầu.

User stories là một phần của phương pháp Agile giúp dịch chuyển từ việc viết các yêu cầu sang kể về các yêu cầu. User stories theo phương pháp agile sẽ là một hoặc hai câu hoặc một chuỗi câu đối thoại về chức năng mong muốn.

Bạn phải làm gì khi thực hiện Product Backlog refinement? Scrum Guide tuyên bố rằng: “Scrum Team quyết định khi nào và theo cách nào để hoàn thành refinement. Refinement thường không chiếm quá 10% công suất làm việc của Development Team”

Một nhiệm vụ khó khăn bậc nhất của Scrum là làm Product Backlog Refinement. Câu hỏi thường phải trả lời khi hướng dẫn về Scrum là “Làm Product Backlog Refinement là làm những gì?”; “Làm thế nào để ngăn việc thảo luận lan man hoặc việc đi vào quá chi tiết?”; “Ai cần tham dự?”; “Ước lượng nên đưa ra khi nào?”

Scrum và Extreme Programming (XP) chắc chắn là dễ đặt cạnh nhau để so sánh vì khá giống nhau. Nếu bạn dẫn dắt đội dự án theo một trong hai qui trình này thì có thể khó nhận ra đang đi theo Scrum hay Extreme Programming. Sự sai khác giữa hai phương pháp này khá tinh vi nhưng rất quan trọng. Có 4 điểm khác biệt chính giữa hai phương pháp Scrum và Extreme Programming (XP).