Cập nhật nội dung chi tiết về Phương Pháp Phát Triển Phần Mềm: Truyền Thống Và Agile mới nhất trên website Cuocthitainang2010.com. Hy vọng thông tin trong bài viết sẽ đáp ứng được nhu cầu ngoài mong đợi của bạn, chúng tôi sẽ làm việc thường xuyên để cập nhật nội dung mới nhằm giúp bạn nhận được thông tin nhanh chóng và chính xác nhất.
Published on
Phương pháp phát triển phần mềm: Truyền thống và Agile. Cảm ơn anh Ngô Trung Việt chọn lọc, biên dịch và giới thiệu tới cộng đồng.
1. Phương pháp phát triển phần mềm : truyền thống và Agile Anthony Lattanze Câu hỏi đầu tiên trong tâm trí nhiều người có thể là: Khuôn khổ qui trình phát triển phần mềm là gì? Tất nhiên, câu trả lời cho điều này là “Điều này là tuỳ.” Qui trình phát triển là nghi thức chung mà các tổ chức tuân theo để phát triển sản phẩm. Trong khi điều này là áp dụng được nói chung cho bất kì miền chế tạo nào, chúng ta có thể an toàn mà nói rằng qui trình phát triển là nghi thức hay thủ tục chung mà các tổ chức tuân theo để phát triển hệ thống dùng nhiều phần mềm và sản phẩm. Trong phần lớn các năm 1980 cho tới nay, sự hội tụ của các cộng đồng cải tiến qui trình đã từng dồn vào qui trình phát triển phần mềm, cho dù sản phẩm và hệ thống tiến hoá nhiều hơn chỉ phần mềm. Mô hình thác đổ từ Khái MLISTD 2167 Phân niệm hệ tích yêu Phân thống cầu hệ tích yêu Thiết kế thống sơ bộ Thiết kế cầu phần chi tiết Viết mã mềm và kiểm thử đơn Kiểm thử triển vị khai Lẫn lộn chung khác là thuật ngữ vòng đời phần mềm, điều thường được dùng một cách đồng nghĩa để chỉ qui trình phát triển phần mềm. Vòng đời phần mềm có xu hướng rất trừu tượng, mô tả các giai đoạn chung của các dự án phát triển phần mềm. Vòng đời phần mềm còn nhiều hơn phát triển hệ thống hay sản phẩm; nó nói tới con đường từ cái nôi tới nấm mồ mà các yêu cầu được thu thập và phân tích, và phần mềm được phát triển, kiểm thử, triển khải, bảo trì, và cuối cùng cho nghỉ việc. Mô hình vòng đời tương tự, có tên là V-mô hình (Forsberg et al., 1996), tồn tại trong cộng đồng kĩ nghệ hệ thống. Tổ chức tạm thời chung của những pha tổng quát này thường định nghĩa loại vòng đời phần mềm mà một tổ chức dùng. Được tổ chức theo cách này, vòng đời có thể là thác đổ, và theo cách khác nó có thể là lặp hay xoáy ốc. Những vòng đời đa dạng này được mô tả trong Hình 1. Mỗi một trong những vòng đời này phục vụ cho các hoàn cảnh phát triển hệ thống và doanh nghiệp khác nhau. Qui trình thác đổ có thể được dùng trong những tình huống mà các yêu cầu sản phẩm hay hệ thống và các công nghệ được hiểu rõ. Các vòng đời lặp hay xoáy ốc thường được dùng trong hoàn cảnh doanh nghiệp nơi các yêu cầu là biến động, công nghệ không được hiểu rõ, hay cả hai. Theo lí thuyết, việc lặp giúp nhận diện và kiểm soát rủi ro do các yêu cầu biến động hay công nghệ thách thức sớm hơn là cách tiếp cận thác đổ giúp. Các vòng đời phát triển phần mềm lặp dường như là được ưa chuộng nhất ngày nay. 1
2. Xác định mục tiêu, phương án và ràng buộc, Đánh giá phương án nhận diện và giảm Phân tích nhẹ rủi ro rủi ro Phân tích rủi ro Phân tích rủi ro Bản mẫu 1 2 3 Lập kế hoạch yêu cầu Thiết kế Viết mã Lập kế hoạch phát triển Kiểm thử Phát triển và trắc nghiệm lần lặp sản phẩm tiếp Lập kế hoạch V- mô hình kĩ nghệ hệ thống cổ điển Yêu cầu hệ thống Kiểm thử hệ thống Yêu cầu phần mềm Kiểm thử chấp nhận Thiết kế sơ bộ Kiểm thử tích hợp Thiết kế chi tiết Phân tích và thiết kế Kiểm thử cấu phần Kiểm thử đơn vị Xây dựng Hình 1 Mô hình vòng đời tổng quát. 2 Kiểm thử và tích hợp Mô hình xoáy ốc của Boehm
3. Tuy nhiên, trong thực hành, nếu người ta xem xét kĩ càng điều tổ chức thực sự làm khi nó xây dựng hệ thống dùng nhiều phần mềm, một tổ hợp của vòng đời lặp và thác đổ thường được dùng. Một khi thiết kế kiến trúc ổn định, thời kì không chắc chắn qua đi, và cách tiếp cận hướng thác đổ trực tiếp hơn có thể được lấy, hay những lần lặp khác nhau có thể được dùng để xây dựng và triển khai các phiên bản đa dạng của sản phẩm hay hệ thống. Các khuôn khổ qui trình phần mềm cung cấp nhiều chi tiết hơn các mô hình vòng đời tổng quát cung cấp, nhưng dầu vậy vẫn cần được làm thể nghiệm hay điều chỉnh cho các dự án và các tổ chức đặc biệt. Các khuôn khổ qui trình phần mềm tổ hợp các mô hình vòng đời phần mềm tổng quát, nhưng qui định các vai trò, trách nhiệm, vật phẩm, thủ tục, phương pháp, vân vân mà phải được tạo ra khi tuân theo khuôn khổ qui trình này. Các tổ chức thường bắt đầu với một khuôn khổ qui trình phần mềm và điều chỉnh nó theo qui trình phát triển phần mềm đặc biệt của họ. Các qui trình phần mềm của tổ chức được làm thể nghiệm là các khuôn khổ qui trình đặc biệt hơn nhiều và mô tả đặc biệt điều được làm, điều được sản xuất ra, và bởi ai. Các qui trình phần mềm của tổ chức có thể xác định các vai trò đặc biệt, trách nhiệm, vật phẩm, thủ tục, dạng thức tài liệu, khuôn mẫu, chuẩn, vân vân. Xem xét kĩ lưỡng hơn về qui trình phát triển của tổ chức, chúng ta thấy rằng không có một sự liên tục của các hoạt động mà khêu gợi yêu cầu, phân tích các yêu cầu, và làm tài liệu các yêu cầu, thiết kế, vân vân mãi cho tới khi hệ thống hay sản phẩm chạy ra. Xây dựng hệ thống phức tạp dùng nhiều phần mềm không giống như chế tạo theo dây chuyền lắp ráp, điều ít nhiều là sự liên tục của các chất liệu thô đi vào từ đầu này của nhà máy chế tạo và sản phẩm chạy ra từ đầu kia. Các qui trình được tổ chức dùng để phát triển hệ thống dùng nhiều phần mềm giống nhiều với tập các qui trình tách rời nhưng có tương hỗ mà được dùng cùng nhau để phát triển sản phẩm hay hệ thống. Qui trình nặng cân so với nhẹ cân Các cộng đồng cải tiến qui trình truyền thống có nguồn gốc ở trong các mô hình vòng đời thác đổ, cải tiến chất lượng toàn bộ, mô hình hoá trưởng thành năng lực, ISO 9000, Six Sigma, và những vấn đề khác. Nhiều trong các phong trào này bắt đầu từ đầu những năm 1980 khi nhu cầu về phần mềm liên tục mất kiểm soát, và thất bại dự án tăng lên là qui tắc. Điều đó là hiển nhiên bởi việc đưa người thông minh vào một phòng để chọc ngoáy mã trong 12 giờ một ngày sẽ không tất yếu đưa tới hệ thống với chức năng và thuộc tính đặc tính chất lượng mong muốn. Truyền thống dùng các khuôn khổ qui trình để hướng dẫn công việc của người thiết kế và người phát triển, và để cải tiến thực hành, vẫn diễn ra ngày nay. Tính mau lẹ ngày nay là mục nóng trong qui trình phát triển phần mềm. Nếu từ mau lẹ (agile) không xuất hiện trong tiêu đều hay tiêu đề con của một khuôn khổ qui trình, dường như là nó bị khinh rẻ bởi thế hệ mới các kĩ sư xem như “trường phái cổ” và “quá nặng cân.” Tương tự, những người thuần khiết từ các cộng đồng qui trình truyền thống dường như hơi chút nghi ngờ về phong trào qui trình nhẹ cân. Trong thực hành, các cực đoan thường không bao giờ là câu trả lời tốt nhất, và đây chắc chắn là trường hợp trong các tranh cãi qui trình nặng cân và nhẹ cân vẫn nổi lên dữ dội ngày nay. Các cộng đồng cải tiến qui trình truyền thống có xu hướng lấy tài liệu làm trọng tâm và tuỳ thuộc vào các qui trình tổ chức được cấu trúc cao, được xác định nghiêm ngặt, và được tuân theo trung thành để xây dựng hệ thống dùng nhiều phần mềm. Khẳng định là ở chỗ các hệ thống được xây dựng theo cách này có chiều chi phí, lịch biểu và chất lượng sản phẩm dự đoán được nhiều hơn – và có nhiều dữ liệu để hỗ trợ cho khẳng định này. 3
4. Mặc dầu những kiểu các khuôn khổ qui trình truyền thống này đã đóng góp lớn cho cải tiến cách các hệ thống được xây dựng, chúng thường nặng nề nhiều hơn cần thiết trong nhiều tình huống và hoàn cảnh doanh nghiệp. Nhiều trong những khuôn khổ này về nguồn gốc được tạo ra với các dự án lớn của bộ quốc phòng Mĩ trong tâm trí và thường quá tốn kém và rắc rối để cho các tổ chức nhỏ có thể theo được trong xây dựng hệ thống và sản phẩm dùng nhiều phần mềm. Một biện luận khác, mới gần đây là ở chỗ các qui trình nghiêm ngặt có xu hướng làm xơ cứng tính sáng tạo của tổ chức, và có bằng chứng từ các trường hợp nghiên cứu của các tổ chức đa dạng để gợi ý rằng có tính đúng đắn nào đó cho luận cứ này. Một ví dụ tuyệt vời là trường hợp nghiên cứu (Hindo, 2007) mô tả cho thành công nổi bật của công ti 3M trong khả năng của nó để lợi dụng phát kiến công nghệ. Tổ hợp của phát minh doanh nghiệp và cấu trúc công ti lớn thường là sự trộn lẫn bất thường. Các công ti lớn điển hình thấy khó phát kiến, và các công ti nhỏ thường thấy khó đạt tới sản xuất qui mô lớn, dự đoán được, có chi phí-hiệu quả. Tuy nhiên, 3M là công ti đã 100 năm đã tận hưởng danh tiếng là một trong những công ti phát kiến nhất trên thế giới trên hành tinh này, với nhiều thu nhập của nó dựa trên các công nghệ phát kiến mới được phát triển bên trong 3M. Thành công này đã được qui cho môi trường khuyến khích nhận rủi ro và sự dung thứ nào đó cho thất bại như chất xúc tác cho khám phá. Bên trong tổ chức nghiên cứu và phát triển của 3M, các qui trình cực nhẹ cân cho phép các kĩ sư được tự do khám phá các ý tưởng mà không bị nặng gánh hay bị gây sức ép của việc đáp ứng cách đo thống kê và các mục đích hay hạn chót thời gian đưa ra thị trường. Một kĩ sư nghiên cứu của 3M khẳng định rằng 5,000 ý tưởng phải được khảo sát để tìm ra một ý tưởng sẽ sinh lời. Mặc cho bản ghi theo dõi về phát kiến, thay đổi trong cấp quản lí điều hành nảy sinh trong những thay đổi nền tảng cho nghiêng về nhẹ cân và các qui trình phát triển ở 3M. Ông CEO mới, người chủ trương mạnh mẽ về quản lí chất lượng toàn bộ (TQM) và Six Sigma – các khuôn khổ qui trình được dựa vào, đã quyết định thể chế hoá kiểm soát qui trình nghiêm ngặt để đo, quản lí, và cải tiến qui trình phát kiến của 3M. Qui trình kiểm điểm pha nghiêm ngặt được thể chế hoá để thúc đẩy nghiên cứu có hứa hẹn. Dưới qui trình này, nếu một dự án nghiên cứu không cho thấy dẫn đến sản phẩm sinh lời sau khi kiểm điểm, dự án này bị cắt bỏ. Mục đích của loại kiểm soát qui trình này là để tăng tốc, hệ thống hoá, và dịch chuyển phát kiến thành sản phẩm sinh lời được cho thị trường. Mục đích của cấp quản lí là làm phát kiến thành dự đoán được nhiều hơn và có chi phí-hiệu quả. Tuy nhiên, phát kiến và khám phá cần qui trình hỗn độn và không dự đoán được nơi cách đo thống kê thô không cho biết được toàn thể câu chuyện về phát kiến thành công. Chẳng hạn, Post-It Notes đã được phát minh tại 3M là ví dụ cổ điển về chất dính bị thất bại đã tìm thấy thành công trong ứng dụng hoàn toàn không được lập kế hoạch trong Post-It Notes. Post-It Notes đã được dùng một thời gian dài trong các phòng thí nghiệm của 3M trước khi ai đó trong tổ chức này đã hứng khởi đưa nó ra thị trường như một sản phẩm cho người tiêu thụ. Dựa trên mục đích nghiên cứu gốc, điều đã dự định để phát triển chất dính mới, con số thống kê đã chỉ ra chương trình nghiên cứu này là thất bại. Tuy nhiên, thực tại là ở chỗ Post-It Notes khéo léo đã làm nảy sinh thu nhập hàng tỉ đô la cho công ti 3M. Theo các kĩ sư ở 3M, dưới chế độ mới về nghiên cứu có kiểm soát, được giám sát chặt chẽ, chất dính cho Post-It Notes chắc đã bị cắt bỏ từ lâu trước khi Post-It Notes được phát minh và tiềm năng thương mại của nó được khảo sát. Dưới các qui trình mới, dự án nghiên cứu bị cắt bỏ, cái không cho kết quả trong khung thời gian nhất quán với các con số thống kê và bên trong khuôn khổ qui trình được xác định nghiêm ngặt. Mặc dầu thu nhập từ chế tạo sản phẩm hiện có tăng trưởng dưới kiểm soát qui trình nghiêm ngặt, thu nhập từ phát kiến mới tụt thẳng xuống. Việc áp dụng kiểm soát qui trình nghiêm ngặt cho các chức năng nghiên cứu và phát triển làm xơ cứng hiệu quả tính sáng tạo. Thất bại không được dung thứ, vì nó là xấu theo thống kế, và các chi phí khảo sát không 4
5. bị trói buộc mà các con số thống kê đã chỉ ra sẽ không dẫn tới sản phẩm sinh lời đã bị khử bỏ. Về truyền thống, 3M đã là nơi các nhà nghiên cứu được cho phạm vi rộng để theo đuổi nghiên cứu tới chỗ nó đưa tới. Tuy nhiên, nhiều nhà nghiên cứu giỏi nhất đã bỏ 3M để tìm đồng cỏ xanh tươi hơn nơi họ có thể theo đuổi chương trình nghiên cứu của họ trong môi trường không bị trói buộc. Hiệu quả của những thay đổi này là đáng ngạc nhiên. Năm 2004, 3M được xếp hạng thứ nhất trên danh sách các công ti phát kiến nhất của Boston Consulting Group. Nó đã tụt xuống thứ hai trong năm 2005, thứ ba trong năm 2006, và xuống thứ bẩy trong năm 2007. Trước khi chấp nhận kiểm soát qui trình nghiêm ngặt, một phần ba các sản phẩm của 3M đã dựa trên phát kiến mới. Sau khi chấp nhận kiểm soát qui trình nghiêm ngặt, con số này tụt xuống một phần tư. Theo trường hợp nghiên cứu này, kiểm soát qui trình nghiêm ngặt dường như phục vụ cho việc chế tạo các sản phẩm đã thiết lập tốt, nhưng tác động nghiêm trọng tới các tổ chức nghiên cứu và phát kiến bên trong 3M. Với một công ti như 3M, không phát kiến trong phân đoạn thị trường của nó có thể là án tử hình chậm. Xu hướng tiêu cực này tại 3M gần đây đã được CEO mới đề cập tới, người đã loại bỏ nhiều sự cứng nhắc trong các tổ chức nghiên cứu và phát triển bên trong 3M và đã thiết lập lại nhiều thực hành trước đây. Điều này đề cập tới câu hỏi: Tại sao các tổ chức cứ nhấn mạnh vào những cực đoan: nhẹ cân hay nặng cân, kiểm soát cao hay kiểm soát mặc kệ cho làm? Dường như là không có chỗ cho cả hai hay mảnh đất ở giữa. Trường hợp nghiên cứu này (và những trường hợp tương tự) sẽ dường như chỉ ra rằng kiểm soát cao, các qui trình nặng cân có thể có chỗ trong sản xuất thường lệ và môi trường chế tạo, nhưng không có chỗ trong môi trường động, hướng phát kiến. Sao không áp dụng cả hai? Sự nổi dậy nhỏ chống lại các khuôn khổ qui trình hướng thác đổ nguyên khối đã bắt đầu từ giữa những năm 1980, đặc biệt trong các tổ chức năng động nhỏ hơn. Nhưng cho dù các tổ chức này nhận ra rằng họ quá cần các qui trình có kỉ luật hơn nào đó, và vấn đề chọc ngoáy hệ thống không thể thức có thể là đơn thuốc cho thảm hoạ. Điều này dẫn tới việc thám hiểm các khuôn khổ qui trình thay thế mà có thể cung cấp đủ qui trình cho các tổ chức năng động, nhỏ hơn trong xây dựng hệ thống dùng nhiều phần mềm. Một xem xét quan trọng khác của nhiều người nghiên cứu là tạo ra khuôn khổ qui trình đảm đương được mà có thể dễ dàng được chấp nhận và rẻ. Phải tốn kém nhiều tiền, nỗ lực, thời gian, và tài nguyên để phát triển, thể chế hoá, dịch chuyển, đo và bảo trì các khuôn khổ qui trình kiểm soát cao, nặng cân. Những chi phí này đã là, và vẫn là vấn đề chính cho các tổ chức công nghệ cao nhỏ hơn. Một khuôn khổ qui trình đã nổi lên vào giữa những năm 1980 làm thay đổi cách các kĩ sư nghĩ về các khuôn khổ qui trình phát triển. Phát triển ứng dụng nhanh (RAD) bùng nở trên khung cảnh công nghệ vào những năm 1980 và là ông tổ của khuôn khổ qui trình agile (uyển chuyển) điều sinh sôi nảy nở ngày nay (Martin, 1991). Mặc dầu chỉ có một đám nhỏ những tín đồ và phần lớn không được các cộng đồng thời đó về qui trình trên máy tính lớn tin tưởng, RAD đã gieo hạt mầm mà vẫn đem lại kết quả ngày nay. Tại lõi của nó, RAD đã dùng mô hình vòng đời xoáy ốc mà đã được Boehm lí thuyết hoá trong bài báo bước ngoặt của ông ấy (Boehm, 1986). Tuy nhiên, RAD đã vận hành hoá khái niệm này trong một khuôn khổ cụ thể hơn mà các tổ chức có thể làm thể nghiệm và duy trì một cách nhanh chóng, dễ dàng và rẻ. Trong suốt cuối những năm 1980 và đầu những năm 1990, các mô hình như Mô hình trưởng thành năng lực (Paulk et al., 1995) đã chi phối, nhưng các khuôn khổ qui trình nhẹ cân dần dần và vững chắc thu được mảnh đất và nhiều uy tín hơn. Dịch chuyển này từ các khuôn khổ qui trình nặng cân sang nhẹ cân có thể được qui cho sự kiện là những nhà sản xuất và tiêu thụ phần mềm lớn nhất trên toàn thế giới trong những năm 1980 là chính phủ Mĩ, và nói riêng là Bộ quốc phòng Mĩ. Hệ thống dùng nhiều phần mềm thường phức tạp, siêu qui mô và được xây dựng bởi lực lượng lao động phân bố cao. Điều này cần việc dùng các qui trình rất 5
11. Thay vì tạo ra lịch biểu đầy đủ trước thời gian, tôi thích dùng cách tiếp cận lặp bằng viết thiết lập lịch biểu một tuần vào mỗi lúc, nơi các thành viên tổ đều tham gia để cho tôi biết họ có thể hoàn thành được cái gì vào tuần đó. Một khi họ đã đạt tới một cột mốc, đó là lúc ước lượng và lập kế hoạch sang cột mốc tiếp. Việc cả tổ tham gia vào ước lượng lịch biểu là tốt hơn nhiều so với ước lượng riêng của các cá nhân. Tôi đòi hỏi từng thành viên tổ phải đưa ra ước lượng riêng của họ và dùng cách tiếp cận “Delphi băng rộng” hay cách tiếp cận trung bình để đi tới lịch biểu toàn thể. Khi bạn cho phép mọi người tạo ra ước lượng riêng của họ, họ có xu hướng theo dõi mình, đi theo mình, và cố gắng làm cho nó được hoàn thành thành công bởi vì ước lượng của họ là một phần công việc của họ. Bởi vì các dự án agile đều nhỏ, bạn phải tích hợp các công việc liên tục, không thành vấn đề bạn đang làm cái gì (mã, kiểm thử, tài liệu, kế hoạch). Bạn phải có người làm quản lí cấu hình phần mềm để giúp thiết lập cấu hình và phiên bản đúng cho phần mềm của bạn vì công việc thường xuyên thay đổi. Khi phiên bản cuối cùng được kiểm đưa vào, và tôi biết trạng thái nó tới trong nó và tôi không phải nghĩ về nó. Ai đó hỏi tôi, nếu agile là hoạt động toàn tổ, có thực sự cần người quản lí dự án không? Câu trả lời của tôi là dứt khoát “Có.” Tuy nhiên, vai trò của người quản lí dự án trong phương pháp agile mang nhiều tính người lãnh đạo và thầy kèm chứ KHÔNG kiểm soát như được dạy trong hầu hết các giáo trình quản lí dự án. Bạn càng cung cấp nhiều hướng dẫn và hỗ trợ cho tổ, họ sẽ càng có kết quả hơn. Bạn càng thực hành cách tiếp cận cộng tác này, bạn càng linh hoạt hơn như một người quản lí dự án, điều làm cho bạn thành người quản lí giỏi hơn. Bạn KHÔNG ra lệnh cho họ, bạn KHÔNG chỉ đạo họ, bạn KHÔNG chỉ huy họ, bạn KHÔNG đe doạ họ mà bạn là người hướng dẫn họ, ai đó mà họ tin cậy và ai đó giúp cho họ làm công việc của họ. Về căn bản, bạn là người lãnh đạo của họ và người lãnh đạo KHÔNG phải là ai đó có thẩm quyền trên họ mà là ai đó họ sẵn lòng đi theo. Dự án agile thành công có hai yếu tố then chốt: Người lãnh đạo là người quản lí dự án và tổ có kinh nghiệm và có kỉ luật. Không có hai yếu tố này, nó sẽ là khó. Câu hỏi của tôi là “Là người quản lí dự án, bạn có sẵn lòng thay đổi để trở thành người lãnh đạo giỏi hơn không?” và “Là thành viên tổ, bạn có đủ kinh nghiệm và kỉ luật để áp dụng phương pháp agile vào công việc của bạn không?” 11
Quản Lý Dự Án Theo Phương Pháp Truyền Thống Hay Phương Pháp Agile
Trong vài năm qua, có một vài xu hướng mới khi nói đến cách khách hàng quản lý các dự án của họ. Ngay cả với những dự án không phải là phát triển phần mềm, xu hướng ổn định nhất vẫn là áp dụng phương pháp Scrum. Liệu xu hướng này là đúng đắn? Các công ty và nhà quản lý đã thực sự hiểu rõ con đường mình đang đi? Chúng ta sẽ tìm ra câu trả lời trong bài viết này.
Để phục vụ cho bài viết, tôi đã xem qua những đặc điểm của phương pháp quản lý dự án truyền thống (TPM) trong cuốn Hướng dẫn về những kiến thức cốt lõi trong Quản lý dự án (PMBOK) do Viện Quản lý Dự án (PMI) công bố. Trong khi PMI không đưa ra một tên gọi cụ thể nào cho phương pháp quản lý dự án truyền thống, thì hầu hết các công ty vẫn thường gọi đó là waterfall (thác nước) – mỗi giai đoạn của dự án sẽ được chuyển đến giai đoạn tiếp theo (sau khi đã kết thúc hoàn toàn thành công công việc) giống như dòng chảy của thác nước và chỉ chảy theo một hướng, không thể quay lui về giai đoạn trước hay nhảy vượt giai đoạn (rõ ràng thì trong một thác nước nước không thể chảy ngược). Đó là một trong nhiều lý do khiến nhiều công ty ào ạt chuyển sang áp dụng phương pháp Agile – bởi với Agile, họ không thể chống lại được sự quyến rũ của kết quả công việc nhanh hơn, chi phí thấp hơn, và sẽ không có biểu đồ Gantt nữa!
Bài học số 1: Agile/Scrum khác một dự án không có kế hoạch
Để hiểu tại sao nhiều công ty phải vật lộn để chuyển đổi bằng được cách thức quản lý dự án, trước hết chúng ta cần phải hiểu được một vài điểm khác biệt cơ bản giữa TPM (Phương pháp quản lý dự án truyền thống) và Agile/Scrum cũng như những thách thức mà người quản lý phải đổi mặt. Phương pháp truyền thống chọn cách tiếp cận một kế hoạch theo định hướng và tập trung vào hoạt động để quản lý dự án. Điều này dẫn đến một loạt các quá trình có đầu vào và đầu ra khác nhau. Người quản lý phải đảm bảo rằng việc bàn giao dự án trung gian đều phải được lập kế hoạch và thực hiện ở các giai đoạn khác nhau của dự án. So sánh với quá trình phát triển Agile, thì trong suốt vòng đời của một dự án, Agile nhấn mạnh việc tạo ra những kết quả hữu hình càng sớm, càng thường xuyên thì càng hiệu quả và chú trọng việc quản lý mối quan hệ, tạo điều kiện tương tác giữa các thành viên trong nhóm quản lý dự án. Điều này có nghĩa là vai trò của một người quản lý dự án Agile hoàn toàn không giống với một người quản lý dự án TPM. Tuyên ngôn của Agile (The Agile Manifesto) thừa nhận sự cần thiết của việc chuyển giao kết quả trung gian, nhưng không nhấn mạnh vai trò của người quản lý trong việc tạo ra hoặc kiểm soát chúng.
Quá trình chuyển đổi từ TPM sang Agile quả thực là một quá trình khó khăn đối với nhiều nhà quản lý dự án. Sự chuyển đổi này thường thì không thay đổi được bản chất (áp dụng phương pháp kế hoạch theo định hướng nhưng lại gọi nó là Scrum bởi các cuộc họp nhóm diễn ra hằng ngày thay vì một cuộc họp báo cáo tình hình dự án theo giai đoạn), hoặc họ mặc định Agile/Scrum nghĩa là không có kế hoạch. Có một sự khác biệt lớn giữa việc không có kế hoạch và lên kế hoạch cho những gì bạn biết và có thể thực hiện trong một thời gian nhất định.
Bài học số 2: Biết được sự khác biệt
1. Kế hoạch hóa so với tập trung vào giá trị
Agile/Scrum đưa ra cách tiếp cận hướng tới giá trị trong khi TPM lại hướng tới mục tiêu để lên kế hoạch cho toàn bộ dự án. Điều này không có nghĩa là một dự án Agile/Scrum thì không có kế hoạch. Với Scrum, mỗi phân đoạn đều có một kế hoạch, nhưng các kế hoạch tập trung vào việc ưu tiên các tính năng mang lại giá trị nhất. Điều này hoàn toàn khác với TPM, nơi một kế hoạch hoàn chỉnh được tạo ra trước khi đi vào chi tiết hoạt động và nhiệm vụ cần thiết cho dự án.
2. Tiên đoán so với Thực nghiệm
Quản lý dự án truyền thống sử dụng phương pháp tiên đoán, có nghĩa là ban giám đốc sẽ dự đoán kết quả có thể đạt được dựa trên các giả định, để từ đó xây dựng một kế hoạch “trả trước” và một khi kế hoạch này được thiết lập, yêu cầu thay đổi phải được đánh giá theo từng trường hợp. Việc thiết kế được khuyến cáo là không nên thay đổi sau khi kế hoạch đã được chấp thuận, và việc sản xuất, phát triển không nên bắt đầu cho đến khi thiết kế hoàn tất. Điều này hoàn toàn khác biệt so với Scrum, theo Jeff Sutherland, đồng sáng tạo ra Scrum, ” Thực hiện một phương pháp thực nghiệm dựa trên lý thuyết kiểm soát quá trình”. Đó là cách mọi người ưa thích khi nói về việc các Scrum Master và nhóm nghiên cứu cần thích ứng với kết quả hiện tại và của các sprints trước đó để điều chỉnh các mục tiêu về năng suất và thực hiện thay đổi để tăng tốc độ dự án. Mỗi iteration (phân đoạn lặp) được điều chỉnh dựa trên dữ liệu từ sprint trước đó và phải tập trung làm thế nào để mang lại nhiều giá trị hơn trong sprint tiếp theo.
3. Cấp trên quản lý so với nhóm tự quản
Một trong những vai trò căn bản của một người quản lý dự án truyền thống là phải tích cực tổ chức và sắp xếp sao cho hợp lý đội ngũ của mình, phân công các vai trò và trách nhiệm cho mỗi thành viên trong dự án. Còn một Scrum Master sẽ lùi lại và cho phép nhóm tự tổ chức. Người quản lý dự án phải tạo điều kiện, cung cấp môi trường để nhóm tự giao tiếp và thực hiện công việc.
5. Lập kế hoạch từ dưới lên so với trên xuống
Quản lý dự án truyền thống theo hướng lập kế hoạch từ dưới lên, có nghĩa là một dự án được lên kế hoạch ngay từ đầu bằng cách lên chi tiết các công việc của mỗi cá nhân trong Cơ cấu phân chia công việc (Work Breakdown Structure – WBS), từ đó dẫn đến một kế hoạch dự án hoàn chỉnh trước khi bắt đầu dự án. Scrum thì ngược lại, nó theo hướng lập kế hoạch từ trên xuống, nghĩa là một lộ trình được phát triển trong giai đoạn đầu của dự án được xây dựng dần dần thành các phân đoạn release (bản phát hành) và sprint (phân đoạn).
Bài học 3: Học cách để triển khai
Có một vài thói quen và thủ tục của TPM dường như không thể phá vỡ được. Một người quản lý dự án sẽ cần phải loại bỏ những thói quen này nếu họ muốn đi tới thành công của quá trình chuyển đổi. Mặc dù việc này thì khá đơn giản, nhưng hầu hết các công ty lại không muốn từ bỏ thói quen này vì sợ hãi. Mặc dù đây là nguyên nhân khiến cho một dự án TPM không đem lại được hiệu quả, nhưng những thói quen này dường như rất dễ nhận thấy trong các giải pháp Agile mà nhiều công ty thực hiện. Việc loại bỏ những thói quen của cách quản lý truyền thống là điều cực kỳ quan trọng để các nhà quản lý dự án có thể xây dựng được lòng tin nơi tổ chức của mình. Giả pháp là nên thí điểm Agile ở một dự án nhỏ hoặc sử dụng một phương pháp tạm thời đã được cân nhắc kỹ lưỡng. Thông thường, ta không thể thoát khỏi những thói quen cũ cho đến khi toàn bộ đội ngũ đã hiểu các triết lý Agile và sẵn sàng đón nhận chúng.
Thói quen #1 – Lập kế hoạch trước mọi thứ
Thói quen #2 – Quản lý và quản lý
Một dự án Scrum cơ bản là một dự án mà nhóm phát triển được trao quyền để đưa ra quyết định vì chủ sản phẩm cũng là một phần của quá trình. Bằng việc tước đi quyền tự ra quyết định và thay đổi của đội ngũ làm việc, nhiều tổ chức đang tự khiến cho dự án trở nên không có hiệu quả. Nếu một nhóm dự án không có quyền đưa ra quyết định, không đưa thêm một mục đề nghị cần thực hiện cho ban lãnh đạo vào tháng tới thì họ vẫn chưa được cho phép để thành công.
Thói quen số #3 – Thời gian, Phạm vi hoặc Ngân sách
Quản lý dự án truyền thống giới thiệu khái niệm về Bộ ba ràng buộc: Thời gian, Phạm vi và Ngân sách. Quản lý dự án “Tam giác sắt” phải được ban giám đốc quản lý chặt chẽ trong TPM. Trong một dự án Scrum, thời gian và chi phí được cố định (“time boxed”) trong mỗi chu trình sprint và phạm vi được xác định bởi chính nhóm quản lý và bị khoá ngay khi bắt đầu một sprint mới. Vai trò của người quản lý trong Scrum không phải là quản lý và thiết lập chúng. Đây sẽ là một cuộc vật lộn thật sự cho một số người quản lý dự án vì lợi ích các nhân để luôn cố mở rộng phạm vi, cắt giảm ngân sách hoặc rút ngắn thời hạn công việc. TPM cho phép quản lý dự án đánh giá những yêu cầu thay đổi và xử lý chúng, điều này thường dẫn đến những biện pháp chữa cháy và khoa trương, khiến cho kế hoạch dự án không còn được triển khai như ban đầu. Trong một dự án Agile/Scrum, chủ sản phẩm phải buông bỏ điều này và đồng ý cam kết phạm vi công việc trong quá trình lên kế hoạch sprint. Rủi ro sẽ giảm theo thời gian của chu trình sprint, do đó tiến trình có thể được thay đổi vào cuối chu trình sprint, thay vì quay lại giai đoạn thiết kế sau 6 tháng.
Kết luận
Các công ty đang cố gắng trở nên “Agile” hơn bằng cách áp dụng khái niệm Agile/Scrum cho dự án phát triển phi phần mềm. Mặc dù các khái niệm này có thể làm giảm nhiều điểm gây tổn thương mà họ đã phải giải quyết trong nhiều năm qua và Agile có vẻ rất minh bạch, thì điều quan trọng vẫ là đừng để bị lừa bởi tính đơn giản của cuốn Scrum Guide- Hướng dẫn áp dụng phương pháp Scrum (chỉ là 17 trang thôi mà!) hoặc nghĩ rằng bạn chỉ việc áp dụng các khái niệm dễ dàng mà không cần đánh giá chu đáo các nguyên tắc cơ bản. Các doanh nghiệp nên xem xét các vấn đề mà họ đang phải cố gắng giải quyết bằng cách chuyển sang áp dụng Agile / Scrum, liệu TPM có vấn đề hay vấn đề thực sự nằm ở nội bộ công ty? Nếu là lý do thứ hai, thì Agile/Scrum sẽ không phải là thần dược. Có rất nhiều cạm bẫy trên con đường chạm đến Agile/Scrum, việc bạn kém hiểu biết nhưng vẫn cố chấp áp dụng Scrum có thể sẽ tồi tệ hơn nhiều lần việc chưa làm tốt các phương pháp quản lý dự án truyền thống. Vậy hãy cẩn trọng với quyết định của mình.
Source: chúng tôi
Phương Pháp Luận Phát Triển Hệ Thống Thông Tin
Phương Pháp Luận Phát Triển HTTT Faculty of MIS GV: LÊ THỊ QUỲNH NGA Nội Dung Tại sao cần phát triển HTTT Nội dung cơ bản của phát triển HTTT Tiến hóa cách tiếp cận phát triển HTTT Vòng đời phát triển HTTT Các phương pháp khác phát triển HTTT Xây dựng thành công HTTT Sơ đồ tổng quát quá trình phân tích thiết kế HTTT Tại sao cần phát triển HTTT Có ~ vấn đề cản trở/hạn chế Tạo ưu thế mới, năng lực mới Do yêu cầu của đối tác Xây dựng HTTT ko chỉ là giải pháp kỹ thuật mà là 1 bộ phận quan trọng trong chiến lược tổng thể phát triển tổ chức cần lộ trình chuyển dịch tổ chức về TC & QL Nội dung cơ bản của phát triển HTTT Phương pháp luận phát triển HT: các hoạt động phát triển & trình tự thực hiện Phương pháp, công nghệ & công cụ sử dụng tổ chức & QL quá trình phát triển HTTT Tiến hóa cách tiếp cận phát triển HTTT Tiếp cận hướng tiến trình Tiếp cận hướng dữ liệu Tiếp cận hướng cấu trúc Tiếp cận hướng đối tượng Vòng đời phát triển HTTT Systems Development Life Cycle (SDLC) Quá trình phát triển HTTT kể từ khi sinh ra đến khi tàn lụi Là phương pháp luận cho phát triển, duy trì & thay thế HTTT Các pha SDLC: Khởi tạo & lập kế hoạch (Planning) Phân tích (Analysis) Thiết kế (Design) Triển khai (Implementation) Vận hành & bảo trì (Maintenance) Quan điểm về SDLC Khởi tạo & lập kế hoạch (Planning) Xác định, phân tích, định độ ưu tiên & sắp xếp nhu cầu về HTTT Phân tích (Analysis) Điều Nghiên & mô hình hóa yêu cầu HT Thiết kế (Design) Chuyển đổi giải pháp đề nghị thành các đặc tả HT Thiết kế Logic: Các đặc trưng được mô tả độc lập với công nghệ máy tính Thiết kế vật lý: Các đặc tả logic được chuyển thành các chi tiết cụ thể gắn với công nghệ Triển khai (Implementation) Viết chương trình, thử nghiệm, cài đặt & hỗ trợ HTTT Vận hành & bảo trì (Maintenance) Sửa đổi & cải tiến HTTT 1 cách có HT Chu kỳ sống phát triển HT truyền thống Waterfall 1 pha bắt đầu khi pha khác hoàn tất, lặp & quay về ít Vấn đề với cách tiếp cận Waterfall Yêu cầu HT bị khoá chặt sau khi đã xác định (ko thể thay đổi) Sự tham gia của Người dùng bị giới hạn (chỉ trong giai đoạn xác định yêu cầu) Tập trung quá nhiều vào các điểm đến hạn của các pha SDLC Các phương pháp khác phát triển HTTT Phương pháp làm bản mẫu (Prototyping) Phương pháp thiết kế ứng dụng liên kết (Joint Application Design (JAD)) Phương pháp phát triển ứng dụng nhanh (Rapid Application Development (RAD)) Phương pháp làm bản mẩu (Prototyping) Tiến trình phát triển lặp: Các yêu cầu nhanh chóng chuyển thành HT làm việc HT được sửa đổi liên tục Hợp tác gần gũi giữa người dùng & người phân tích Phương pháp thiết kế ứng dụng liên kết (Joint Application Design (JAD)) Tiến trình có cấu trúc bao gồm sự tham gia của người dùng, nhà phân tích, & nhà quản lý Các phiên làm việc theo nhóm tập trung trong vài ngày Mục đích: để xác định hay xem xét yêu cầu HT Phương pháp phát triển ứng dụng nhanh (Rapid Application Development (RAD)) Giảm thời gian thiết kế & triển khai Bao gồm: prototyping, JAD, CASE tools, & Bộ tạo chương trình (code generators) Xây dựng thành công HTTT Có hiệu quả góp phần nâng cao chất lượng hoạt động QL tổng thể Đạt mục tiêu thiết kế Chi phí vận hành chấp nhận được Tin cậy, đáp ứng các chuẩn mực dễ học, dễ nhớ & dễ dùng Mềm dẻo, dễ bảo trì Sơ đồ tổng quát quá trình phân tích thiết kế HTTT Khảo sát hiện trạng HT Xác định mô hình nghiệp vụ: mô tả TT TC Phân tích HT & đặc tả yêu cầu: mô hình DFD, mô hình ERD Thiết kế HT: logic & vật lý Sơ đồ tổng quát quá trình phân tích thiết kế HTTT Khảo sát hiện trạng HT: Hồ sơ, tài liệu khảo sát, tổng hợp Xác định yêu cầu (mô hình nghiệp vụ): mô tả TT TC Sơ đồ ngữ cảnh, sơ đồ phân rã chức năng DS các thực thể DL các ma trận phân tích mô tả chi tiết các chức năng nghiệp vụ, sơ đồ ngữ cảnh miền nghiên cứu, sơ đồ phân rã chức năng rút gọn, chi tiêt DS thực thể DL rút gọn, tự điển DL Sơ đồ tổng quát quá trình phân tích thiết kế HTTT Phân tích HT & đặc tả yêu cầu (mô hình khái niệm): mô tả chi tiết tiến trình, mô hình DFD vật lý, mô hình ERD, tự điển dữ liệu Thiết kế logic (mô hình logic) Đặc tả logic mỗi tiến trình, DFD logic ở các mức, thiết kế biểu mẫu, báo cáo Mô hình dữ liệu quan hệ, tự điển dữ liệu Thiết kế vật lý (mô hình vật lý) Đặc tả module chương trình, đặc tả cấu trúc hệ thống, Đặc tả tương tác, giao diện Đặc tả CSDL vật lý, thiết kế an toàn & bảo mật hệ thống
Phương Pháp Xác Định Chi Phí Sản Xuất Truyền Thống (Phần 1)
Phần 1: Phương pháp xác định chi phí sản xuất sản phẩm theo công việc (Đơn đặt hàng)
1. Đối tượng áp dụng:
Phương pháp xác định chi phí sản xuất sản phẩm theo công việc thường được vận dụng tại các doanh nghiệp sản xuất kinh doanh sản phẩm dịch vụ theo đơn đặt hàng, quy trình công nghệ sản xuất khép kín. Để áp dụng phương pháp này thì sản phẩm thường có những đặc điểm sau
Sản phẩm mang tính chất đơn chiếc, do sản xuất theo đơn đặt hàng của khách hàng như: bưu thiếp, công trình xây dựng…
Sản phẩm thường có giá trị cao như: kim loại quý, đá quý, máy bay, tàu biển…
Sản phẩm thường có kích thước lớn, gắn liền với những yêu cầu kỹ thuật, tính thẩm mĩ và thường thông qua bản thiết kế kỹ thuât, dự toán chi phí, VD: công trình xây dựng, đồ gỗ làm theo đơn đặt hàng của khách…
Tóm lại, phương pháp xác định chi phí theo công việc được áp dụng cho những sản phẩm được thực hiện theo đơn đặt hàng và theo yêu cầu của từng khách hàng riêng biệt. Sản phẩm dễ nhận diện, có giá trị caio và cí kích thước lớn. Phương pháp này thường áp dụng trong các doanh nghiệp xây dựng, sản phẩm là các công trình, hạng mục công trình, hạng mục công trình, các doanh nghiệp thiết kế, khảo sát, dịch vụ sửa chữa ô tô…
2. Nội dung và quá trình tập hợp chi phí sản xuất sản phẩm theo công việc
Để tập hợp chính xác và đúng đối tượng chi phí theo công việc, kế kế toán cầ phải nắm chắc được trình tự công việc phải thực hiện:
Căn cứ vào nhu cầu của khách hàng về đơn đặt hàng cho doanh nghiệp thông qua các đặc điểm chi tiết của sản phẩm, dịch vụ. Từ đó doanh nghiệp mới dự toán tài chính cho đơn đặt hàng và đưa ra quyết định giá bán cho phù hợp.
Quá trình tập hợp chi phí sản xuất theo đơn đặt hàng thường được tiến hành theo sơ đồ sau:
Thông thường mỗi sản phẩm gồm ba khoản mục chi phí sản xuất chủ yếu sau:
Chi phí nguyên vật liệu trực tiếp.
Chi phí phân công trực tiếp.
Chi phí sản xuất chung hay gọi chi phí phân xưởng, đội sản xuất.
Theo phương pháp tập hợp chi phí theo công việc đối tượng được tập hợp chi phí là sản phẩm hay đơn đặt hàng của khách. Từ các chứng từ kế toán chi phí, kế toán tập hợp theo các đối tượng sản phẩm hay đơn đặt hàng.
Theo mô hình này, chi phí nguyên vật liệu được xác định trên cơ sở phiếu xuất kho nguyên vật liệu sử dụng trực tiếp không qua nhập kho. Chi phí nhân công trực tiếp, được xác định dựa trên bảng chấm công của công nhân hoặc phiếu giao nhận sản phẩm, hợp đồng giao khoán công việc. Chi phí sản xuất chung được xác định theo mức phân bổ dự toán, mức phân bổ chi phí sản xuất chung thường được xác định như sau:
Mức phân bổ chi phí sản xuất chung ước tính cho đơn hàng 1:
Mức độ hoạt động ước tính tuỳ thuộc vào đặc điểm kinh doanh của từng doanh nghieeph để luwacj chọn, có thể là số giờ lao động trực tiếp của công nhân, chi phí nguyên vật liệu trực tiếp, chi phí nhân công trực tiếp…
Tất cả các chi phí sản xuất được tập hợp vào phiếu chi công việc hoạc đơn đặt hàng là một chứng từ chi tiết dùng để tổng hợp các chi phí sản xuất phát sinh khi đơn đặt hàng được thực hiện. Phiếu tập hợp chi phí sẽ được lưu tại phân xưởng sản xuất trong quá trình sản xuất, sau đó là căn cứ để tính tổng giá thành sản phẩm, dịch vụ hoàn thành trong kỳ. Thông thường phiếu tập hợp chi phí theo công việc thường có mẫu sau:
Phiếu xuất kho nguyên vật liệu ;à căn cứ để tập hợp chi phí vật liệu chính, phụ cho từng đơn đặt hàng.
Phiếu theo dõi lao động, giao nhận sản phẩm, hợp đồng giao khoán công việc là căn cứ để xác định chi phí nhân công trực tiếp cho từng đơn đặt hàng. Mức phân bổ ước tính của chi phí nhân công trực tiếp cho từng đơn đặt hàng.
Mức phân bổ ước tính của chi phí sản xuất chung.
Chi phí sản xuất chung thường là các khoản chi phí hỗn hợp vừa mang tính chất định phí, vừa mang tính chất biến phí và phát sinh từ khi phân xưởng bước vào sản xuất cho tới khi phân xưởng kết thúc quá trình sản xuất. Do vậy xác định chi phia sản xuất chung cho một đơn vị sản phẩm khó chính xác trong giai đoạn đầu tiên vì thế ta thường phân bổ theo chi phí sản xuất chung ước tính sau đó điều chỉnh.
Ví dụ 1: Xí nghiệp sửa chữa ô tô 19-5 đang thực hiện 4 đơn hàng của khách hàng, kế toán tập hợp chi phí sảm xuất như sau: (đvt: ngàn đồng).
Tên đơn đặt
hàng
Chi phí nguyên vật
liệu trực tiếp
Chi phí nhân
công trực tiếp
Tổng cộng Đơn 1 2.000 14.000 16.000 Đơn 2 52.000 106.000 158.000 Đơn 3 24.000 18.000 4.000 Đơn 4 8.000 2.000 10.000 Tổng cộng 86.000 140.000
Chi phí sản xuất chung dự toán và chi phí phát sinh như sau:
Yếu tố chi phí Theo dự toán Thực tế phát sinh 1. Biến phí sản xuất chung 192.000 a. Nguyên vật liệu phụ 32.000 30.000 b. Tiền lương 112.000 106.000 c. Dịch vụ mua ngoài 48.000 46.000 2. Định phí sản xuất chung 64.000 a. Lương quản đốc 40.000 40.000 b. Chi phí khấu hao 24.000 24.000 Tổng cộng 256.000 246.000
Dự toán chi phí nhân công trực tiếp: 160.000, hệ số phân bổ chi phí sản xuất chung là:
256.000:160.000 = 1,6
Chi phí sản xuất sản phẩm dở dang của đơn đặt hàng 1 là: 70.500 trong đó nguyên vật liệu : 17.500, nhân công trực tiếp là 22.000, sản xuất chung : 31.000.
Yêu cầu:
1. Xác định chi phí sản xuất chung phân bổ thừa (thiếu)?
2. Giả thiết 3 đơn đặt hàng (Đơn 2,3,4) không hoàn thành, hãy xác định giá vốn hàng bán?
3. Giả thiết 2 đơn hàng (Đơn 2,3,4) không hoàn thành, hãy xác định sản phẩm dở dang cuối kỳ?
4. Giả thiết chi phí sản xuất chung trong năm phân bổ thiếu 22.000, nếu phần này được phân bổ cho giá vốn hàng bán và SPDD theo chi phí đã tính, thì lượng phân bổ là bao nhiêu
Bải giải:
1. Xác định chi phí sản xuất chung phân bổ thừa (thiếu)?
Chi phí sản xuất chung thực tết phát sinh: 246.000
Chi phí sản xuất chung đã phân bổ: 140.000 x 1,6 = 224.000
Chi phí sản xuất chung phân bổ tối thiểu: 22.000
2. Giá vốn hàng bán của Đơn 1:
Chi phí sản xuất sản phẩm dở dang đầu kỳ: 70.500
Chi phí NVTTT và NCTT phát sinh trong kỳ: 16.000
Chi phí sản xuất chung phân bổ: 14.000 x 1,6 = 22.400
Vậy giá vốn bán hàng Đơn 1: 108.900
3. Giả thiết 3 đơn hàng (Đơn 2,3,4) không hoàn thành, hãy xác định sản phẩm dở dang cuối kỳ?
Khoản mục chi phí Đơn 2 Đơn 3 Đơn 4 Tổng cộng 1. Chi phí nguyên vật liệu trực tiếp 52.000 24.000 8.000 84.000 2. Chi phí nhân công trực tiếp 106.000 18.000 2.000 126.000 3. Chi phí sản xuất chung 169.600 28.800 3.200 201.600
4. Tổng cộng chi phí sản xuất
sản phẩm dở dang
327.600 70.800 13.200 411.600
4. Giả thiết chi phí sản xuất chung trong năm phân bổ tối thiểu 22.000, nếu phần này được phân bổ cho giá vốn hàng bán và SPDD theo chi phí đã tính, thì lượng phân bổ là bao nhiêu?
Mức chi phí sản xuất chung phân bổ thêm cho GVHB: (22.000 x 108.900)/(108.900 + 411.600) = 7.646
Mức chi phí sản xuất chung phân bổ thêm cho sản phẩm dở dnag cuối kỳ: 22.000 – 7.646 = 14.354
3. Quá trình phản ánh chi phí sản xuất vào sổ sách:
Phương pháp tập hợp chi phí theo công việc sử dụng các tài khoản sau đây để phản ánh chi phí sản xuất từ khi phát sinh cho đến khi hoàn thành:
Chi phí nguyên vật liêu trực tiếp
Chi phí nhân công trực tiếp
Chi phí sản xuất chung
Chi phí sản xuất kinh doanh dở dang và tài khoản” Thành phẩm” để phản ánh giá trị hoàn thành; tài khoản “giá vốn hàng bán” để phản ánh giá vốn của thành phẩm tiêu thụ ngay.
Về nguyên tắc, chi phí nguyên vật liệu trực tiếp, chi phí nhân công trực tiếp và mức phân bổ chi phí sản xuất chung được hạch toán vào tài khoản: Sản phẩm dở dang. Đồng thời các khoản chi phí này cũng được phán ánh vào các phiếu chi phí công việc tương ứng. Song song với quá trình vận động của chi phí qua các tài khoảnchữ T là sự vận động của các phiếu chi phí công việc tương ứng quá các khâu sản xuất và tiêu thị.
Bên nợ TK chi phí sản xuất chung phản ánh chi phí thực tế phát sinh gồm chi phí nhân viên phân xưởng, chi phí vật liệu, công cụ, dụng cụ, chi phí khấu hao TSCĐ, dịch vụ mua ngoài…dùng trong phân xưởng…
Bên có TK chi phí sản xuất chung phản ánh chi phí sản xuất chung được phân bổ đầu kỳ theo chi phí ước tính. Mức phân bổ là mức ước tính dựa trên tổng chi phí sản xuất chung với mức hoạt động của đối tượng cần phân bổ.
Do bên Nợ là số thực tế, bên Có là số phân bổ ước tính, nên bên Nợ và Có của tài khoản chi phí sản xuất chung thường có chênh lệch vào lúc kết chuyển cuối kỳ. nếu hai bên Nợ, Có của TK chi phí sản xuất chung bằng nhau thì chỉ là trường hợp ngẫu nhiên.
Nếu chênh lệch nhỏ, phân bổ cả mức chênh lwchj đó vào số dư của tài khoản “Giá vốn hàng bán” của kỳ đó.
Nếu chênh lệch lớn và doanh nghiệp đặt nặng yêu cầu về tính chính xác thì phân bổ chênh lệch về các số dư của tài khoản “Sản phẩm dở dang? và “Giá vốn hàng bán” theo tỷ lệ kết cấu của các số dư đó hoặc các tiêu thức thích hợp.
Khi công việc hoàn thành, thành phần từ khâu sản xuất được chuyển qua kho chứa thành phẩm. Khi thành phẩm đem giao cho khách hàng, giá trị của thành phẩm được chuyển từ khâu thành phẩm qua khâu tiêu thụ.
Ví dụ 2: Công ty Hoàng Sơn đầu tháng 1- N có số dư các tài khoản hàng tồn kho như sau: (đvt: 1.000đ).
TK Chi phí sản xuất sản phẩm dở dang: 146.300
TK Nguyên vật liệu: 32.500
TK Thành phẩm: 10.000
Trên các đơn đặt hàng đầu tháng 1 như sau:
Số đơn ĐH
Chi phí
NVLTT
Chi phí
NCTT
Chi phí SXC
phân bổ
Tổng cộng H 101 7.600 10.700 6.900 25.200 H 102 20.200 27.600 11.200 59.000 H 103 30.450 21.950 9.700 62.100 Cộng 58.250 60.250 27.800 146.300
Trong tháng 1 có các nghiệp vụ kinh tế phát sinh như sau:
1. Mua nguyên vật liệu chưa thanh toán 25.000, trong đó xuất vật liệc cho các đơn đặt hàng: H 101: 7.000, H 102: 8.000, H 103: 10.000
2. Tiền lương của công nhân trực tiếp: H 101: 13.400, H 102: 11.500, H 103: 14.450. Chi phí nhân viên PX: 6.450, BHXH, BHYT, KPCĐ trích theo tỷ lệ quy định.
3. Các chi phí sản xuất chung khác:
Khấu hao tài sản cố định: 1.500
Chi phí điện nước: 1.150
Chi phí sản xuất chung ước tính được phân bổ cho các đơn đặt hàng bằng 25% tiền lương công nhân trực tiếp.
Cuối kỳ H 101 và H102 đã hoàn thành bàn giao cho khách hàng.
Yêu cầu
1: Phản ánh các nghiệp vụ vào tài khoản?
2. Phân bổ chi phí sản xuất chung ước tính cho từng đơn trong kỳ?
3. Xác định giá thành sản xuất cho từng đơn đặt hàng hhoanf thành và chi phí sản xuất sản phẩm dở dang cho đơn đặt hàng chưa hoàn thành?
4. Xử lý phần chi phí sản xuất chung thừa (thiều) cuối kỳ?
Bài giải:
1 Phản ánh các nghiệp vụ vào tài khoản.
a. Phản ánh nguyên vật liệu mua cho sản xuất.
Nợ TK “NVL”: 25.000
Có TK “PTNB”: 25.000
b. Phản ánh chi phí nguyên vật liệu dùng cho sản xuất.
Nợ TK “CPNVLTT”: 25.000
Có TK “NVL”: 25.000
c. Phản ánh chi phí nhân công trực tiếp
Nợ TK “CPNCTT”: 46.826,5
Có TK “PTCNV”: 39.350
Có TK “PTPNK”: 7.476,5
Nợ TK “CPSXKĐ”: 46.826,5
d. Phản ánh chi phí sản xuất chung ước tính phân bổ
Nợ TK “CPSXKDD”: 9.837,5
Có TK “CPSXC”: 9.837,5
e. Phản ánh chi phí sản xuất chung thực tế phát sinh
Nợ TK “CPSXC”: 10.325,5
Có TK “PTCNV”: 6.450
Có TK “PTPNK”: 1.225,5
Có TK “HMTSCĐ”: 1.500
Có TK: “Tiền mặt”: 1.150
2. Chi phí sản xuất chung ước tính được phân bổ cho từng đơn như sau:
H 101: 13.400 x 0,25 = 3.350
H 102: 11.500 x 0,25 = 2.875
H 103: 14.450 x 0,25 = 3.612,5
3. Xác định giá thành sản xuất cho đơn đặt hàng hoàn thành và chi phí sản xuất sản phẩm dở dang cho đơn đặt hàng chưa hoàn thành?
Số đơn ĐH
Chi phí SX
SPDDĐK
Chi phí sản xuất phát sinh trong kỳ
Tổng cộng
giá thành SXSP
hay CPDPDD
NVLTT NCTT SXCƯTPB H 101 25.200 7.000 15.946 3.350 51.496 H 102 59.000 8.000 13.685 2.875 83.560 H 103 62.100 10.000 17.195,5 3.612,5 92.908 Cộng 146.300 25.000 46.826,5 9.837,5 227.964
4. Xử lý phần chi phí sản xuất chung thừa (thiếu) cuối kỳ?
Chi phí sản xuất chung đã phân bổ: 9.837,5
Chi phí sản cuất chung thực tế phát sinh: 10.325,5
Chi phí sản xuất chung phân bổ thiếu: 488
Tổng giá thành sản phẩm hoàn thành: 135.056
Chi phí sản xuất sản phẩm dở dang cuối kỳ: 92.908
Phân bổ số dư TK Chi phí sản xuất chung.
Chi phí sản xuất chung thực tế phát sinh nhiều hơn chi phí đã ước tính phân bổ là 488, số chi phí này sẽ được kết chuyển vào 2 TK “GVHB” và “CPSXKDD” theo tỷ lệ:
Mức phân bổ vào tài khoản “GVHB”: 488 x 135.056 / 227.964 = 289,1
Mức phân bổ vào TK “CPSXKDD”: 189,9
Ta ghi tài khoản sau:
Nợ TK “GVHB”: 289,1
Nợ TK “CPSXKDD”: 198,9
Cơ TK “CPSXC”: 488
Ví dụ 3: Tình hình chi phí sản xuất của Công ty Minh Quang như sau:
1. Các khoản chi phí sản xuất phát sinh theo đơn đặt hàng như sau:
Số thứ tự
đơn đặt hàng
CP nguyên vật liệu
trực tiếp
CP nhân công
trực tiếp
Tổng cộng Đ1 2.000 14.000 16.000 Đ2 52.000 106.000 158.000 Đ3 24.000 8.000 42.000 Đ4 8.000 2.000 10.000
2. Các khoản chi phí phát sinh gián tiếp theo từng đơn vị như sau:
Yếu tố chi phí Nguyên vật liệu Nhân công Chi phí khác Tổng cộng 1. Nguyên vật liệu phụ 30.000 30.000 2. Nhân công gián tiếp 106.000 106.000 3. Tiền điện 46.000 46.000 4. Khấu hao TSCĐ 24.000 24.000 5. Lương nhân viên phân xưởng 40.000 40.000 6. Tổng cộng 30.000 146.000 70.000 246.000
3. Dự toán chi phí sản xuất chung trong năm (Đvt: 1.000đ)
Chi tiêu Số tiền 1. Biến phí nguyên vật liệu 32.000 2. Biến phí nhân công 62.000 3. Biến phí dịch vụ mua ngoài 48.000 4. Định phí nhân công 40.000 5. Định phí khấu hao TSCĐ 24.000 Tổng cộng 216.000
4. Dự toán chi phí nhân công trực tiếp: 160.000
5. Thông tin trên tài khoản sản phẩm dở dang vào đầu năm như sau: (Đvt: 1.000đ)
Đ1: Nguyên vật liệu: 35.000, nhân công trực tiếp: 44.000, sản xuất chung: 66.000
Yêu cầu:
1. Xác định tỉ lệ phân bổ chi phí sản xuất chung theo chi phí nhân công trực tiếp, biết số giờ máy hoạt động là 120.000h.
2. Tính trong năm công ty đã phân bổ thừa hoặc thiếu chi phí sản xuất chung là bao nhiêu?
3. Giả thiết trong năm DD1 hoàn thành và tiêu thụ, hãy xác định giá vốn hàng bán của đơn này.
Bải giải (đvt: 1.000đ)
1. Tính tỷ lệ phân bổ chi phí sản xuất chung theo chi phí nhân công = 216.000 : 120.000 = 180%
2. Tính trong năm công ty đã phân bổ thừa hoặc thiếu chi phí sản xuất chung là bao nhiêu?
a. chi phí sản xuất chung thực tế phát sinh:
Nguyên vật liệu phụ: 30.000
Nhân công gián tiếp: 106.000
Tiền điện: 46.000
Khấu hao TSCĐ: 24.000
Lương nhân viên PX: 40.000
Tổng cộng chi phí chung phát sinh: 246.000
b. Tổng chi phí lao động trực tiếp trong năm:
Tổng cộng chi phí nhân công của 4 đơn hàng = 130.000
Mức chi phí sản xuất chung phân bổ: 180% x 130.000 = 234.000
Vậy mức chi phí SX chung phân bổ thiếu: 246.000 – 234.000 = 12.000
3. Giá vốn của hàng bán đơn 1 như sau:
CHi phí sản xuất dở dang đầu kỳ: 145.000
Nguyên việt liệu TT: 2.000
Chi phí nhân công TT: 14.000
Chi phí sản xuất chung = 180% x 14.000 = 25.200
Vậy tổng cộng giá vốn hàng bán: 186.200
4. Tính số dư tài khoản sản phẩm dở dang.
Đơn 2, 3 và 4 chưa hoàn thành do vậy toàn bộ các khoản chi phí tập hợp cho đơn được coi là chi phí dở dang cuối kỳ và đó chính là số dư tài khoản sản phẩm dở dang cuối kỳ.
Chỉ tiêu Đơn 2 Đơn 3 Đơn 4 Tổng cộng 1. Chi phí nguyên vật liệu trực tiếp 52.000 24.000 8.000 84.000 2. Chi phí nhân công trực tiếp 106.000 8.000 2.000 116.000 3. Chi phí sản xuất chung = 180% chi phí nhân công TT 190.800 14.400 3.600 208.800 Tổng cộng (1+2+3) 348.800 46.400 13.600 408.800
Bải tiếp theo: Phương pháp xác định chi phí sản xuất truyền thống (Phần 2)
Bạn đang đọc nội dung bài viết Phương Pháp Phát Triển Phần Mềm: Truyền Thống Và Agile trên website Cuocthitainang2010.com. Hy vọng một phần nào đó những thông tin mà chúng tôi đã cung cấp là rất hữu ích với bạn. Nếu nội dung bài viết hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất. Chúc bạn một ngày tốt lành!