Qui trình đơn giản cho dự án nhỏ
Hôm qua, một sinh viên đã tốt nghiệp vài năm trước tới gặp tôi. Anh ta nói: “Em đã đi làm cho một công ti phần mềm lớn trong vài năm, bây giờ em muốn bắt đầu công ti riêng của em. Em có đủ kinh nghiệm và một số tiền mà em đã tiết kiệm trong những năm qua. Em cũng có một vài người phát triển người sẵn lòng làm việc cho em. Em lập kế hoạch bắt đầu công ti của em bằng việc làm các dự án nhỏ và dần dần phát triển công ty. Em cần lời khuyên của thầy để thiết lập qui trình tốt để phát triển phần mềm có chất lượng với chi phí thấp nhất có thể được. Vì em chỉ có “vốn giới hạn”, em không muốn phí hoài nói. Thầy nghĩ điều đó có thể được thực hiện không?”
Sau khi suy nghĩ một chốc, tôi bảo anh ta: “Điều tốt là bắt đầu từ các dự án nhỏ. Nếu bạn có người phát triển có kĩ năng, bạn có cơ hội tốt hơn để thành công và xây dựng danh tiếng cho công ti của bạn. Bắt đầu từ những cái nhỏ cũng có thể tiết kiệm được tiền bạc bởi vì nếu bạn phạm sai lầm nó sẽ không là thảm hoạ và bạn có thể phục hồi được. Phần lớn mọi người thường bắt đầu công ti bằng việc hội tụ vào khía cạnh kĩ thuật. Đó KHÔNG phải là ý tưởng hay. Là người chủ công ti, bạn phải hội tụ vào khách hàng đầu tiên. Ưu tiên của bạn phải bắt đầu với việc có khách hàng và hiểu yêu cầu của họ. Đây là việc của bạn bởi vì không hiểu nhu cầu của khách hàng và không đáp ứng mong đợi của khách hàng là nguyên nhân chính cho thất bại doanh nghiệp. Bạn phải tiếp xúc với khách hàng, thu được yêu cầu, phân tích và làm tài liệu chúng cẩn thận. Bạn phải trắc nghiệm với khách hàng để chắc rằng bạn hiểu rõ yêu cầu và mong đợi của họ. Khách hàng phải chấp thuận tài liệu yêu cầu trước khi bạn bắt đầu làm bất kì việc nào. Trong khi có nhiều công cụ làm yêu cầu có tính thương mại bán sẵn trên thị trường, để tiết kiệm tiền, tôi gợi ý rằng bạn dùng Microsoft Word hay Excel cho việc làm tài liệu yêu cầu của bạn.”
Anh ta đồng ý: “Điều đó là dễ dàng, phần lớn các máy tính đều tới với Window 7 và Microsoft Office nạp sẵn cho nêm em sẽ không phải chi thêm tiền phụ.”
Tôi tiếp tục: “Nếu khách hàng chấp thuận yêu cầu và kí hợp đồng thì bạn có thể bắt đầu dự án. Với những dự án nhỏ bạn nên dùng cách tiếp cận phát triển Agile bởi vì nó ít rủi ro hơn các phương pháp khác. Bạn có thể tránh rủi ro của thay đổi yêu cầu thường xuyên điều thường xảy ra trong công nghiệp.”
Anh ta gật đầu: “Một ý hay là dùng cách tiếp cận Agile, em biết “Phương pháp Scrum.”
Tôi bảo anh ta: “Trong trường hợp đó, bạn phải chia yêu cầu thành những nhiệm vụ nhỏ hơn dùng kĩ thuật Cấu trúc phân việc (WBS). Bạn cần ước lượng công việc cần được thực hiện, phân công chúng cho người phát triển của bạn và xác định ngày chuyển giao. Với cách tiếp cận Agile dùng Scrum, bạn phải xác định công việc được yêu cầu cho từng đợt nước rút Sprint (2-4 tuần). Bạn có thể dùng Microsoft's Excel để lập kế hoạch công việc và làm tài liệu cho mọi nhiệm vụ. Nếu bạn có dự án lớn hơn, bạn có thể dùng công cụ “Project” của Microsoft. Điều này sẽ cho phép bạn làm một số việc lập kế hoạch lại trong trường hợp thay đổi yêu cầu hay nếu khách hàng quyết định thay đổi một số chức năng vào phút chót. Bạn cũng có thể dùng công cụ “Bugzilla” để theo dõi và ghi lại các lỗi, những nâng cao, hay thay đổi yêu cầu. Bugzilla là chọn lựa phổ biến trong những người phát triển phần mềm và nó dễ dùng với đào tạo tối thiểu.
Anh ta đồng ý: “Em có thể kiếm những công cụ này và để cho người phát triển của em bắt đầu dùng chúng.”
Tôi tiếp tục: “Làm việc tổ trong Agile là rất quan trọng. Trước khi bắt đầu dự án bạn phải đào tạo mọi người phát triển về cách làm việc trong tổ. Cho dù họ có thể đã biết “Scrum”, bạn vẫn cần nhắc nhở họ về cách tiếp cận này và vai trò của họ để chắc không có hiểu lầm nào. Với dự án Scrum, có ba vai trò: Người chủ sản phẩm là người chịu trách nhiệm cho khía cạnh doanh nghiệp của dự án và ra quyết định về sản phẩm. Thầy Scrum người quản lí qui trình phát triển, giúp người phát triển làm việc cùng nhau, tạo điều kiện họp và theo dõi tiến độ và vấn đề. Tổ phát triển người xây dựng ra sản phẩm bằng làm việc cùng nhau để đạt tới mục đích của dự án. Vì dự án của bạn là nhỏ, bạn nên giả định giữ cả vai trò người chủ sản phẩm và thầy Scrum.”
Anh ta gật đầu: “Vâng, em không thể đảm đương được việc có nhiều người chừng nào em còn chưa thể phát triển công ti lên. Gợi ý của thầy rất hợp lí.”
Tôi tiếp tục: “Điều quan trọng là thiết lập việc tách bạch môi trường phát triển, môi trường kiểm thử, và môi trường sản xuất sớm để tránh việc trộn lẫn công việc. Đây là khái niệm đơn giản nhưng tôi đã thấy nhiều công ti nhỏ phạm sai lầm và trộn lẫn công việc của họ với những phiên bản sai, phần mềm đã kiểm thử để cùng phần mềm chưa kiểm thử, cho nên tôi nghĩa đáng nhắc bạn. Bạn phải thiết lập hệ thống kiểm soát nguồn để tạo điều kiện cho qui trình phát triển và lưu trữ mọi công việc đầy đủ. Quản lí cấu hình phần mềm là quan trọng bởi vì là công ti nhỏ, bạn có thể không có qui trình kiểm soát mạnh và những người được chỉ định để thực hiện vai trò quản lí cấu hình. Mọi người phát triển phải hiểu cơ sở về làm sao “Kiểm vào” công việc của họ và “Kiểm ra” khi chúng được thực hiện để tránh dư thừa, khi nào họ làm thay đổi cho phần mềm. Trong khi có một số công cụ sẵn có, bạn vẫn có thể dùng phương pháp thủ công bằng việc để những người phát triển gõ vào tình trạng số hiệu nhiệm vụ như “Mở”, “Đóng” và “Đã phân công” để cho mọi người có thể theo dõi thay đổi một cách dễ dàng. Để tiết kiệm tiền, bạn có thể xem xét dùng công cụ “nguồn mở” như CVS cho quản lí cấu hình. Là công ti nhỏ, bạn không cần phải mua những công cụ đắt tiền nhưng ĐỪNG BAO GIỜ thử tiết kiệm tiền bằng việc giảm đào tạo. Để thành công bạn phải hội tụ vào việc cải tiến kĩ năng của những người phát triển của bạn bằng những đào tạo phụ vì công nghệ thường xuyên thay đổi.”
Anh ta nói: “Em bao giờ cũng nhớ việc dạy của thầy từ nhiều năm trước, học liên tục là chìa khoá cho thành công trong khu vực này.”
Tôi kết luận: “Tôi vui là bạn nhớ điều đó. Phần còn lại của qui trình phát triển là đơn giản. Với từng dự án, bạn sẽ có cuộc họp hàng ngày để phân công công việc cho người phát triển vì bạn xây dựng phần mềm trên cơ sở hàng ngày. Bạn sẽ có những người phát triển viết mã, thực hiện kiểm thử đơn vị, tạo ra trường hợp kiểm thử và các kiểm thử tự động để chạy mọi đêm sau khi phần mềm được dựng ban ngày và kiểm tra các lỗi. Là thầy Scrum, bạn phải giám sát tiến độ trên cơ sở hàng ngày, kiểm tra các lỗi và để chúng được sửa và phải chắc mọi người đang làm nhiệm vụ được phân công của họ một cách tương ứng. Nếu bạn kiểm soát qui trình phát triển đơn giản này tốt thì bạn có thể mong đợi sản phẩm chất lượng cao. Bạn KHÔNG cần mua nhiều công cụ, bạn KHÔNG cần chi tiền vào bất kì cái gì phụ thêm, yếu tố quan trọng là có qui trình đơn giản mà mọi người hiểu và cam kết tuân theo nó cho công việc của họ. Một qui trình có chất lượng KHÔNG phải phức tạp, hay tinh vi mà nó phải được mọi người phát triển hiểu. Chìa khoá để thành công trong cách tiếp cận Agile KHÔNG phải là kĩ thuật mà là làm việc tổ và trao đổi. Bạn phải động viên mọi người thảo luận vấn đề, hỗ trợ lẫn nhau và sẵn lòng giải quyết vấn đề khi chúng tới. Tổ phải có mục đích chung, biết vai trò và trách nhiệm của họ và tuân theo qui trình chất lượng và đạo đức để hỗ trợ cho công ti đạt tới việc thoả mãn khách hàng.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
