Nội Dung tóm gộp về Scrum Căn Bản:
Mô Hình Thác Nước( model WaterFall) là phương pháp phát triển phần mền truyền thống,được sử dụng cho cả công ty lớn lẫn nhỏ.
+Lập kế hoạch !!!
->Lập kế hoạch:Xem xét,thiết kế,ước lượng đầu ra của sản phẩm thông qua các tài liệu thực tế,thống kê.Ước tính thời gian của từng cá nhân tham gia dư án ở mỗi bước phát triển.
->Bên liên quan:Xem xét kĩ lưỡng và phê chuẩn kế hoạch
//duyệt :Các thành viên trong nhóm hoàn thành công việc chuyên môn của mình và chuyển giao cho người khác trong dây chuyền sản xuất.
//không duyệt:Xem xét,thay đổi ,ước lượng ,thiết kế lại dựa trên nền cở sở,khái niệm dự án
Dây chuyền sản xuất
thiết kế sản phầm-----------testing-------------->Sản phẩm hoàn chỉnh
Bộ phận quản lí chất lượng QA
Yêu cầu của Tester:Trong quá trình sản xuất,độ lệch so với kế hoạch được kiểm soát nghiêm ngặt nhằm đảm bảo sản phẩm ra đời thực tế với thiết kế.(Hight Quality, nói chung kiếm tiền tốt)
Rủi Ro:
+Cách tiếp cận này yêu cầu tất cả những ý tưởng tốt cần đưa ra ngay từ đầu,để đưa vào kế hoạch .nhưng như chúng ta biết ,các ý tưởng tốt xuất hiện trong suốt quá trình phát triển -lúc bắt đầu .
+Khi giữa chừng và thậm chí đôi khi xuất hiện trước ngày giới thiệu sản phẩm ,và một quy trình không cho phép những thay đổi sẽ kiềm chế sự đổi mới .với mô hình thác nước ,ý kiến hay nhưng đưa ra muộn không phải là một món quà mà là một nguy cơ.
Ưu điểm: Mô hình Thác Nước:Là đề cao việc viết ra mọi thứ như là phương pháp chính để trao đổi những thông tin quan trọng.
Giả Định(...Rủi RO):
Trường Hợp 1:Khi tôi viết ra giấy mọi thứ trong suy nghĩ của tôi ,sẽ đáng tin cậy hơn khi truyền đạt cho người khác trong nhóm ,hơn nữa,nếu nó ở trên giấy (ẸC TRÊN GIẤY ).SẼ LÀ BẰNG CHỨNG RẮNG TÔI ĐÃ HOÀN THÀNH CÔNG VIỆC CỦA MÌNH. Trên thực tế cho thấy phần lớn các tài liệu mô tả yêu cầu của khách hàng chi tiết hơn 50 trang sẽ không được đọc.Và khi họ phải đọc!. thường xuất hiện nhiều hiểu lầm.Một tài liệu được viết ra là một bức tranh không màu (không đầy đủ) về các ý tưởng của tôi,khi bạn đọc nó ,bạn hiểu theo cách khác xa với điều tôi nghĩ hoặc tôi muốn nói.Sẽ không có gì ngạc nhiên khi nảy sinh những hiểu lầm nghiêm trọng.
Trường hợp 2:Bạn Đột nhiên nghĩ ra 20 cách để làm cho nó tốt hơn.không may,những ý tưởng có giá trị này hay vào cuối quá trình phát triển .khi mọi thay đổi đều rất khó khăn và rắc rối nói cách khác sẽ phải trả giá đắt khi muốn làm lại cho đúng, .... "LÀM THẾ NÀO " ....Con người không có khả năng đoán trước tương lai ,không thể đoán trước được một thông báo như mong đợi từ đối thủ cạnh tranh.Các vấn đề kỹ thuật có thể xuất hiện bất ngờ làm thay đổi định hướng công việc .hơn nữa ,con người đặc biệt kém khi lên kế hoạch cho những việc không chắc chắn trong tương lai xa -sẽ là ảo tưởng để đoán rằng bạn sẽ sử dụng một tuần như thế nào trong tám tháng kể từ hôm nay. Vâng .đã có rất nhiều thất bại trong việc phát triển phần mền!!!
Trường hợp 3:Chu trình phát triển tuần tự kích thích mối quan hệ đối kháng khi chuyển giao công việc giữa người này và người kia:"Ơ đệt ,anh yêu cầu tôi xây cái này mà éo có mô tả là sao ?"."Tôi éo chịu trách nhiệm cái này tôi không thể kiểm soát nó".Và điều đó cho thấy bộ mặt thật của sự phát triển theo tuần tự-nó không thú vị !!!!
Kết:
->Khách hàng: Một quy trình cứng nhắc ,khó thay đổi sẽ cho ra những sản phẩm tầm thường.Khách hàng có thể được những yêu cầu lúc đầu.nhưng đó có phải là điều khách hàng mong muốn khi thấy sản phẩm không ?Bằng cách thu thập tất cả các yêu cầu khách hàng và ép cứng chúng, Sản phẩm chỉ "tốt" như ý tưởng ban đầu.Thay vì trở thành tốt nhất nhất khi mọi người đã tìm hiểu và khám phá ra những điều mới.
->Người quản lí:Nhiều người sử dụng chu trình tuần tự phải trải nghiệm những thiếu sót này không biết bao lần.Nhưng có vẻ như rất hợp lí khi phản ứng thông thường hướng vào bên trong:"chỉ cần chúng ta làm tốt hơn,nó đã hoạt độn rồi" -nếu chúng ta lên kế hoạch ,làm tài liệu tốt hơn chống lại sự thay đội nhiêu hơn,mọi thứ có lẽ đã diễn ra suôn sẽ.nhưng không may nhiều .Nhóm phát triển lại gặp lại những điều ngược lại:càng cố gắng bao nhiều,kết quả càng tồi tệ bấy nhiêu!!! nhiều nhà quản lí đã đầu tư cả danh tiếng của họ và nhiều tài nguyên khác vào mô hình thác nước,việc họ chuyển sang một mô hình khác biệt về cơ bản là sự thừa nhận rõ ràng họ ĐÃ SAI LẦM !!!.SCRUM LÀ SỰ KHÁC BIỆT!!!
l.Phát triển linh hoạt và Scrum
Các phương pháp phát triển linh hoạt ra đời dựa trên niềm tin bằng việc tiếp cận thực tại cuộc sống và phát triển sản phẩm để học hỏi cải tiến,và thay đổi sẽ mang lại các kết quả tốt hơn.các nguyên tắc phát triển để học hỏi,cải tiến,và thay đổi.sẽ mang lại các kết quả tốt hơn.các nguyên tắc phát triển sản phẩm để học hỏi,cải tiến,và thay đổi sẽ mang lại các kết quả tốt hơn.Các nguyên tắc phát triển linh hoạt nhấn mạnh đến việc con người có thể nhanh chóng tạo ra phần mền chạy được,hơn là dành nhiều thời gian của đoạn đầu cho việc viết các đặt tả kỹ thuật.
<Giải thích đơn giản lại :ví dụ mình làm trang web bán hàng ...chúng ta sẽ xem các trang web bán hàng (vatgia.vn) khác để coi các thao tác,nội dung ,giao diện để họi hỏi ,rút kinh nghiệm ,khảo sát thực tế các yêu cầu của khách hàng>
Phương pháp này còn tập trung vào các phân đoạn lặp nhanh ,với việc tiếp nhận thông tin liên tục từ phía khách hàng trong quá trình phát triển hoặc Scrum,thường có một chút mơ hồ trong nhận thức -điều này có vẻ rất giống những thuở đầu khi chúng ta nói "XỊT.LÀM ĐI ".
Luận:Điểm mấu chốt Scrum chính là cơ chế "THANH TRA VÀ THÍCH NGHI".Vì trong quá trình phát triển không bao giờ tránh được việc học hỏi,đổi mới,và các yếu tố bất ngờ .Scrum nhấn mạnh việc đi từng bước nhỏ ,thanh tra cả kết quả lẫn hiệu quả công việc thực tại để từ đó thích ứng với các mục tiệu của sản phẩm cũng như quy trình thực tế .và cứ thế lặp đi lặp lại như vậy .
-----------------------------------------------------------------------------------------------------------------------------------
VÀI TRÒ TRONG SCRUM
Trong Scrum có 3 vài trò: +Chủ sản phẩm
+Nhóm phát triển
+Scrum Master
Chủ sản phẩm:Chịu trách nhiệm tối đa lợi nhuận trên vốn đầu tư bằng cách chỉ các chức năng của sản phẩm,chuyển chúng thành danh sách ưu tiên hóa,quyết định chức năng nào cho sản phẩm.Và liên tục điều chỉnh sao cho nó tối ưu nhất. Chủ sản phẩm có trách nhiệm về lợi nhuận và tổn thất cho sản phẩm
Chủ sản phẩm thường xuyên phải tương tác với khách hàng !!!
Người Quản lí sản phẩm(dự án) tương tác với nhóm phát triển
Chủ sản phẩm(Product Owner) Chủ quan đưa ra sự ưu tiên và check kết quả mỗi vòng phát triển hoặc 4 tuần,thay vì ủy quyền quyết định cho người quản lí dự án.Một điều quan trọng cần chú ý là trong Scrum chỉ có duy nhất một vị trí và có quyền quyết định đó là Product Owner ,và đó là người đó có trách nhiệm với gái trị sản phẩm.
Nhóm phát triển sản phẩm: vài trò là "Liền chức năng"(cross-functional) từ trên đưa xuống,mức độ làm việc là độc lập và trách nhiệm rất cao.Nếu đã cam kết làm cái gì,thì phải làm hoàn thành cam kết đó.
Scrum Master:Giúp nhóm phát triển học và áp dụng Scrum để đạt đc giá trị thương mại.Scrum marster làm tất cả những gì có thể trong quyền hạn để giúp nhóm phát triển hay quản lí dự án.thay vào đó scrum master phục vụ nhóm phát triển,bảo vệ các thành viên khỏi sự can thiệp từ bên ngoài,đào tạo và hướng dẫn Product Owner cũng như Nhóm Phát triển vẫn dụng Scrum một cách khéo léo.đảm bảo rằng mọi người hiểu và làm Scrum,để lãnh đạo tổ chức vượt qua qua những khó khăn thường gặp trong quá trình thay đổi và thành công với phương pháp phát triển linh hoạt.Vì Scrum giúp phát lộ nhều trở ngại và nguy cơ cho nhóm phát triển và product owner ,nên rất quan trọng khi có một Scrum Master luôn hết mình giúp đỡ giải quyết mọi trở ngại.Nếu ko có vai trò này thì sản phẩm khó thành công.
Scrum Master tốt có thể xuất phát từ mọi vị trí hoặc chuyên môn:Kỹ sư,thiết kế,tester,Product Manager,Project Managar,hoặc quản lí chất lượng.
SCRUM MASTER VÀ PRODUCT OWNER KHÔNG THỂ LÀ CÙNG MỘT NGƯỜI,TẠI NHỮNG THỜI ĐIỂM,SCRUM MASTER CÓ THỂ GÂY ÁP LỰC VỚI PRODUCT OWNER.không giống như người quản lí dự án .Scrum Master đã nắm giữ một quản lí trước đó,họ có thể thay đổi tư duy và cách tương tác với nhóm phát triển để có thể thành công.
II.Bắt đầu với Scrum
1.Bước đầu trong Scrum là Product Owner là làm rõ tầm nhìn sản phẩm.Cuối cùng đưa ra cách Product Backlog (chỉ 1 backlog tồn tại).Product Owner đc yêu cầu ưu tiên hóa toàn hạng mục công việc,thể hiện quyền lợi của các nhóm liên quan và bị chi phối bởi nhóm phát triển
Xem tài liệu ở dưới
2.Họp kế hoạch Sprint:Họp để xem xét hạng mục .nhóm phát triển có hiểu thấu suy nghĩ của Product Owner không,đảm bảo về mặt kĩ thuật.Nhóm quyết định cảm kết hoàn thành bao nhiêu công việc.Một khi năng lực sản xuất đã xác định ,nhóm phát triển tính toán hạng mục trong Product Backlog mà họ có thể hoàn thành ,và cách họ sẽ tiến thành các hạng mục đó.Thường thì việc này sẽ bắt đầu thảo luận về thiết kế bảng trắng.Khi hiểu thiết kế tổng thể ,nhóm phát triển phân tách các hạng mục trong Product Backlog.Product Owner phải sẵn sàng làm sáng tỏ các vấn đề (_nếu cần).Nhóm phát triển sẽ tiến hành tuần tuần tự như vậy từ trên xuống dưới của Product Backlog,đến khi sử dụng hết năng lực ước tính.Cuối buổi họp.Nhóm phát triển sẽ đưa ra danh sách tất cả công việc và ước tính khối lượng của chúng.
3.Họp Scrum hằng ngày
4.Cập nhật Sprint Backlog và biểu đồ Sprint Burndown
5.Làm mịn Product Backlog
6.Kết thúc Sprint
Một trong những nguyên lý cốt lõi của Scrum là thời gian của một Sprint không bao giờ đc mở rộng-Sprint phải kết thúc vào đúng ngày đã đc ấn định trước bất kể nhóm phát triển có hoàn thành cam kết hay không!!!
7.Họp sơ kết Sprint
Sau mỗi Sprint sẽ có một buổi họ[p] sơ kết Sprint để nhóm phát triển và Product Owner xem xét lại Sprint vừa diễn ra.Đây là 1 buổi họp sơ kết Sprint là một hoạt động để thanh tra và thích nghi dành cho sản phẩm.Đó là cơ hội để Product Owner tìm hiểu những gì đã đc làm về sản phẩm và nhóm phát triển (xem xét lại Sprint) và là cơ hội để nhóm phát triển biết về các yêu cầu cua Product Owner và thì trường.Bởi thế,yếu tố quan trọng của buổi họp là trao đổi chất lượng giữa nhóm phát triển và Product Owner để xem xét tình hình,đưa ra lời khuyên
8.Họp cải tiến Sprint
Buổi họp sơ kết Sprint tập trung vào việc thành tra và thích nghi hướng đếns ản phẩm .Trong khi đó,buổi họp cải tiến Sprint đc tiến hành ngay sau buổi Sơ kết lại hướng việc thanh tra và thích nghi vào quy trình.Dây là một thực tế mà nhiều nhóm bò qua,vạ thật không may,đó lại là cơ chế chủ đạo mang lại sự minh bach vốn có trong Scrum ,điều sẽ đem đến cơ hội cải tiến và chuyển thành kết quả .Đây là cơ hội cho Nhóm Scrum thảo luận xem điều gì làm đc và chưa đc ,và đồng ý với các thay đổi thử nghiệm .Thành phần tham dự buổi họp là nhóm phát triển ,Scrum Master và Product Owner có thể tham dự nhưng không bắt buộc.Scrum Master sẽ đóng vai trò là điều phối viên trong buổi họp.nhung tốt hơn là một người trung lập nắm giữ vai trò này,một cách tiếp cận tốt cho Scrum Master để giúp các thành viên cải tiến lẫn nhau ,là phép sự trao đổi chéo giữa các thành viên trong đội.
-------------------------------------------------------------------------------------------------------------------------------
9.Cập nhập Release Backlog và biểu đồ Release Burndown
10.Khởi đội Sprint tiếp theo
11.Sprint phát hành
12.Lâ[p] kế hoạch phát hành và làm mịn Product Backlog ban đầu
-----------------------------------------------------------------------------------------------------------------------------------
13.Tập trung vào ứng dụng sản phẩm
//Những thách thức phổ biến
Scrum không chỉ đúc rúc từ thực tiễn-hơn thế và quan trọng hơn nó là 1 khung làm việc mang đến sự minh bạch,và một cơ chế cho phép "thanh tra và thích nghi"Scrum thực hiện điều này bằng cách phát lộ ra các chức năng hộn độn và trở ngại ảnh hưởng đến hiệu suất làm việc của Product Owner và nhóm phát triển,để họ có thể giải quyết chúng.
Ví dụ:Product Owner thực sự không hiểu rõ về thị trường,hoặc cách ước tính các giá trị liên quan .hoặc nhóm phát triển có thể thiếu kỹ năng trong việc ước tính nội lực của mình hoặc công việc phát triển
Scrum sẽ giúp nhanh chóng phát hiện ra các yếu điểm đó.Scrum không giải quyết các vấn đề vể phát triển ,nó làm chó các vấn đề này hiển hiện ra như một vấn đề nhức nhối và cung cấp 1 khung làm việc để mọi người phát hiện ra cách giải quyết những vấn đề đó trong thời gian ngăn,mà chỉ cần thực những cải tiến nhỏ.
Giả sữ nhóm phát triển thất bại trong việc chuyển giao những gì họ đã cam kết trong Sprint đầu tiên do yếu kém trong việc phân tích và kỹ năng ước tính.Đối với nhóm phát triển họ cảm thấy như là một thất bại.Nhưng trong thực tế ,kinh nghiệm này là bước đầu tiên cần thiết để họ thực tế hơn và thận trọng hơn với những cam kết của mình .mô hình này cùa Scrum giúp làm rõ các chức năng hỗn độn,cho phép nhóm phát triển phát triển thực hiện điều gì đó với vấn đề này ,nó là một co chế cơ bản mạng lại những lợi ích rất quan trọng với những nhóm phát triển có kinh nghiệm trong việc sử dụng Scrum.
Một sai lầm phổ biên nảy sinh khi phát triển Scrum trong thực tế đó là thay đổi Scrum,đây chính là một thách thức.
ví dụ:nhóm phát triển khi gặp khó khắn trong việc thực hiện những cam kết của họ trong một sprint nào đó họ có thể đi đến quyết định kéo dài thời gian triển khai không bao giờ nhóm học đc cách làm việc tốt hơn với khoảng thời gian đã ước tính và quản lí thời gian của mình.Với cách thức này,nếu không có sự huấn luyện và hỗ trợ của một Scrum master có kinh nghiệm,tổ chức có thể thay đổi Scrum thành một hình ảnh phản chiếu các khuyết điểm và sự xung độ chức năng của chinh họ ,đồng thời hủy hoại những lợi ích thực sự mà scrum đem lại.Làm lộ rõ các mặt tốt và xấu và cung cấp cho tổ chức những lựa chọn để nâng họ lên một tầm cao mới.
Một sai lầm phổ biên khác là việc cho rằng một hoạt động nào đó trong Scrum ko đc khuyến khích hoặc bị ngăn cấm chỉ vì Scrum không đưa ra yêu cầu bắt buộc về nó.
Ví dụ:Scrum không quy định Product Owner thiết lập 1 chiến lược dài hạn cho sản phẩm của mình,cũng ko yêu cầu các kỹ sư tìm kiếm lời khuyên từ những người có kinh nghiệm hơn về những vấn đề kỹ thuật phức tạp .Scrum để mặc cho mỗi cá nhân có liên quan đưa ra những quyết định đúng đắn và nhiều trường hop,cả 2 thực tế (cùng nhiều thứ khác)đều là những lời khuyên tốt.
Trái lại,có những điều cần cảnh giác khi các nhà quản lí áp dụng Scrum vào nhóm phát triển của họ.scrum mạng lại cho nhóm phát triển không qian riêng và công cụ để họ tự quan,và việc có các quyết định áp đặt từ trên xuông sẽ không đem lại sự thành công.Cách tiếp cận tốt hơn với một nhóm phát triển khi mới bắt đầu nghiên cứu về scrum là từ một đơn vị ngang hàng hoặcnhà quản lí.triển khái huấn luyện một cách chuyên nghiệp và toàn diện,và say đó đưa ra các quyết định để 1 nhóm triển khai thực tế trong một giai đoạn nhất định,cuối giai đoạn đó,nhóm phát triển sẽ đánh giá những trải nghiệm của mình và quyết định việc có tiếp tục triển khai hay không.