Chương 4 : Ứng dụng Agile/Scrum trong dự án phát triển ứng dụng trên smartphone
4.3 Cách thức đội quản lý dự án theo quy trình Agile/Scrum
4.3.3 Xây dựng print backlog cho iOs và Website
Product Owner tạo Product backlog và chia product backlog thành các task nhỏ trong mỗi sprint. Mô hình 4.4 diễn tả các công việc của đội phát triển và chia công việc phát triển ứng dụng.
Đầu tiên Product Owner tạo product backlog. Đối với n
Hình 4.4: Chia công việc cho mỗi Scrum Team
Sub-backlog Sub-backlog
Sub-backlog
PO
Sau khi đã chia xong sprint cho mobile. Leader bên mobile xác định các service cần thiết và yêu cầu backend làm các service đó.
Story id Story name Points Name of Dev
1 Register screen 8 Duy
2 Login screen 4 Duy
3 Settings screen 8 Duy
4 Create post 8 Tring
5 Show Users 8 Duy
6 Show user profile 8 Duy
7 Show followers 8 Duy
8 Capture photo / record video, set duration 16 Tring
9 Set Post type 8 Tring
10 Share created Post on Story 16 Trinh
11 add text to photo/video, free draw 16 Hoang
12 apply filter to photo/video 8 Hoang
13 add lat long, city to Post 8 Hoang
14 add hashtags to Post 8 Hoang
15 store Media locally 8 Hoang
16 open & edit saved Media (trim video), then share / delete
16 Hoang
17 share created Post 8 Trinh
18 select all (Followers) 8 Trinh
19 group Users into clusters 16 Duy
20 list visible Users on Map 16 Duy
21 show Story length 8 Trinh
22 view User's Story 8 Trinh
23 show Users 16 Duy
24 view new posts 16 Duy
25 list Users that shared something 8 Hoang
26 view shared Posts 8 Hoang
27 list of Posts 8 Hoang
Product Backlog cho API
Story id Story name Points Name of Dev
1 Register 8 Duy
2 Login 4 Duy
3 edit user 8 Duy
4 upload/change avatar 8 Trung
5 upload media 8 Trung
6 upload Post 8 Trung
7 share Post to Story 8 Trung
8 list "active" Users 4 Duy
9 get user info 4 Duy
10 follow user 8 Duy
11 download media 8 Trung
12 store latest Post lat long to user info (logic) 8 Trung 13 story length, lat long in get user info 8 Trung 14 get story's posts of a User (public/followed
private)
8 Trung
15 get post info 8 Trung
16 list "Feed" Users (Users I followed, with count of "new" seconds)
Duy 17 list new Posts of "Feed" user 16 Duy
18 list Followers 8 Duy
19 share a new Post to some of the Followers 16 Trung 20 list "Notification" Users (Users who shared
something to me)
8 Duy
21 list shared Posts of "Notifications" user 8 Duy Estimate thời gian hoàn thành công việc của mỗi thành viên
Ở mỗi đội dự án. Trong cuộc họp Sprint sẽ chia các Task cho các thành viên trong nhóm và các thành viên trong nhóm sẽ ước lượng thời gian phát triển dự kiến.
Cụ thể các công việc của đội iOS trong Sprint 1 như sau
Story ID Story Name Points Name of Dev Start Date End Date
1 Register screen 16 Duy Phạm 1/9/2015 2/9/2015
2 Login screen 8 Duy Phạm 3/9/2015 3/9/2015
Story ID Story Name Points Name of Dev Start Date End Date
4 Show Users 8 Duy Pham 4/9/2015 4/9/2015
5 Show user profile 16 Trinh Nguyễn
1/9/2015 4/9/2015
6 Create Post 24 Trinh
Nguyễn 2/9/2015 5/9/2015 7 add text to photo/video, free draw 24 Hoang 2/9/2015 5/9/2015
Áp dụng công cụ Trello để quán lý dự án phát triển phần mềm trên Smartphone.
Là một công cụ để phối hợp công việc hiệu quả giúp cho mọi người trong team chỉ cần nhìn qua là biết được có những đầu việc nào, ai đang làm gì, và làm đến giai đoạn nào rồi. Dựa vào các task trong sprint tạo các card trong trello để quản lý được công việc của từng thành viên và tiến độ thực hiện công việc. Trong mỗi card detail thêm các thành viên làm một công việc và thêm deadline cho mỗi công việc.
Trello rất đơn giản trong việc thao tác bằng việc dễ dàng tạo các cột. Các cột này là nơi chứa các công việc đang hoàn thành ở mức độ nào.
Áp dụng vào quản lý dự án bằng Agile/Scrum, ta xây dựng các cột như hình…
Hình 4.5: Luồng thực hiện tác nghiệp Backlog Backlog
Task 9
Task 10
Task 11
Todo Doing Review Done
Task 8 Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7
Backlog để chứa các công việc trong một sprint
Todo chứa các task chuẩn bị làm
Review chứa các task trong thời gian test
Done chứa các task đã hoàn thành 4.3.4 Quy trình thực hiện
Ban đầu tất cả các task sau khi họp chia sprint sẽ để trong BackLog. Trong cuộc họp daily meeting sẽ phân chia công việc cho các thành viên trong đội. Khi bắt đầu một công việc sẽ kéo task từ cột backlog sang cột Todo. Các task đang làm sẽ
kéo sang cột Doing, sau khi hoàn thành xong kéo từ cột doing sang cột review để
tester kiểm tra lại. Nếu task đó đã đúng rồi tester sẽ kéo sang Done, nếu chưa sẽ kéo lại về
Todo
Hình 4.6: Liệt kê các công việc trong sprint 1 của dự án trong trello
Trong mỗi card trong sprint backlog tạo check list để liệt kê các công việc của sprint như hình bên dưới. Tạo các đường dẫn ở mỗi item của checklist cho mỗi card detail.
Hình 4.7: Chi tiết của Sprint 1
Sau khi tạo công việc và chia công việc cho mỗi thành viên, các thành viên kéo card của mình sang doing.
Trong thời gian thực hiện công việc, vào 8h30 các buổi sáng hàng ngày trừ thứ 7 và chủ nhật nhóm họp scrum hàng ngày
Mỗi công việc được hoàn thành, ở trong git các dev sẽ tạo một branch mới là tên card cả mình và pust lên để yêu cầu teamlead pull code vể và kiểm tra xem chức năng đã đúng hay chưa. Trong khi đó ở trong trello các developer kéo card công việc đó sang review. Để bên test đã đúng chưa, card nào đã đúng teamlead chuyển sang done.
4.3.5 Họp scrum hàng ngày
Cuộc họp lúc 8h30 bao gồm các thành viên của đội mobile và backend. Nội dung cuộc họp bao gồm
- Trình bày công việc hôm trước làm được của mỗi thành viên trong nhóm - Mỗi thành viên khó khăn gì nếu ra để cả nhóm cùng giải quyết
- Trình bày công việc ngày hôm nay làm gì
- Đội backend cung cấp cho mobile những service nào đã hoàn thành.
4.3.6 Tổng hợp kết quả trên biểu đồ
Dựa vào biểu đồ tổng hợp kết quả làm việc trong một Sprint của Trello để biết dự án đang được tiến hành đến đâu, còn lại khoảng bao lâu thời gian để hoàn thành. Những chuyển biến của công việc còn lại cho đến từng cột mốc sẽ được hiển thị trong đường diễn tả công việc hoàn thành thực tế. Ta có thể xem được mức chênh lệch giữa đường mô tả ban đầu theo kế hoạch và đường diễn tả thực tế đạt được để hiểu tình trạng tiến độ cho đến mốc tiếp theo.
Hình 4.8: Biểu đồ mô tả hoạt động của cả dự án
Như trong hình trên là diễn tả quán trình thực hiện trong dự án ở hình bên trái và tóm tắt các số liệu thống kê của dự án. Mô tả biểu đồ gồm:
- Đường màu xanh là thời gian còn lại của hệ thống
- Đường màu da cam là đường mô tả thời gian thực hiện lý tưởng cho dự án. - Đường màu đỏ là đường mô tả thời gian thực khi thực hiện dự án.
Qua biểu đồ cho ta thấy được đến thời điểm hiện tại thời gian thực hiện dự án đã vượt quá thời gian lý tưởng đặt ra từ ban đầu. Nhìn vào biểu đồ ta thấy hoạt động của
dự án từ khi bắt đầu phát triển là tháng 9 đến giữa tháng 10 và tháng 11 đã vượt qua mức thời gian lý tưởng đề ra ban đầu. Nhưng khi so sánh 2 mốc thời gian từ đầu dự án đế giữa tháng 10 và từ giữa tháng 10 đến cuối của dự án, ta thấy:
- Thời gian thực hiện dự án từ đầu đến giữa tháng 10 ước lượng khoảng 270 giờ
- Thời gian thực hiện dự án từ giữa tháng 10 đến cuối dự án ước lượng khoảng 500 giờ. Sự thay đổi về thời gian thực hiện dự án này do việc sử dụng nguồn nhân lực khác có trình độ thấp hơn những thành viên tham gia dự án ở giai đoạn từ đầu đến giữa tháng 10.
Qua bảng tóm tắt số liệu của dự án ở hình bên phải, bao gồm: - Phần trăm thực hiện dự án đang là 65%
- Phần trăm thời gian sử dụng để thoàn thành dự án so với thời gian đề ra là 85%. Nhìn vào số liệu và biểu đồ hoạt động có thể thấy được dự án đang bị chậm rất nhiều so với thời gian ước lượng ban đầu.Một trong những lý do làm ảnh hưởng đến việc này là việc khách hàng thay đổi yêu cầu thường xuyên hay thêm các chức năng mới cho dự án.
4.4 Đánh giá và nhận xét
Sau khi áp dụng Agile Scrum vào quy trình phát triển dự án SEF, một dự án phát triển ứng dụng trên diện thoại iPhone của hãng Apple sử dụng hệ điều hành iOS kết hợp với việc sử dụng Backend API do một đội phát triển độc lập cung cấp.Phương pháp phát triển trước đây đã tạo ra khó khăn trong việc trao đổi thông tin và tiến độ dự án, khó khăn trong phối hợp với nhau giữa các đội sử dụng mỗi nền tảng phát triển khác nhau. Thông qua việc áp dụng phương pháp Scrum of Scrums là một cầu nối kết hợp giữa các đội phát triển phần mềm cũng như là các đội Scrum nhỏ trong một nhóm Scrums. Như trong ví dụ được nêu là dự án SEF thì việc liên kết và phối hợp giữa các đội dự án độc lập là rất quan trọng. Chúng ta có thể thấy ngay những thay đổi nhỏ từ sự thay đổi yêu cầu của khách hàng làm sản phẩm, khi đó cả hai đội dự án đều phản ứng nhanh hơn và kịp thời cập nhật vào các công việc cụ thể của dự án. Ví dụ, khi khách hàng có yêu cầu thay đổi giao diện màn hình, chức năng của hệ thống… Một số thay đổi của khách hàng yêu cầu phải cập nhật những phần hiện tại hoặc phải thêm
API mới. Như thế, dự án đòi hỏi cả hai đội phải theo kịp trong một chu kỳ để không chậm tiến độ của dự án.
Trong việc phát triển dự án bằng quy trình Scrum thì việc linh hoạt trong quan hệ với khách hàng cũng như việc sử dụng nguồn nhân lực cho dự án là rất quan trọng. Để áp dụng quy trình dự án đòi hỏi nguồn nhân lực phát triển tốt và chuyên nghiệp có thể đáp ứng nhanh những thay đổi trong thời gian ngắn.
Dựa vào các số liệu báo cáo và biểu đồ của quản lý dự án được tạo ra trong từng Sprint ở từng mốc thời gian đưa, tình trạng phát triển của dự án đang ở trạng thái như thế nào để đưa ra các quyết định để giải quyết các vấn đề của dự án. Quản trị dự án và các thành viên của các đội sẽ dễ dàng hình dung được và hiểu rõ công việc của từng giai đoạn. Khi có thay đổi sẽ dễ dàng cập nhật và bám theo phù hợp với yêu cầu.
KẾT LUẬN
Trong luận văn này chủ yếu đưa ra giải pháp để giải quyết vấn đề phát triển ứng dụng cho Smartphone để đạt được sản phẩm chất lượng cao trong thời gian ngắn hơn. Scrum là một lựa chọn tốt cho các công ty phát triển ứng dụng cho Smartphone để đáp ứng yêu cầu đó. Bằng việc áp dụng phương pháp phát triển Scrum of Scrums là một phương pháp áp dụng cho các dự án lớn đưa vào sử dụng trong dự án cho Smartphone, là một kiểu dự án không lớn nhưng lại có nhiều nền tảng khác nhau. Scrum of Scrums chia các đội dự án thành nhiều các đội Scrum khác nhau nhằm mục đích dễ dàng hơn trong việc quản lý và chia các công việc rõ ràng hơn. Vì Product Owner hiểu rõ ràng yêu cầu của hệ thống nhưng không thể hiểu rõ chi tiết công việc của từng nền tảng là gì và ai là người có thể thực hiện tốt công việc nào.
Dựa vào đặc điểm của dự án cho Smartphone cho thấy quy trình Agile-Scrum phù hợp để thực hiện được các đặc điểm như là: chu kì phát triển ngắn, thường xuyên được cập nhập, thường xuyên thay đổi yêu cầu với giao diện hoặc tính năng... Việc áp dụng quy trình Agile-Scrum vào dự án SEF nhưng không thành công cho ta thấy được để đạt được một dự án thành công khi sử dụng phương pháp Agile-Scrum cần phải áp dụng đúng quy trình và các yêu cầu cơ bản của quy trình.
Trong quá trình thực hiện đề tài có nhiều điểm cần phải nghiên cứu và cải thiện như là việc áp dụng kiểm thử vào trong mỗi Sprint. Do thời gian có hạn nên không tránh khỏi những nhược điểm và sai sót. Vì thế, tôi rất mong được sự góp ý của các thầy cô và các bạn.
TÀI LIỆU THAM KHẢO Tiếng Việt
1. Ken Swchaber - Jeff Sutherland (2013), Hướng dẫn Scrum.
Tiếng Anh
1. Anthony I. Wasserman (2010), Software Engineering Issues for Mobile Application Development, Carnegie Mellon Silicon Valley, Bldg. 23 M/S 23-14 Moffett Field, CA 94035 USA.
2. Robert Holler President& CEO, Mobile Application Development: A Natural Fit with Agile Methodologies.
3. Andrei Cristian Spataru (2010) , Agile Development Methods for Mobile Applications
4. Alistair Cockburn (2010-2011), Agile Software Development
5. Harleen K. Flora1, Dr. Swati V. Chande, A review and analysis on mobile application development processes using Agile methodologies.
6. David Conhen Mikael Lindvall and Patricia Costa (2004), An Introduction to Agile Methods
7. Anthony I. Wasserman, Software Engineering Issues for Mobile Application Development
8. Shakira Banu Kalee - Ssowjanya HariShankar (2013), Applying Agile Methodology in Mobile Software Engineering: Android Application Development and its Challenges
9. M. Cohn (2006), Agile estimating and planning
10.Abeer M. AlMutairi - M. Rizwan Jameel Qureshi (2015), The Proposal of Scaling the Roles in Scrum of Scrums for Distributed Large Projects
PHỤ LỤC
1. SEFSocial_MasterPlan_v1.0.xlsx 2. SEF_REQM.xlsx