Tổng quan về đề tài
Tổng quan về đề tài
Trong những năm gần đây ngành công nghiệp di động đang chứng kiến sự phát triển nhanh chóng về số lượng thiết bị di động được sử dụng cũng như sự phát triển mạnh mẽ về công nghệ Bảng thống kê bên dưới liệt kê chi tiết tỷ lệ phát triển của thị trường Smartphone từ năm 2010 đến năm 2014
Hình 1.1 Mô tả quá trình phát triển của Smartphone từ năm 2010-2014 (Nguồn http://techlomedia.in)
Cùng với sự phát triển mạnh mẽ của Smartphone ở trên toàn thế giới thì thị trường Smartphone ở Việt Nam cũng đang phát triển Thông qua việc thống kê của tổ chức GFT Forecasts ở năm 2015 thì Việt Nam đang được đứng thứ 9 trên thế giới về số lượng Smartphone sử dụng
Hình 1.2: Danh sách 10 quốc gia sử dụng Smartphone nhiều nhất (Nguồn http://blog.gfk.com)
Cùng với sự phát triển về số lượng cũng như về công nghệ của Smartphone các ứng dụng cho Smartphone cũng phát triển không ngừng Cụ thể sự phát triển các ứng dụng cho Smartphone được nhìn thấy rõ rệt trong biểu đồ bên dưới
Hình 1.3: Biểu đồ thể hiện sự phát triển ứng dụng từ năm 2009-2013
(Nguồn https://research2guidance.com) Chính vì lẽ đó ngành công nghiệp di động có sự cạnh tranh cao và năng động
Việc phát triển ứng dụng cho Smartphone đòi hỏi các công ty về phần mềm cho điện thoại di động phải có một quy trình phát triển phần mềm nhanh và thỏa mãn được yêu cầu khách hàng
Agile là một quy trình giúp cho việc phát triển phần mềm được nhanh gọn và linh hoạt hơn Do đó, khi sử dụng phương pháp Agile cho việc phát triển phần mềm làm cho quá trình phát triển phần mềm đủ linh hoạt để thích ứng với các công nghệ nhanh chóng và dễ dàng khi công nghệ thay đổi Trong việc phát triển ứng dụng trên Smartphone, phương pháp này là rất quan trọng vì các ứng dụng được thay đổi và phát triển dựa trên yêu cầu của người dùng là ngay lập tức Đối với các đội tập trung vào yêu cầu của khách hàng thông qua việc phát triển ứng dụng trên một quy trình phát triển sản phẩm thì Agile là phương pháp lý tưởng để làm được điều này.
Phương pháp nghiên cứu
- Tìm hiểu phương pháp phát triển phần mềm Agile và so sánh phương pháp phát triển phần mềm Agile với các quy trình phát triển phần mềm truyền thống khác
- Tìm hiểu quy trình phát triển phần mềm Agile-Scrum là một quy trình phát triển phần mềm dựa trên các đặc điểm của phương pháp phát triển phần mềm nhanh nhẹn Agile
- Nghiên cứu về các đặc điểm của thiết bị Smartphone và đặc điểm của các dự án Smartphone, qua đó cũng tìm hiểu các quy trình phát triển phần mềm cho Smartphone đã được sử dụng như Mobile D, MASAM, SLeSS
- Nghiên cứu cách thức để thực hiện dự án Smartphone dựa trên mô hình Agie-Scrum và áp dụng vào dự án phát triển ứng dụng SEF là một dự án phát triển trên Website và nền tảng iOS để đưa ra các đánh giá và nhận xét chi tiết về phát triển ứng dụng cho Smartphone sử dụng quy trình Agile-Scrum.
Tổng quan về Agile
Tìm hiểu chung về Agile
Phương pháp Agile để phát triển phần mềm đã trở nên lan rộng trong thời gian qua Cụ thể là vào tháng 2 năm 2015 theo khảo sát của tổ chức Scrum Alliance Những ý tưởng của phương pháp này có nguồn gốc từ phương pháp lặp của Lean Manufacturing (1940) và Agile Manufacturing (1990) Trong đó nhấn mạnh khả năng thích nghi của các công ty đến một môi trường năng động Các tính năng độc đáo của phương pháp này được tìm thấy trong “Agile Manifesto” là cá nhân và tương tác quan trọng hơn quy trình nghiệp vụ, sản phẩm tốt hơn tài liệu đầy đủ
Phát triển phần mềm linh hoạt (Agile software development) là một triết lí cùng với nhóm các phương pháp và phương pháp luận phát triển phần mềm dựa trên các nguyên tắc phát triển phân đoạn lặp (iterative) và tăng trưởng (incremental), theo đó nhu cầu và giải pháp tiến hóa thông qua sự hợp tác giữa các nhóm tự quản và liên chức năng Agile thường sử dụng cách lập kế hoạch thích ứng (adaptive planning), việc phát triển và chuyển giao theo hướng tiến hóa sử dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển
2.1.2 Vì sao nên sử dụng Agile?
- Sản phẩm của một dự án phần mềm là khác nhau nên việc áp dụng một quy trình để phát triển hàng loạt là rất khó khăn
- Ngay từ đầu khách hàng khó có thể hình dung đầy đủ các yêu cầu đặt ra cho sản phẩm mà phải qua quá trình hình thành nên việc ứng phó với những thay đổi yêu cầu sẽ giúp giảm thiểu rủi ro cho dự án
- Đảm bảo sản phẩm đầu ra đúng theo nhu cầu của khách hàng
2.1.3 Các đặc trƣng của Agile
Có rất nhiều cách tiếp cận khác nhau với phương pháp Agile Bên cạnh các cách thức tổ chức công việc, thiết lập quy trình, các phương pháp Agile còn nghiên cứu và đưa vào sử dụng các công cụ và kĩ thuật đặc thù như công cụ tích hợp liên tục kiểm thử đơn vị, mẫu thiết kế, tái cấu trúc, phát triển hướng kiểm thử, phát triển hướng hành vi, hay lập trình theo cặp … để đảm bảo và gia tăng tính linh hoạt
Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại Các phân đoạn (được gọi là Sprint) này thường có khung thời gian ngắn (từ một đến bốn tuần) Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử (với các mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm
Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng Các phần nhỏ này thường là đầy đủ, có khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử dụng ngay Theo thời gian, phân đoạn này tiếp nối phân đoạn kia, các phần chạy được này sẽ được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn
Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, và việc lập kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu …) đều có thể được đáp ứng theo cách thích hợp
Ràng buộc về thời gian (Time - Bound)
Thời gian luôn là vấn đề rất quan trọng trong việc phát triển phần mềm bằng Agile Nó xác định thời gian hoàn thành dự án và mỗi sprint phát triển dự án để bàn giao sản phẩm cho khách hàng kiểm tra xem đúng yêu cầu và chức năng hay không
Quản lý thực nghiệm (Empirical Process Control)
Các nhóm Agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì tính toán lý thuyết hay các giả định Việc phân nhỏ dự án thành các phân đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển thu thập dữ kiện cho phép điều chỉnh các chiến lược phát triển của mình Theo thời gian, các chiến lược này sẽ tiến gần đến trạng thái tối ưu, nhờ đó nhóm có thể kiểm soát được tiến trình, và nâng cao năng suất lao động
Dựa trên giá trị (value - based)
Một trong những nguyên tắc cơ bản của Agile là phần mềm chạy tốt chính là thước đo tiến độ Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm Để vận hành được cơ chế “làm việc dựa trên giá trị”, nhóm Agile thường làm việc trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng), cộng tác trực tiếp với họ để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn cho dự án Nhờ đó các dự án Agile thường giúp khách hàng tối ưu hóa được giá trị của dự án
Chính vì thế, Agile làm gia tăng đáng kể độ hài lòng của khách hàng
2.1.4 Ưu điểm và nhược điểm của phương pháp Agile
Có một số lý do khiến Agile được sử dụng rộng rãi và bàn giao được một sản phẩm hoàn thiện theo đúng yêu cầu của khách hàng
- Ưu điểm đầu tiên có thể nói đến ở đây đó là sự hài lòng của khách hàng về việc liên tục có những bản release được gửi và sớm có sản phẩm có giá trị để có thể sử dụng thử
- Sự tương tác giữa con người với con người được chú trọng hơn là việc thực hiện theo quy trình và các công cụ Điều này được thể hiện bằng quá trình liên tục trao đổi giữa development và tester, giữa development và tech leader, giữa team phát triển và khách hàng qua mail, skype liên tục trong suốt dự án
- Sẵn sàng thích ứng với những thay đổi thường xuyên xảy ra, kể cả khi đó là sự thay đổi rất muộn
- Khó khăn hơn để xác định một trường hợp kinh doanh cho dự án và để đàm phán các dự án giá cố định
- Đôi khi sự tương tác giữa con người quá nhiều dẫn đến việc thiếu tập trung vào thiết kế và các tài liệu cần thiết
- Cần có đội ngũ phát triển có năng lực cao, kinh nghiệm, có sự năng động và linh hoạt để có khả năng đưa ra các quyết định cần thiết trong quá trình phát triển phần mềm khi gặp phải những khó khăn trở ngại
2.1.5 So sánh mô hình phát triển của Agile với các mô hình phát triển phần mềm truyền thống khác Đặc điểm Waterfall Spiral Scrum
Xác định các giai đoạn phát triển
Bắt buộc Bắt buộc Chỉ có giai đoạn lập kế hoạch và kết thúc Sản phẩm cuối cùng Được xác định trong quá trình lập kế hoạch Được xác định trong quá trình lập kế hoạch
Xác định trong quá trình xây dựng dự án
Chi phí sản phẩm Được xác định trong quá trình lập kế hoạch
Thay đổi cục bộ Xác định trong quá trình xây dựng dự án
Ngày hoàn thành sản phẩm Được xác định trong quá trình lập kế hoạch
Thay đổi cục bộ Xác định trong quá trình xây dựng dự án Đáp ứng với môi trường sử dụng
Trong kế hoạch ban đầu
Trong kế hoạch ban đầu
Xuyên suốt từ kế hoạch đến xây dựng và kết thúc Kinh nghiệm trao đổi Đào tạo trước cho đến khi bắt tay làm dự án Đào tạo trước cho đến khi bắt tay làm dự án
Thực hiện trong quá trình làm dự án Khả năng thành công Thấp Trung bình thấp Cao
So sánh về giá thành phát triển phần mềm
Quy trình Agile/Scrum trong dự án SMARTPHONE
Đặc điểm của phát triển ứng dụng trên Smartphone
Đặc điểm của thiết bị SmartPhone được xác định bởi 3 đặc điểm riêng biệt
Thiết bị di động được biết đến với khả năng di chuyển thường xuyên Bất kì thiết bị di động nào cũng thực hiện chức năng hoạt động liên tục khi di chuyển
Là những thiết bị có màn hình nhỏ để sử dụng màn hình cảm ứng dể nhận đầu vào, các thiết bị di động cho phép người dùng có thể dùng nó bằng 1 tay Do thiết bị di động có màn hình nhỏ nên các ứng dụng di động cần có thiết kế phù hợp, cấu trúc các thông tin được trình bày một cách tối ưu nhất cho người dung tiện sử dụng
Thiết bị di động thường có khả năng giao tiếp với các thiết bị tương tự khác, với các máy tính văn phòng và hệ thống, mạng và điện thoại di động Thiết bị điện thoại di động cơ bản đều có khả năng truy cập Internet thông qua mạng Bluetooth hoặc Wi-Fi, và nhiều mô hình được trang bị truy cập điện thoại di động và mạng dữ liệu không dây là tốt Email và nhắn tin là cách tiêu chuẩn giao tiếp với các thiết bị di động, mặc dù nhiều người cũng có khả năng của điện thoại, và một số các thiết bị di động chuyên ngành, giao tiếp trực tiếp với một thiết bị trung tâm
3.1.2 Đặc điểm của phát triển ứng dụng trên Smartphone
Hầu hết các dự án trên Smartphone đểu là những dự án vừa và nhỏ chỉ có vài nghìn dòng mã nguồn với số lượng người phát triển rất ít Nhưng trên nhiều khía cạnh, phát triển ứng dụng di động việc phát triển phần mềm cho các ứng dụng nhúng khác
Cụ thể như một số vấn đề về tích hợp với phần cứng, an ninh truyền thông, hiệu suất, độ tin cậy và hạn chế việc lưu trữ Tuy nhiên, các ứng dụng trên Smartphone trình bày một số yêu cầu ít được tìm thấy với các ứng dụng truyền thống khác, bao gồm:
- Chu kì phát triển ngắn
- Thường xuyên thay đổi nhu cầu sử dụng
- Phải dễ dàng cập nhập
- Tương tác với các ứng dụng khác trong thiết bị di động như là camera, voice
- Xử lý Sensor đây là một việc phải xử lý hầu hết ở trên các ứng dụng Smartphone, như là việc di chuyển thiết bị, màn hình cảm ứng đáp ứng nhiều các cử chỉ khác nhau, hệ thống định vị …
- Ứng dụng Native và Hybrid
- Sự phức tạp khi thử nghiệm
3.1.3 Các thành phần khi phát triển một ứng dụng di động
Hình 3.1: Các thành phần phát triển của dự án cho Smartphone Hiện nay có rất nhiều các hệ điều hành khác nhau cho điện thoại di động như Android, iOS, WindowPhone, BlackBerry Nên để xây dựng một ứng dụng di động thỏa mãn đa số người dùng thì phải xây dựng mỗi nền tảng một ứng dụng riêng Do vậy, mỗi ứng dụng cho một hệ điều hành cần một đội phát triển riêng Như: iOS Team cung cấp ứng dụng cho hệ điều hành iOs bằng việc cung cấp các gói
Xcode, trong đó bao gồm một giao diện Builder, một giả lập iPhone, và một môi trường hoàn chỉnh được sử dụng trên tất cả các sản phẩm của Apple
Android Team cung cấp ứng dụng cho hệ điều hành Android, ở nhóm này sử dụng các công cụ phát triển Android plugin cho môi trường lập trình Eclipse
WindowPhone Team sử dụng Visual Studio của Microsofts.… và cần một
Backend team để xử lý về cơ sở dữ liệu qua việc tạo ra các Api để các đội mobile sử dụng Như hình … miêu tả việc trao đổi dữ liệu của các đội Mobile với đội Backend
Backend API đóng vai trò cung cấp các service cho bên mobile để truy vấn đến cơ sở dữ liệu hay xử lý các vấn đề liên quan đến quy trình xử lý Các service này được các nhóm phát triển nền tảng cho mobile đòi hỏi mình cần những service nào Có thể coi các đội phát triển nền tảng cho mobile là khách hàng của đội Backend API
3.1.4 Vòng đời phát triển ứng dụng trên Smartphone
Phương pháp phần mềm truyền thống được thiết kế lại để phù hợp tính chất thích nghi của các ứng dụng di động Phương pháp phát triển phần mềm truyền thống vào vòng đời phát triển ứng dụng thiết bị di động
Hình 3.2: Quy trình phát triển Agile-Scrum cho ứng dụng di động Phương pháp này gồm các giai đoạn cụ thể là:
Giai đoạn 1: Yêu cầu phân tích (Requirement Analysis) Giai đoạn 2: Thiết kế và phát triển (Design & Development) Giai đoạn 3: Kiểm tra và đảm bảo chất lượng (Test & Quality) Giai đoạn 4: Nghiệm thu sản phẩm (Product Acceptance) Giai đoạn 5: Phát hành vào thị trường (Release to Market)
Khi khách hàng đặt yêu cầu thiết kế một ứng dụng trên Smartphone Nó được định nghĩa tại giai đoạn 1 Trong giai đoạn này cần phải phân tích được thị trường và thiết bị Smartphone Nó đóng vai trò giảm thiểu những bất ổn và rủi ro kĩ thuật tương ứng Ở giai đoạn 2 và 3, một Sprint trong một dự án kéo dài 1-4 tuần Việc tái sử dụng trong phát triển phần mềm được áp dụng triệt để trong giai đoạn 2 Cuộc họp Sprint hàng ngày là một phần quan trọng của Sprint cho các đội để chia sẻ thông tin cập nhập về các công việc hoàn thành, lập kế hoạch cho các công việc tiếp theo hay là việc giải quyết các vấn đề còn tồn đọng
Giai đoạn 4 là một giai đoạn nước rút, nó thực hiện phản hồi hiệu quả các yêu cầu cũng như việc so sánh sản phẩm với yêu cầu ban đầu bằng việc gửi yêu cầu cho khách hàng
Giai đoạn 5 là một bước quan trọng để hoàn thiện sản phẩm Nó phải đáp ứng đầy đủ yêu cầu của khách hàng và sản phẩm sẽ ra mắt thị trường chính thức Đối với mỗi nền tảng di động đều có một nơi chứa tất cả các ứng dụng để mọi người có thể download app về Như ở trong Android là ở trên Google Play và trong iOS là App Store.
Một số phương pháp phát triển phần mềm cho Smartphone
Một số phương pháp phát triển phần mềm cho Mobile
3.2.1 Mobile-D (Abrahamsson et al, 2004) Được biết đến vào năm 2004 bởi Abrahamsson, Mobile D là cách tiếp cận dựa trên Rational Unified Process RUP, eXtreme Programming XP (Phương pháp phát triển phần mềm) và phương pháp Crystal (khả năng mở rộng) Nghiên cứu này cung cấp một cái nhìn tổng thể về phát triển ứng dụng di động, về những đặc điểm và hạn chế ảnh hưởng đến quá trình phát triển phần mềm di động Nghiên cứu này cũng giới thiệu một cách tiếp cận phát triển phần mềm được rút ra từ phát triển phần mềm linh hoạt Agile
Có 9 yếu tố liên quan đến các hoạt động khác nhau trong suốt chu trình phát triển
Mobile-D gồm 5 giai đoạn: Explore, Initialize, Productionize, Stabilize, and System System Test & Fix Mỗi giai đoạn liên quan đến một giai đoạn thực tiễn
Hình 3.3: Các giai đoạn phát triển của Mobile-D
Trong giai đoạn đầu tiên Explore , nhóm phát triển tạo ra một kế hoạch và thiết lập các đặc điểm của dự án Điều này được thực hiện trong 3 giai đoạn: stakeholder establishment, scope definition và project establishment Nhiệm vụ liên quan đế giai đoạn này là các công việc liên quan đến khách hàng như lập kế hoạch dự án, thu thập yêu cầu của khách hàng
Giai đoạn tiếp theo Initialize, nhóm phát triển và các bên liên quan tích cực tìm hiểu về sản phẩm phát triển Ví dụ như các nguồn lực về vật chất, công nghệ, truyền thông Giai đoạn này chia làm 3 phân đoạn: project set-up, initial planning and trial day
Giai đoạn Productionize bao gồm các hoạt động về việc triển khai thực hiện, vào cuối giai đoạn này thì hầu hết các công việc cần được hoàn chỉnh Giai đoạn này được chia thành planning days, working days, and release days
Hai giai đoạn cuối cùng Stabilize và System Test & Fix được sử dụng để hoàn thành sản phẩm và thử nghiệm tương ứng, và một số sửa đổi để xây dựng tài liệu hướng dẫn và kiểm tra hệ thống
Mobile-D được áp dụng cho các dự án phát triển nhằm tang khả năng nhìn nhận về quy trình, phát hiện sớm và sửa chữa các vấn đề kĩ thuật, mật độ sai lệch cho sản phẩm cuối cùng
Jeong et al đề xuất việc phương pháp phát triển phần mềm ứng dụng di động Agile cung cấp cho quá trình phát triển ứng dụng di động nhanh chóng bằng cách sử dụng phương pháp Agile Nó được dựa trên Extreme Programming (XP), Agile Unified Process, RUP và Software and Systems Process Engineering Metamodel (SPEM) Đó là GUI dựa trên kiến trúc trung tâm là sử dụng phương pháp tiếp cận phát triển Agile và sử dụng kiến thức miền MASAM cho thấy một sự ràng buộc với phương pháp Mobile – D và giới thiệu các sự thay đổi chẳng hạn như việc quản lý dự án và kết hợp các công cụ theo dõi với Eclipse Process Framework
MASAM được mô tả theo ba loại tài sản quy định sau
Role Nó định nghĩa tập hợp các kĩ năng liên quan, năng lực và trách nhiệm của từng cá nhân
Planner, Manager, UI designer, Developer,
Development team, Initial development team,
Tester, Use Task Nó là một đơn vị chuyển nhượng được gán cho một vai trò cụ thể Chi tiết của một công việc thường là vài giờ đến vài ngày và thường ảnh hưởng đến một số các Work Product
Product Summary, Initial Planning, User
Definition, Initial Analysis, Select Resource,
Select Process, Establish Environment, Write
Story Card, UI Design, Define Architecture,
Planning, Iteration plan, Face-to-face Meeting,
Incremental Design, TDD, Refactoring, Release
Plan, Feedback, Pattern Manage, Pair
User Test Figure Work Product Là một thuật ngữ chung cho các đầu vào công việc và kết quả đầu ra
UI Model, UI pattern, Architecture Pattern,
Application Pattern, Story Card, Task Card,
Architecture Model, Component Model, Test
MASAM đề xuất một quy trình phát triển ứng dụng di động gồm 4 giai đoạn
Giai đoạn chuẩn bị một bản tóm tắt, định nghĩa khái niệm đầu tiên của sản phẩm, gán vai trò và trách nhiệm Giai đoạn Embodiment tập trung vào sự hiểu biết nhu cầu của người sử dụng và xác định cấu trúc của sản phẩm phần mềm Giai đoạn cuối cùng hình thành giai đoạn phát triển mà lợi ích từ các nguyên tắc nhanh nhẹn truyền thống để cung cấp một trình tự Extreme Programming lặp đi lặp lại Việc thực hiện các sản phẩm phần mềm được thực hiện thông qua các giai đoạn Test-Driven Development, Pair Programming, Refactoring và Continuous Integration với một mối quan hệ chặt chẽ các thử nghiệm lặp đi lặp lại Cuối cùng là giai đoạn Commercialization tập trung vào các hoạt động ra mắt sản phẩm và bán sản phẩm
Preparation Phase Grasping Product Product summary
Pre-planning Product Concept Sharing User Definition
Initial product analysis Project Set-up Development process coordination Project resource coordination
Pre study Embodiment Phase User Need Understanding Story card workshop
UI design Architecting Non-functional requirement analysis Architecture definition Pattern management Development Phase Implementation &
Environment setup Development Planning Release Cycle Release Planning
Commercialization Phase System Test Acceptance Test
User Test Product Selling Launching Test
Ứng dụng Agile/Scrum và phương pháp Scrum of Scrums trong dự án SmartPhone
Đối với mỗi nền tảng di động cần phát triển trong dự án Smartphone như Android, iOS, Window Phone sẽ chia thành làm các đội Scrum và đội xây dựng API cho Mobile cũng là một đội Scrum như hình 3.4 Mô tả quy trình phát triển Scrum cho các đội phát triển áp dụng vào việc Product Owner tạo ra các Product Backlog và chia Product Backlog thành các Sub-Backlog cho các đội phát triển cho SmartPhone Các đội phát triển Smartphone sau khi nhận được các công việc trong Sub-Backlog sẽ phân tích yêu cầu và thiết kế các giả lập màn hình để hiểu rõ yêu cầu hơn Và gửi các giả lập màn hình này cho bên đội API để đội API dựa vào những màn hình này có thể thấy được các yêu cầu cơ bản của dự án và những API mình sẽ cung cấp cho bên Mobile
Hình 3.4: Mô tả Scrum dự án phát triển Smartphone
Ứng dụng Agile/Scrum trong dự án phát triển ứng dụng trên smartphone 36
Giới thiệu tóm tắt về dự án phần mềm cho điện thoại di động thông minh
Mục tiêu phát triển Kết nối người dùng qua Smartphone bằng cách chia sẻ ảnh, video hay trạng thái của người dùng, nói chuyện trực tiếp giữa các người dùng
Server Cài đặt nodejs cho chức năng chat pear to pear
Apache cho Web php and mobie Phân quyền người dùng Admin/ customer
App iOS Phát triển bằng iOS cho Customer
Web Phát triển bằng PHP để quản lý hệ thống cho
API Phát triển bằng PHP
Mô tả chức năng ban đầu của dự án
Stt Chức năng Mô tả
1 Download app Download app trên app store
2 Đăng nhập và đăng kí
Mỗi người dùng cần phải đăng nhập hay nếu chưa có tài khoản thì phải đăng kí để sử dụng App
3 Chụp ảnh Sau khi người dùng login thì cần phải chụp ảnh thay đôi avatar
4 Xác định vị trí Xác định vị trí hiện tại của người dùng
5 Tìm kiếm những người dùng
Tìm kiếm những người dùng có cùng sở thích
6 Push notification Gửi thông báo đến cho người dùng
7 Kết bạn Có thể thêm bạn, hủy kết bạn
Một số khó khăn khi đội dự án triển khai
Nhân lực của dự án thay đổi
Do tính chất công ty là một công ty Oursource nên có rất nhiều dự án chạy cùng một lúc nhưng nguồn nhân lực còn hạn chế nên việc thay đổi nguồn nhân lực của dự án bị thay đổi Cụ thể là sau khi dự án chạy hết sprint 1, một số developer trình độ cao bị đưa sang dự án khác và thay vào đó là developer với trình độ thấp hơn
Yêu cầu của khách hàng thay đổi
Nhưng vì một lý do nào đó khách hàng muốn thay đổi yêu cầu của dự án
Hình 4.1: Những thay đổi của dự án liệt kê trong Excel
Dự án được bắt đầu ngày 17/8 nhưng qua một số mốc thời gian trong file excel
“SEF_Requirements_Management_old.xlsx” được tóm tắt như hình 4.1 ta thấy được là dự án được thay đổi rất nhiều về yêu cầu cho đến ngày 3/9
No Feature group Feature detail Status
1 Chat Chat between 2 users Reject
3 Free User cannot chat with User with no common
Interest, paid User can only if the User with no common Interest allows chat from no common Interest
4 User User registers with email, password, name, date of birth
5 Map User set his location on Map Reject
6 Push notification push new Activity hashtag in area Reject
- Chat permission for no common Interest
- Avatar from image or video (9s)
Như vậy các sẽ mất nhiều thời gian để phân tích thực hiện chức năng
Hình 4.2: Ví dụ những thay đổi yêu cầu của dự án từ khách hàng Hình 4.2 là ví dụ về sự thay đổi yêu cầu dự án của khách hàng liên tục từ ngày 23/9, 24/9, 25/9, 28/9 Xem sự thay đổi chi tiết trong tài liệu “SEF_REQM.xlsx”.
Cách thức đội quản lý dự án theo quy trình Agile/Scrum
4.3.1 Thiết lập kế hoạch thực hiện
Sau khi phân tích yêu cầu phát triển dự án đưa ra được kế hoạch thực hiện dự án trong tài liệu “SEFSocial_MasterPlan_v1.0.xlsx” Bản tóm tắt được mô tả như hình 4.3
Hình 4.3: Kế hoạch thực hiện dự án
Dựa vào tài liệu ta có thể thấy được kế hoạch dự án ban đầu là bắt đầu ngày 17/8 kết thúc ngày 9/11 Effort thực hiện dự án là 139 man/days
4.3.2 Thành lập đội dự án
No Name Role Date Start
1 Phạm Vũ Dương Chủ sản phẩm 17/08/2015
3 Lê Thị Thảo Trinh Dev 01/09/2015
9 Nguyễn Văn Tiến Dev 01/09/2015 Áp dụng đội dự án vào quy trình Scrum
Chia đội dự án thành 3 đội Scrum là Team Scrum iOS, Team Scrum API, Team Scrum Website và phân rõ vai trò của từng thành viên trong đội ở vị trí nào trong nhóm Scrum
1 Phạm Vũ Dương Product Owner chính
2 Phạm Thế Duy Scrum master iOs
3 Lê Thị Thảo Trinh Dev
5 Nguyễn Văn Phi PO - Scrum master API
8 Nguyễn Văn Duy PO - Scrum Master Website
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
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
8 Capture photo / record video, set duration 16 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
16 open & edit saved Media (trim video), then share / delete
19 group Users into clusters 16 Duy
20 list visible Users on Map 16 Duy
25 list Users that shared something 8 Hoang
Story id Story name Points Name of Dev
7 share Post to Story 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)
16 list "Feed" Users (Users I followed, with count of "new" seconds)
17 list new Posts of "Feed" user 16 Duy
19 share a new Post to some of the Followers 16 Trung
20 list "Notification" Users (Users who shared something to me)
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
Story ID Story Name Points Name of Dev Start Date End Date
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 để 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ề
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
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 giá và nhận xét
á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.
