Từ vấn đề đến sản phẩm số: năm chặng, nhóm làm việc và tiến độ của một dự án công nghệ thông tin | LUKATO AI
Bài giảng khái niệm Tin học 12 theo khung năm chặng từ vấn đề đến sản phẩm số: yêu cầu, thiết kế, làm và kiểm thử, hoàn thiện và đánh giá, cùng nhóm làm…
LUKATO AI · TIN HỌC 12 · DỰ ÁN SỐ
VẤN ĐỀ · YÊU CẦU · THIẾT KẾ · LÀM VÀ THỬ · ĐÁNH GIÁ
Từ vấn đề đến sản phẩm số:
năm chặng, một nhóm,
một bảng tiến độ
Một nhóm học sinh nhận lời làm trang đặt lịch tham quan phòng truyền thống của trường. Nhóm có thể mở máy và viết mã ngay, nhưng những dự án trôi chảy thường bắt đầu ở chỗ khác: ai đang gặp khó, khó ở đâu, và thế nào thì gọi là xong. Bài giảng này đi theo trang đặt lịch ấy qua năm chặng từ vấn đề đến đánh giá, rồi nhìn hai lớp chạy suốt dự án: nhóm (vai trò, kho chung, họp ngắn, nhóm nghề) và tiến độ (danh sách việc, phụ thuộc, đường găng, rủi ro). Phần nào ngoài sách giáo khoa được ghi là kiến thức bổ sung; các con số trong lab là số liệu minh họa.
- ① Một dự án số đi qua những chặng nào, và vì sao một lỗi thấy ở chặng sau lại tốn công hơn nhiều so với thấy ở chặng đầu?
- ② Làm sao chia vấn đề thành việc nhỏ, giao việc cho đúng người, và biết việc nào quyết định ngày xong?
- ③ Ngành công nghệ thông tin có những nhóm nghề nào, và em ghép một nhiệm vụ với nhóm nghề thế nào?
5+2
năm chặng, cộng lớp nhóm và lớp tiến độ chạy suốt
12 lab
phòng lab: xếp chặng, phân loại lời kể, giá của lỗi thấy muộn, chia nhỏ, chọn theo tiêu chí, kho chung, phân công, đường găng, chọn ca thử, chọn nhóm nghề, hồ sơ năng lực, kịch bản giữa chừng
14 bẫy
mỗi bẫy có mục, phòng lab và bài để quay lại luyện
12 bài
10 chọn đáp án, 1 đúng sai, 1 trả lời ngắn
01
Bản đồ chung
Năm chặng của một dự án số và hai lớp chạy suốt
Một dự án số khác với một bài tập lập trình ở chỗ nó có người dùng thật, có hạn chót, có nhiều người cùng làm và có cái giá phải trả khi làm sai. Thầy Khoa phụ trách phòng truyền thống muốn có một trang web nhỏ để các nhóm học sinh đặt lịch tham quan; hiện nay thầy ghi lịch vào sổ giấy và đôi khi hai nhóm cùng đến một giờ. Muốn đi từ câu chuyện ấy đến một trang chạy được, nhóm đi qua năm chặng : xác định vấn đề, làm rõ yêu cầu, thiết kế, làm và kiểm thử, hoàn thiện và đánh giá. Bài giảng này lấy năm chặng ấy làm khung chung; khi gặp một tình huống lạ, em hỏi: việc này đang nằm ở chặng nào, và nó cần đầu ra gì để chặng sau dùng được?
Hình rộng hơn màn hình: vuốt ngang để xem đầy đủ.
Bản đồ năm chặng: mỗi khối ghi việc chính và đầu ra. Vòng lặp nét đứt cho thấy khi đánh giá chưa đạt thì nhóm quay về yêu cầu hoặc thiết kế. Hai dải ngang là lớp nhóm và lớp tiến độ, chạy suốt từ chặng đầu đến chặng cuối. Bấm vào một khối để đọc mô tả và số mục.
Điều khiến khung này dùng được lâu là một nhận xét đơn giản: mỗi chặng có một đầu ra , và đầu ra ấy là đầu vào của chặng kế tiếp. Chặng vấn đề cho ra một câu mô tả; chặng yêu cầu biến câu ấy thành bảng yêu cầu có tiêu chí kiểm tra được; chặng thiết kế biến bảng yêu cầu thành cây việc và cách làm; chặng làm và kiểm thử cho ra sản phẩm đã thử; chặng đánh giá so sản phẩm với tiêu chí và rút bài học. Nếu một đầu ra còn mờ thì chặng sau phải đoán, và đoán sai là một nguồn lớn của việc phải làm lại.
Năm chặng, hai lớp và những gì mỗi phần giữ
Chặng hoặc lớp
Việc chính
Đầu ra
Mục
① VẤN ĐỀ
Tìm hiểu ai gặp khó, trong tình huống nào, hậu quả ra sao; chốt phạm vi cần giải quyết
một câu mô tả vấn đề
② YÊU CẦU
Nghe người dùng và người vận hành; tách chức năng, chất lượng đo được, ràng buộc; hỏi lại câu mơ hồ
bảng yêu cầu có tiêu chí
③ THIẾT KẾ
Chia vấn đề thành việc nhỏ; so sánh phương án theo nhiều tiêu chí; phác màn hình và dữ liệu
cây việc và cách làm đã chọn
④ LÀM VÀ KIỂM THỬ
Viết từng phần, ghép trên kho chung, thử từng phần và thử cả hệ thống
sản phẩm đã thử
4, 6
⑤ HOÀN THIỆN VÀ ĐÁNH GIÁ
Sửa lỗi còn lại, đo kết quả so với tiêu chí, tìm nguyên nhân gốc của sự cố, rút kinh nghiệm
báo cáo đánh giá
LỚP NHÓM
Vai trò, kho chung, họp ngắn, nhóm nghề và năng lực của từng người
nhóm làm việc trơn tru
4, 7
LỚP TIẾN ĐỘ
Danh sách việc, người nhận, thứ tự phụ thuộc, đường găng, rủi ro trễ hạn
bảng tiến độ cập nhật
Chia thành năm chặng cộng hai lớp là cách trình bày của LUKATO để xâu chuỗi các bài. Các dự án ngoài thực tế có thể gọi tên chặng khác hoặc làm các chặng chồng lên nhau; điều cốt lõi là thứ tự logic của đầu ra.
Vì sao đi theo chặng mà không nhảy thẳng vào làm
Có ba lí do. Thứ nhất , chi phí sửa sai tăng nhanh theo chặng: một chữ sai trong bảng yêu cầu chỉ tốn một lần sửa chữ, nhưng nếu nó đã được viết thành màn hình, dữ liệu và mã thì phải sửa cả ba chỗ. Mục 2 có phòng lab cho em thấy mức chênh lệch này. Thứ hai , mỗi chặng trả lời một câu hỏi khác nhau: ở chặng đầu là «giải quyết cái gì?», ở chặng yêu cầu là «thế nào thì đạt?», ở chặng thiết kế là «làm bằng cách nào?». Trộn các câu hỏi với nhau thì nhóm tranh luận cách làm khi chưa thống nhất mục tiêu. Thứ ba , đầu ra rõ ràng cho phép chia việc: người làm màn hình và người làm dữ liệu chỉ làm song song được khi cả hai đã nhìn cùng một bản thiết kế.
Điều này không có nghĩa là chỉ đi một chiều. Sau khi thử sản phẩm, nhóm có thể thấy một yêu cầu đã bị hiểu sai, và phải quay về chặng yêu cầu. Vòng lặp nét đứt trong bản đồ là chỗ ấy. Khác biệt giữa một nhóm đi vòng có chủ đích và một nhóm làm đi làm lại là: nhóm thứ nhất biết mình quay về để sửa đầu ra nào.
Đoán trước, rồi thử tay
Đoán trước: nhóm làm trang đặt lịch đã viết xong chức năng chọn ngày và giờ. Từ chặng yêu cầu, nhóm đã đặt tiêu chí «ít nhất 8 trong 10 bạn đặt xong lịch dưới hai phút». Giờ họ nhờ mười bạn lớp khác dùng thử, bấm giờ xem mỗi bạn đặt xong lịch mất bao lâu, đối chiếu với tiêu chí ấy, rồi ghi lại điều cần đổi cho lần sau. Việc này thuộc chặng nào của khung?
Việc «bấm giờ mười bạn dùng thử, đối chiếu với tiêu chí dưới hai phút, rồi ghi điều cần đổi» thuộc chặng nào?
Đến lượt em: mười hai việc dưới đây mô tả những gì nhóm có thể làm trong cùng dự án. Trên điện thoại và máy tính bảng, chạm vào thẻ rồi chạm vào chặng đúng; dùng chuột thì có thể kéo thẻ thả vào chặng. Một vài thẻ dễ nhầm giữa hai chặng liền nhau; lời nhắc sau khi chấm giải thích cách hỏi để phân biệt.
Cách dùng phòng lab
Chọn thẻ, rồi chọn chặng đích; bấm «Chấm các thẻ đã xếp» để thấy thẻ nào đúng, thẻ nào sai và lí do. Phòng lab hoàn thành khi em đã xếp đúng cả mười hai thẻ vào năm chặng. Khi gặp một việc khác với mười hai việc này, hãy hỏi: việc này làm rõ vấn đề, ghi điều phải làm, chia và chọn cách làm, tạo và thử sản phẩm, hay đo và sửa cho tốt hơn? Phòng lab này luyện bẫy 1.
Thử tay: một dự án đang đi lệch ở chặng nào?
Nhóm làm trang đặt lịch ra mắt bản thử. Ba nhóm học sinh thấy trang đẹp, nhưng thầy Khoa bảo trang không cho đặt lịch hai nhóm vào cùng một giờ nên vẫn phải ghi thêm vào sổ. Em hãy chỉ ra đầu ra nào của chặng nào đã thiếu.
Gợi ý 1 · Hỏi lại điều thầy cần
Thầy cần tránh trùng giờ. Đó là điều phải làm, không phải chuyện đẹp hay xấu của màn hình.
Gợi ý 2 · Tìm nơi điều ấy lẽ ra được ghi
Điều phải làm được ghi trong bảng yêu cầu của chặng ②. Hãy xem bảng ấy có dòng «không cho hai nhóm đặt cùng một khung giờ» hay không.
Đáp án
Bảng yêu cầu ở chặng ② thiếu một yêu cầu chức năng, hoặc có nhưng không ai đưa nó vào thiết kế dữ liệu. Chỗ cần quay lại là chặng yêu cầu, rồi đi tiếp xuống thiết kế và kiểm thử. Sửa riêng màn hình ở chặng ④ sẽ không đủ, vì nguyên nhân nằm ở đầu ra của chặng trước.
Chỗ dễ nhầm ở bản đồ
Bẫy 1: coi chặng đầu của dự án số là chọn công cụ và viết mã, còn hỏi han xem ai gặp khó thì cho qua thật nhanh. Phòng lab 1 cho em thấy mười hai việc khác nhau có chặng riêng; việc nào thuộc chặng ① đều trả lời cho câu hỏi «giải quyết cái gì, cho ai», trước các bàn bạc về cách làm.
Mục 2 đi tiếp hai chặng đầu: làm sao viết một câu mô tả vấn đề, làm sao biến lời kể thành yêu cầu kiểm tra được, và vì sao lỗi ở các chặng sớm là lỗi đắt nhất.
02
Chặng ① VẤN ĐỀ · chặng ② YÊU CẦU
Mô tả vấn đề, biến lời kể thành yêu cầu kiểm tra được
Thầy Khoa kể: «Em nào đến phòng truyền thống cũng phải ghi tên vào sổ. Có hôm hai nhóm cùng đến lúc chín giờ, một nhóm phải về.» Từ câu kể ấy, nhóm có thể nghĩ ngay đến cách làm: một trang web, một biểu mẫu, một ứng dụng. Nhưng chưa ai nói trang web ấy phải làm được gì, cho ai, và phải tốt đến mức nào mới gọi là xong. Hai chặng đầu của dự án là để trả lời những câu đó. Chúng không tạo ra dòng mã nào, nhưng ảnh hưởng nhiều đến việc công sức ở các chặng sau có đáng hay không.
Câu mô tả vấn đề: ai, tình huống nào, hậu quả gì
Một câu mô tả vấn đề tốt có bốn thành phần: ai gặp khó, trong tình huống nào, kéo theo hậu quả gì, và phạm vi mà nhóm sẽ giải quyết. So sánh hai câu sau.
Câu
Nội dung
Nhận xét
Câu 1
«Trường cần một trang web đặt lịch.»
Đã nhảy sang cách làm; không nói ai gặp khó và vì sao
Câu 2
«Các nhóm học sinh đặt lịch tham quan phòng truyền thống bằng sổ giấy; đôi khi hai nhóm cùng đến một giờ, một nhóm phải chờ hoặc ra về. Nhóm chỉ giải quyết việc đặt lịch, chưa bàn việc hướng dẫn viên.»
Có người gặp khó, tình huống, hậu quả và phạm vi
Câu thứ nhất khiến cả nhóm tranh luận «web hay ứng dụng» trước khi biết vấn đề. Câu thứ hai mở ra những câu hỏi đúng: có bao nhiêu nhóm một tuần, một nhóm đông bao nhiêu, ai duyệt lịch. Để viết được câu như câu thứ hai, nhóm cần nghe và nhìn: nói chuyện với thầy Khoa, hỏi vài nhóm học sinh đã đặt lịch, và ngồi xem một buổi ghi sổ để thấy chỗ nhầm xảy ra khi nào.
Nghe ai, hỏi gì, ghi lại sao
Mỗi dự án có ít nhất ba loại người cần nghe. Người dùng là người bấm, gõ, nhìn trang hằng ngày. Người vận hành là người giữ cho hệ thống chạy, ở đây là thầy Khoa cùng người duyệt lịch. Người quyết định là người cho phép dự án đi tiếp, ví dụ nhà trường. Họ có thể nói những điều khác nhau, và việc của nhóm là ghi lại đủ các ý kiến rồi tìm chỗ mâu thuẫn để hỏi lại. Bốn câu hỏi nên mang theo vào buổi gặp: hiện nay việc này làm thế nào, chỗ nào hay sai hoặc mất công, nếu có trang mới thì thế nào là «tốt hơn», và có điều gì nhất định không được thay đổi.
Cách phân ba nhóm người ở trên là cách trình bày của LUKATO. Trong sách và trong thực tế, người ta gọi chung họ là các bên liên quan; điều cần nhớ là nghe đủ các bên, không chỉ nghe người nói nhiều nhất.
Bốn loại câu trong bảng yêu cầu
Sau buổi gặp, nhóm có một đống câu nói. Mỗi câu thuộc một trong bốn loại, và mỗi loại được xử lí khác nhau.
Loại
Đặc điểm
Ví dụ để so sánh
Chức năng
Nói hệ thống phải làm được việc gì; kiểm tra bằng cách làm thử việc ấy
«Người duyệt xem được danh sách lịch của một tuần.»
Chất lượng đo được
Có con số hoặc ngưỡng, nói việc ấy phải tốt đến đâu; kiểm tra bằng cách đo
«Trang hiện đầy đủ trên điện thoại cỡ nhỏ trong vòng ba giây.»
Ràng buộc
Điều kiện bên ngoài nhóm không tự đổi được: kinh phí, thời hạn, nơi đặt dữ liệu, quy định
«Dữ liệu người đặt lịch được giữ trong hệ thống của nhà trường.»
Mơ hồ
Không có tiêu chí để kiểm tra đạt hay chưa; phải hỏi lại trước khi ghi vào bảng
«Trang phải thân thiện.»
Câu «thân thiện» là mơ hồ không phải vì nó sai, mà vì hai người đọc nó có thể hình dung hai trang khác nhau và cả hai đều tin mình đúng. Cách xử lí không phải là bỏ câu ấy mà là hỏi lại cho đến khi nó thành một câu kiểm tra được.
Từ mong muốn đến tiêu chí
Hình rộng hơn màn hình: vuốt ngang để xem đầy đủ.
Ba bậc chữ cùng nói về một điều: mong muốn, yêu cầu, tiêu chí. Chỉ bậc cuối cho phép kiểm tra đạt hay chưa. Bên phải là bốn câu hỏi để đi từ bậc này xuống bậc kế.
Công thức viết tiêu chí có thể gọn như sau: ai làm việc gì trong điều kiện nào thì được coi là đạt khi đạt mức nào . Phần «mức nào» thường là một tỉ lệ: nếu có 10 bạn thử và 8 bạn đặt xong dưới hai phút thì tỉ lệ đạt là \dfrac{8}{10}=80\%. Khi viết «ít nhất 8 trong 10 bạn» ta đã chốt sẵn cách đo (mười bạn dùng thử), mức đạt (8) và ngưỡng thời gian (hai phút). Ba thứ ấy thiếu một thì tiêu chí chưa kiểm tra được.
Điều này liên quan đến nhiều dự án khác nhau: chữ nào mang tính cảm nhận, như đẹp, dễ dùng, gọn, đều cần được đổi thành một phép đo hoặc một việc người dùng làm được. Có những điều khó đổi sang con số, nhưng cố gắng đổi sẽ cho thấy điều nhóm thật sự muốn.
Đoán trước, rồi thử tay
Đoán trước: một lỗi nằm ngay trong bảng yêu cầu: nhóm quên yêu cầu «không cho đặt trùng giờ». Nếu lỗi ấy chỉ bị phát hiện khi nhóm chạy thử bản đã làm xong, tức ở chặng làm và kiểm thử, hãy đoán xem giá sửa tăng bao nhiêu. Theo mô hình minh họa của LUKATO, sửa lúc này tốn gấp mấy lần so với sửa ngay ở chặng yêu cầu?
Lỗi yêu cầu thấy ở chặng làm và kiểm thử tốn gấp mấy lần so với thấy ở chặng yêu cầu?