Giới thiệu các bài trình bày

Chủ đề Giới thiệu
Con đường can đảm từ đổi mới tới chuyển giao linh hoạt

Jas Chong -HLV Chuyển đổi Agile

Giới thiệu Scrum@Scale

Kiro Harada – Sáng lập viên và Giám đốc điều hành, Attractor Inc

Scrum@Scale là một khung là việc trong một mạng lưới gồm nhiều nhóm Scrum thực hành đồng nhất theo Scrum Guide, có thể giải quyết những vấn đề phức tạp trong khi vẫn chuyển giao sáng tạo các sản phẩm với chất lượng cao nhất có thể. Những “sản phẩm” có thể là phần cứng, phần mềm, hệ thống tích hợp phức tạp, quy trình, dịch vụ… phụ thuộc vào lĩnh vực của những nhóm Scrum.

Bài trình bài bao gồm giới thiệu về Scrum@Scale.

 

Doanh nghiệp Linh hoạt

Cherry Vũ – Giám đốc điều hành, Two Hills Ltd

Tư duy Agile đang biến đổi ngành CNTT, các doanh nghiệp, chính phủ và xã hội. Tác động của nó đủ sâu để nói về Agile như sự phục hưng trong suy nghĩ, một sự thay đổi mới mẻ hoặc bước đi chỉ xuất hiện một hoặc hai lần trong một thế kỷ. Đây không phải là cường điệu. Agile dẫn đến các cách làm việc mới: Lặp đi lặp lại, tăng trưởng, thử nghiệm, khám phá các hệ thống phức tạp. Đây là sự thay thế cho các dự án big-bang; không rủi ro; chắc chắn và chính xác; kế hoạch để thực hiện hoàn hảo; không lựa chọn thất bại.

“Vận tốc thông qua chất lượng” là cách làm việc mới. Tại trung tâm, linh hoạt là đi nhanh hơn bằng cách tốt hơn. Chúng tôi xây dựng nền văn hóa này thông qua sự chú ý đến lãnh đạo, hạnh phúc, không gian, trao quyền, cộng đồng và truyền thông.

Mặc dù vậy, quan trọng nhất, là cách quản lý mới. Các quản lý thường xem việc chuyển đổi sang các cách thức mới như một điều được thực hiện để cải thiện lực lượng lao động chứ không phải để quản lý. Điều này là không thể. Để một tổ chức thay đổi, việc quản lý phải thay đổi. Vì vậy, chúng tôi kết hợp cả hai thành cụm từ Cách Làm Việc và Quản Lý Mới, NWOWAM ™. Dù cồng kềnh, nhưng chúng tôi muốn làm cho một điểm. Đây là một trong những vấn đề lớn nhất mà các tổ chức phải đối mặt với những cách làm việc linh hoạt. Người quản lý phải hiểu và tập trung vào trao quyền, hợp tác, linh hoạt và lưu thông.

Giáo dục Linh hoạt: Các lớp học cần Linh hoạt

Nguyễn Khắc Nhật – Đồng sáng lập viên, CodeGym

Áp dụng Agile vào trong việc thiết kế chương trình, triển khai lớp học với thông tin phản hồi từ học viên, đánh giá của huấn luyện viên và doanh nghiệp để thích ứng chương trình cho từng học viên một cách nhanh chóng
Bài học thất bại từ cô gái tới cuối cùng

Elise Aplin – Quản lý sản phẩm, Clover.com.au

Trong nhiều năm, nhiều nhóm đã kỷ niệm vai trò thất bại trong việc xây dựng sản phẩm. Rất nhiều điều đã được nói về Thất Bại Nhanh mà chúng tôi đã quên rằng mục tiêu thực sự của chúng tôi là phát triển cá nhân, nhóm và sản phẩm. Chủ đề này sẽ khám phá các ý tưởng hiện tại xung quanh sự thất bại và cách chúng hạn chế khả năng phát triển nhóm và những cá nhân trong nhóm.

 

Chúng ta là ai? Chúng ta đang làm gì?

Duncan Campbell

Bạn đang lập trình, hay bạn đang là một kỹ sư phần mềm?

Bạn nói bạn là người chuyên nghiệp, hay bạn đang chuyên nghiệp?

Bạn đang thực hành Agile, hay bạn đang Agile?

Bạn đang theo một số các quy trình và sử dụng những công cụ, hay bạn đang chuyển đổi cách làm việc và cách chuyển giao những giải pháp đúng, theo cách đúng đắn trong tình huống phù hợp tới khách hàng?

 

HLV Agile là gì, tại sao chúng ta cần nhiều HLV Agile?

Wahid Nurdin – Đồng sáng lập viên, Ekipa

Ngày nay, vai trò HLV Agile đang rất “nóng”, một số công ty đang trong quá trình triển khai Agile tuyển dụng HLV Agile để giúp quá trình chuyển đổi. Nhưng chính xác HLV Agile là gì? Họ giúp gì cho chuyển dịch Agile trong tổ chức? Tổ chức đang sử dụng Scrum, đã có vị trí ScrumMaster, tại sao vẫn cần HLV Agile?
Với những câu hỏi cơ bản, Wahid sẽ chỉ rõ vai trò chính của HLV Agile và tại sao tổ chức lại cần nhiều HLV Agile?
Retrospectives: từ tốt tới Vĩ đại!

Rohit Aroara – Agile Champion cho CIO châu Á, Barclay

Kiến thức mới hình thành từ kinh nghiệm. Agile Retrospectives cho phép toàn nhóm học tập, hoạt động như chất xúc tác để tự cải tiến và tạo ra các hành động tích cực.

Retrospectives là trung tâm của vòng lặp phản hồi tồn tại trong Scrum để khuếch đại các bài học nhóm. Trong thời gian Retrospectives có thể mất giá trị nếu họ không được thực hiện đúng. Là một HLV Scrum, chúng tôi cần làm cho Retrospectives có giá trị để tạo ra các đội có hiệu suất cao.

Mô tả:

Nhóm của bạn có coi thường Retrospectives không? Retrospectives có trở nên nhàm chán, không hiệu quả và không được coi là hữu ích không? Hãy đến và nhận được vài cách mới và thủ thuật dưới tay áo của bạn có thể mang đội trở lại đúng hướng!

Mục tiêu học tập:

Là thành viên nhóm,
Tôi muốn tìm hiểu tầm quan trọng của Retrospectives và cách thực hiện các hành động
để chúng ta có được giá trị.

Là ScrumMaster,
Tôi muốn một bộ công cụ Retrospectives để tạo điều kiện thuận lợi cho việc truy tìm lại hiệu quả
để nhóm không còn nhàm chán và tham gia hiệu quả hơn.

Là Chủ sản phẩm,
Tôi muốn tìm cách cải tiến liên tục cho một nhóm,
để nhóm hướng tới hiệu suất cao.

CI/CD cho hệ thống bất biến

Phương Công Quân – Trưởng nhóm VC Cloud & Edumall, HLV DevOps, Học viện Agile

Việc áp dụng CI/CD trong các hệ thống có cấu hình đã cố định rất khác với những hệ thống có thể thay đổi được. Thông thường chúng ta nghĩ rằng phải phá hủy những điểm này. Nhưng không.
Có gì ngoài mã nguồn?

Andre Rubin Santos – HLV Agile – Scrum Master, Mindvalley

Lập trình viên thường chỉ tập trung vào việc viết mã nguồn và những ngôn ngữ, mẹo và framework mới và họ hy vọng có thể thăng tiến. Đôi khi những lập trình viên kinh nghiệm cũng cho rằng vai trò của họ là viết code. Tuy nhiên, khi họ làm việc trong nhóm Agile, vai trò của họ không chỉ viết Code. Vai trò thực sự của họ là bàn giao giá trị tới khách hàng. Công việc của họ rất nhiều khi không phải viết code và đôi khi không phải viết dòng mã nào mà vẫn mang lại giá trị cho khách hàng. Trong bài nói sẽ hướng dẫn cách cải thiến cách đánh giá giá trị bàn giao cho khách hàng.
Linh hoạt để bảo toàn thế giới

Dahm M. Hongchai – HLV Agile, Elsner Engineering Works Inc

Một công ty sản xuất túi ni-lon tại Thái Lan đã áp dụng Agile và Scrum để thu thập những chiếc túi ni-lon đã qua sử dụng để tái chế.

Chúng tôi đã học được:

– áp dụng ý tưởng nhỏ trước khi mở rộng dự án

– giao tiếp giữa các thành viên và tôi khi tôi huấn luyện họ từ San Francisco

– thay đổi tư duy của lãnh đạo cao cấp

Cải thiện nghề Chuyển giao Phần mềm qua Scrum, Kanban, DevOps và Nexus

Shirley Santiago – Chief Architect, RCG Global Services Offshore Delivery Center

 

Chủ đề này là giới thiệu tốt cho những ai đang áp dụng Agile trong Chuyển giao Phần mềm, bao gồm Scrum, Scrum với Kanban, Scrum với DevOps và Scaled Scrum hoặc khung làm việc Nexus.

Bài nói chuyện đưa ra một cái nhìn tổng quan về bốn chủ đề rộng lớn nhưng sẽ bao gồm đủ thông tin để khán giả có ý thức về cách có thể áp dụng tại nơi làm việc.

Scrum – là một khung làm việc trong đó mọi người có thể giải quyết các vấn đề thích ứng phức tạp, đồng thời mang lại hiệu quả và sáng tạo các sản phẩm có giá trị cao nhất có thể.

Kanban – Quan điểm dựa trên dòng chảy của Kanban có thể tăng cường và bổ sung cho khung làm việc Scrum và việc thực thi. Các nhóm có thể áp dụng Kanban cho dù họ chỉ định sử dụng Scrum hoặc đã sử dụng tất cả đồng thời.
Kanban (n): một chiến lược để tối ưu hóa dòng chảy của giá trị các bên liên quan thông qua một quá trình sử dụng hệ thống kéo hạn chế trực quan, công việc đang tiến hành
Trung tâm định nghĩa của Kanban là khái niệm “dòng chảy”.
Dòng chảy là sự chuyển động của giá trị mang lại cho khách hàng trong toàn bộ hệ thống phát triển sản phẩm.
Kanban tối ưu hóa dòng chảy bằng cách cải thiện hiệu quả tổng thể, hiệu quả và khả năng dự đoán của quy trình.

DevOps – là một tập hợp hiểu biết về thực tiễn và giá trị văn hóa đã được chứng minh để giúp các tổ chức thuộc mọi quy mô cải thiện chu kỳ phát hành phần mềm, chất lượng phần mềm, bảo mật và khả năng nhận phản hồi nhanh về phát triển sản phẩm.

Nexus – là một lớp nằm trên Scrum (một “bộ xương ngoài mà các Nhóm Scrum hiện có có thể đặt để cho phép chúng mở rộng”). Một khung làm việc nhẹ để mở rộng quy mô Scrum cho 3 đến 9 nhóm

Chuyển giao giá trị với BDD

Ritesh Mehrotra – Tư vấn viên Phần mềm, Credit Suisse

BDD (Phát triển Hướng Hành vi – Behavior Driven Development) không phải gherkin… viết tính năng với cucumber.

Trong bài nói, chúng ta sẽ khám phá nguồn gốc, niềm tin và ưu điểm của việc áp dụng BDD vào phát triển sản phẩm.

DevOps với Kubernetes

Phạm Thanh Tú – Sáng lập viên, Agiletech

Tác giả sẽ trình bày, demo giải pháp sản phẩm sử dụng Kubernetes
Quên điều đã học: Bài học về quản lý và tạo điều kiện as một Dungeon Master

Guillaume Duquesnay – Senior Agile Coach, Giom Consulting, Singapore

Kinh nghiệp 25 năm chơi nhập vai của tôi, nhiều hơn so với 15 năm kinh nghiệm làm việc. Tôi vẫn chơi game mỗi 2-3 tháng.

Tôi phải thừa nhận: khả năng quản lý, tạo điều kiện (facilitation) và lãnh đạo tốt nhất tôi học được từ những trò chơi đóng vai, nhiều hơn trong công việc. Nếu bạn muốn nghe, tôi sẽ kể hành trình như một Game Master.

Chúng ta trở về những năm 90, bạn sẽ gặp một vài người bạn cũ của tôi, theo dõi chúng tôi qua nhiều năm, sống những kỷ niệm tốt nhất cũng như tệ nhất của chơi game. Tôi cũng sẽ chia sẻ việc học, việc tạo điều kiện, lãnh đạo, quản lý, cam kết và nhiều nữa.

X