Showing posts with label project-management. Show all posts
Showing posts with label project-management. Show all posts

Friday, March 3, 2023

Using Gantt Charts in an Agile Environment

https://www.smartsheet.com/content/agile-gantt#:~:text=In%20an%20Agile%20environment%2C%20you,and%20quickly%20revise%20project%20plans. 


Gantt charts can be useful in Agile environments, especially when revising project plans. Gantt charts can also benefit teams, clients, and stakeholders. A Scrum master shares how you can (and can’t) use Gantt charts for Agile.

Included on this page, you will find a step-by-step overview on using Gantt charts in Agile and a free downloadable Gantt chart template. Read a discussion of the Cynefin framework and how it can help. Plus, find a recap of the 12 Agile principles, including which ones Gantt charts can support.


What Is an Agile Gantt Chart?

In an Agile environment, you can use a Gantt chart to track the status of projects. Teams can view, manage, interact with, and quickly revise project plans. 

A Gantt chart in Agile might seem like blasphemy to some. Some Agile project managers — especially those working in a blended environment (using aspects of both Waterfall and Agile project management) — have found a place for Gantt charts. By using sprint planning and Gantt charts in tandem, you can take advantage of the fluid, flexible, and adaptable nature of Agile projects while adding details about deadlines, dependencies, and resource allocation that Gantt charts contain. 

If you’re unfamiliar with Agile project management, learn all about it in this intro to Agile project management article. 

Agile Process Versus Waterfall Process

Waterfall projects use sets of pre-planned phases, where later phases rely on completion of preceding phases. Agile projects work in a series of iterative cycles. Managers select tasks for each iteration using a combination of judgement, resources, and team input.

Agile vs. Waterfall: What’s the Difference?

This diagram illustrates the process differences between Agile and Waterfall project management.

Gantt Charts in Agile Difference From Waterfall Process

How Gantt Charts Work with the Agile Framework

Within the Agile framework, a Gantt chart can show the progress of sprints, determine which tasks to remove from a sprint, track change requests from stakeholders, help organize work, and track time spent on each task.

How Can Agile Teams Use Gantt Charts?

A Gantt chart can be useful as a part of adaptive planning to help teams manage sprints and their assigned tasks. Teams can use the charts to improve collaboration and assess resource allocation.

Managing Tasks in Agile

  • A sprint consists of sets of dependent tasks. You can use a Gantt chart to map dependencies and each task relates to others. During sprint planning, add the tasks assigned to the sprint to the Gantt chart.
  • If a task is in danger of not being completed, you can remove it and all tasks that depend on it from the sprint. Be sure to remove them during the daily planning portion of stand-up meetings.
  • Add the information that stakeholders want directly to the tasks on the Gantt chart. 
  • Color-code each sprint to enable a real-time comparison of the time it took to complete each (and their accompanying tasks).

How to Use Gantt Charts as a Collaboration Tool 

  • Plan and organize work with team members.
  • Note the deliverables for each task.
  • Assign tasks to team members.
  • Attach files to tasks (e.g., bug tickets or issues), so the team has everything it needs in one spot.
  • Add comments and notes.
  • Use the Gantt chart as the basis for creating a dashboard or roll-up report that contains the status and delivery date for each sprint.

Monitor and Review Resource Allocation with a Gantt Chart in Agile

  • By using the Gantt chart to track the time each team member puts into each task, you enable it to function as both a timesheet and an at-a-glance overview. 
  • By adding projected time needed for tasks to a Gantt chart, you allow project managers to see the demand on resources during a sprint and determine if they need to add more.
  • By looking at how long it takes to complete tasks and sprints, you can gauge a team’s efficiency.

Step by Step: How to Use a Gantt Chart for Agile Projects

When you decide to use a Gantt chart to support your Agile project, here are the steps you can take to ease the process. First you’ll need a Gantt chart tool that allows you to easily move tasks from one chart to another. 

  1. Create one task item per feature of the sprint’s product. Repeat for each planned iteration. 
  2. Give each task a start-to-finish dependency with the iteration’s testing period.
  3. Create needed dependent relationships with other tasks.
  4. During daily standups, review each iteration and the features assigned to them. Examine each task’s required time/resources and dependencies. When you need to transfer a feature to a later iteration, move the task to that iteration’s Gantt chart.

Gantt Chart Template for Agile Projects

This free downloadable Gantt chart template for Agile projects allows you to manage dependencies, track change requests from stakeholders, keep abreast of time and resource used (actual and projected), and easily remove tasks from sprints. Create a copy for each sprint in a project in order to move a task between sprints. 

Gantt Chart Template for Agile Projects

Download Agile Gantt Chart Template

Excel | Google Sheets | Smartsheet

You can also download other free Agile project management templates, including a sprint backlog with burndown chart, user story, and project charter timeline templates.

How to Blend Agile Methodology with the Gantt Chart Approach

When deciding whether to blend Agile with a Gantt chart, a basic approach is to determine if the chart helps clarify or confound the work it is tracking. If it makes management easier, use it. If not, don’t. This is a trial-and-error process, but the effort can be worthwhile.

Some see the Agile framework and Gantt charts like the Millennium Falcon and the U.S.S. Enterprise, never to inhabit the same space. But Gantt charts can comfortably overlap in some areas of Agile.

The Cynefin Framework

A route to discovery uses the Cynefin framework because it can help you decide where Gantt charts make sense. Cynefin was developed at IBM in the late ’90s and early 2000s to give decision makers a method for grounding their perceptions.

Cynefin talks about the relationship between causes and effects and divides activities into four quadrants:

  • Obvious: Best practices already exist, and the relationship between causes and effects is well known. Obvious events are knowns. The best approach is sensing, categorizing, and responding.
  • Complicated: The relationship between causes and effects requires analysis or applying expert knowledge to choose from a variety of possible courses of action. Good practices are available. Complicated items are unknowns. The best approach is sensing, analyzing, and responding.
  • Complex: Suss out cause-and-effect relationships after the fact; these events require significant analysis. There are no right answers, only a number of choices that might have positive outcomes. Emergent practices are available. Complex items are unknown unknowns. The best approach is probing, sensing, and responding. 
  • Chaotic: Cause-and-effect relationships are unknown. The goal is to quickly stop the metaphorical bleeding. You may discover new practices. The best approach is acting, sensing, and responding.

In the center of it all is disorder. Cause-and-effect relationships don’t really exist, and you may not realize this is where you are. People fall back on what’s worked in the past, which probably won’t succeed here. The best approach is gathering information, which can help you move into another domain.

Phương pháp đường găng (Critical path method) trong quản lý dự án

 Trong lĩnh vực quản lý dự án, phương pháp đường găng hay phương pháp đường tới hạn (Critical path method - CPM) được áp dụng nhằm phân tích cơ sở cho việc thành công của dự án. Trong bài viết này chúng ta sẽ gọi tắt phương pháp đường găng là “Critical path”, đi tìm hiểu về lịch sử ra đời, định nghĩa và ứng dụng phương pháp đường găng này vào thực tế công việc quản lý dự án.

Lịch sử ra đời critical path

Trong những năm 1960, Dupont nghiên cứu phát triển rất nhiều chất liệu mới đòi hỏi phải có các qui trình sản xuất chi tiết. Nhu cầu của các doanh nghiệp tư nhân và quốc doanh về những vật liệu mới đã vượt quá khả năng của Dupont trong việc xây dựng những thiết bị và qui trình cần thiết để sản xuất hàng loạt, vì thế Dupont đã xây dựng Phương pháp Đường găng (Critical Path Method, viết tắt là CPM) nhằm giúp xác định chính xác hơn những ràng buộc về tài nguyên có ảnh hưởng thế nào đến thời gian đưa ra thị trường. Ngày nay rất nhiều người coi CPM là phương thức tiếp cận mặc định trong việc vẽ sơ đồ mạng cho những dự án có ràng buộc về tài nguyên.

Critical path là gì?

Trong mỗi dự án, critical path là tập hợp các công việc có quan hệ với nhau và ảnh hưởng trực tiếp đến ngày kết thúc dự án. Nói cách khác, nếu chúng ta đứng từ ngày kết thúc của dự án và đi ngược về ngày bắt đầu của dự án qua các công việc bị phụ thuộc thì nó là đường dài nhất. Vì vậy, mỗi 1 công việc trên critical path đều rất quan trọng và ảnh hưởng trực tiếp đến dự án có hoàn thành đúng tiến độ không. Việc xác định critical path và kiểm soát sự trì hoãn các công việc trên đường critical path sẽ giúp bạn kiểm soát tốt được tiến độ dự án.

Phương pháp đường găng (Critical path method) trong quản lý dự án

Ví dụ: Một critical path gồm các công việc A -> D -> H -> I -> K; Nếu D bị chậm tiến độ 02 ngày thì để đảm bảo tiến độ dự án bạn chỉ có cách duy nhất là đẩy nhanh tiến độ bằng cách rút ngắn H, I, K được đủ 02 ngày.

Cách xác định critical path

  • Xác định tất các công việc cần làm để hoàn thành một dự án theo cấu trúc phân cấp công việc (WBS).
  • Xác định thời gian và nguồn lực để hoàn thành các công việc.
  • Xác định sự phụ thuộc công việc: SS (Start to Start), FS (Finish to Start), SF (Start to Finish), FF (Finish to Finish).
  • Xác định danh sách mốc mục tiêu.

Sau khi đã phân tích đủ dữ liệu cho 4 bước trên, bạn sẽ tiến hành đi ngược và đánh dấu các công việc từ thời điểm kết thúc về thời điểm bắt đầu của dự án qua các công việc phụ thuộc để rồi tìm ra đường dài nhất, đó chính là bạn đã xác định được critical path.

Kiểm soát tiến độ dự án bằng phân tích critical path

Sau khi đã xác định được critical path, bạn nên xem xét lại các công việc trên critical path này dưới 2 góc độ để đảm bảo chắc chắn hơn cho tiến độ dự án:

  • Đánh giá lại thời gian
  • Đánh giá lại nguồn lực

Lập kế hoạch dự án và vẽ đường critital path bằng đồ họa nhằm dễ kiểm soát các công việc này để đảm bảo dự án về đích đúng kế hoạch theo mục tiêu ban đầu. Ví dụ sử dụng sơ đồ gantt có hỗ trợ critical path để hiển thị đường này.

Phương pháp đường găng (Critical path method) trong quản lý dự án

Đặt cảnh báo ở mức độ cao hơn theo cơ cấu tổ chức dự án khi việc này có nguy cơ chậm tiến độ (chỉ số SPI). Ví dụ: Công việc không thuộc critical path (công việc bình thường) có nguy cơ chậm thì cảnh báo đến người phụ trách, người phối hợp, quản trị dự án; Công việc thuộc critical path mà có nguy cơ chậm thì ngoài gửi cảnh báo như công việc bình thường khi đó sẽ gửi đến các line khác trong cơ cấu dự án như: Điều phối viên, Trưởng ban chỉ đạo, Trợ lý, Giám đốc dự án.

Khi 1 công việc trên critical path bị chậm, bạn cần và nhất thiết quản lý phê duyệt thay đổi (CR) nhằm đảm bảo mọi sự chậm chễ hoặc ảnh hưởng chậm chễ đến dự án đều được phê duyệt. Kích hoạt đèn trạng thái dự án để các bên liên quan trong cơ cấu tổ chức dự án nắm được và tìm giải pháp có thể như bổ sung nguồn lực để đẩy nhanh tiến độ các công việc khác trên critical path. Trong trường hợp tiếp tục không cải thiện được tình hình dự án có thể được đưa sang trạng thái thành lập hội đồng đánh giá (HC) nhằm đưa ra các giải pháp và chỉ đạo để dự án về đích kịp tiến độ.

Nếu quy mô dự án trên cỡ vừa hoặc bạn quản trị nhiều hơn 05 dự án nhỏ, chúng tôi khuyên bạn nên tìm một phần mềm quản lý dự án (tốt hơn là một phần mềm dự án online) có các tính năng cần thiết để giúp bạn thực hiện những việc trên đơn giản hơn, dễ dàng hơn và tất nhiên là hiệu quả hơn.

02 PHƯƠNG PHÁP NÉN TIẾN ĐỘ TRONG PMP®: CRASHING VÀ FAST TRACKING

 Trong lĩnh vực Quản lý Tiến độ Dự án, khi ban Quản lý dự án phải đối mặt với việc trễ tiến độ (hoặc được yêu cầu bất ngờ phải chuyển giao thành phẩm trong thời gian sớm hơn), có hai phương pháp quan trọng để nén tiến độ nhằm bắt kịp với hạn chót mà vẫn đảm bảo được phạm vi dự án là: Crashing và Fast-Tracking. Hai kỹ thuật này có những điểm giống và khác nhau. Bài viết này sẽ giải nghĩa thêm để bạn nắm rõ hơn về hai kỹ thuật này nhằm áp dụng tốt trong kỳ thi PMP®.


Crashing là gì?

- Là kỹ thuật nén tiến độ nhằm rút ngắn thời lượng của hoạt động bằng cách thêm vào nguồn lực bổ sung (tài lực và/hoặc nhân lực).

- Crashing làm tăng chi phí vì nguồn lực bổ sung có thể thêm từ việc:

  • Làm thêm giờ/Tăng ca
  • Thêm nhân lực
  • Thuê ngoài

- Crashing thường được cân nhắc sử dụng sau kỹ thuật Fast-Tracking.

- Giám đốc dự án cần quyết định hoạt động nào có thể dùng phương pháp này với chi phí thấp nhất và mang lại hiệu quả cao nhất.

- Crashing có thể dẫn đến rủi ro tạo ra lỗi hay phải làm lại (rework).

Fast-Tracking là gì?

- Là kỹ thuật nén tiến độ bằng cách thực hiện các hoạt động song song với nhau (một phần hoặc toàn bộ) để tiết kiệm thời gian.

- Các hoạt động được thực hiện song song nên cần phân tích kỹ để đảm bảo mối quan hệ chặt chẽ và cả hai hoạt động có thể thực hiện đồng thời cùng lúc với nhau (có thể chồng chéo một phần hoặc toàn bộ hoạt động)

- Kỹ thuật này thông thường không cần thêm nguồn lực bổ sung khác

- Fas-Tracking có thể tạo ra thêm rủi ro

- Đây là phương pháp được ưa chuộng khi cần nén tiến độ

Cả hai kỹ thuật Crashing và Fast-Tracking đều phải áp dụng cho các hoạt động nằm trên Đường tới hạn (Critical Path) để có thể rút ngắn thời hạn dự án. Nếu áp dụng cho các hoạt động không nằm trên Đường tới hạn (Critical Path), nó sẽ chỉ làm tăng độ trễ (Float) mà không hề rút ngắn thời hạn dự án. (Lưu ý: Critical Path có thể khác đi khi các hoạt động của dự án có độ trễ).

Minh họa hai kỹ thuật Crashing và Fast-Tracking

Lấy Dự án Chuẩn bị học và thi PMP® làm ví dụ

Giả sử bạn lên kế hoạch chuẩn bị cho kỳ thi PMP® trong 2 tháng với 3 giờ tự học mỗi ngày. Sau một tháng ôn luyện, bạn hoàn thành được 40%. Bạn dự đoán được có thể mình sẽ không chuẩn bị đầy đủ đúng như thời gian dự kiến cho kỳ thi, nên bạn muốn nén tiến độ học để hoàn thành 60% các hoạt động còn lại trong vòng một tháng.

Bây giờ, theo lời khuyên chung, bạn bắt đầu “Fast Tracking” việc ôn thi của mình bằng cách:

  • Thực hiện và vượt qua bài thi cuối cùng của khóa luyện thi trực tuyến sau khi hoàn thành mức độ phần trăm yêu cầu của khóa học (ví dụ: 80%) để lấy chứng chỉ 35 giờ đào tạo bắt buộc cho kỳ thi PMP®. Sau đó, bạn tiếp tục học các nội dung còn lại của bài thi trong khi PMI đánh giá hồ sơ đăng ký thi để tiết kiệm thời gian (như vậy, bạn thực hiện song song việc nộp đơn đăng ký thi và học để lấy chứng nhận 35 giờ đào tạo bắt buộc)
  • Thực hiện 1 bài thi thử hoàn chỉnh trước khi đọc qua toàn bộ giáo trình thi để đánh giá mức độ sẵn sàng của mình cho kỳ thi PMP®

Tuy nhiên, sau khi thực hiện kỹ thuật “Fast-Tracking”, bạn vẫn chưa đủ tự tin rằng mình có thể đạt được mục tiêu, nên bạn sử dụng tiếp kỹ thuật “Crashing” như sau:

  • Tăng thời gian học mỗi ngày lên 4 giờ vào các ngày trong tuần và 8 giờ vào cuối tuần (bạn dành thêm thời gian để ôn luyện)
  • Mua một bộ Flashcard PMP® để giúp ghi nhớ nhanh hơn các ý chính trong bài thi (bạn bỏ thêm tiền)
  • Đăng ký khóa luyện thi trực tuyến để có thể tranh thủ nghe thêm các bài học trong những lúc di chuyển (bạn tiếp tục bỏ thêm tiền)

Bằng việc sử dụng hai kỹ thuật trên, bạn đã chuẩn bị đầy đủ, kịp thời cho kỳ thi và vượt qua nó trong lần thử sức đầu tiên. Chúc mừng bạn!

Tóm lại, Crashing và Fast-Tracking là hai kỹ thuật nén tiến độ phổ biến nhất nhằm rút ngắn thời hạn dự án để trong trường hợp bị trễ vẫn đảm bảo phạm vi dự án. Fast Tracking là thực hiện song song (một phần hoặc toàn bộ) các hoạt động ban đầu trong khi Crashing là thêm vào các tài nguyên bổ sung để rút ngắn thời lượng thông thường của các hoạt động.

Fast-Tracking được ưa tiên lựa chọn hơn Crashing vì Fast-Tracking không liên quan đến tài nguyên cũng như chi phí bổ sung, ảnh hưởng đến hiệu suất ngân sách của dự án. (nếu không, điều này đã được kết hợp với Kế hoạch Dự án ngay từ thời điểm ban đầu) – rủi ro làm lại này cần được cân bằng một cách cẩn thận so với lợi ích của việc nén tiến độ.

Ngoài ra, có thêm một kỹ thuật nén tiến độ khác cũng hiệu quả là cắt giảm phạm vi dự án, nhưng điều này có thể ảnh hưởng đến mục tiêu dự án và do đó không phải là cách ưa chuộng để thực hiện.

Hy vọng bài viết này có thể minh họa rõ sự khác biệt giữa Crashing vs Fast Tracking đến bạn.


Thursday, March 2, 2023

Hiện tượng Gold plating

 

Hiện tượng Gold plating (mạ vàng) là gì? Tại sao có ảnh hưởng quyết định đến chất lượng dự án?






Gold Plating Là Gì?

Theo định nghĩa gốc tiếng Anh:


Gold plating happens when team adds features that it thinks helps users, instead of sticking to what is defined in the scope baseline. Who knows the end user’s needs better than the customer?

 

Trong đội dự án có một developer (lập trình viên phát triển phần mềm) nghĩ ra một tính năng tiện ích rất "cool" hay một hiệu ứng đẹp mặt hiển thị các hình ảnh, menu trên trang chủ (giống như một tòa nhà hiện đại phát ánh sáng laser ban đêm vậy). Vì sự sáng tạo và nhiệt tình này mà anh ấy cần mất thêm 2 ngày để làm và 2 ngày nữa để hoàn thiện. QA team không có yêu cầu cho việc kiểm tra tính năng này vì thế họ chỉ kiểm thử theo ý của họ và "deliver" sản phẩm cho khách hàng.

Khi khách hàng nhận sản phẩm cuối cùng đã rất ngạc nhiên về tính năng thêm này.  Rất nhiều khách hàng có thể cảm nhận điều thú vị này, nhưng cũng có những khách hàng sẽ phàn nàn rằng các lập trình viên sáng tạo quá mức, thiếu tập trung vào nghiệp vụ, và do đó làm chậm tiến độ dự án. Thí dụ mục tiêu quan trọng nhất của khách hàng là thời gian "book" phòng phải nhanh nhất có thể, tránh các bước rườm rà. Tốc độ "load" trang phải nhanh, do đó việc thêm các hiệu ứng là không cần thiết.

Trong trường hợp vừa nêu, nhóm lập trình đang làm cái gọi là "mạ vàng cho khách" (gold plating). Khách hàng không cần điện thoại Vertu mạ vàng xung quanh, họ chỉ cần chiếc điện thoại smartphone chạy nhanh, hỗ trợ 2 sim. Đây chính là mục tiêu (objective) của dự án.

Hiểu một cách đơn giản Gold Plating là làm dư thừa, làm cái mà khách hàng không yêu cầu, làm những thứ ngoài phạm vi (scope) dự án. Khi phần vượt lớn hơn phần phải có (trong phạm vi) thì dẫn đến một loạt các sụp đổ (công việc, chất lượng, tiến độ...).

Trong nhiều trường hợp Gold Plating lại giúp ích cho chiến lược kinh doanh (của những công ty lớn). Nhớ lại thập kỷ 2000-2010, các máy tính xách tay tích hợp công nghệ đăng nhập vân tay và sau này là khuôn mặt, nhưng lúc đó độ chính xác chưa cao. Vậy các hãng máy tính đưa vào để làm gì? Rõ ràng là gold plating và điều này có thể làm tăng giá bán sản phẩm. Thực tế thì không hẳn vậy. Các hãng máy tính cố gắng tiếp cận công nghệ mới và tạo ra những sản phẩm flagship, "educate" khách hàng quen dần với công nghệ - những thứ sẽ trở nên quen thuộc trong tương lai

Gold Plating Làm Chệch Mục Tiêu Chính Của Dự Án

Trong thực tế, có rất nhiều dự án thất bại do đi chệch mục tiêu. Thí dụ dự án Cổng thông tin một cơ quan Bộ tích hợp module CMS. Team kỹ thuật nghĩ ra một loạt các quy trình kiểm duyệt bài vô cùng phức tạp vốn chỉ dành cho báo chí điện tử (vnexpress, dantri...).

Cổng thông tin ở trên chính xác là mô hình P-CMS (Publications CMS). P-CMS hỗ trợ việc quản lý các loại ấn phẩm trực tuyến (sổ tay, sách, trợ giúp, tham khảo...). Đây là "objective" của phần lớn các Cổng thông tin Portal ở Việt Nam. Đừng bao giờ cố ý hay vô ý biến Cổng thông tin thành tòa soạn báo chí điện tử bạn nhé, nếu không bạn đã phạm vào quy tắc chống Gold Plating.

Gold Plating có nguy cơ tạo ra hiệu ứng domino. Một thay đổi của bạn sẽ khiến cả module hoặc cả hệ thống phải "test" lại. Các lập trình viên và quản lý sẽ vất vả kiểm tra xem đoạn code bạn viết có tốt hay không, có phá vỡ cấu trúc tổng thể hay không. Thậm chí, chính bạn (tác giả của đoạn code thay đổi) cũng không kiểm soát nổi những thay đổi bạn đưa vào vì bạn không "document" nó ở đâu cả.


Gold Plating là một trong mười rủi ro của dự án phát triển phần mềm

Gold Plating sẽ kéo theo các hiệu ứng khác, thí dụ hiệu ứng “Sụt lở/leo thang trong phạm vi công việc”. Một thay đổi tưởng chừng vô hại tích tụ lại và tăng nhanh chóng thành thay đổi lớn mà có ảnh hưởng đến các nguồn lực hạn chế dự án, giống như hiệu ứng ”Quả cầu tuyết” (Snowball Effect).

Khi Nào Gold Plating Có Ảnh Hưởng Tích Cực Đến Sản Phẩm Của Bạn?

Như đã nói ở trên Gold Plating không hoàn toàn mang ý nghĩa xấu. Gold Plating là sản phẩm của giới quý tốc, vậy thì bạn cũng cần thiết nâng cao tư duy để tạo đẳng cấp cho kinh doanh của bạn. Tiếng Anh có câu "go extra miles" để chỉ việc cố gắng thêm một chút, trong kinh doanh chúng ta hiểu như khuyến mại một cái gì đó. Chúng ta không nên cứng nhắc khi chỉ làm cho khách hàng những thứ đã được "chốt" trong specs. Chúng ta có thể "free" cho họ những thứ chúng ta đã có sẵn, nhưng không thể free những thứ chúng ta "mới chỉ đang thử" vì việc phát sinh như vậy có thể ảnh hưởng tiến độ dự án, làm tăng chi phí dự án, ảnh hưởng chung đến tình hình tài chính doanh nghiệp.

Gold Plating Khác Với Giá Trị Đem Lại Cho Khách Hàng Như Thế Nào?

Gold Plating có thể đem lại giá trị, có thể không. Giá trị đem lại cho khách hàng không chỉ là sản phẩm bàn giao, mà còn bao gồm chất lượng thương hiệu, uy tín của team (thí dụ triển khai dự án đúng tiến độ, luôn sáng tạo để tăng tính trải nghiệm người dùng...).

Gold Plating chỉ là một cách nói về "sự nhiệt tính quá giới hạn". Bạn đem lại quá nhiều giá trị cho khách hàng, khi đó bạn vô tình trở thành người chịu trách nhiệm về dự án chậm tiến độ, khiến công ty bạn phải tăng cường nhân lực, dự án phải gia hạn thêm, chung quy lại sẽ ảnh hưởng đến tính hình tài chính của dự án.

Khác Nhau Giữa Gold Plating Và Scope Creep

Gold Plating là hiện tượng khi team kỹ thuật vô tình thêm vào các tính năng khách hàng không cần, trong khi Scope Creep là vấn đề khi khách hàng đưa vào các yêu cầu mới theo thời gian, dẫn đến "vỡ trận" khi dự án không thể kết thúc nổi. Trong nhiều trường hợp, khách hàng sẽ đưa vào mỗi lần một ít, dần dần sẽ tích tiểu thành đại (chiến lược lát cắt Salami). Ban đầu team kỹ thuật nghĩ rằng các thay đổi nhỏ đó hoàn toàn vô hại, nhưng họ vô tình không thể nào biết được nguy cơ "sạt lở" từ đống source code khổng lồ của họ do chồng chất thay đổi hết đợt này đến đợt khác. Đến khi dự án chuẩn bị nghiệm thu, quản lý dự án mới nhận ra rằng có quá nhiều thay đổi khác hẳn với bản mẫu (prototyping) ban đầu. Mọi quyết định lúc đó đã quá muộn, một sự tiến thoái lưỡng nan "tiền trảm hậu tấu" vì các lập trình viên đã sa vào cái bẫy chết người có tên "quả cầu tuyết khổng lồ".



Đầu tiên đó chỉ là 1 thay đổi đơn giản nhưng sau đó là một thay đổi lớn ảnh hưởng đến tiến độ dự án, và sẽ nghiêm trọng hơn nếu công việc này còn nằm trên đường găng (critical path) bởi vì sẽ trì hoãn tiến độ của cả dự án.

Dự án trong trường hợp những yếu tố không kiểm soát được về mặt thời gian và nguồn lực, xuất phát từ những thay đổi nhỏ rồi thành thay đổi lớn gọi là scope creep.

Định nghĩa gốc tiếng Anh của Scope Creep:

 

A simple, seemingly harmless change snowballs into a big change that impacts project constraints resulting in scope creep.

 

Gold Plating Trong Các Lĩnh Vực Khác

Ngoài lĩnh vực phần mềm, các lĩnh vực khác cũng từng xuất hiện những vấn đề như vậy. Dự án phim ảnh cho vào quá nhiều cảnh không cần thiết, quá nhiều hiệu ứng chuyên nghiệp nhưng người xem họ chỉ tập trung vào nội dung về cuộc sống làng quê dân dã trong bộ phim.

Lĩnh vực công trình xây dựng ít chịu ảnh hưởng của Gold Plating nhất. Vì sao vậy?

Lĩnh vực công trình xây dựng và lĩnh vực phát triển phần mềm có rất nhiều điểm tương đồng, đây cũng là 2 lĩnh vực hàng đầu hay được nhắc đến trong chứng chỉ quản lý quốc tế PMP. Chính nhờ lĩnh vực CNTT xuất hiện, mà kéo theo sự ra đời của PMP.

Mặc dù có nhiều điểm tương đồng, nhưng giữa 2 lĩnh vực này vẫn có sự khác biệt quan trọng sau:

  • Lĩnh vực xây dựng có đầu vào là các nguyên vật liệu, còn phần mềm có đầu vào là chất xám và các tài sản trí thức mà nhà thầu có được (thí dụ công nghệ, tài sản mã nguồn core...).
  • Bạn không thể thiết kế thêm một cái cửa nếu như nó không có trong bản vẽ. Nếu đó là cửa Euro Window đi nữa, khách hàng cũng không cần đến vì nó phá vỡ cấu trúc chung của ngôi nhà.
  • Nếu mắc sai lầm trong lĩnh vực xây dựng, bạn sẽ mất cả chi phí, thời gian và uy tín. Trong lĩnh vực phần mềm, bạn không mất chi phí vật tư, bạn vẫn có thể sử dụng lại đoạn code đó ở những dự án trong tương lai (đặc tính "portable"). Đặc tính của phần mềm là tính dễ dàng thử nghiệm hay tìm tòi sáng tạo mà không cần đến phòng lab, không cần đến nguồn nguyên liệu/vật tư, không quá phụ thuộc vào quyết định của toàn đội.





So sánh các GitFlow model và áp dụng với CICD

https://medium.com/oho-software/so-s%C3%A1nh-c%C3%A1c-gitflow-model-v%C3%A0-%C3%A1p-d%E1%BB%A5ng-v%E1%BB%9Bi-cicd-b6581cfc893a