Your SlideShare is downloading. ×
A brief introduction to agile  duong trong tan 2014-06
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

A brief introduction to agile duong trong tan 2014-06

419
views

Published on

A brief introduction to agile by duong trong tan …

A brief introduction to agile by duong trong tan
Giới thiệu ngắn gọn về Agile - Dương Trọng Tấn, Hà Nội 2014/06

Published in: Software

0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
419
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
30
Comments
0
Likes
8
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Agile nói chuyện Dương Trọng Tấn duongtrongtan@gmail.com @Septeni HN/2014
  • 2. Trích chéo • Đã: FPT Aptech Hanoi, Khoa Quốc tế - ĐH FPT, AgileVietnam. • Khởi xướng HanoiScrum • Hiện nay: nghỉ hưu non AgileVietnam, làm RnD ở ĐH FPT và Cánh Buồm, công việc chính: thí nghiệm.
  • 3. Nội dung Agile là gì? Tại sao Agile? Agile là gì? Tại sao Agile? Ví dụ XP Scrum Lean & Lean Startup Ví dụ XP Scrum Lean & Lean Startup Trở nên/dùng agile cách nào ? Tư duy Kĩ thuật Cộng tác Công cụ Trở nên/dùng agile cách nào ? Tư duy Kĩ thuật Cộng tác Công cụ
  • 4. NHÓM SCRUM TẠO RA PHẦN MỀM NHƯ THẾ NÀO
  • 5. Có vài người nghĩ là phải làm phần mềm gì đấy để phục vụ việc gì đấy Rồi đổ tiền vào Giao nhiệm vụ cho (vài) người nào đấy Rồi nghĩ ra vài chức năng cần phải có, được gọi là YÊU CẦU (REQUIREMENTS)
  • 6. Công việc xây dựng phần mềm được quẳng cho ĐỘI SẢN XUẤT Bọn này ngồi lại với nhau để LẬP KẾ HOẠCH Tháng tới làm gì Để có được (vài) chức năng nào đó hoàn chỉnh để “show hàng” vào cuối tháng
  • 7. Kết quả của buổi họp lập kế hoạch là một BẢN KẾ HOẠCH Gồm mục tiêu và những việc cần làm trong tháng
  • 8. Dựa trên Bản kế hoạch ấy Đội sản xuất hì hụi ai có việc người ấy làm cộng tác chặt chẽ với nhau Ngày nào cũng Họp  15 phút mỗi ngày Để đồng bộ hóa công việc của nhau, nắm tiến độ và phát hiện trở ngại (JIT PLANNING)
  • 9. Nếu có việc gì phải làm thêm, hoặc bớt đi vài việc không cần làm nữa Thì cập nhật luôn vào Bản Kế hoạch
  • 10. Cứ như thế cho đến khi hết Khung thời gian
  • 11. Phần Mềm Chạy Tốt Sẽ Tòi Ra
  • 12. DEMO Phần mềm Chạy tốt Chúng ta có gì rồi?
  • 13. Chưa xong, còn phải ngồi lại xem thời gian vừa rồi làm việc có ỔN không, có thể làm tốt hơn không? Cố tìm cho bằng được cái gì đó để CẢI TIẾN cho tháng tiếp theo
  • 14. Rồi ta lại như thế …
  • 15. Scrum Framework Đồ họa: Demer et al.
  • 16. Những Cách Khác Scrum XP Lean Software Development Crystal DSDM Agile FDDAgileUP
  • 17. eXtreme Programming Đọc thêm: http://www.hanoiscrum.net/hnscrum/learning/167 Nguyên lý • Phản hồi nhanh (Rapid Feedback) • Giả định Đơn giản (Assume Simplicity) • Thay đổi tăng trưởng (Incremental Change) • Sống chung với Thay đổi (Embracing Change) • Công việc chất lượng cao (Quality Work) Nguyên lý • Phản hồi nhanh (Rapid Feedback) • Giả định Đơn giản (Assume Simplicity) • Thay đổi tăng trưởng (Incremental Change) • Sống chung với Thay đổi (Embracing Change) • Công việc chất lượng cao (Quality Work) Giá trị • Giao tiếp (Communication) • Tính đơn giản (Simplicity) • Phản hồi (Feedback) • Tôn trọng (Respect) • Can đảm (Courage) Giá trị • Giao tiếp (Communication) • Tính đơn giản (Simplicity) • Phản hồi (Feedback) • Tôn trọng (Respect) • Can đảm (Courage) Phát triển những phần mềm với chất lượng cao nhất, với chi phí thấp nhất, ít lỗi nhất, siêu năng suất và tối đa hóa lợi nhuận đầu tư Phát triển những phần mềm với chất lượng cao nhất, với chi phí thấp nhất, ít lỗi nhất, siêu năng suất và tối đa hóa lợi nhuận đầu tư
  • 18. Kĩ thuật XP Xem thêm: http://www.slideshare.net/duongtrongtan/practices-of-an-agile-developer-16001474
  • 19. Lean Software Development Sử dụng Tư duy Tinh gọn (Lean Thinking) cho lĩnh vực phát triển phần mềm Sử dụng Tư duy Tinh gọn (Lean Thinking) cho lĩnh vực phát triển phần mềm 7 Nguyên lý 1. Loại bỏ lãng phí 2. Khuếch trương việc học 3. Quyết định càng muộn càng tốt 4. Chuyển giao càng nhanh càng tốt 5. Trao quyền cho nhóm 6. Tạo ra tính toàn vẹn tự thân 7. Thấy toàn cảnh 7 Nguyên lý 1. Loại bỏ lãng phí 2. Khuếch trương việc học 3. Quyết định càng muộn càng tốt 4. Chuyển giao càng nhanh càng tốt 5. Trao quyền cho nhóm 6. Tạo ra tính toàn vẹn tự thân 7. Thấy toàn cảnh Đọc thêm: http://www.hanoiscrum.net/hnscrum/learning/168-agilemethod3-lean-software-development 22 Công cụ 1. Nhìn ra Lãng phí 2. Ánh xạ Dòng Giá trị 3. Phản hồi 4. Phân đoạn 5. Đồng bộ hóa 6. Phát triển theo lô 7. Tư duy Lựa chọn 8. Trách nhiệm Phút cuối 9. Ra quyết định 10. Hệ thống kéo 22 Công cụ 1. Nhìn ra Lãng phí 2. Ánh xạ Dòng Giá trị 3. Phản hồi 4. Phân đoạn 5. Đồng bộ hóa 6. Phát triển theo lô 7. Tư duy Lựa chọn 8. Trách nhiệm Phút cuối 9. Ra quyết định 10. Hệ thống kéo 11. Lý thuyết Hàng đợi 12. Giá của Trì hoãn 13. Tự-Xác-định 14. Động viên 15. Lãnh đạo 16. Chuyên môn 17. Toàn vẹn Nhận thức 18. Toàn vẹn Khái niệm 19. Tái cấu trúc 20. Kiểm thử 21. Đo lường 22. Hợp đồng 11. Lý thuyết Hàng đợi 12. Giá của Trì hoãn 13. Tự-Xác-định 14. Động viên 15. Lãnh đạo 16. Chuyên môn 17. Toàn vẹn Nhận thức 18. Toàn vẹn Khái niệm 19. Tái cấu trúc 20. Kiểm thử 21. Đo lường 22. Hợp đồng
  • 20. Kanban Phương pháp luận Cải tiến Quy trình theo cách thức tiến hóa và tăng trưởng ‘Complex Adaptive System for Lean’ Phương pháp luận Cải tiến Quy trình theo cách thức tiến hóa và tăng trưởng ‘Complex Adaptive System for Lean’ Không cần Phân đoạn? Bỏ luôn! Không cần Ước lượng? Bỏ luôn! Không cần Phân đoạn? Bỏ luôn! Không cần Ước lượng? Bỏ luôn! 5 Đặc điểm 1. Trực quan hóa Luồng công việc 2. Giới hạn Việc-đang-làm 3. Đo lường và Quản lí Luồng 4. Công khai Chính sách Quy trình 5. Dùng Mô hình để nhận biết các cơ hội Cải tiến 5 Đặc điểm 1. Trực quan hóa Luồng công việc 2. Giới hạn Việc-đang-làm 3. Đo lường và Quản lí Luồng 4. Công khai Chính sách Quy trình 5. Dùng Mô hình để nhận biết các cơ hội Cải tiến
  • 21. Lean Startup | Khởi nghiệp Tinh gọn Giả định, thử nghiệm Dữ liệu, phản hồi Vấn đề: chưa rõ Giải pháp: chưa rõ
  • 22. Build-Measure-Learn
  • 23. Minimum Viable Product Gồm những tính năng tối giản đủ để học từ thực tiễn, sớm nhất có thể • Tránh làm ra chức năng không ai dùng • Mỗi ‘đồng’ bỏ ra đều thu được bài học quý BuildBuild
  • 24. Chung | Riêng Ảnh: Hendrik Kniberg
  • 25. PHÍA SAU CÁNH GÀ ...
  • 26. Agile | Agility | Linh hoạt • Ken Schwaber: 1. flexibility, the capacity and capability of rapidly and efficiently adapting to change. 2. ability to take advantage of opportunities while controlling risk. Wiki: Agile Software Development: một họ các phương pháp phát triển phần mềm dựa trên các nguyên lí tăng trưởng (incremental) và lặp (iterative), trong đó các yêu cầu và giải pháp tiến hóa thông qua sự cộng tác giữa các nhóm liên chức năng (cross-functional) tự tổ chức (self-organizing).
  • 27. Triết lí Agile • Định nghĩa các giá trị cốt lõi • Định hướng các phương pháp Agile • Mô tả trong Tuyên ngôn Agile (Manifesto) và 12 Nguyên lí Agile.
  • 28. Tuyên ngôn Phát triển Phần mềm Linh hoạt 28 Chúng tôi đã phát hiện ra cách tốt hơn để phát triển phần mềm thông qua việc thực hiện nó và giúp đỡ người khác thực hiện. Qua công việc này, chúng tôi đã đi đến việc đánh giá cao: Cá nhân và tương tác hơn là quy trình và công cụ;hơn là quy trình và công cụ; Phần mềm chạy tốt hơn là tài liệu đầy đủ;hơn là tài liệu đầy đủ; Cộng tácvới khách hàng hơn là đàm phán hợp đồng;hơn là đàm phán hợp đồng; Phản hồi với thay đổi hơn là bám sát kế hoạch.hơn là bám sát kế hoạch. Mặc dù các thứ bên phải vẫn còn giá trị, chúng tôi đánh giá cao hơn các mục ở bên trái. Dịch từ: AgileManifesto.org Xem thêm: http://www.hanoiscrum.net/hnscrum/learning/145-agileprincipleandvalues
  • 29. Tuần tự và Chồng lấp Nguồn: “The New New Product Development Game” của Takeuchi và Nonaka. Harvard Business Review, tháng Giêng 1986. Phát triển tuần tự Nhóm Scrum làm mỗi thứ một ít ở mọi thời điểm, tập trung đưa ra các chức năng [chạy tốt] sớm nhất. 29
  • 30. Chồng lấp: cùng làm, từng tí một Nguồn: Mike Kohn
  • 31. Sprint | Iteration | Phân đoạn Vòng đời phản hồi ngắn Khuyến khích việc học Gia tăng Visibility Thích ứng với thay đổi
  • 32. Thực nghiệm | Empiricism Chim di cư bay hàng chục nghìn km mỗi năm
  • 33. Just-in-time | Tức thì Cập nhật Hằng ngày Daily Standup Kế hoạch động, thích ứng liên tục
  • 34. Nhóm Tự tổ chức Self-organized Team
  • 35. Hướng đến Mục tiêu chung 35 • Tập trung vào Mục tiêu, không phải Task • Giới hạn việc-đang-làm
  • 36. Nhóm liên chức năng Cross-functional Team Ảnh: suitcaseorchestra.com
  • 37. Retrospective | Kaizen Cải tiến liên tục Image: Rachel Davies & Liz Sedley
  • 38. Độ trực quan Khả năng thay đổi Giá trị mang lại Rủi ro Tại sao Agile? Nguồn: Ken Schwaber
  • 39. Công cụ hỗ trợ • Index Card, Miếng giấy dán (sticky notes) • Planning Poker • Task Board|Kanban Board|Scrum Board| Các loại bảng • Công cụ giao tiếp (Skype, Hangout,Yammer …) • Các công cụ soạn thảo cộng tác: wiki, online office suites, mindmapping … • Các hệ ALM( Application Lifecycle Management) của MS, IBM, HP, Rally, CollabNet, VersionOne, Atlassian, Redmine ... • Các phần mềm tự động hóa: CI (continuous integration), các test automation framework (xUnit, Cucumber, FitNess, Robots …) • Và nhiều nữa …
  • 40. User Story & Backlogs User Story & Backlogs Image: iqupi.wordpress.com mountaingoatsoftware.com agilemodeling.com agilistapm.com
  • 41. Release Burndown Sprint Burndown Release Ảnh: mountaingoat.com
  • 42. Ảnh: pages.kiva.org | Atlassian | Quang NB
  • 43. Học và hành Học thông qua … • Ghép cặp (Pairing) • Cộng đồng thực hành (Coding Dojo, Interest Group …) • Hội thảo chuyên ngành (AgileTour, ScrumDay …) • Đọc sách • Các tài nguyên online (video) • Thuyết trình|Dạy lại người khác Thực hành • Thực học là để làm, làm được mới được coi là học được • Pilot project • Các bài tập lớn (assignment) • Các Dự án|Đồ án (Project) • Quản lí công việc cá nhân (Personal Kanban, Personal Scrum, Lean …)
  • 44. Học tập cũng cần chiến lược SHU Bám sát Quy tắc SHU Bám sát Quy tắc HA Nghĩ lại về Quy tắc Tìm kiếm ngoại lệ, Phá vỡ Quy tắc HA Nghĩ lại về Quy tắc Tìm kiếm ngoại lệ, Phá vỡ Quy tắc RI Quên đi Quy tắc RI Quên đi Quy tắc 44
  • 45. Tới Bruce Lee - bậc thầy Kungfu Novice Advanced Beginner Proficient Competent Expert Image: http://goo.gl/1RzEE Cậu bé bắt đầu học Vịnh Xuân 45 10.000 Giờ leo núi
  • 46. Đọc thêm nữa 46
  • 47. Tài nguyên online • HanoiScrum.net • AgileAtlas.org • ScrumAlliance.org • AgileAlliance.org • InfoQ.com/process-practices/ • Các hội thảo Agile Conference, Scrum Gathering, Agile Tour, ScrumDay … • Tool Vendors (MSDN, IBM, VersionOne …)
  • 48. Cộng đồng HanoiScrum.net AgileVietnam.org
  • 49. THANK YOU!:-)
  • 50. BACKUP SLIDES
  • 51. Độ phức tạp của dự án Scrum Nguồn: Ken Schwaber
  • 52. Đội Y ************* 1. Thời gian Daily Scrum: 9:00 2. Phạt đến muộn: 2 $ 3. Mọi người đều tích hợp liên tục 4. Tái cấu trúc lại mã bẩn 5. Hỏi nếu không rõ 6. Sử dụng Lập trình cặp và TDD 7. Thực hiện đúng chuẩn viết mã 8. Kiểm tra lại Định nghĩa Hoàn thành trước khi commit. Quy tắc Làm việc 52 Đã kýĐã ký
  • 53. Một tình huống phát triển Requirement Analysis UI Mocking • Customer discussion Design Draft • Design Discussion Code the skeleton to test the design Coding in team Refactoring and Refinement Build the increment $$ DevTeamPO Collaboration: Steps: Artifacts: As a super user, I want to … As a super user, I want to … A B IDo Interface IDo{ //TODO … } Class A{ //TODO … } Class B:IDo{ //TODO … } Note: TDD|BDD|AMDD can be used or not Interface IDo{ //TODO … } Class A{ method1(){ //Mr. A codes here } } Class B:IDo{ method1(){ //Mrs. B codes here } } Class C{ } $$ PO 53
  • 54. User Story • User story là các yêu cầu linh hoạt (agile requirement) • Đảm bảo sự cân bằng của các bên tham gia phát triển sản phẩm: khách hàng, người dùng và nhà phát triển – Thể hiện bằng một ngôn ngữ hướng-người-dùng và các nhà phát triển có thể hiểu được • Hướng tới người dùng và nghiệp vụ, không chứa các đặc tính về hệ thống 54
  • 55. INVEST – các tiêu chuẩn cho một user story tốt 55 Independent – Độc lậpIndependent – Độc lập Negotiable – Đàm phán đượcNegotiable – Đàm phán được Valuable – Đáng giáValuable – Đáng giá Estimatable – Ước tính đượcEstimatable – Ước tính được Sized appropriately – Kích thước phù hợpSized appropriately – Kích thước phù hợp Testable – Kiểm thử đượcTestable – Kiểm thử được
  • 56. Tập hợp các user story Chuẩn bị các câu hỏi Chuẩn bị các câu hỏi Quan sátQuan sát Phỏng vấn người dùng Phỏng vấn người dùng Viết user storyViết user story 56
  • 57. Họp xây dựng user story • Người tham gia: nhà phát triển, người dùng, khách hàng, thành phần khác (được gọi là những “chú lợn”) • Thảo luận để đưa ra các story • Mục tiêu là viết được càng nhiều story càng tốt – Một số sẽ “sẵn sàng triển khai” – Một số khác sẽ là “epic” • Không xác định độ ưu tiên trong buổi hội thảo này • Product Owner và những người có liên quan được tham gia nhưng không bắt buộc. 57
  • 58. Lập trình cặp Pair-Programming • Hai LTV cùng chia sẻ một vấn đề, với một máy tính, một bàn phím và với mục tiêu: giải quyết vấn đề đó. • Sử dụng sự ĐỒNG THUẬN, nhưng thông qua TRANH LUẬN! • Một ví dụ về “luồng một sản phẩm” • Chậm hơn nhưng hiệu quả hơn & chất lượng hơn • Có 2 vai trò: Người lái (Driver) và Hoa tiêu (Navigator): – Người lái không quan tâm tới bức tranh toàn cảnh – Người lái nên “rời bàn phím trong giây lát” – Hoa tiêu có xu hướng sử dụng tư duy mẫu trong giải quyết vấn đề 58
  • 59. Tích hợp Liên tục • Tích hợp Liên tục (Continuous integration - CI) triển khai liên tục các tiến trình để đảm bảo việc quản lý chất lượng — từng phần nhỏ hiệu quả, áp dụng thường xuyên. • Được hỗ trợ bởi một hệ thống CI với rất nhiều các kiểm thử tự động, build và các thành phần khác. • Lợi ích: – Tăng cường sự minh bạch – Tăng cường sự hợp tác và truyền thông – Cho phép mọi người cùng làm việc trên một mã nguồn 59
  • 60. Hệ thống Tích hợp liên tục CI Systems 60
  • 61. Thiết kế tiến hóa Incremental Design Thiết kế những thứ phức tạp có khả năng linh hoạt trên giấy hoặc công cụ Thiết kế tiến hóa 61 Luôn có những thứ thay đổi bất ngờ Luôn có những thứ thay đổi bất ngờ Nhiều phức tạp hơn mức cần thiết. Khó khăn trong việc bảo trì Dễ dàng thích nghi. ID thay đổi dễ dàng. Giảm bớt phức tạp
  • 62. Làm Bản mẫu • Bản mẫu có sớm sẽ giúp người dùng dễ hình dung ra sản phẩm sau khi hoàn thành • Khuyến khích sự tham gia tích cực của người dùng và nhà phát triển • Tăng tốc độ phát triển hệ thống Xác định các yêu cầu cơ bản Phát triển bản mẫu đầu Xem xét Kiểm tra và cải tiến bản mẫu 62
  • 63. Phát triển Hướng-Kiểm-thử Test-Driven Development • Không viết mã nguồn cho tới khi các kiểm thử đã được thiết kế hoàn chỉnh! • Chiến lược – Làm cho Thất bại • Không có mã nguồn nào mà không có kiểm thử thất bại – Làm cho Thành công • Đơn giản nhất có thể – Làm cho Tốt hơn • Cải tiến (mã nguồn, thiết kế, kiểm thử, tài liệu) – Tin tưởng vào việc kiểm thử 63
  • 64. 64 Các bước trong TDD Nguồn ảnh: Excirial (http://upload.wikimedia.org/wikipedia/en/9/9c/Test-driven_development.PNG)
  • 65. Cái giá của bug
  • 66. Ba nhân tố RGB 66 Thất bạiThất bại Thành công Thành công Cải tiếnCải tiến
  • 67. Phát triển Hướng Kiểm thử Chấp nhận (ATDD) • Một kỹ thuật dành cho tự động kiểm thử chấp nhận • Chiến lược 3D – Thảo luận (Discuss) trong hội thảo về xác định yêu cầu • Để xây dựng các thư viện kiểm thử – Phát triển (Develop) với sự đồng thuận • Để tạo ra nhiều tính năng đạt kiểm thử hơn – Cung cấp (Deliver) các chấp nhận • Để đạt được định nghĩa hoàn thành, cần sự chấp nhận của người dùng 67 Yêu cầuYêu cầu Kiểm thử Chấp nhận Tự động hóa Kiểm thử Chấp nhận Tự động hóa TDDTDD Định nghĩa Hoàn thành Định nghĩa Hoàn thành
  • 68. Phát triển Hướng-Hành-vi Behavior-Driven Development • Phát triển phần mềm được chỉ dẫn trực tiếp bởi các mô tả hành vi và các tính năng (và mô phỏng). • Hơi giống với ATDD, nhưng khác về tư duy • Chất lượng phần mềm cao hơn, tính tự tổ chức tốt hơn 68 Xác nhận lại hành vi Phát triển Xác nhận với mô phỏng UI Các mô tả hành vi
  • 69. Tái cấu trúc Refactoring • Bạn thực hành “viết mã một ít, sửa lỗi một ít” => kết quả là code bẩn và thiết kế tồi. • Tái cấu trúc để code tốt hơn, có thiết kế tốt hơn, vẫn giữ nguyên chức năng của hệ thống • Giữ cho mã nguồn: – Dễ bảo trì – Dễ mở rộng – Tính gắn kết cao (High Cohesion) – Ít phụ thuộc (Low Coupling) – Loại bỏ trùng lặp • Database cũng cần được tái cấu trúc cho phù hợp 69
  • 70. Các kỹ thuật tái cấu trúc • Trừu tượng hóa (Abstraction) – Bao gói các trường – Dùng kiểu khái quát (generic) – Thay thế mã kiểm tra (check) với State/Strategy – Thay thế các điều kiện bằng đa hình • Phân tách mã – Tạo mới phương thức, thay thế một phần lớn mã trong một phương thức bằng phương thức khác – Tạo thêm lớp mới • Chuẩn hóa mã – Chuyển phương thức hoặc trường – Đổi tên phương thức, trường – Đẩy lên lớp cấp trên hoặc lớp cha – Đẩy xuống lớp cấp dưới hoặc lớp con 70