Trong thời buổi ngày nay, hầu hết các doanh nghiệp đều cần sự linh hoạt (agility) để có thể tồn tại và tận dụng rất nhiều cơ hội xuất hiện nhưng cũng biến mất rất nhanh. Những yếu tố nào của hiệu năng phát triển phần mềm giúp tăng tính linh hoạt? Cẩm nang linh hoạt trong kinh doanh của CA cho rằng đó là những yếu tố sau:
Biểu hiện của những điểm nhóm bạn đang không có khả năng linh hoạt:
- Chậm ngày phát hành – Nhóm mất nhiều tháng, thậm chí nhiều quý để hoàn thành tính năng do kinh doanh yêu cầu
- Sát ngày phát hành, nhưng sản phẩm vẫn thiếu ổn định – Nhóm tuyên bố gần như đã hoàn thành, nhưng sản phẩm vẫn còn nhiều bug, nhóm không kiểm soát được hết
- Việc lập kế hoạch quá mất thì giờ mà vẫn không đâu vào đâu – trượt các kế hoạch từ thời gian cho tới chất lượng, bạn ngày càng dành nhiều thời gian để lập kế hoạch, nhưng càng làm, càng bị trượt nhiều.
- Rất khó để thay đổi giữa chừng – khi bạn học/nhận biết được từ thị trường, nhưng cũng không thể đưa vào phát triển được vì nhóm rất khó thực hiện
- Chất lượng sản phẩm cứ giảm sút – càng về sau lượng bug cứ tăng dần và nhóm ngày càng dành nhiều thời gian để sửa lỗi thay vì phát triển sản phẩm
- Deadline, Over-time, và Stress – là những hành trình mệt mỏi làm giảm sự gắn bó của đội ngũ cũng như gây khó khăn cho việc tuyển dụng
Nếu nhóm không làm bạn hài lòng thì cũng không phải là chuyện lạ, đặc biệt khi bạn áp dụng Waterfall, bởi theo báo cáo Chaos 2015 của Standish Group thì tỷ lệ thành công của các dự án công nghệ thông tin áp dụng Waterfall chỉ là 11%, và dù có áp dụng Agile thì cũng chỉ là 39%
Chaos Report 2015 trên InfoQ
Cứ sau 1 khoảng thời gian ngắn (1- 4 tuần) gọi là sprint, nhóm đã hoàn thành phần mềm mà tất cả chúng ta từ khách hàng, marketing, bán hàng, nhà bảo trợ, … đều có thể sử dụng được.
Sau mỗi sprint, chúng ta thanh tra và thích nghi về sản phẩm cũng như cách thức làm việc với những điều chúng ta học được về nhóm, công nghệ, thị trường, các bên liên quan,vv… Thông thường chúng ta sẽ đi theo một hướng khác so với những gì ban đầu cho là đúng. Trên hành trình theo đuổi tầm nhìn, mỗi phần tăng trưởng sẽ động viên cũng như thôi thúc chúng ta suy nghĩ những cách sáng tạo và cũng rất cụ thể để thực hiện hóa tầm nhìn của sản phẩm hoặc mục tiêu sản phẩm. Đôi khi nhận thấy sự thật phũ phàng là tầm nhìn đó không thể đạt được và chúng ta có chứng cứ cho điều đó. Ta phải quyết định cho một sự thật phũ phàng – loại bỏ sản phẩm, nhưng điều đó cũng giúp tiết kiệm được công sức và phần thời gian còn lại.
Scrum có giúp giảm thiểu những nỗi đau mà chúng ta liệt kê ban đầu?
Thời gian phát hành quá lâu. Các phát hành của chúng ta bao gồm một hay nhiều sự tăng trưởng được tích hợp với nhau, chúng được phát triển một cách tuần tự, từ sprint này tới sprint khác. Chúng ta có thể dừng ở bất kỳ sprint nào mà chúng ta muốn. Chúng ta có thể dừng lại khi đã tối đa hóa giá trị, đặc biệt là khi chúng ta biết được rằng hơn một nửa số chức năng phần mềm không bao giờ hoặc hiếm khi được sử dụng. Chúng ta cũng có thể chỉ dừng lại và phát hành khi đến hạn hoặc hết ngân sách. Chúng ta sẽ có những tăng trưởng có giá trị được tích để triển khai.
Lỡ mất kế hoạch phát hành. Lịch phát hành của chúng ta không thể trễ hơn một sprint (1-4 tuần). Chúng ta chuyển giao các tăng trưởng được tích lũy khi đến hạn định. Chúng ta không phân bổ các sprint để xây dựng những chức năng có giá trị thấp, điều đó cho phép chúng ta phát hành một hệ thống hoàn chỉnh sớm hơn nhiều so với bình thường. Nếu sử dụng phương pháp phát triển phần mềm truyền thống, thì có ít hơn 50% các chức năng được sử dụng thường xuyên. Chúng ta không phát triển những chức năng này.
Mất nhiều thời gian cho sự ổn định vào cuối kỳ phát hành. Mỗi sprint tạo ra chức năng tăng trưởng hoàn thiện, đầy đủ và sẵn sàng để sử dụng. Mỗi tăng trưởng sau được tích hợp với những tăng trưởng của các sprint trước đó, do vậy nó cũng được hoàn tất và sẵn sàng để sử dụng. Không cần phải làm gì mà vẫn có được sự ổn định trước khi phát hành.
Lên kế hoạch quá dài và không đúng. Việc lập kế hoạch ban đầu được giảm xuống để thiết lập mục tiêu và xác định những khả năng, tính năng có tính giá trị cao, những chức năng cần thiết để đạt được mục tiêu đã xác lập. Thời hạn và chi phí được dự báo trước. Lập kế hoạch trước sprint đầu tiên thường chỉ bằng 20% so với những gì mà chúng ta phải bỏ ra khi dùng Waterfall, hay phương pháp tiên lượng. Chúng ta lập kế hoạch chi tiết về những yêu cầu của mỗi sprint chỉ trước khi nó bắt đầu. Khi chúng ta thanh tra kết quả thì xuất hiện các yêu cầu mới và những yêu cầu tốt nhất được đưa vào sprint tiếp theo.
Khó thay đổi trong quá trình phát hành. Không có bản phát hành dở dang trong một dự án tiếp cận lặp và tăng trưởng. Các yêu cầu có thể nảy sinh và được đưa vào trước bất kỳ sprint nào, với chi phí tối thiểu.
Chất lượng giảm sút. Phần tăng trưởng của mỗi sprint là hoàn chỉnh và sẵn sàng để sử dụng với chất lượng dựng sẵn (built-in quality). Mỗi tăng trưởng tiếp theo cũng được bổ sung vào với chất lượng phù hợp. Không có giai đoạn ổn định gấp gáp vào cuối dự án khi mà chất lượng có thể bị ảnh hưởng bởi thời gian cam kết. Công việc đã làm xong.
Hành trình gian nan làm tổn thương tinh thần. Kết cục của ổn định phát hành đã được loại bỏ, cùng với những gian nan được gây ra bởi việc làm thêm giờ, làm vào cuối tuần.
Quản lý yêu cầu dự án/sản phẩm chỉ sử dụng ba biến. Đầu tiên là các yêu cầu (A), những chức năng phần mềm hình dung sẽ cung cấp. Thứ hai là thời gian (B), mà bây giờ chúng ta đo lường trong đơn vị 30 ngày. Thứ ba là công việc đã hoàn thành (C), được đo bằng các chức năng dùng được đã bàn giao, hoặc số lượng của (A) được hoàn thành trong bất kỳ khoảng thời gian 30-ngày nào được tích tụ lại.
Bạn có thể tạo ra biểu đồ để quản lý dự án, như sau:
- Product Backlog trên trục y, hay trục thẳng đứng. Tính toán nỗ lực cần thiết để đáp ứng từng yêu cầu. Giả sử chúng tôi có năm yêu cầu tương ứng với các nỗ lực để hoàn thành là 2, 3, 5, 3, và 8 đơn vị. Những nỗ lực này tạo ra một khối lượng công việc trên trục y cao 21 đơn vị. Các đơn vị được sắp xếp theo thứ tự mà bạn muốn chuyển hóa thành những chức năng dùng được. Giả sử thứ tự, từ trên xuống vẫn là 2, 3, 5, 3, và 8.
- Thời gian trên trục x, hay trục ngang. Đơn vị là khoảng thời gian 2-tuần, là chiều dài sprint.
- Dựa trên kinh nghiệm trước đó, chúng tôi dự đoán nhóm phát triển sẽ hoàn thành năm đơn vị công việc ở tất cả các sprint. Chúng tôi sẽ tìm hiểu năng suất thực tế của họ khi chúng tôi bắt đầu, nhưng đây là một dự báo dựa vào “thời tiết của ngày hôm qua” (yesterday’s weather). Do đó, chúng tôi dự kiến hoàn thành hai mươi đơn vị làm việc trong bốn sprint đầu tiên (5, 5, 5, 5), và phần công việc còn lại sẽ ở được thực hiện ở sprint thứ năm, sprint cuối cùng.
- Số lượng công việc hoàn thành và chức năng sẵn sàng để sử dụng được tính vào cuối mỗi sprint. Chúng tôi lập kế hoạch rằng hai yêu cầu đầu tiên, đó là yêu cầu có 2 và 3 đơn vị công việc, sẽ được hoàn thành trong sprint đầu tiên. Chúng tôi dự kiến chức năng sẽ được hoàn thành ở sprint thứ hai, chức năng có kích thước là 5 đơn vị. Vào thời điểm này, chúng tôi thường đổi ý về việc sẽ phải làm tiếp theo. Chúng tôi đã thấy hai tăng trưởng đầu tiên, và thường thấy các yêu cầu không mong đợi hoặc bị sửa đổi cho sprint kế tiếp. Nếu không, chúng tôi tiến hành như kế hoạch. Tuy nhiên, kế hoạch và yêu cầu sắp tới có thể thay đổi mà không có bất lợi gì ở cuối bất kỳ sprint nào. Các tăng trưởng có cùng đơn vị như các yêu cầu trên trục y.
- Nhóm phát triển đã tạo ra 3, 5, và 5 đơn vị chức năng trong ba sprint đầu tiên. Biểu đồ kết quả được hiển thị trong hình 2.4.
Ngoài ra việc giải quyết những vấn đề đã nêu Scrum còn hỗ trợ những việc sau:
Quản lý: Chúng ta biết chính xác số lượng và những yêu cầu mà bạn đã hoàn thành và sẵn sàng để sử dụng ở cuối mỗi sprint. Bạn có thể dự báo về xu hướng dựa trên tiến độ ở quá khứ và đánh giá thời gian có thể hoàn thành dự án. Bạn đưa ra các dự báo và biết rằng nó có thể thay đổi vào thời điểm cuối của sprint tiếp theo.
Kiểm soát: Nếu dữ liệu cho thấy bạn sẽ hoàn tất công việc trễ hơn mong đợi, bạn có thể giảm kích thước hoặc số lượng các chức năng còn lại sẽ phải hoàn thành. Ví dụ, ở cuối sprint 2, với 13 đơn vị yêu cầu đòi hỏi phải hoàn thành, bạn có thể giảm phạm vi của chúng xuống còn 10 đơn vị. Nếu nhóm phát triển vẫn tiếp tục với tốc độ 5 đơn vị yêu cầu trong mỗi sprint, các chức năng sẽ được hoàn thành vào cuối sprint thứ tư.
Khả năng dự báo: Dự báo có thể sai. Dự án sẽ hoàn thành trễ hơn vài tuần so với dự kiến. Sau sprint đầu tiên có thể nghi ngờ khả năng xảy ra điều này, sau sprint thứ hai thì thấy điều này có thể xảy ra, đến cuối sprint thứ ba thì khả năng sẽ xảy ra là rất rõ ràng. Những người sử dụng các chức năng có thể phải điều chỉnh lịch của mình để đồng bộ. Tương tự như vậy, ngân sách cũng có thể được điều chỉnh và phê duyệt sớm.
Quản lý rủi ro: Ba sprint đầu tiên, nhóm phát triển chỉ hoàn thành được 2 đơn vị chức năng với mỗi sprint. Vào cuối sprint thứ ba, một dự báo sẽ chỉ ra cho đến giữa sprint thứ 10 công việc sẽ chưa được hoàn tất. Nếu ngân sách ban đầu là 100,000 USD, thì theo dự báo mới sẽ là hơn 150,000 USD. Nếu lợi nhuận trên đầu tư của 250,000 USD không phù hợp, sẽ hủy bỏ dự án sau sprint thứ ba.
Bài viết có lấy nội dung từ sách: “Software in 30 days”
