Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Agile in a nutshell
Similaire à Agile in a nutshell (20)
Dernier
Dernier (20)
Agile in a nutshell
- 1. 1. The waterfall model 2. Incremental development 3. Reuse-oriented software engineering. 1 POPULAR SOFTWARE PROCESS MODELS 3 WHY WE NEED AGILE? 1. Agile manifesto 2. Agile principles 3. Agile umbrella 2 AGILE OVERVIEW 4 FAQS
- 2. Facts • Obviously we are changing so fast, there is almost no room for long-term plans • A lack of clear goals is the most common factor (37%) behind project failure, according to executive leaders. • Only 37% of teams in the U.K. reported completing projects on time more often than not. • More than half (56.6%) of manufacturers use a combination of project management methodologies. • 59% of U.S. workers say communication is their team’s biggest obstacle to success, followed by accountability (29%).
- 3. Software project elements Why are software development projects so risky and expensive? By the rigors of approaching methods
- 4. The waterfall model This model takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing, and so on.
- 5. Incremental development This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version.
- 6. Reuse-oriented software engineering This approach is based on the existence of a significant number of reusable components. The system development process focuses on integrating these components into a system rather than developing them from scratch.
- 8. Agile manifesto That is, while there is value in the items on the right, we value the items on the left more. Individuals and interactions over Process and Tools Working Product over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to change over Following a plan
- 9. 12 agile principles • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. • Business people and developers must work together daily throughout the project. • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. • Working software is the primary measure of progress. • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. • Continuous attention to technical excellence and good design enhances agility. • Simplicity--the art of maximizing the amount of work not done--is essential. • The best architectures, requirements, and designs emerge from self-organizing teams. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- 10. Agile umbrella
- 11. Scrum, for collaboration and focus
- 16. • What is Agile? (and is not)? • How is Agile? (and is not)? • What does Agile have (and does not)? • What does Agile aim for (and does not)? • What is Agile suitable for (and is not)? • Is agile a religion? • What does Scrum do well (and does not)? FAQs
- 17. Thank For Your Attention!
Notes de l'éditeur
- Rõ ràng là chúng ta đang thay đổi quá nhanh và gần như không còn chỗ cho những kế hoạch dài hạn. Bởi vậy khả năng thích nghi kịp thời chính là năng lực tối thượng của mỗi doanh nghiệp. Ví dụ như vừa mới ra mắt Odoo 12 với hàng loạt thay đổi ít lâu mà bây giờ đã có plan cho odoo 13 với hứa hẹn là sẽ có rất rất nhiều thay đổi. Rồi thì cái chết của những ông lớn như Yahoo, Nokia có cũng do không bắt kịp theo những sự thay đổi đó. Ngay cả như Apple từng mạnh mồm cho tỉ lệ vàng trên Iphone 4 và ghét màn hình to rồi cũng phải theo. Rồi cả khi những chiếc Apple Watch bé tí ra đời thì họ nghĩ đây là thời của những thiết bị đeo tay nhỏ gọn, rồi đúng cái lại có những chiếc iPad Pro to đùng. Thống kê cho thấy . thiếu đi mục tiêu hoặc mục tiêu không rõ ràng là yếu tố chính, phổ biến đằng sau sự thất bại của project. Chỉ 37% team ở Anh báo lại là hoàn thành đúng hạn, còn lại là toàn delay => Chúng ta không hề cô đơn! Hơn 56% nhà sản xuất kết hợp nhiều phương pháp quản lý, ở VN chúng ta hay nôm na là Đông Tây Y kết hợp. 59% người làm việc Mĩ nói là giao tiếp là rào cản lớn nhất tới thành công.
- Các yếu tố phát triển của dự án phần mềm chính là Time Cost và Quality. Rõ ràng thật khó để vừa có giá rẻ mà chất lượng cao, thời gian làm ngắn mà chất lượng cao được. Vậy thì tại sao dự án phát triển phần mềm luôn tiềm tàng nhiều rủi ro và đắt? Do sự gò bó trong cách tiếp cận. Thường thì chúng ta hay chia việc ra bằng cách chia nhỏ từng phân đoạn công việc, và mỗi người chỉ quan tâm đến phần việc của mình đang đảm nhiệm và không care đến tổng thể cũng như những việc khác đang chạy song song. Trong khi hiện nay, sự thích ứng với thay đổi cần được ưu tiên đưa lên hàng đầu, vì vậy mô hình làm việc theo nhóm mà đề cao sự cộng tác sẽ tăng khả năng thành công lên rất nhiều. Từng cá nhân cũng thế. Chúng ta buộc phải thích nghi với mô hình làm việc với tăng sự công tác trong nhóm để tối ưu hóa khả năng của mỗi cá nhân. Cuộc sống của chúng ta cũng biến đổi từng ngày, nên chúng ta không thể phớt lờ hiện thực đó bởi việc bám sát kế hoạch từ trước. Và rõ ràng chúng ta đều biết là không có 1 phương pháp nào phù hợp với mọi cá nhân hay mọi tổ chức, việc chúng ta cần làm là tìm ra phương pháp làm việc với từng cá nhân, từng dự án và từng tổ chức cụ thể. Dù đề cao sự ừng biến linh hoạt, nhưng không thể phủ nhận việc tổ chức vẫn cần giữ tầm nhìn và 1 mục tiêu dài hạn!
- OK. Trước khi đi vào những định nghĩa của Agile thì xin lướt qua 3 mô hình tiếp cận và phát triển phần mềm. Phần này dành cho team dev nhưng mọi người có thể theo dõi để có thêm hình dung về công việc của developer,. Việc phát triển được trải qua những giai đoạn tách biệt và rất cụ thể thực hiện bởi các phòng ban chuyên trách, từ phân tích ý tưởng, thiết kế tổng thể, thiết kế chi tiết, lập trình, kiểm thử cho đến triển khai và bảo trì. Mô hình waterfall là 1 ví dụ của plan-driven process - đại loại là PHẢI lên kế hoạch và lên lịch cho tất cả các hoạt động TRƯỚC khi bắt đầu làm việc. Kết quả của mỗi giai đoạn là tài liệu, giai đoạn tiếp theo không nên bắt đầu cho đến khi giai đoạn trước đó xong. Về nguyên lý thì mô hình này chỉ nên sử dụng khi yêu cầu rõ ràng và ít có thay đổi lớn trong quá trình phát triển.
- Cách làm này thực hiện xen kẽ những hoạt động từ việc lên yêu cầu, phát triển, kiểm thử. Hệ thống được phát triển với nhiều các phiên bản chạy được và được bù đắp liên tục, mỗi version mới ra thì thêm những chức năng vào version trước đó. Đây là tiền đề của Agile nhé.
- Reuse-oriented software engineering: cách làm này dựa trên những thành phần đã có, chỉ tập trung để chỉnh sửa, tích hợp các thành phần đó để chạy được hơn là phát triển từ đầu. Nhìn qua thì có thể thấy việc chúng ta phát triển Kiu ERP dựa trên Odoo đang rơi vào reuse-oriented. Việc chúng ta thực hiện customization cho khách nên rơi vào waterfall hoặc incremental. Nhưng vì chúng ta phải đưa ra quotation trước, nên thực sự để đúng đắn đó là tránh thiệt cho công ty (estimate sai, dev phải làm thêm, hoặc phải sửa lại do làm sai..) và thiệt hại cho khách hàng khi bị tốn tiền, không được nhận cái mình muốn thì nó nên rơi vào mô hình waterfall. Với những sản phẩm phải build từ đầu như: Kiu POS, CSE, KLP thì nên làm theo mô hình incremental. Thực tế thì các mô hình này không hoàn toàn tách biệt, mà thường được sử dụng cùng nhau. It makes sense to kết hợp những cái hay ho nhất của waterfall và incremental. Cần có thông tin về những yêu cầu cơ bản, nền tảng để thiết kế kiến trúc để hỗ trợ các requirements, phần này không thể làm theo kiểu incremental. Những phần tiếp theo có thể sử dụng các mô hình khác nhau. Những cái mà chúng ta hiểu rõ biết rõ thì có thể làm theo waterfall, những cái khó thì làm theo kiểu incremental, ví dụ giao diện.
- Agile là phương pháp tiếp cận lặp cho việc quản lý và phát triển phần mềm, giúp team đưa ra giá trị tới khách hàng nhanh chóng hơn với ít đau đầu hơn. Thay vì dự đoán mọi thứ cho 1 việc ra mắt big bang, thì agile team triển khai công việc theo những phần nhỏ, nhưng dùng được, và tăng dần. Yêu cầu, kế . hoạch và kết quả được đánh giá liên tục, vì vậy team sẽ phản xạ nhanh chóng với những thay đổi hơn. Điều này rất quan trọng với thế giới ngày nay. Thuật ngữ phát triển phần mềm linh hoạt, agile software development lần đầu được đưa ra trong cuộc họp (thảo luận kết hợp giải trí, trượt tuyết) giữa 17 chuyên gia hàng đầu, và sau đó một bản tuyên ngôn Agile được đưa ra.
- Chúng tôi đã phát hiện ra cách phát triển phần mềm tốt hơn bằng cách 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ác với khách hàng hơn là đàm phán hợp đồng Phản hồi với các thay đổi hơn là bám sát với các kế hoạch Mặc dù các điều bên phải vẫn còn giá trị nhưng chúng tôi đánh giá cao hơn các mục bên trái.
- Nếu bạn thấy bản tuyên ngôn này quá ngắn và chung chung thì có thể tham khảo 12 nguyên lý đứng sau tuyên ngôn dưới đây:
- Scrum là phương pháp thực nghiệm và được sử dụng nhiều nhất, áp đảo trong những phương pháp khác,
- Scrum đơn giản nhưng đủ chi tiết và đặc biệt phù hợp với việc phát triển sản phẩm. Scrum vận hành dựa trên những khung thời gian cố định, lặp đi lặp lại, gọi là Sprint giúp cho nhóm phát triển luôn có được nhịp đập đều đặn và tập trung cao độ trong thời gian ngắn. Thực nghiệm
- Tối ưu hiệu quả, tập trung vào luồng công việc, workflow thay vì thời gian. Mỗi công việc được trực quan hóa trên 1 bảng trạng thái tương ứng với luồng thực hiện công việc. Để tối ưu sự tập trung, Kanban sử dụng khái niệm giới hạn công việc đang thực hiện WIP. Nhờ tính trực quan và tập trung vào luồng công việc, Kanban giúp nhóm phát triển nhanh chóng nhận ra những nơi có thể cải tiến để có một luồng công việc hiệu quả hơn.
- XP đặc biệt, vì có chọn framework nào thì cũng đều sử dụng 1 hoặc 1 số kĩ thuật trong XP. XP tập trung vào phân chia các tác vụ thành những công việc cụ thể lặp lại trong thời gian ngắn và tập trung vào kỹ thuật để đưa ra sản phẩm với chất lượng cao bằng TDD, BDD...
- Tinh gọn và nhanh, loại bỏ tất cả những công việc không cần thiết nhằm thúc đẩy sự chuyển giao nhanh và tiết kiệm hơn. Nếu có trở ngại nào được tìm th ấy, thành viên tỏng nhóm được trao quyền để giải quyết nhanh nhất có thể. Sự trao quyền nhé!!!! Lean k đc coi là phươgn pháp phát triển phần mềm cụ thể, nhưng tư tưởng của Lean rất đc đáng lưu tâm, loại bỏ lãng phí, chất lượng từ cốt lõi, trì hoãn sự cam kết, tối ưu hệ thống, khuyến khích học tập...
- Dự án phần mềm bắt đầu với một khoảng thời gian ngắn, nhằm thiết lập những công việc sẽ xảy ra với những mô hình cụ thể cugnf danh sách chức năng và kế hoạc phát triển được trao quyền. Sau đó mỗi iteration thực hiện một vài chức năng đảm bảo đủ cho việc chuyển giao với đầy đủ chức . Năng và tài liệu liên quan. FDD phức tạppppp
- Nhìn lại 4 điều trong Tuyên ngôn và 12 nguyên lý, dễ nhận thấy là chúng khá chung và đúng. Điều này dễ hiểu vì tìm kiếm điểm chung của nhiều phương pháp cũng như đồng thuận của 17 người, đại diện cho 17 tư duy, quan điểm thì khó mà cụ thể được. Thời điểm đó, Agile là tập hợp của các phương pháp phát triển phần mềm dựa trên sự kết hợp của phương pháp lặp và tăng trưởng. Lưu ý, tôi đang nói về phần “thể hiện” của các phương pháp, không phải “tư duy” (nguyên lý) phía sau. Nhưng sau này, dựa trên nguyên lý, nhiều thứ khác được coi là Agile với nhưng thể hiện không giống như ban đầu. Người ta bắt đầu nói về no planning, no estimation, no Sprint,… đủ thứ. Một ví dụ là Kanban, nó chỉ có thể hiện phần tăng trưởng, không rõ ràng đề cập tới lặp nhưng vẫn nằm trong Agile. Lưu ý rằng Agile Software Development cũng phải dựa trên một số nguyên tắc về quản lý, cách tổ chức nói chung nhưng những thứ này không được định nghĩa rõ ràng. Điều này dẫn đến một số hiểu lầm khá tệ. Ví dụ như “self-organized team” và “cross-functional team”, Agile sử dụng mà không sở hữu; vậy nên không thể hiểu chỉ Agile mới xây dựng những team như vậy. Hay như mô hình về team stage của Tuckman cũng không thuộc về Agile. Kỹ thuật 5Whys, Kaizen… cũng vậy. Đó là những công cụ để nhóm hay người quản lý nhóm thực hiện tiến hoá quy trình. Agile hướng tới giá trị (value oriented), không hướng quy trình (process oriented). Quy trình trong Agile cũng buộc phải thể hiện được giá trị mới có lý do để tồn tại. Để tìm được giá trị, bắt buộc phải trả lời câu hỏi “tại sao (why)?”. Để tìm được quy trình, câu hỏi là “thế nào (how)?”. Câu hỏi why khó hơn rất, rất nhiều câu hỏi how. Và thông thường, để trả lời được câu hỏi why, chúng ta cần dựa trên how đang tồn tại. Agile ra đời với “Agile Software Development” tức là để giải quyết bài toán của phát triển phần mềm. Scrum nói rõ nó phù hợp với các dự án / sản phẩm nằm trong miền “phức hợp và phức tạp tương đối” về yêu cầu và kỹ thuật – tức là các dự án / sản phẩm đơn giản (đã rõ ràng) hoặc quá phức tạp (VD: R&D, công nghệ quá cao…) cần được xem xét. Thế nào là đơn giản, phức tạp… phụ thuộc nhiều yếu tố: con người, trình độ, công cụ,… nên (ví dụ) Scrum có thể phù hợp với team này ở sản phẩm này nhưng không phù hợp với team khác ở chính sản phẩm đó. Agile dựa trên giả định về việc “chào đón sự thay đổi” (welcome change, Scrum: adapt to change, XP: embrace change); tức là, mọi cá nhân trong tổ chức đều thống nhất rằng “thay đổi là điều được chấp nhận”. Tổ chức không đồng tình với sự thay đổi, không “chào đón” mà áp dụng Agile là sai từ gốc. Hầu hết các phương pháp Agile đều dựa trên giả định “cá nhân có động lực làm việc” nên các tổ chức còn loay hoay trong việc này cũng nên cẩn trọng. Agile dự trên pull-system, giả định “cá nhân có động lực làm việc”, điều này đi ngược với phần lớn cách tư duy về quản lý hiện có. Dù có hệ thống lý thuyết chặt chẽ đứng sau, Agile vẫn cần niềm tin để thực hiện trong tổ chức. Khi phương pháp cần tới “niềm tin” là điểm xuất phát thì nó không khác gì “đạo” – sẽ có kẻ sùng đạo và phản đạo. Scrum thực sự tuyệt vời. Nó là một mô hình tuyệt vời với đủ sự tinh gọn, hiệu quả cho phép tổ chức “nhận diện vấn đề”. Đây là điều siêu quan trọng để phát triển sản phẩm cũng như phát triển tổ chức. Scrum không làm việc giải quyết vấn đề. Vậy nên nếu nhóm không giải quyết những vấn đề được nhận diện thf scrum cũng k để làm gì. Nhưng có phương pháp nào giải quyết vấn đề không? Scrum làm tốt trong việc ghi chú “Scrum dễ hiểu, khó làm chủ”. Scrum (đúng hơn là các tổ chức cấp chứng chỉ Scrum (Master, Developer, PO)) làm không tốt trong việc đào tạo. Khá dễ dãi. Có 2 lỗ hổng lớn, khiến các ScrumMaster cầm chứng chỉ và nếu không chịu học hỏi thêm sẽ mắc phải: Không trả lời được rõ ràng các câu hỏi trên. Cái gì thuộc Scrum, cái gì không? Dẫn đến ngộ nhận trong lý thuyết lẫn thực hành. ScrumMaster không yêu cầu kiến thức về phát triển phần mềm. Về lý thuyết, điều này không sai; song thực tế thật khó để tham gia vào nhóm phát triển phần mềm mà không hiểu gì về cách nhóm thực hiện. Từ đây dẫn tới những hệ luỵ vô cùng phức tạp. Chuyển giao cái gì? Technical debt là gì? Simple design là gì? Xử lý thế nào? Tài liệu thế nào là đủ?… ScrumMaster yếu về chuyên môn (ngành) và non tay dẫn dắt nhóm có trình độ cao hơn mình sẽ là thảm hoạ. Đội bóng cần HLV tương xứng. Vấn đề là, tốc độ phát triển của thành viên Nhóm phát triển thường nhanh hơn (và khởi đầu tốt hơn) những ScrumMaster. Vậy nên nhiều nhóm phát triển bắt đầu chán ghét Scrum. Tuyệt nhiên không thể mông lung như Agile làm nhóm hạnh phúc hơn, Agile giúp tăng năng suất, Agile giúp tăng tốc độ hoàn thành dự án… – những điều Agile nguyên thuỷ không hề đề cập.
- Ngay cả khi làm cái slide này cũng rất agile