Gioi thieu scrum

1,268 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,268
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
73
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Gioi thieu scrum

  1. 1. Cộng đồng OpenERP Việt Nam terp.vn Giới thiệu sơ lược về ScrumMục tiêu của bài viết này là nhằm giải thích những khái niệm cơ bảnvề Scrum trong khuôn khổ của một bài viết ngắn để bạn đọc có thể hiểu sơ lượcvề Scrum và có thể áp dụng Scrum vào việc phát triển các dự án của bạn. Đây làbài viết lược dịch từ bài của tác giả Stephen Walther.Product Backlog và Product OwnerGiả sự bạn là thành phần của một đội đang có nhu cầu tạo một website mới, ví dụnhư là một website thương mại điện tử (e-commerce). Các bạn có quá nhiều việcđể làm. Các bạn cần phải xây dựng giỏ hàng, cài đặt chứng chỉ SSL, tạo danh mụcsản phẩm, tạo trang giới thiệu trên Facebook và hàm tram thứ khác mà bạn chưakịp nghĩ đến.Theo Scrum, việc đầu tiên bạn nên nghĩ đến đó là tạo ra một danh sách. Hãy đặtcác phần tử có độ ưu tiên cao nhất lên phía trên của danh sách, và các phần tử cóđộ ưu tiên thấp hơn nằm ở dưới. Ví dụ như, tạo ra giỏ hàng và mua domain namelà công việc có độ ưu tiên cao, còn tạo ra trang Facebook thì có lẽ là có độ ưu tiênthấp hơn. Với Scrum, danh sách này được gọi là Product Backlog.Làm sao để bạn đặt độ ưu tiên cho các phần tử trong Product Backlog? Các bênliên quan khác nhau của dự án sẽ có độ ưu tiên khác nhau. Giám đốc sản phẩmthì cho rằng website thương mại điện tử bắt buộc phải có ứng dụng mobile.Manager của bạn thì nghĩa rằng áp dụng các tính năng của HTML5 là quan trọnghơn. Càng nhiều người tham gia, bạn sẽ càng thấy sự khác biệt về quan điểm, vàcó lẽ sẽ làm bạn rối rắm hơn.Theo Scrum, điều quan trọng nhất mà bạn nên làm đó là luôn chọn một người, vàchỉ một người làm Product Owner (chủ của sản phẩm). Product Owner là ngườiquyết định việc nào (hay tác vụ nào) sẽ được đặt vào Product Backlog và độ ưutiên của các phần tử trong Product Backlog. Product Owner có thể là khách hàng – Trang 1/9
  2. 2. Cộng đồng OpenERP Việt Nam terp.vnngười trả chi phí thực hiện, cũng có thể là quản lý dự án – người có trách nhiệmhoàn thành dự án, hoặc là một đại diện của khách hàng. Điểm mấu chốt đó là,Product Owner luôn phải là một người duy nhất và cũng là người duy nhất cóquyền với Product Backlog.Sprints và the Sprint BacklogLúc này, đội phát triển phần mềm đã có danh sách ưu tiên của các nhiệm vụ màhọ có thể làm. Cả đội bắt đầu cài đặt thứ được ưu tiên nhất đó là giỏ hàng. Tuynhiên, khi công việc đi đến nữa đường thì Product Owner có ý thay đổi, anh ta chorằng nên tạo ra danh mục sản phẩm trước khi cài đặt giỏi hàng. Dù hơi phật ý,nhưng cả đội vẫn chuyển qua tập trung vào việc cài đặt danh mục sản phẩm. Tuynhiên, khi công việc đã gần hoàn thành, Product Owner lại thay đổi quan điểm vềviệc được ưu tiên nhất.Khó có thể hoàn thành công việc khi độ ưu tiên dành cho các nhiệm vụ cần thựchiện luôn thay đổi. Tuy nhiên, Product Owner vẫn có quyền để thay đổi độ ưu tiêncủa các công việc cần thực hiện. Để giải quyết mâu thuẫn này, Scrum đưa ra kháiniệm về Sprint. Sprint được dịch bởi Google Translate là cuộc đua nước rút.Khi áp dụng Scrum, nhóm phát triển sẽ làm việc trong các Sprint. Tại thời điểmbắt đầu của một Sprint, các lập trình viên và Product Owner đồng ý về các phần tửđược chọn từ backlog mà họ sẽ phải hoàn thành trong suoosts quá trình của mộtSprint. Danh sách các việc cần hoàn thành lấy ra từ Product Backlog sẽ trở thànhSprint Backlog. Trong suốt quá trình của Sprint, Product Owner không được phépthay đổi các phần tử trong Sprint Backlog. Nói một cách khác, Product Ownerkhông được thay đổi độ ưu tiên của các phần tử cần thực hiện trong suốt thời giandiễn ra Sprint.Thời gian của mỗi Sprint được quyết định tùy thuộc vào mỗi đội phát triển, có thểlà một tháng, hai tuần hoặc chỉ là một tuần. Đối với các dự án mang tính cấpbách, và thời gian là độ ưu tiên số một, các team thường chọn các sprint ngắn(thường là một tuần). Đối với các dự án ổn định, thời gian một tháng sẽ hợp lýhơn. Chúng ta nên chọn thời lượng của một Sprint một cách hợp lý và giúp ổn địnhnhóm phát triển.Daily ScrumTrong suốt mỗi Sprint, nhóm phát triển phải gặp nhau để điều phối công việcnhằm hoàn thành các nhiệm vụ ở Sprint Backlog. Ví dụ, cả nhóm cần phải thảoluận xem thử ai làm việc gì và những vấn đề đã phát hiện ra và cần giải quyết.Các lập trình viên thường ghét họp hành. Họp hành khiến lập trình viên không thểlàm việc chính của họ được, việc chính ở đây là lập trình, thay vào đó họ phải ngồibàn về những chuyện họ cần làm. Tuy nhiên, một đội không bao giờ họp hành vàkhông điều hành công việc của họ sẽ dẫn đến nhiều vấn đề. Ví dụ lập trình viên Ađang gặp phải một vấn đề và không giải quyết được trong nhiều ngày, trong khi Trang 2/9
  3. 3. Cộng đồng OpenERP Việt Nam terp.vnđó anh không biết rằng lập trình viên B đã gặp và giải quyết được. Hoặc có thể cósự chồng chéo, trùng lắp trong công việc của các lập trình viên.Với Scrum, để giải quyết các mâu thuẫn kể trên, đồng thời để đảm bảo tiến độ củacác đội, Scrum đưa ra ý tưởng về Daily Scrum. Daily Scrum là một buổi họp nhằmđiều hướng công việc của nhóm lập trình và là buỗi họp diễn ra mỗi ngày. Để giữcho buổi họp diễn ra nhanh chóng, các lập trình viên chỉ trả lời đối với ba câu hỏisau:1. Bạn đã làm gì ngày hôm qua?2. Bạn định làm gì hôm nay?3. Có gì cản bước bạn không?Trong suốt cuộc họp Daily Scrum, các lập tình viên không được phép nói chuyệnvề các vấn đề không liên quan, trình diễn cái họ đã làm, hay nói về những kinhnghiệm khi giải quyết các vấn đề lập trình. Buổi họp phải diễn ra nhanh gọn,thường la ftrong 15 phút. Các vấn đề được nêu ra trong Daily Scrum sẽ được thảoluận kỹ hơn trong các cuộc meeting khác, và lúc đó không cần thiết phải có sự cómặt của toàn đội.Stories và TasksCác phần tử trong Product Backlog hoặc Sprint Backlog như là xây dựng giỏ hànghoặc tạo ra trang Facebook thường được gọi là User Stories hoặc Stories. CácStories được tạo bởi Product Owner và chúng thường nói về nhu cầu dành cho sảnphẩm.Khác với Product Owner, các lập trình viên cần phải nghĩ cách để cài đặt cho cácStory. Tại thời điểm bắt đầu của mỗi Sprint, nhóm phát triển sẽ lấy các Stories từSprint Backlog và chia nhỏ các story thành các tasks (tác vụ).Ví dụ, nhóm phát triển sẽ phân nhỏ story “Tạo giỏ hàng” thành các nhiệm vụ nhưsau:• Cho phép người dùng thêm và quản lý các phần tử trong giỏ hàng.• Cập nhật giỏ hàng vào database sau mỗi lần viếng thăm• Chuyển người dùng đến trang thanh toán khi nút Thanh toán được nhấn.Trong suốt cuộc họp Daily Scrum, thành viên của nhóm phát triển sẽ xung phonghoàn thành các task cần để cài đặt cho Story tiếp theo có trong Sprint Backlog.Khi một lập trình viên nói về những việc anh ta đã hoàn thành vào ngày hôm qua,và những việc sẽ làm kế tiếp, anh ta nên nói về các task.Stories được sở hữu bởi Product Owner và mỗi story thường nói về giá trị thương Trang 3/9
  4. 4. Cộng đồng OpenERP Việt Nam terp.vnmại mang lại. Ngược lại, các task là do nhóm phát triển sở hữu, và task nói mộtcách chi tiết về việc cài đặt. Mỗi story nếu muốn được cài đặt thì cần vài ngàyhoàn vài tuần để hoàn thành. Một task là một công việc mà một developer có thểhoàn thành trong một khoảng thời gian ít hơn một ngày.Một số nhóm thường biếng nhác và không chia nhỏ các stories thành tasks. Việckhông chuyển các stories thành tasks có thể biến các câu chuyện trở thành“những câu chuyện không có hồi kết”. Nếu bạn không phân nhỏ một story thànhcác tasks, bạn sẽ chẳng thể nào biết được một story sẽ được hoàn thành như thếnào, bao nhiêu lâu, bởi vì bạn không có ý tưởng rõ ràng cho việc cần bao nhiêubước để hoàn thành một story.ScrumboardTrong mỗi Daiy Scrum, nhóm phát triển sẽ sử dụng Scrumboad để quản lý côngviệc của họ. Một Scrumboard sẽ có danh sách các stories của Sprint hiện tại, cáctác vụ thuộc về mỗi Story, và trạng thái của mỗi Tasks. Mỗi thành viên trong nhómsẽ thấy được tiến độ công việc của bất cứ người nào khác trong nhóm. Trang 4/9
  5. 5. Cộng đồng OpenERP Việt Nam terp.vnKhi lập trình viên làm việc với một task, thì task sẽ được chuyển trạng thái nàysang trạng thái khác, và trạng thái của task sẽ được cập nhật trên Scrumboard.Các task thông thường có các trạng thái là ToDo, In Progress và Done (Cần làm,Đang làm, và xong). Một số nhóm còn thêm các trạng thái như Needs Review,Needs Testing (cần xem lại, cần kiểm thử).Một số nhóm sử dụng bảng Scrumboard vật lý. Lúc đó, bạn sẽ sử dụng các miếnggiấy để thể hiện các stories và các tasks và bạn sẽ dán các miếng giấy đó lênbảng vật lý.Sử dụng bảng Scrumboard vật lý mang lại đôi chút bất lợi. Thứ nhất là nó khôngphù hợp với những nhóm làm việc phân tán. Thứ hai, tạo ra các báo cáo từ bảngScrumboard vật lý sẽ khó hơn nhiều so với việc xuất ra các báo cáo từ onlineScrumboard.Ước lượng cho Stories và TasksCác bên liên quan trong dự án, những người đầu tư vào dự án cần phải biết dự ánđang tiến triển như thế nào và khi nào dự án sẽ hoàn thành. Và bạn không thể trảlời rằng “dự án sẽ sớm xong thôi”, hoặc “chắc là sắp xong rồi”, hay “còn lâu nữamới xong”, bởi vì các bên liên quan có ngân quỹ giới hạn để đầu tư cho dự án. Vànếu không biết được khi nào xong, thì các bên liên quan hoàn toàn không thể xácđịnh giá trị mang lại của dự án.Các lập trình viên ghét phải ước lượng thời gian phát triển các tính năng. Lý dochính là bởi vì hầu như chả bao giờ họ có thể ước lượng đúng, và họ chỉ có thể ướclượng khi bắt tay vào nghiên cứu, và chỉ có thể biết được thời gian chính xác khihọ đã làm xong. Bởi lập trình giống như việc tìm ra phương thuốc chữa bệnh ungthư hơn là ngồi xây một bức tường bằng gạch. Việc xây tường thì thật đơn giản, cứthế mà trộn hồ, trét vữa bỏ gạch.. là xong. Việc xây tường quen thuộc đến mứchầu như chả có chuyện gì xảy ra để mà ngạc nhiên.Viết mã chương trình thì lại giống như việc tìm phương pháp chữa bệnh ung thư,bác sĩ sẽ không thể đoán được khi nào sẽ tìm ra phương pháp chữa bệnh nếu bạnđòi hỏi ông ta ước lượng thời gian. Lý do chính để không ước lượng được là vì bàitoán có nhiều yếu tố chưa xác định. Và thật khó để có thể ước lượng được nếukhông bắt tay vào nghiên cứu và chữa bệnh.Rõ ràng là các lập trình viên ghét phải ước lượng, nhưng Product Owner và cácbên liên quan lại cần có ước lượng. Scrum sẽ giải quyết mâu thuẫn này bằng cáchsử dụng ý tưởng Story Points.Các đội khác nhau sẽ dùng các loại đơn vị khác nhau để đại diện cho các StoryPoints. Một số nhóm dùng kích thước của áo quần như Small, Medium, Large và X-Large. Một số nhóm lại thích dùng kích cở của ly cà phê như Tall, Shot và Grande. Trang 5/9
  6. 6. Cộng đồng OpenERP Việt Nam terp.vnCác nhóm khác lại thích sử dụng các số lấy từ dãy Fibonacci.Cho dù bạn có chọn loại đơn vị để đại diện cho Story Points như thế nào đi nữa, thìmục tiêu vẫn là giống nhau. Thay vì ước lượng một Story theo giờ (thường thì lúcnào cũng ước lượng sai), bạn sẽ dùng phương thức đo ít chi li hơn. Nhóm lập trìnhsẽ thích ước lượng một Story là Small hoặc X-Large hơn là số lượng chính xác làbao nhiêu giờ để để hoàn thành một Story. Như vậy, Story Points cũng có thể xemlà sự thỏa hiệp giữa nhu cầu của Product Owner và nhu cầu của nhóm phát triển.Khi Sprint bắt đầu, nhóm phát triển sử dụng nhiều thời gian để suy nghĩ về cácStories trong Sprint và chia nhỏ các Stories thành các Tasks. Trong Scrum, bạn ướclượng thời gian hoàn thành Story bằng các Story Points và bạn sẽ ước lượng khốilượng công việc cần phải làm để hoàn thành mỗi task bằng giờ.Sự khác biệt giữa Stories và Tasks đó là bạn không tạo ra một task cho tới khi bạnsẵn sàng làm việc với một task. Một task là thứ mà bạn có tể tạo và thực hiệntrong một ngày, và lúc đó bạn có thể ước lượng chính xác để hoàn thành một taskhơn là một story.Burndown ChartsỞ Scrum, bạn có thể sử dụng Burndown charts để hiển thị những công việc còn lạicủa một dự án. Bạn sử dụng Release Burndown charts để hiển thị công việc còn lạicủa một dự án và bạn có thể sử dụng Sprint Burndown charts để hiển thị côngviệc còn lại của một Sprint.Bạn có thể tạo ra Release Burndown chart bằng cách tính toán số Story Pointschưa hoàn thành của Product Backlog mỗi ngày. Trục dọc của biểu đồ biểu diễn sốlượng Story Points, và trục ngang của biểu đ biểu diễn thời gian. Trang 6/9
  7. 7. Cộng đồng OpenERP Việt Nam terp.vnSprint Burndown chart cũng tương tự như Release Burndown chart, nhưng nó tậptrung vào các công việc còn lại cho một Sprint cụ thể. Có hai loại Sprint Burndownchart. Bạn có thể hiển thị khối lượng công việc của một Sprint bằng Story Pointshoặc bằng giờ.Khi mỗi Story trong Product Backlog được hoàn thành, đường đồ thị trong ReleaseBurndown chart sẽ đi xuống. Khi mỗi Story hoặc task được hoàn thành, đường đồthị Sprint Burndown chart cũng sẽ đi xuống.Mục đích của Burndown chart là giúp cho bạn có thể theo dõi tiến trình làm việccủa cả nhóm. Nếu qua nữa thời gian của một Sprint, Sprint Burndown chart vẫncòn rất cao thì rõ ràng là đội của bạn đang gặp vấn đề.Team VelocityCác bên liên quan trong một dự án luôn muốn công việc được làm nhanh hơn nữa.Ví dụ, Product Owner của website thương mại muốn website sẽ online một thờigian ngắn. Các lập trình viên có thể sẽ rất lạc quan và sẽ đồng ý với yêu cầu củaProduct Owner. Tuy nhiên, hiếm khi các lập trình viên biết được giới hạn vật lý củachính họ.Thường thì các bên liên quan và nhóm lập trình hay ước lượng thời gian phát triểnphần mềm quá hoàn hảo, với năng suất tối ưu. Điều đó dẫn đến một thực tế là, rấtnhiều dự án phần mềm bắt đầu với ước lượng rất lạc quan và sau đó lại trễ hẹn Trang 7/9
  8. 8. Cộng đồng OpenERP Việt Nam terp.vnmột cách đáng thất vọng.Với Scrum, vấn đề trên sẽ được khắc phục thông qua một đại lượng có tên là TeamVelocity (velocity có nghĩa là vận tốc). Team Velocity là số lượng Story Points trungbình mà nhóm lập trình hoàn thành trong các Sprints trước.Xác định được Team Velocity rất quan trọng đối với cuộc họp Sprint Planning, vì tạithời điểm đó Product Owner và nhóm lập trình sẽ làm việc cùng nhau để ước đoánsố lượng stories có thể hoàn thành trong Sprint tiếp theo. Nếu xác định được TeamVelocity, bạn có thể tránh được việc giao công việc quá sức của nhóm so với khảnăng đã thể hiện trước đây, và nhóm của bạn có thể hoàn thành tất cả các côngviệc cần thiết cho Sprint tiếp theo.Scrum MasterCó ba vai trò trong Scrum: Product Owner, nhóm phát triển và Scrum Master.Chúng ta đã đề cập đến Product Owner. Product Owner là người duy nhất quản lýProduct Backlog và sắp xếp độ ưu tiên của các stories.Chúng ta cũng đã đề cập đến vai trò của nhóm phát triển. Các thành viên củanhóm phát triển làm công việc triển khai xây dựng các stories bằng cách chia nhỏcác stories thành các task.Có một vai trò mà chúng ta chưa nhắc đến, đó là Scrum Master. Scrum Master cóvai trò đảm bảo cho cả đội làm việc theo quy trình Scrum. Ví dụ, Scrum Master sẽđảm bảo cả đội sẽ tham gia các cuộc họp Daily Scrum và trong mỗi cuộc họp cácthành viên sẽ trả lời đầy đủ ba câu hỏi tiêu chuẩn.Scrum Master cũng có vai trò loại bỏ các chướng ngại (không phải về kỹ thuật) màcả nhóm có thể mắc phải. Ví dụ, nếu cả đội không thể làm việc cho tới khi mọingười đều cài đặt phiên bản mới nhất của Microsoft Visual Studio, vìvậy, Scrum Master sẽ làm việc với IT để đảm bảo phiên bản mới nhất của VisualStudio được cài đặt càng sớm càng tốt.Scrum Master có thể là thành viên của đội phát triển. Tuy nhiên, vị trí này có thểcho những người khác nhau đảm đương. Một điều bạn cần đặc biệt lưu ý, đólà Scrum Master không thể là Product Owner, hay nói theo một cách khác, khôngthể để một người đảm nhiệm cùng một lúc hai vai trò này.The Scrum Master can be a member of the developer team. Furthermore, differentpeople can take on the role of the Scrum Master over time. The Scrum Master,however, cannot be the same person as the Product Owner.Tổng kếtBài viết này đã đề cập nhiều khái niệm cơ bản về Scrum. Bạn đã được biết Product Trang 8/9
  9. 9. Cộng đồng OpenERP Việt Nam terp.vnOwner sử dụng Product Backlog để tạo và sắp xếp độ ưu tiên của các stories.Chúng ta cũng đã được giải thích tại sao công việc được hoàn thành trong cácSprints, và nhờ vậy nhóm lập trình làm việc có hiệu suất cao hơn.Chúng ta cũng đã được giải thích về cách mà nhóm lập trình viên sử dụngdaily scrum để quản lý công việc. Bạn cũng đã biết về cách mà nhóm lập trìnhviên sử dụng Scrumboard để xem, theo dõi ai đang làm tác vụ gì và trạng thái củamỗi task.Chúng ta cũng đã được giới thiệu sơ qua về các biểu đồ Burndown. Chúng ta cũngđã biết cách sử dụng Realease Burdown charts và Sprint Burndown charts để theodõi tiến trình của đội trong việc hoàn thành dự án.Cuối cùng bài viết đã mô tả vai trò của Scrum Master, người có vai trò đảm bảocác quy tắc của Scrum được tuân thủ.Mục tiêu của bài viết này không phải để diễn tả tất cả các khái niệm của Scrum.Bài viết này chỉ nhằm giới thiệu tổng quan. Để hiểu rõ về Scrum, bạn nên đọccuốn sách của Ken Schwaber có tựa đề “Agile Project Management with Scrum”.(Nguồn internet) Trang 9/9

×