0:00 Context engineering, Spec Design Driven, Spec Engineering. Rất nhiều những cái thuật ngữ mới được đưa ra nghe rất là xa hoa và xịn sò. Nhưng mà chỉ cần một phương pháp thôi, bốn chữ cái BMX. Nếu các bạn theo dõi và có để ý thì việc mình nhắc đến BM và sử dụng BM thì cũng từ được một thời gian khá là dài rồi. quả thực tác giả đã mở mang cái con mắt của mình ngoài cái việc ứng dụng trong việc development mà còn cho rất nhiều những cái domain khác từ cái việc mình đảo personal là có nghĩa là những cái tính cách những cái system prom ngay trong một cái context window làm thống nhất một cái luồng làm việc từ đầu đến
0:46 cuối là mình đã cảm thấy rất là wow rồi. Mình không nghĩ đến là ồ mình có thể tương tác được với language model theo cái kiểu như vậy. Vì vậy đối với mình PM method là một cái gì đó rất là hay và hy vọng là hết cái video này chúng ta có thể thay đổi được cái mindset, có thể thay đổi được cái góc nhìn, ứng dụng tốt hơn trong cái công việc của mình. hay mình có thể là bớt lo lắng đi về những cái thuật ngữ xa hoa. Chúng ta không cần phải quan tâm quá nhiều đến những cái ứng dụng như là Kiro với SP Design Driven hay là bất cứ một cái công cụ nào hết. Nó như là một cái phần cốt lõi rồi khi mà chúng ta hiểu được cái bản chất thì ở đâu công cụ nào mình cũng dùng được hết. không phải quan tâm quá nhiều nữa. Chúng ta không
1:33 cần phải quan tâm constate, engineering làm gì cả vì dem nó đã có những cái đó rồi. Mình cảm thấy thực sự là rất may mắn vì mình được tiếp xúc từ sớm ấy. Thế nên là khi những cái term, những cái thuật ngữ đấy được đưa ra mình không bị ngộp một chút nào cả mà mình có thể ứng dụng mình xài được luôn. Và nhân tiện thì cũng rất nhiều người để lại comment đó là muốn biết cách mình structure một cái project từ đầu như thế nào. Thì hôm nay mình sẽ nhân chủ đề về BM mình sẽ làm một cái ví dụ nho nhỏ để cho chúng ta có thể hình dung ra được cách sử dụng ứng dụng và BMX vào đối với một cái project mới. Và không chỉ thế đâu nữa mà chúng ta hoàn toàn có thể là sử dụng để
2:18 ứng dụng vào những cái existing project có sẵn rồi nhá. Thực sự thì mình rất là ngại khi mà nói đến BM tại vì nó có quá nhiều thứ mà nói nên chắc chắn là ở trong một cái video thì mình sẽ không thể cover được hết được. Chính vì thế nên là mình nghĩ đây nó sẽ là một cái video mở tại vì cái chủ đề tiếp theo mà chúng ta bàn luận nó sẽ phụ thuộc vào các bạn. Phụ thuộc vào những cái phần mình còn đang thắc mắc, những cái phần mình đang muốn tìm hiểu thêm thì hãy comment ở vào phần bình luận. Và cái chủ đề tiếp theo chúng ta sẽ đi theo cái hướng mà mọi người đang thắc mắc như vậy. Trước khi mà mình đi sâu vào BMS, trước khi mà mình bắt đầu đi vào BMX thì mình muốn ờ đi qua một chút khái niệm về. Vì ag vì tiền thân của BM nó chính
3:04 là một cái phương thức để chúng ta có thể là tối ưu hóa cái hiệu suất làm việc thì thông qua phương pháp ag và mình biết là những cái bạn đã xuất phát là take và làm thì cũng không quá có quá gì xa lạ với cả các cái phương pháp ag development rồi. Tuy nhiên mình biết là người xem kênh của mình không chỉ riêng những bạn Tech mà còn đến từ các đa dạng các lĩnh vực khác nhau. Thậm chí có những các bạn còn vẫn còn đang học khái niệm assign development một chút tại vì nó sẽ ảnh hưởng rất lớn đến cái cách làm việc và chúng ta có thể hiểu từng cái component, từng cái cấu tạo nó ra làm sao thì chúng ta nó đỡ bị ngợp trước khi chúng ta bắt đầu ứng dụng sử dụng BMX. Vậy thì là một cái phương pháp một cái phong cách phát triển phần mềm linh hoạt. Nó chú ý vào cái sự thích nghi
3:52 thay đổi liên tục giữa các thành viên và phản hồi nhanh từ phía khách hàng nhằm tạo ra một cái sản phẩm chất lượng theo một cái chu kỳ ngắn thường là 1 đến 4 tuần. Và những cái chu kỳ ngắn này thì nó gọi là sprint. Và thường một cái team khi mà chúng ta phát triển à development ấ thì nó sẽ bao gồm những cái thành phần ví dụ như là product owner, chúng ta có Scram Master, chúng ta có development team bao gồm cả developer, QA engineer, UIX designer. Cái team của chúng ta nó sẽ có bao gồm từ ba đến chín thành viên như vậy để đảm bảo mỗi người là một phần mà công tác nó hiệu quả và linh hoạt. Mỗi một screen thì chúng ta đều là vòng lại những cái vòng lặp như thế này. À trước tiên thì product owner
4:38 mà làm việc với khách hàng product chúng ta sẽ lấy những cái phần mà chúng ta muốn làm ở trong screen những cái tính năng những cái thành phần như nào đó. Sau đó là mình sẽ lên một cái plan và từ cái plan đấy mình bắt đầu là mình design mình estimate ra cái khoảng cho nó phù hợp ờ trong vòng một sprint đối với những cái tas nào nó quá dài có thể rơi sang cái spring sau thì chúng ta có thể đánh giá cái độ ưu tiên và để những cái tas phần còn lại đấy sang cái phần face đằng sau ở sprint khác. Sau khi design xong rồi, estimate xong xuôi rồi thì chúng ta có cái quá trình là develop phát triển. Lúc này các bạn dep sẽ bắt đầu làm xong thì chúng ta sẽ có QA ngồi test lại. Test lại và cuối
5:23 cùng là deploy đóng gói, review và cuối cùng là lunch cái phần mình đã làm trong một cái sprint đấy. Và cứ lặp đi lặp lại cái sprint các cái spring như vậy cho liên tục update, liên tục phát triển để cái phần mềm của mình càng ngày càng hoàn thiện hơn. Thì đấy là cái cấu trúc làm việc trong một cái sprint thì nó sẽ bao gồm những cái bước cơ bản là như vậy. Vậy thì ở BM chúng ta có gì? Chúng ta có đầy đủ thành phần của một teams từ product owner, từ product manager, master đến dep đến anh X architecture đủ các cái thành phần. Và cùng với cái
6:10 cái kinh nghiệm phong phú của mình, tác giả đã vô cùng khéo léo khi mà sắp xếp việc chuyển giao và những cái task của từng cái row có thể làm. để tạo ra một cái workflow ag hoàn chỉnh trơn chu từ đầu đến cuối thì mình cảm thấy thực sự là rất khâm phục tác giả. À để đọc hết thì có lẽ là rất là nhiều đấy. Thế nên là ví dụ như ở đây chúng ta đã có rất nhiều asent này. Ngoài ra thì tác giả cũng khéo là sắp xếp đấy là TAS. Đó là những cái đầu việc và những cái con agent nào nó có thể làm được những việc gì, những cái tas gì có thể define vào đây. Ngoài tas ra thì chúng ta có workflow đó là brow field
6:56 full stack. Có nghĩa là cái application này của chúng ta đã có sẵn có sẵn rồi. Full stack chúng ta làm cả front end cả back end hay là brow field ui và green field là những cái project mà mới và bao gồm nhiều thành phần à mới nhá. công trang winf UI service full stack full stack thì thường là nhiều thành phần đó ngoài ra có checklist để là kiểm tra lại xem là từng đối tượng từng personal họ nó đã làm đủ và đúng cái yêu cầu mà được đề ra hay chưa. Đó rất là nhiều thứ. Cái format document cần phải xuyên suốt như thế nào, phd trông ra làm sao? Story thì trông như thế nào? từng cái output của một cái
7:42 document expected nó phải ra làm sao chúng ta đã có hết ở đây rồi. Bây giờ mình sẽ đi vào một cái ví dụ cụ thể đi. Tại vì BMX thì có rất nhiều cách để ứng dụng tuy nhiên là nói không thì nó sẽ hơi khó hình dung và thậm chí là chúng ta có thể dùng BMX ở ngay bản web UI ở đây có nghĩa là gì? là mình à mình cop những cái personal cũng như là cái hướng dẫn cái knowled của BMX mình ném vào cho con CHGBT hay là mình ném vào một cái custom Gam để mình có thể tương tác ở ngay trên đấy chứ không nhất thiết là mình chỉ là là chỉ dành cho các bạn dep và dùng ở IDE hay là code thôi. Đó tuy nhiên là ở cái video này thì mình sẽ tập trung vào
8:27 cái việc là sử dụng ứng dụng DM vào trong cái việc development. Ờ để đơn giản và dễ nhất thì chúng ta sẽ sử dụng câu lệnh là NPBM method install là chúng ta bắt đầu cài cái đống hệ thống DM này vào cái project của mình. Mình đã có cái mình chưa mình chưa tạo một cái project mới. Bây giờ mình sẽ bắt đầu tạo nhá. Đây mình sẽ tạm cái folder mới vmes mình cũng chưa biết là mình muốn làm cái gì ở trong cái video này luôn cơ. Mình vào cái folder idol VM nhá. Đầu tiên là mình có lệnh PWD để mình lấy cái đường dẫn này. Sau đó là mình cài
9:13 mình sẽ cần phải đưa cái đường dẫn vào đây. Đó là mình muốn cài BM vào trong cái folder này. Các bạn để ý này, ở đây có một số thứ. Thứ nhất là BM Core là toàn bộ những thứ mình vừa nói ở trên. Face 3 2D Game. Đây là một cái bản expension mở rộng của BMP cho lĩnh vực game development. Thậm chí là chúng ta có cả dep luôn này. Một cái bản mở rộng chuyên về de off. Ờ mình sẽ cài BM C system nha. Ấ [âm nhạc] Chúng ta có muốn là SH cái DC PD không? Đây là một cái rất hay. Có tí nữa mình sẽ nói rõ hơn. Chúng ta có muốn SH
9:58 Archit không? có luôn. Rồi tiếp theo là mình sẽ chọn những cái hiện tại IDE nào mình đang sử dụng để nó nhúng vào. Mình sử dụng claw code. Ờ vậy thôi. Và mình đang rất mong chờ BMX một cái phiên bản mới tại vì ờ CL code nó đã ra sub agent. Mỗi một con agent nó có một cái context riêng. Tuy nhiên là tác giả vẫn đang gọi là khúc, vẫn đang chế à một cái hệ thống cho nó phù hợp với cái thệ thống sub agent. Đấy, hiện tại ông ấy cũng đã có rồi nhưng mà tuy nhiên là nó chưa official, nó chưa chính thức. Thế nĩ là mình đang rất mong chờ phiên bản BM mới nhất hoạt động với Subagent mang lại cho chúng ta
10:44 một cái context window rất là rộng. Mỗi có một cái context window riêng. Ok. Mình có muốn cài cái bản web bandle không? Như lúc nãy mình nói mình không muốn cài. Mình sẽ tập trung vào đây thôi. Đó, vậy là chúng ta đã có xong rồi. Kiểm tra lại nào. Mình có BM này. Và đó thậm chí là nó tạo luôn cho mình là cái các cái command dành cho cludy. Bật clud lên. Rồi vậy là bimade đã nằm trong hệ thống của mình đó. Rất là nhiều thứ. Rồi đây. Vậy thì điều đầu tiên bây giờ mình mình không biết gì cả. Mình không biết ví dụ như các bạn là mình chưa biết bắt đầu với BMX đâu. Hoàn toàn chúng ta có thể
11:30 nói chuyện với BM Master. BM Master được tác giả thiết kế nó có access đến cái BMX những cái file BMX knowledge để nó hiểu xem là BMX hoạt động như thế nào. Mình không nhớ là giả để cái knowledge ở đâu nữa. Đại khái ví dụ như chúng ta muốn hỏi thêm BMX sử dụng ra làm sao, hoạt động như thế nào. Mình hoàn toàn có thể nói chuyện với lại cả BM Master nhá. Ví dụ đây B Master này đó BM Master sẽ có toàn bộ cái knowledge của BMX. Bạn có thấy ở đây điều đặc biệt đó là khi nó đã load được personer của BM Master và cái kiểu làm việc của BM
12:15 với những cái custom command câu lệnh ở đây nó là họng là để biết được là a mình đã load cái BM rồi bây giờ mình có thể làm gì đó nhìn đấy đây là những cái con con măng con có của con BM Master rồi quay lại cái cái việc của mình hiện tại mình đang là mình có một cái project mới mình chưa nghĩ ra là project này làm gì. Có thể là bây giờ mình sẽ làm một cái một cái web đi. Một cái web và có chức năng đăng nhập với username password. Ờ vậy đi. Đó tại vì thực ra mình cũng hơi bí rồi mình chưa biết là phải làm gì. Nếu mà là một cái project to thì
13:01 thực sự là nói chuyện với BMS nó rất là lâu. Nói lâu lắm luôn. Và nếu mà chúng ta không để ý mà mà không kiểm tra lại những cái output của BMX thì nó hơi bị over engineering và làm nó sẽ khá là mệt. Thế nên là mình khuyên đó là chúng ta nên phải có sẵn cái idea mà mình muốn làm. Nếu chưa có idea muốn làm hoàn toàn là mình có thể brainstorm với BME nó là mình sẽ làm gì và làm như thế nào. Nó nó là một cái cách gọi là self reflection. Nó nó hỏi lại mình những cái thứ mà mình chưa nghĩ đến để cho mình hình dung ra và đôi khi là nó khuyến khích mình đi tìm đi thêm những cái thông tin đấy đi. Mày giải quyết cái vấn đề đấy đi. Nếu
13:48 mày giải quyết vấn đề đấy rồi chứng tỏ là cái idea này nó là valid. Cái hướng đi này nó là đúng. Đó. Đấy là một trong những cái mà BMS nó rất là hay như vậy. Nó cảm giác như là mình không phải là mình phụ thuộc vào đấy. Mình có cái knowledge của mình, mình có cái định hướng của mình và nó chỉ gọi là hướng dẫn, nó đưa thêm những thứ để cho mình đi theo đúng cái con đường đấy thôi. Ồ, bên cạnh cái con BM Master vừa rồi thì chúng ta còn một cái nữa đó là BM orchestrator ở đây. BMOR đây đó là cái con điều hướng khi mà chúng ta đang không rõ là mình sẽ cần phải sử dụng đấy
14:35 là luồng công việc nào, sử dụng Asian nào cho cái việc gì thì chúng ta nói chuyện với BMX Orchestrator. Thường thì khi mà mình trigger một cái session làm việc của mình, điều đầu tiên đó là mình sẽ nói chuyện với BMS orchestrator để nó có thể điều hướng cái công việc của mình đến đúng cái con Asian cũng như là cái công việc mình cần sử dụng hơn. Ví dụ như lúc nãy mình đang nói đến cái application mới của mình thì bây giờ bước đầu tiên mình sẽ vào đây và mình sẽ brainstorm cái idea của mình trước khi mình bắt đầu đi ra một cái bản gọi là PRD hay là một cái bản architecture. Đó thì vào đây mình sẽ bắt đầu brainstorm nó nhé. Ví dụ
15:20 như bây giờ là tôi I want to create a new web. Mình muốn tạo một cái web app với basic authentication email and password nhé. Mình sẽ sử dụng i like mình sử dụng Super Base đi cho nó nhanh. cái database mình sử dụng fast API từ backend mình dùng UV
16:09 cho Python à thì mình sử dụng react vi PNPM brainstorm đi. Đó thì khi mình bắt đầu mình sẽ nói chuyện với lại VMS orator. Lúc này chúng ta sẽ có một cái gọi là brainstorming session để xem là những cái phần này mình còn thiếu cái gì không, mình còn thêm cái gì
16:55 không. Nó làm cho chúng ta gọi là đầy đủ và và phong phú hơn trước khi chúng ta bắt đầu làm. Đó, như mọi người nhìn thấy ở đây là nó bắt đầu hỏi mình thêm những cái phần mà mình có thể là mình chưa nghĩ đến. Ví dụ như là cái timeline của mình thì như thế nào? Target audience của mình ra làm sao pasit như mà đó tùy vào cái context tùy vào cái expectation mà mình muốn thì mình sẽ có thêm những cái thông tin để cho cái ứng dụng của chúng ta nó trở nên chính xác hơn. Mình thấy những cái điều như thế nó cực kỳ hữu dụng. Đặc biệt đối với những cái bạn mà chúng ta ví dụ không nằm trong cái domain knowledge này, mình không có được những cái kiến thức về những cái phần nào đó chẳng hạn thì khi mà mình tương tác với
17:43 từng cái con agent của VM nó sẽ có những cái kiến thức chuyên môn sâu về từng cái phần của nó những cái đấy nó sẽ được hỏi đáp lại để chúng ta làm bồi bổ hơn cho cái context thông tin của mình nó chính xác hơn. Đó có thể như là mình sẽ nếu mà như lúc nãy mình không nói ở phía front end mình dùng là gì, back end là gì, mình dùng là dùng cái service gì chẳng hạn ấy thì rất có thể là nó sẽ đến một cái đoạn nó hỏi lại mình những cái đấy. Đó thì cảm giác như là cái thành phần cái app của chúng ta nó sẽ đầy đủ và chi tiết hơn trước khi là mình bắt đầu. Và kiểu như giống như là vai code ấy mà chúng ta mà chỉ nói một cái câu ném một câu rất là đơn giản mà thôi sơ vào thì kết quả của nó về sau nó sẽ rất là khó. Thì thay vào đấy chúng ta phải đánh đổi
18:31 bằng cái việc là tương tác với BM, tương tác với cái hệ thống Asian này thật là chặt chẽ để hiểu được một cái bức tranh toàn bộ trước khi mà mình thực sự là mình nhúng tay và mình spend time ở đây nhiều hơn. Giả sử sau khi mà mình đã gọi như là kết thúc cái brain storming session rồi chẳng hạn thì như các bạn có thấy ở đây đó là mình đã brainstorm một hồi với lại con BMS orchestrator thì cái điều mình thường làm đó là mình sẽ output ra cái đống document mà mình vừa nói chuyện với nó. Như mọi người để ý ở đây thì nó có một cái command đó là dog out và sử dụng cái command đấy thì dùng theo format của BMS đó là có một
19:19 cái sao trước khi gọi out thôi. Mình thường sẽ doc out cái brainstorming session ra cái document của mình trước khi mình bắt đầu là mình đưa xuống cho con product manager để nó bắt đầu là tạo ra cho mình một cái pi mới. Mình sẽ yêu cầu nó out cái brainstorming session. Out brain storming documentation. Tại vì vừa rồi nó vẫn là nockout PD thì mình chưa muốn nó đi theo cái flow đấy. Đó như mọi người có nhìn thể thấy ở đây đó là nó
20:05 chuẩn bị cho mình một cái brainstorming documentation rất là chi tiết với những thứ mà mình đã bàn luận với nó tự qua cái brainstorm session của mình. Sau khi nó đã output cho mình cái documentation xong xuôi ở đây này. Đó, như mọi người có nhìn nhìn thấy thì việc tiếp theo mình thường làm đó là mình clear luôn cái đống này đi. Tại vì những cái thông tính quan trọng nó đã được capture vào trong cái documentation kia rồi. Nên là mình hoàn toàn được làm clear cái context này đi, cái đống session này đi vì không cần phải giữ cái context gì ở lại. Ờ nếu như chúng ta đã quen hoặc là như mình đã quen và biết thì mình biết có thể là sau đây mình sẽ
20:50 gọi Asian analysis lên để làm một chút gọi là market research hay đó là mình có thể gọi thẳng PM lane để bắt đầu chúng ta tạo piure làm việc. Tuy nhiên là nếu mà chúng ta vẫn hoài nghi chưa biết mình cần phải làm gì tiếp thì chúng ta hoàn toàn lại gọi lại cái con trader này lên thôi. Lúc này nó lại load lại cái personal của cái con orchestrater và lúc này mình có thể hỏi nó là bây giờ mình có cái storming documentation rồi mình nên làm gì tiếp hay là mình nên làm cái workflow nào tiếp. Đó BM nó rất là đa dạng có cái nhiều cách sử dụng. Nếu như ở trong cái trường hợp này mình hoàn toàn mình có thể gọi một cái
21:37 workflow, workflow green field lên nó sẽ gọi hết những cái đống agent từ đầu đến cuối để nó bổ ra cho mình từ cái documentation này thành những cái phần documentation khác để chúng ta có thể xây dựng cái ứng dụng của mình. Đó, bây giờ mình sẽ thử hỏi nh what should I do next? And we have the brainstorming or what should what workflow should I take? Để xem nó recommend mình làm cái gì nhá. Trong cái lần thử ví dụ này của mình thì
22:23 mình thấy cái kết quả nó đưa ra nó chưa được chính xác lắm. Vì lý do vì sao mình biết nó là như vậy? Vì trong ba cái workflow nó đưa ra thì trong cái bộ knowledge của BMS nó không có cái workflow đấy. Nên đôi khi những cái trường hợp này có xảy ra nên để cho chắc chắn thì hãy kiểm tra lại trong cái workflow của mình. Ở đây mình biết nó đây là một cái project mới thế nên thường đối với mình thì mình sẽ gọi cái work work workflow là Greenfield Full Stack lên. Trong Greenfield full stack nó là một cái tổ hợp lại chạy theo một cái sequalis PMX đó architecture đó. Sau khi này xong chúng ta sẽ có một bộ document hoạn hảo từ project brief
23:12 cho đến pr cho đến rồi nói chung là rất nhiều documentation để chúng ta chuẩn bị. Đó. Thế nên là trong cái ví dụ này của mình thì có lẽ là lần này mình sẽ trực tiếp mình sẽ gọi cái workflow mình sẽ gọi workflow Greenfield Fack lên. Green Full Stack. Đấy các bạn nhìn thấy Greenfield Fack workflow is activated. Chúng ta sẽ có famous planning này bắt
23:59 đầu từ analysis tạo ra project brief. Thứ hai là PM, thứ ba là expert, thứ tư là architecture, sau đó sẽ là face development cycle. Bây giờ thì mình sẽ đồng ý đi với cái option là full workflow nhé. Đây các bạn nhìn đây là cách mà nó đảo personel. Đấy, nó chuyển sang là Mary Business Analysis. À tạo một cái project brief để mình
24:47 Ok. Đây là một cái phần cũng cực kỳ quan trọng khi mà chúng ta bắt đầu vào cái lượt nói chuyện với personal, chúng ta sẽ có hai lựa chọn đó là interactive mode hay là yolo mode. Interactive mode ở đây có nghĩa là chúng ta sẽ cần phải trao đổi rất là chi tiết đối với cái personal agent để nó có thể collect những cái mong muốn, những cái định hướng mà mình muốn làm. Mình nói trước đó là interactive mode cực kỳ hữu dụng nhưng chúng ta cũng phải có đủ kiên trì để nói chuyện với nó vì nó nói rất là nhiều nó hỏi nhiều thứ lắm. Hai đó là chúng ta chọn yolo mode. Ở cái thời điểm này cái yolo mode sẽ
25:32 output cho chúng ta full cái documentation và để chúng ta review. Nếu thấy nó hợp lý ok thì mình có thể sử dụng luôn. Còn nếu không thì chúng ta có thể là quay lại tiếp tục chat điều chỉnh cho đến khi mà mình cảm thấy phù hợp đến sẵn sàng để tạo ra cái documentation. Ở cái video này mình sẽ sử dụng y mode này cho nó nhanh. Yellow mode Yolo đi. Project Brief đã được tạo ra. Chúng ta có thể đọc và review lại. Nó rất là chi
26:18 tiết và hữu ích nếu chúng ta làm kỹ. Sau đó thì ở đây là mình sẽ tiếp tục chuyển sang con PM và mình cũng sẽ sử dụng yolo mode thôi cho mục đích là demonstrate cho các bạn một cách dễ hiểu và dễ hình dung. Mình không đi quá sâu chi tiết vào những cái gì mà nó nói ở trong đấy. Mình sẽ đồng ý làm create đi. Mình muốn cho mọi người nhìn thấy cái flow mà mình vẫn hay làm và sử dụng nó đang là như thế nào. Chúng ta đã có cái padd cho cái bản lần này. PID rất là quan trọng. Mọi người cần phải đọc kỹ cái padd nhá. Trong đấy
27:05 nó sẽ có requirement là những cái cần có và yêu cầu sẽ phải có ở trong cái bản à application của mình. Cái nào cảm thấy không phù hợp chúng ta có thể loại bỏ đi. Vì đôi khi là BMX rất là theo xu hướng over engineering nhá. làm theo đủ PD và làm theo đủ tất cả mọi thứ thì chắc nó phải kéo dài đến vài ngày mới xong đấy. Thì vài ngày cũng là nhanh rồi. VD xong theo đúng workflow là chúng ta sẽ đến Expert. Có lẽ là mình sẽ skip. Sau đây mình sẽ skip những cái bước này để cho chúng ta đến cái bước quan trọng tiếp theo thì mình sẽ nói sâu hơn về cái bước đấy nhé. Như các bạn có thể thấy ở
27:52 đây thì mình đã skip qua cái workflow này khá là nhiều từ UI Expert này tạo ra những cái front end spec này chạy đến anh architecture tạo ra bản full stack architecture và cuối cùng là nó hand off cho PO validation để chạy lại checklist để kiểm tra xem là những cái phần gì có thể thiếu và còn thiếu hay là kiểu có đủ để đảm bảo hay không. Ý ý ở đây là mình kiểu như là gọi là có thể đã cover hết tất cả những cái cơ bản cây cơ bản hay chưa? Thì cái quá trình này nếu mà mình ngồi mình làm với BMS chi tiết thì có lẽ là nó cũng sẽ
28:37 rơi mất vào đâu đấy vài ngày đấy. Nhưng mà ở đây vì mục đích là show cho mọi người thấy cái workflow, cái cách mình chuẩn bị cho một cái green field application thì mình đã skip hết. Đến một cái giai đoạn này là tất cả những cái documentation của mình đã xong và chuẩn bị cho cái bước implementation. Vậy thì mình sẽ làm gì tiếp theo? Điều tiếp theo ở đây đó là mình sẽ chuyển sao cho Scrum Master. Cái người Grandmaster này nó sẽ tạo ra những cái story trong story đã được phân bố và được sắp xếp để có đủ những cái reference documentation từ front end đến back end cho đến cái gọi là mục đích của cái story đấy. Nó là
29:24 một phần trong cái ag development và cái story và mình sẽ bắt đầu là mình chuyển xuống dep để dep có thể implementation. Ok. Thì như ở đây thì mình mình tất cả những cái documentation quan trọng mình đã có rồi. Thế nên là mình sẽ clear nó đi thôi. Và điều cái đặc biệt ở đây này đó chính là mình sẽ sử dụng cái thằng gọi là shd. Shutdog. Ús sorry. Shard ở đây là gì? SD ở đây nó chính là việc ờ nó BMX nó sẽ chia nhỏ những cái heading này thành những cái phần nhỏ và để cái con Scram Master nó có thể chọn lọc nó nhặt ra từ cái Epic nó nhặt ra được những cái task những cái phần liên quan
30:11 tạo ra một cái context tập trung cho một phần nhỏ đó thay vì là mình phải reference tất cả nơi với những cái document của mình nhiều như thế này mà mình gom hết vào concake thì cái Windows của mình nó sẽ không còn nhiều chỗ để mình làm việc và thậm chí là nó còn gọi là nó nhiều quá nó cũng không hay ấy, nó bị loãng gì ấy. Đó, thì chính vì thế nên là mình sẽ sử dụng gọi là shutdog và shutdog ở đây thì mình sẽ shutdog ở cái doc pi thôi. Mình cứ gọi cái shd này lên xem sao đã. Này trong cái lúc shog thì nó sẽ kiểm tra là mình có cái thư viện MD3 hay không. Nếu có thì nó sẽ sử dụng thư viện đấy. Còn nếu không thì nó sẽ suggest cho mình việc là mình cài cái MD Command để phục vụ cho việc mà shutdog. À shotg ở đây mình sẽ
30:58 chủ yếu cái ông Scammaster sẽ cần đấy là cái padd, cái full stack architecture và một chút và thậm chí là cái front and spec nên mình sẽ chọn ba cái đốc đấy nhá. Tứ nhất là mình chọn cái PD này stack architecture và cuối cùng cũng là thằng frontend architecture. Đây mọi người thấy nó shoock nó chia ra thành những cái đốc nhỏ hơn thôi. Rồi đợi choc xong hoàn toàn đi. Đó vậy thì vậy là cái phần chuẩn bị documentation của mình đã xong. Chuẩn bị context của mình đã ok. Bước tiếp theo
31:44 là mình gọi ông Scrammaster lên. Và đến lúc này mình có thể clear được rồi. Scram master này sm mình sẽ bảo là draft the next story. Có nghĩa là cái việc mình cần làm cái sprint tiếp theo chẳng hạn. Việc tạo story này thì BMS nó sẽ tiếp tục tạo ra cho mình một cái folder mới có tên là story. À và nó bắt đầu nhặt từ
32:29 cái Epic 1. Đó bây giờ nhá. từ cái Epic 1. Trong Epic 1 này mình có thể nhìn thấy là mình sẽ có story 1.1, story 1.2 từ những cái yêu cầu à acceptance criteria tức là những điều kiện chấp nhận được gọi là để xong cái story đấy. Ví dụ như cái app của mình đó là có việc đăng ký vào authentication này. Đó thì cái acceptant criteria của mình sẽ là gì? user có thể đăng ký được email và password này đấy và có validation có thể login bằng những cái credential và sử dụng session token rất rất nhiều thứ như vậy thì ờ nó sẽ bắt đầu nhặt từ cái Epic này ra
33:16 cộng thêm cả với ông full architecture và ông front and Spect để tạo ra cho mình một cái story hoàn chỉnh đây để khi để nó tạo xong thì mọi m người sẽ nhìn thấy nó dễ dàng hơn. Đấy, bắt đầu đọc cái Epic 1. Đấy, thì cái việc start doc của mình thấy mình thấy BMS rất là hay. Tại vì lúc này thay vì nó sẽ đọc cả một cái cục PD rất là to thì nó sẽ chỉ tập trung vào cái Epic 1. Trong Epic 1 có những cái gì và nó đọc. Đấy, ví dụ này đọc index của cái ông Fullstack Architecture đã được start ra này để biết được là trong cái architecture này thì nó có những document nào và nó nằm ở đâu. Đó, nó rất
34:03 là hay. cái việc chia nhỏ ra như vậy để cho mình có một cái contex tập trung hơn thì cái việc chuẩn bị cái dữ liệu cái nguồn context đầu vào cho mình nó sẽ được cô đọng ở trong một cái story. Đó như chúng ta có thể thấy là cái story 1.1 của mình đã tạo xong. Ngó qua cái story 1.1 một chút nào. Đây story này. Đây story 1.1 đây. Trong này chúng ta là mục đích của cái story 1.1 này là gì? Những cái điều kiện cần để hoàn thành à những cái điều kiện mà được cho là hoàn
34:49 thành story 1.1 là gì? Trong đó được chia ra là các cái task cũng như là các cái subtask. Đó. Ngoài ra này ví dụ đây nó có liên quan đến data model user thì trông như thế nào, data schema trông ra làm sao. Tất cả những cái đoạn hai đã được chúng ta tạo ở bên trên và có reference đến để sau đây cái story 1.1 này nó sẽ được đưa xuống cho con dep à cái con depeler để nó implement. Đó mà mọi người nhìn thấy cái cách sắp xếp mình quả là phải gọn gọi là không phục đấy. Cái cách sắp xếp quá là hay của tác giả để làm ra cái cái cái hệ thống cái method BMS này. Vậy sau đây
35:34 thì mình sẽ làm gì? Mình có thể là tiếp tục mình tạo hết tất cả các cái story trong các cái epic hạng hai. Đó là mình sẽ chuyển giao cho à con dep để bắt đầu implement. Thì trong cái trường hợp này mình sẽ gọi như là chuyển sao sang cho con dep để implement nhé. Trước khi chuyển giao cho adap implement thì cái việc của chúng ta đấy là chúng ta phải review cái documentation này. Đấy, sau khi review xong thì mình chuyển cái status là approve tức là đã được review. Cái việc này nó có nghĩa là gì? Khi mà chúng ta có nhiều cái story ở trong cái for story này này mà mình tự dưng mình gọi con dep lên nó làm á và mình bảo nó
36:20 là làm cho tao cái việc tiếp theo đi thì lúc này nó sẽ look up trong cái đống story này nó xem là cái story nào nó có cái status là chưa completed thì nó mặc định nó mặc nhiên là cái story tiếp theo là việc nó cần làm. Đấy, nó cũng là một cái rất là hay nhưng mà ở trong cái trường hợp này thì mình sẽ chủ động mình sẽ gọi nó làm story 1.1 hay là story 1.2. Clear cái context này đi. Đấy, như mọi người nhìn thấy là bây giờ mình không hề có một cái gọi là cái cái context Windows của mình gọi là trống không ấy, không có. Nhưng mà bây giờ mình bắt đầu gọi cái con dep lên và chỉ vì đọc cái story này thôi mà nó có thể develop cái context đủ thông tin để nó làm theo cái plan mà mình đã đề ra.
37:05 Ba cái bước này là ba những cái bước mà khi dành cho Browfield hoặc là sau đây khi mà chúng ta đã develop được cái con Greenfield của mình gọi là đủ xong một cái ok rồi đấy thì có một cái bước gọi là document project nó sẽ tạo ra những cái này để là cái hệ thống của cái document này à sorry của cái project này trông như thế nào. Những cái này cũng rất là hay. Ok, bây giờ mình đã activate bạn D này là Jam rồi. Mình mình giờ mình sẽ vào là please implement cái story 1.1 đấy. Story impment của mình
37:52 đây. Như mọi người có thể thấy đấy là mình đã để cho con cho bạn James bạn ấy implement cái story 1.1 của mình. Và story 1.1 của mình sau khi đã hoàn thành xong chúng ta đã có một cái foundation trông cũng khá là gọn gàng và sạch sẽ. Tuy nhiên là tại vì mình cũng không nói rõ từ đầu, mình cũng không review kỹ lắm thành ra là có những thứ nó cũng không theo cái cách mình hay sử dụng nhưng không sao cả vì mình mục đích là đang demo cho mọi người thấy cái cách mình sử dụng thôi. Vậy thì sau khi mà dep xong thì chúng ta làm gì đây? Sau khi chúng ta develop xong rồi thì nó là cái giai đoạn test.
38:37 Vậy thì đó là cái lúc mà chúng ta cần activate cái anh QA engineering lên để anh ấy làm cái công việc test lại cái phần đã được làm à đã được implement ở cái story này. Và nếu mà mình vào đây thì mình cũng có thể thấy đó là tất cả những cái tas làm xong đều đã được đánh dấu hoàn thành cũng như là còn có ký tên ấy và đặc biệt là cập nhật. Đấy, sau đây là cũng có ờ đưa chuyển giao trong QA thì cũng sẽ có kết quả của QA được điền vào đây luôn. Đấy, rất là hay, hoàn chỉnh luôn. Thì ví dụ như bây giờ ở đây thì mình có thể gọi cái ông QA lên QA. Đó, thì đây chính là một cái quy trình
39:29 đóng gói từ đầu đến cuối theo Development. một và mình cảm thấy gọi là mình mình rất thích cái method của BMS và nếu mà bạn đã có cơ hội bạn sử dụng qua Kiro thì bạn sẽ có thể thấy là cái spec design engineering của Kiro nó cũng tương tự như vậy thôi. Nó cũng có một cái plan breakout cái plan đấy ra thành cái design. sau cái design thì là sẽ cái tas list và chúng ta implement từng cái tas list ở đây như một nữa nên là cái cái mô hình nó sẽ trông nó sẽ là như vậy. Sau đây thì chúng ta có thể bắt đầu draft tiếp cái story tiếp theo lại đưa cho dep lại đưa cho QA để validate. Và bản thân chính chúng ta là cũng đến từng
40:15 cái giai đoạn mình cũng phải hiểu được là mình expect được cái Epic này là gì, story này là gì để mình tự mình phải kiểm tra lại chứ mình vẫn phải kiểm tra lại, mình vẫn phải xem lại xem nó như thế nào. có lệch hướng hay không hay hay có bị làm quá hay không. Đấy thì đó là những cái gì mà mình đang ứng dụng mà mình sử dụng BMS vào. Ôi cái video này nó đã quá dài rồi và mình không biết là đến giờ này còn ai xem đến cái đoạn này không nữa hay là đã out hết rồi. Thì mình rất là cảm ơn các bạn đã xem hết cái video của mình. Hy vọng là qua cái video này thì chúng ta đã có được thêm những cái góc nhìn mới, có những thêm cái cái cách my mindset cũng như là cách việc sử dụng những cái phương thức phù
41:02 hợp cho với cái workflow của mình để tăng được cái output, cái productivity của mình lên. Nếu các bạn thấy hay thì hãy like, subscribe và thậm chí là hãy chia sẻ cái video này nhiều hơn nữa thì mình nghĩ là sẽ không chỉ riêng cho các bạn dep mà kể cả những cái bạn mà mình có cái idea, mình có cái architecture à cũng không phải architecture mà đại khái là mình biết cách hoạt động này hoặc là mình có một cái ý tưởng nào đấy và mình đang muốn tìm cách mình phát triển nó lên thì mình hoàn toàn có thể sử dụng BM như là một cái à cách ờ để mình có thể giúp mình hoàn thành cái sản phẩm của mình giống như việc là bây giờ mình đã đi thuê được hẳn một team
41:49 dep luôn đấy. Hoàn chỉnh vậy đấy. Ok, xin chào và hẹn gặp lại. Cảm ơn mọi người rất nhiều vì đã xem hết cái video này của mình. À rất tiếc đó là bởi vì BMS nó nó nhiều thứ quá nó nó làm nên là mình không show được cái ví dụ trực quan về cái sản phẩm mà được làm ở BMP lên. Thế nên là mình hy vọng là mọi người có thể trải nghiệa và có thể chia sẻ những cái điều đấy à với mình. Và đặc biệt là mình đang mong muốn có một cái community nhỏ và nơi mà mình có thể là cùng mọi người trao đổi bàn luận về cái cách không chỉ diễn BM mà còn nhiều các cái ứng dụng sử
42:36 dụng AI nữa trong cái công việc của mình. Đế nên là mình đang định tạo một cái cộng đồng Discord để sau đó là chúng ta có thể gọi là kết nối với nhau nhanh hơn thông qua không chỉ riêng qua YouTube hay là Facebook nơi mà không chỉ riêng mình mà có thể lại có rất nhiều những cái bạn khác thì mình đã nói chuyện với rất nhiều các bạn giỏi rồi và bây giờ mình muốn là chúng ta có một cái sân chơi chung để chúng ta cùng nhau chia sẻ chúng ta cùng nhau kết bạn kết nối với nhau. Đó thì nếu mà mọi người quan tâm thì mình để cái link Discord à sorry Discord ở bên dưới phần description nhé. Ok, chào và hẹn gặp lại.
