Đường vào agile - 2013
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Đường vào agile - 2013

on

  • 2,613 views

Giới thiệu Agile tới sinh viên ĐH FPT tại Hòa Lạc.

Giới thiệu Agile tới sinh viên ĐH FPT tại Hòa Lạc.
Tháng 1-2013.

Statistics

Views

Total Views
2,613
Views on SlideShare
2,393
Embed Views
220

Actions

Likes
14
Downloads
196
Comments
2

3 Embeds 220

http://duongtrongtan.wordpress.com 205
https://duongtrongtan.wordpress.com 14
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Đường vào agile - 2013 Presentation Transcript

  • 1. Agile đường vào Dương Trọng Tấn tandt@fpt.edu.vn @FU HL/2013
  • 2. Nội dung Agile là gì? Trở nên agile? Tại sao Agile? Tư duyCác Phương pháp Kĩ thuật XP Cộng tác Scrum Lean & Lean Startup Công cụ Kanban
  • 3. NHÓM SCRUM TẠO RAPHẦN MỀM NHƯ THẾ NÀO
  • 4. 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 đấyRồi nghĩ ra vài chức năng cần phải có, được gọi là YÊU CẦU (REQUIREMENTS)
  • 5. 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
  • 6. 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
  • 7. 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ủanhau, nắm tiến độ và phát hiện trở ngại
  • 8. 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ữaThì cập nhật luôn vào Bản Kế hoạch
  • 9. Cứ như thếcho đến khi hết Khungthời gian
  • 10. PhầnMềmChạyTốt SẽTòiRa
  • 11. Chúng tacó gì rồi?DEMO Phần mềm Chạy tốt
  • 12. Chưa xong, còn phải ngồi lại xem thời gian vừa rồilà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
  • 13. Rồi ta lại như thế …
  • 14. ScrumFramework Đồ họa: Demer et al.
  • 15. Những Cách Khác Agile XP Lean Software Development Scrum Crystal DSDM AgileUP FDD
  • 16. eXtreme Programming Phát triển những phần mềm với chất Nguyên lýlượng cao nhất, với chi phí thấp nhất, ít • Phản hồi nhanh (Rapidlỗi nhất, siêu năng suất và tối đa hóa lợi Feedback) nhuận đầu tư • Giả định Đơn giản (Assume Simplicity) Giá trị • Thay đổi tăng trưởng• Giao tiếp (Incremental Change) (Communication) • Sống chung với Thay• Tính đơn giản (Simplicity) đổi (Embracing Change)• Phản hồi (Feedback) • Công việc chất lượng• Tôn trọng (Respect)• Can đảm (Courage) cao (Quality Work) Đọc thêm: http://www.hanoiscrum.net/hnscrum/learning/167
  • 17. Kĩ thuật XPXem thêm: http://www.slideshare.net/duongtrongtan/practices-of-an-agile-developer-16001474
  • 18. Lean Software DevelopmentSử dụng Tư duy Tinh gọn (Lean Thinking) 7 Nguyên lý cho lĩnh vực phát triển phần mềm 1. Loại bỏ lãng phí 2. Khuếch trương việc học 22 Công cụ 3. Quyết định càng muộn 11. Lý thuyết Hàng đợi 12. Giá của Trì hoãn càng tốt1. Nhìn ra Lãng phí 13. Tự-Xác-định2. Ánh xạ Dòng Giá trị 4. Chuyển giao càng 14. Động viên3. Phản hồi 15. Lãnh đạo4. Phân đoạn nhanh càng tốt 16. Chuyên môn5. Đồng bộ hóa 17. Toàn vẹn Nhận thức 5. Trao quyền cho nhóm6. Phát triển theo lô 18. Toàn vẹn Khái niệm7. Tư duy Lựa chọn 6. Tạo ra tính toàn vẹn tự 19. Tái cấu trúc8. Trách nhiệm Phút cuối 20. Kiểm thử9. Ra quyết định thân 21. Đo lường10. Hệ thống kéo 22. Hợp đồng 7. Thấy toàn cảnh Đọc thêm: http://www.hanoiscrum.net/hnscrum/learning/168-agilemethod3-lean-software-development
  • 19. KanbanPhương pháp luận Cải tiến Quy trình theo cách thức 5 Đặc điểm tiến hóa và tăng trưởng 1. Trực quan hóa Luồng công việc 2. Giới hạn Việc-đang-làm ‘Complex Adaptive System for Lean’ 3. Đo lường và Quản lí Luồng 4. Công khai Chính sách Quy trìnhKhông cần Phân đoạn? Bỏ luôn! 5. Dùng Mô hình để nhận biếtKhông cần Ước lượng? Bỏ luôn! các cơ hội Cải tiến
  • 20. Lean Startup | Khởi nghiệp Tinh gọnVấn đề: chưa rõ Giả định, thử nghiệmGiải pháp: chưa rõ Dữ liệu, phản hồi
  • 21. Build-Measure-Learn
  • 22. Minimum Viable Product Gồm những tính năng tối giản đủ để học từ Build 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ý
  • 23. Chung | Riêng Ảnh: Hendrik Kniberg
  • 24. PHÍA SAU CÁNH GÀ ...
  • 25. 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).
  • 26. 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.
  • 27. Tuyên ngôn Phát triển Phần mềm Linh hoạt 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ụ; Phần mềm chạy tốt 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; Phản hồi với thay đổi 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 27Xem thêm: http://www.hanoiscrum.net/hnscrum/learning/145-agileprincipleandvalues
  • 28. Tuần tự và Chồng lấp 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.Nguồn: “The New New Product Development Game” của Takeuchi vàNonaka. Harvard Business Review, tháng Giêng 1986. 28
  • 29. Chồng lấp: cùng làm, từng tí một Nguồn: Mike Kohn
  • 30. 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
  • 31. Thực nghiệm | Empiricism Chim di cư bay hàng chục nghìn km mỗi năm
  • 32. Just-in-time | Tức thì Cập nhật Hằng ngàyKế hoạch động,thích ứng liên tục Daily Standup
  • 33. Nhóm Tự tổ chứcSelf-organized Team
  • 34. Hướng đến Mục tiêu chung• Tập trung vào Mục tiêu, công phải Task• Giới hạn việc-đang-làm 34
  • 35. Nhóm liên chức năngCross-functional Team Ảnh: suitcaseorchestra.com
  • 36. Retrospective | KaizenCải tiến liên tục Image: Rachel Davies & Liz Sedley
  • 37. Độ trực quan Khả năng thay đổi Giá trị mang lại Rủi roTại sao Agile? Nguồn: Ken Schwaber
  • 38. 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 …
  • 39. User Story & BacklogsImage: iqupi.wordpress.com mountaingoatsoftware.com agilemodeling.com agilistapm.com
  • 40. Sprint Burndown Release Release BurndownẢnh: mountaingoat.com
  • 41. Ảnh: pages.kiva.org | Atlassian | Quang NB
  • 42. Học và hành Học thông qua … Thực hành• Ghép cặp (Pairing) • Thực học là để làm, làm• Cộng đồng thực hành được mới được coi là học (Coding Dojo, Interest được Group …) • Pilot project• Hội thảo chuyên ngành • Các bài tập lớn (assignment) (AgileTour, ScrumDay …) • Các Dự án|Đồ án (Project)• Đọc sách • Quản lí công việc cá nhân• Các tài nguyên online (Personal Kanban, Personal (video) Scrum, Lean …)• Thuyết trình|Dạy lại người khác
  • 43. Học tập cũng cần chiến lược SHU HA RI Bám sát Quy tắc Nghĩ lại về Quy tắc Quên đi Quy tắc Tìm kiếm ngoại lệ, Phá vỡ Quy tắc 43
  • 44. Expert Competent Proficient Tới Bruce Lee - bậc thầy Kungfu Advanced Beginner Novice 10.000 Giờ leo núiCậu bé bắt đầu học Vịnh Xuân Image: http://goo.gl/1RzEE 44
  • 45. Đọc thêm nữa 45
  • 46. 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 …)
  • 47. Cộng đồng HanoiScrum.netAgileVietnam.org
  • 48. :-)THANK YOU!
  • 49. BACKUP SLIDES
  • 50. Độ phức tạp của dự án Scrum Nguồn: Ken Schwaber
  • 51. Quy tắc Làm việc Đội Y *************1. Thời gian Daily Scrum: 9:002. Phạt đến muộn: 2 $3. Mọi người đều tích hợp liên tục4. Tái cấu trúc lại mã bẩn5. Hỏi nếu không rõ6. Sử dụng Lập trình cặp và TDD7. 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. Đã ký 51
  • 52. Một tình huống phát triển $ $Collaboration: PO DevTeam PO UI Mocking Design Draft Code the RefactoringSteps: Requirement Coding in Build the • Customer • Design Discussion skeleton to and Analysis team increment discussion test the design Refinement Interface IDo{ //TODO … A Interface IDo{ } //TODO … Class A{ IDo } method1(){ As a super user, Class A{ //Mr. A codes hereArtifacts: I want to … //TODO … } } B } Class B:IDo{ Class B:IDo{ //TODO … method1(){ } //Mrs. B codes here } } Note: Class C{ TDD|BDD|AMDD can be used or not } 52
  • 53. 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 53
  • 54. INVEST – các tiêu chuẩn cho một userstory tốt Independent – Độc lập Negotiable – Đàm phán được Valuable – Đáng giá Estimatable – Ước tính được Sized appropriately – Kích thước phù hợp Testable – Kiểm thử được 54
  • 55. Tập hợp các user story Chuẩn bị các Quan sát câu hỏi Phỏng vấn Viết user story người dùng 55
  • 56. 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. 56
  • 57. Lập trình cặpPair-Programming • Có 2 vai trò: Ngườilái• Hai LTV cùng chia sẻ một vấn đề, với một máy tính, một (Driver) và Hoa tiêu bàn phím và với mục tiêu: (Navigator): giải quyết vấn đề đó. – Người lái không quan tâm tới bức tranh toàn cảnh• Sử dụng sự ĐỒNG THUẬN, – Người lái nên “rời bàn phím nhưng thông qua TRANH trong giây lát” LUẬN! – Hoa tiêu có xu hướng sử dụng tư• Một ví dụ về “luồng một sản duy mẫu trong giải quyết vấn đề phẩm”• Chậm hơn nhưng hiệu quả hơn & chất lượng hơn 57
  • 58. 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 58
  • 59. Hệ thống Tích hợp liên tục CI Systems 59
  • 60. Thiết kế tiến hóaIncremental DesignThiết kế Luôn có Nhiều phức tạpnhững thứ những thứ hơn mức cầnphức tạp có thay đổi bất thiết. Khó khănkhả năng linh ngờ trong việc bảohoạt trên trìgiấy hoặccông cụ Dễ dàng thích Luôn có nghi. ID thay những thứ đổi dễ dàng.Thiết kế tiến Giảm bớt phứchóa thay đổi bất ngờ tạp 60
  • 61. 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 Xác định các yêu cầu cơ bản sản phẩm sau khi hoàn thành Phát triển bản mẫu đầu• Khuyến khích sự tham gia tích cực của người dùng và nhà phát triển Xem xét• Tăng tốc độ phát triển hệ thống Kiểm tra và cải tiến bản mẫu 61
  • 62. 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ử 62
  • 63. Các bước trong TDDNguồn ảnh: Excirial (http://upload.wikimedia.org/wikipedia/en/9/9c/Test-driven_development.PNG) 63
  • 64. Cái giá của bug
  • 65. Ba nhân tố RGB Thất bại Thành Cải tiến công 65
  • 66. 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 Kiểm thử Định nghĩa Yêu cầu Chấp nhận Tự Hoàn thành động hóa TDD 66
  • 67. Phát triển Hướng-Hành-viBehavior-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 Các mô Xác nhận Xác nhận Phát tả hành với mô lại hành triển vi phỏng UI vi 67
  • 68. Tái cấu trúcRefactoring• 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 68
  • 69. 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 69