1.

3 Pillars of empirical process control (3 trụ cột của kiểm soát quá trình thực
nghiệm)
Tính minh bạch(Transparency) : Điều này có nghĩa là trình bày sự thật như hiện
trạng. Tất cả những người có liên quan—khách hàng, Giám đốc điều hành, cá nhân đóng
góp—đều minh bạch trong giao dịch hàng ngày với những người khác. Tất cả họ đều tin
tưởng lẫn nhau và có đủ can đảm để giúp nhau cập nhật tin tốt cũng như tin xấu. Mọi
người đều phấn đấu và cộng tác chung vì mục tiêu chung của tổ chức và không ai có bất
kỳ chương trình nghị sự ẩn giấu nào.
Kiểm tra(Inspection) : Kiểm tra trong bối cảnh này không phải là kiểm tra bởi thanh tra
viên hay kiểm toán viên mà là kiểm tra bởi mọi người trong Nhóm Scrum. Việc kiểm tra
có thể được thực hiện đối với sản phẩm, quy trình, khía cạnh con người, thực tiễn và cải
tiến liên tục. Ví dụ: nhóm giới thiệu sản phẩm một cách công khai và minh bạch vào cuối
mỗi Sprint cho khách hàng để thu thập phản hồi có giá trị. Nếu khách hàng thay đổi yêu
cầu trong quá trình kiểm tra, nhóm sẽ không phàn nàn mà sẽ điều chỉnh bằng cách tận
dụng cơ hội này để cộng tác với khách hàng nhằm làm rõ các yêu cầu và thử nghiệm giả
thuyết mới.
Thích ứng(Adaptation) : Thích ứng trong bối cảnh này là cải tiến liên tục, khả năng
thích ứng dựa trên kết quả thanh tra. Mọi người trong tổ chức phải thường xuyên hỏi câu
hỏi này: Chúng ta có khá hơn ngày hôm qua không? Đối với các tổ chức hoạt động dựa
trên lợi nhuận, giá trị được thể hiện dưới dạng lợi nhuận. Sự thích ứng cuối cùng sẽ quay
trở lại một trong những lý do để thích ứng Agile—ví dụ, thời gian tiếp thị nhanh hơn,
tăng lợi tức đầu tư thông qua phân phối dựa trên giá trị, giảm tổng chi phí sở hữu thông
qua nâng cao chất lượng phần mềm và cải thiện sự hài lòng của khách hàng và nhân viên.
2. Focus on MVP
Minimum Viable Product
#Minimum Valuable
Product
- In product development, the Minimum Viable Product (MVP) is the product
with the highest ROI versus risk
- Being able to quickly and inexpensively create a product to gauge the market
before investing time and resources into something that may not be
successful is a great idea
- Trong phát triển sản phẩm, Sản phẩm khả thi tối thiểu (MVP) là sản phẩm
với Tỉ suất Lợi nhuận Đầu tư cao nhất so với rủi ro
 - Có khả năng tạo ra sản phẩm để đánh giá thị trường một cách nhanh chóng và ít
tốn kém trước khi đầu tư thời gian và nguồn lực vào một việc gì đó có thể không
phù hợp thành công là một ý tưởng tuyệt vời
3. Agile Principles (shortcut)
1) Produce Value Early
2) Welcome Changes
3) Iterative Delivery
4) Daily Business Collaboration
5) Trust motivated team
6) Face to face
7) Working software
8) Sustainable development
9) Technical exellence
10) KISS-Smart, Sexy
11) Self-Organized team
12) Reflect, Adjust, Adapt

4. Agile [thinking]
Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
 Responding to change over Following a plan
Các cá nhân và tương tác hơn là quy trình và công cụ
Phần mềm hoạt động hơn là tài liệu chi tiết
Sự hợp tác với khách hàng hơn là đàm phán hợp đồng
Đáp ứng thay đổi hơn là tuân thủ kế hoạch
5. Framework/Scrum

Các giá trị Scrum là:

 Can đảm - Các thành viên của Nhóm Scrum cần có can đảm để làm điều đúng
đắn và đối mặt với những vấn đề khó khăn. Ví dụ, họ nên thể hiện lòng can đảm
để khám phá những điều chưa biết, thay đổi hướng đi, chia sẻ thông tin và tham
gia vào các cuộc bất đồng một cách lịch sự.
 Trọng tâm - Nhóm Scrum tập trung vào công việc của Sprint và các mục tiêu của
nó. Ví dụ về điều này bao gồm tập trung vào: tạo ra giá trị, điều quan trọng nhất
hiện tại và hoàn thành.
 Cam kết - Mỗi thành viên của Nhóm Scrum cam kết đạt được các mục tiêu của
nhóm và hỗ trợ lẫn nhau. Điều này liên quan đến sự cam kết hoặc cống hiến cho:
o Mang lại giá trị;
o Chất lượng;
o Làm việc hướng tới Mục tiêu Sprint và Sản phẩm;
o Sử dụng chủ nghĩa kinh nghiệm.
 Tôn trọng - Các thành viên của Nhóm Scrum phải tôn trọng lẫn nhau như những
chuyên gia lành nghề. Các thành viên của Nhóm Scrum nên tôn trọng chuyên môn
và quan điểm khác nhau của nhau và tôn trọng khi họ không đồng ý.
 Tính cởi mở - Nhóm Scrum và các bên liên quan đồng ý cởi mở về tất cả công
việc cũng như những thách thức khi thực hiện công việc. Các thành viên của
Nhóm Scrum nên cởi mở về những khó khăn mà họ gặp phải. Họ nên chia sẻ phản
hồi và học hỏi lẫn nhau cũng như từ các bên liên quan.
 6. Combination & Compare

7. scrum team bao gồm:

product owner, development team, scrum master
PO có quyền lực cao nhất trong scrum team
build the right things
make right thing
- PO
-Build the right things
- He is the driver of the Product→He will make the decision
- where the journey will end up..
- Drives the Product to Success
- Create and Maintains the Product Backlog
- Create the Product Vision
- Collaborates with Stakeholders
- Collaborates with the Team
- Participates in Sprint Meeting
- Authority
-Xây dựng những điều đúng đắn
- Anh ấy là người điều khiển Sản phẩm→Anh ấy sẽ đưa ra quyết định
- nơi cuộc hành trình sẽ kết thúc..
- Đưa sản phẩm đến thành công
- Tạo và duy trì Product Backlog
- Tạo tầm nhìn sản phẩm
- Hợp tác với các bên liên quan
- Phối hợp với Đội
- Tham gia Sprint Meet
- Thẩm quyền
PO-Pitfall
PO is overloaded
PO is not authorized
will also slow down the process
will also make the planning inefficient
PO is not available
PO get no support by Management
PO bị quá tải
PO không được ủy quyền
cũng sẽ làm chậm quá trình
cũng sẽ làm cho việc lập kế hoạch trở nên kém hiệu quả
PO không có sẵn
PO không nhận được sự hỗ trợ từ Ban quản lý
- Development team
Responsible for delivering the USEFUL product after each sprint
(potential shippable product increment)
Manage the work inside the Sprint & manage progress inside the Sprint
3-9 member -> selt-organized
Practicipates in all sprint meetings
 -Plan how much work they can do in a Sprint, Release
-What working steps are necessary to reach the GOAL
- Organize and manage the work by themselves
- Bring suggestion how to get the work done
- Improve the quality and the teamwork and the productivity
This all needs trust! And Authority
Chịu trách nhiệm đưa ra sản phẩm HỮU ÍCH sau mỗi sprint
(tăng sản phẩm có thể vận chuyển được)
Quản lý công việc trong Sprint & quản lý tiến độ trong Sprint
3-9 thành viên -> tự tổ chức
Thực hành trong tất cả các cuộc họp sprint
-Lập kế hoạch khối lượng công việc họ có thể làm trong Sprint, Release
-Các bước làm việc cần thiết để đạt được MỤC TIÊU
- Tự tổ chức và quản lý công việc
- Đưa ra gợi ý về cách hoàn thành công việc
- Nâng cao chất lượng, tinh thần đồng đội và năng suất
Tất cả điều này cần sự tin tưởng! Và quyền hạn
- Development Team-Pitfall
No commitment
Not self-organized
- Part in several Teams
Not a cross-functional Team
- Not working as one team
Stop Learning
Không có cam kết
Không tự tổ chức
- Tham gia vào một số Đội
Không phải là một nhóm đa chức năng
- Không làm việc theo nhóm ngừng học tập
 Scrum Master
Coaches the Product Owner and Dev Team
The Scrum Master is the expert in Scrum
The Scrum Master helps the PO, Team and Organization to improve:
- Productivity
- Quality
- Working Practice
- Facilitate Meetings, if needed
The Scrum Master will follow up that the Impediments will be solved
Huấn luyện Chủ sở hữu sản phẩm và Nhóm phát triển
Scrum Master là chuyên gia về Scrum
Scrum Master giúp PO, Nhóm và Tổ chức cải thiện:
- Năng suất
- Chất lượng
- Thực hành làm việc
- Hỗ trợ các cuộc họp nếu cần
Scrum Master sẽ theo dõi xem các Trở ngại sẽ được giải quyết
Remove Impediments
The Scrum Master will help to Identify Impediments
The Scrum Master will follow up that the Impediments will be
solved
Loại bỏ trở ngại
Scrum Master sẽ giúp xác định các trở ngại
Scrum Master sẽ theo dõi các Trở ngại sẽ được giải quyết
đã giải quyết
Process Related Responsibility
Teach and Coach the Scrum Framework
Scrum Master should be the expert in Scrum
Trách nhiệm liên quan đến quy trình
Dạy và huấn luyện Khung Scrum
Scrum Master phải là chuyên gia về Scrum
 Protect the Team
The Scrum Master will shield and protect the Team from
external interruptions during the Sprint
Bảo vệ đội
Scrum Master sẽ che chắn và bảo vệ Nhóm khỏi
gián đoạn bên ngoài trong Sprint
Guides the Team
Help and support the Team with Values & Agile Principles
The SM needs to be an example
Encourage and support the Team to
Challenge themselves
Continuous improving
Hướng dẫn đội
Giúp đỡ và hỗ trợ Nhóm bằng các Giá trị & Nguyên tắc linh hoạt
SM cần phải làm gương
Khuyến khích và hỗ trợ Nhóm
Thử thách bản thân
Cải tiến liên tục
Keep the list of Impediments transparent and visible...
To solve the impediments...
Don't forget, never stop to lean more!
Giữ danh sách Trở ngại minh bạch và dễ thấy...
Để giải quyết những trở ngại...
Đừng quên, đừng bao giờ dừng lại để nạc nhiều hơn!
Authority based on Values
No authority to make decision on behalf of the Team
Can not make commitment about Deadlines
But can enforce the Scrum process
•Ensures that everybody will follow the process (SCRUM,
TIMEBOX)
 •Ensures that the team is fully functional and productive
(don't get speed by pushing the team!)
Quyền lực dựa trên giá trị
Không có thẩm quyền đưa ra quyết định thay mặt cho Nhóm
Không thể cam kết về deadline
Nhưng có thể thực thi quy trình Scrum
•Đảm bảo rằng mọi người sẽ tuân theo quy trình (SCRUM,
HỘP THỜI GIAN)
•Đảm bảo rằng nhóm hoạt động đầy đủ và hiệu quả
(không đạt được tốc độ bằng cách đẩy đội!)
Scrum Master-Pitfall
1. Stopped learning
2. Stopped improving
3. SM makes decision for the Team
4. No communication
5. Unclear or absent Definition of Done
6. Overworked Team
7. Change of scope during Sprints
8. Ineffective planning
9. SM is only a Team leader position not a Facilitator
10. Accept the status quo (bad existing state)
Scrum Master-Cạm bẫy
1. Ngừng học tập
2. Ngừng cải thiện
3. SM đưa ra quyết định cho Đội
4. Không giao tiếp
5. Định nghĩa hoàn thành không rõ ràng hoặc không có
6. Đội làm việc quá sức
7. Thay đổi phạm vi trong Sprint
8. Lập kế hoạch không hiệu quả
9. SM chỉ giữ chức vụ Trưởng nhóm chứ không phải Người điều phối
10. Chấp nhận hiện trạng (trạng thái hiện tại xấu)
8. Responsibility (Team roles)
PO: Build the right things
(Quality)
Team: Build the things right
(Quality)
SM: Support to improve the
productivity

PO: Xây dựng những điều đúng đắn (Chất lượng)

Nhóm: Xây dựng mọi thứ đúng đắn (Chất lượng)
SM: Hỗ trợ cải thiện năng suất
9. Sprint Planning topic 1 [WHAT?]
TO DO WHAT?
1. PO prepare the Product Backlog
2. The Scrum Team select WHAT could be needed and possible to do
3. Get forecast of Items for the Sprint (selected PBL)
4. Define the Sprint Goal
ĐỂ LÀM GÌ?
1. PO chuẩn bị Product Backlog
2. Nhóm Scrum chọn NHỮNG GÌ có thể cần và có thể làm
3. Nhận dự báo hạng mục cho Sprint (PBL đã chọn)
4. Xác định mục tiêu Sprint

Time Box
4 hours for a 4 week sprint (4 giờ cho chạy nước rút trong 4 tuần)
3 hours for a 3 week sprint
2 hours for a 2 week sprint
1 hours for a 1 week sprint
 Activities techniques
- Keep it simple
- Focus on Understanding
- Focus on Communication
- Teamwork
- Prepare the material for a efficient meeting
Kỹ thuật hoạt động
- Giữ nó đơn giản
- Tập trung vào sự hiểu biết
- Tập trung vào giao tiếp
- Làm việc theo nhóm
- Chuẩn bị tài liệu cho một cuộc họp hiệu quả
Velocity
Velocity is a prediction, not a guarantee!
Velocity is a planning tool, not for productivity measurement!
Velocity is the speed and show how much a team could do in one sprint
vận tốc
Vận tốc là một dự đoán, không phải là một sự đảm bảo!
Vận tốc là một công cụ lập kế hoạch, không phải để đo lường năng suất!
Vận tốc là tốc độ và cho thấy một nhóm có thể làm được bao nhiêu trong một lần chạy
nước rút
Activities techniques
- Visualize...
- Get dependencies...
- Team work
- KISS
- Work with PO together
Kỹ thuật hoạt động
- Hình dung...
- Nhận phụ thuộc...
- Làm việc nhóm
- HÔN - Cùng làm việc với PO
 10. Sprint Planning topic 2 [HOW?]
Create the Design for the Sprint
Technical discussion / knowledge exchange
Get a detailed Sprint forecast
- Paper is more efficient as you maybe think...
Tạo thiết kế cho Sprint
Thảo luận kỹ thuật/trao đổi kiến thức
Nhận dự báo Sprint chi tiết
- Giấy hiệu quả hơn như bạn nghĩ...
Time Box
4 hours for a 4 week sprint
3 hours for a 3 week sprint
2 hours for a 2 week sprint
1 hours for a 1 week sprint

TO DO HOW?
- DT decide HOW to build this function to get it "DONE"
- Usually designing the system and the work that should be done
A more detailed and updated forecast
- Get smaller work items (usually units that are less than a day)
Sprint Backlog (List of work items that needs to be done in this Sprint)
- DT quyết định cách xây dựng chức năng này để nó "XONG"
- Thường thiết kế hệ thống và công việc cần làm
Dự báo chi tiết và cập nhật hơn
- Nhận các hạng mục công việc nhỏ hơn (thường là các đơn vị dưới một ngày)
Sprint Backlog (Danh sách các hạng mục công việc cần thực hiện trong Sprint này)
Participates
Product Owner (should be available)
- Development Team
Scrum Master
Tham gia
Chủ sở hữu sản phẩm (nên có sẵn)
- Nhóm phát triển -Đội sản xuất
 Sprint Backlog
- Get the Design
- Get a list of work that needs to be done
- Get a order
- Keep the tasks small (smaller than 1 day)
Sprint backlog
- Nhận thiết kế
- Nhận danh sách công việc cần thực hiện
- Nhận đơn đặt hàng
- Giữ các nhiệm vụ nhỏ (nhỏ hơn 1 ngày)
Get the working plan & design is ready for the next Sprint
The Team is able to explain to the PO how they intend to work that they can
archive the Sprint Goal as a self-organized team
Nhận kế hoạch làm việc và thiết kế sẵn sàng cho Sprint tiếp theo
Nhóm có thể giải thích cho PO về cách họ dự định làm việc mà họ có thể lưu trữ Mục
tiêu Sprint với tư cách là một nhóm tự tổ chức
Activities techniques
- Keep it simple
Focus on Understanding
Focus on Communication
Team work
Kỹ thuật hoạt động
- Giữ nó đơn giản
Tập trung vào sự hiểu biết
Tập trung vào truyền thông
Làm việc nhóm
11. Sprint Planning-Pitfall
Pushing the Development Team
- Scrum Master will not facilitate if needed
Making assumptions & have misunderstandings
- Too many discussions
Culture difference: team too shy for important questions
 - Just stick too much to online tools
(Tools are not solving problems)
- No PO available
Kế hoạch Sprint-Cạm bẫy
Thúc đẩy nhóm phát triển
- Scrum Master sẽ không tạo điều kiện nếu cần
Đưa ra giả định và có những hiểu lầm
- Quá nhiều cuộc thảo luận
Sự khác biệt về văn hóa: nhóm quá nhút nhát trước những câu hỏi quan trọng
- Chỉ dính quá nhiều vào các công cụ trực tuyến
(Công cụ không giải quyết được vấn đề)
- Không có PO nào
12. Responsibility
PO Project manager + Business analyst (wrong)
SM=Team Leader Position + Manager (wrong)
DT=Testing+Developing + Design.. (right)
The everybody take care everything that is needed to develop
the Product
Trách nhiệm
PO Quản lý dự án + Chuyên viên phân tích kinh doanh (sai)
SM=Vị trí Trưởng nhóm + Quản lý (sai)
DT=Thử nghiệm+Phát triển + Thiết kế.. (phải)
Mọi người quan tâm mọi thứ cần thiết để phát triển sản phẩm
13. Scrum Events
-Print Planning Topic 1
-Print Planning Topic 2
-Daily Scrum
Sprint Review
Sprint Retrospective
Sự kiện Scrum
-In Quy hoạch Chủ đề 1
-In Quy hoạch Chủ đề 2
-Scrum hàng ngày
Đánh giá nước rút
Hồi tưởng nước rút
14. Daily Scrum
Planning the 24h for the Team
Collect impediments
Update remaining work
Scrum hàng ngày
Lập kế hoạch 24h cho nhóm
Thu thập chướng ngại vật
Cập nhật công việc còn lại
TODO
- What did I do yesterday that helped the Development Team meet the Sprint
Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from
meeting the Sprint Goal?
Hôm qua tôi đã làm gì giúp Nhóm phát triển đáp ứng được Sprint
Mục tiêu?
- Hôm nay tôi sẽ làm gì để giúp Nhóm phát triển đạt được Mục tiêu Sprint?
Tôi có thấy bất kỳ trở ngại nào ngăn cản tôi hoặc Nhóm phát triển không
đáp ứng Mục tiêu Sprint?
TIMEBOX
Maximum 15 MIN everyday
LOCATION
Same place every day
Same time every day
Tối đa 15 PHÚT mỗi ngày
VỊ TRÍ
Cùng một nơi mỗi ngày
Cùng một thời điểm mỗi ngày
Activities techniques
Easy, if there is on a Team board
- Everything should be visible
The team owns the tasks
Everything is based on the remaining Time...
(forecast how long it still will take..)
DT decide the Flow (kanban/fields.....)
Kỹ thuật hoạt động
Dễ dàng, nếu có trên bảng Đội
- Mọi thứ nên được nhìn thấy
Nhóm làm chủ nhiệm vụ
Mọi thứ đều dựa trên Thời gian còn lại...
(dự báo sẽ mất bao lâu ..)
DT quyết định Luồng (kanban/fields...)
15. Daily Scrum-Pitfall
- Late in meeting
Reporting to Scrum Master or PO
- Assigning tasks to Team members
- Scrum Master manage everything
- Don't understand the idea of Daily Scrum
Using a meeting room
Too many discussion during the meeting
Need more than 15 min..
Cạm bẫy Scrum hàng ngày
- Đi họp muộn
Báo cáo cho Scrum Master hoặc PO
- Phân công nhiệm vụ cho các thành viên trong nhóm
- Scrum Master quản lý mọi thứ
- Chưa hiểu ý tưởng Daily Scrum
Sử dụng phòng họp
Quá nhiều cuộc thảo luận trong cuộc họp
Cần hơn 15 phút..
16. Sprint Review
Show the work that is DONE
Get valuable input for next Iteration
Market place for next Iteration
- Have a Potentially Releasable Product Increment
(PSPI potentially shippable product increment)
Not a Status meeting (informal Meeting)
Đánh giá nước rút
Hiển thị công việc ĐÃ HOÀN THÀNH
Nhận đầu vào có giá trị cho lần lặp tiếp theo
Thị trường cho lần lặp tiếp theo
- Có mức tăng sản phẩm có khả năng phát hành được
(PSPI tăng sản phẩm có khả năng vận chuyển được)
Không phải là cuộc họp Trạng thái (Cuộc họp không chính thức)
Participates
- Product Owner
Development Team
- Scrum Master
TODO
1. Explain what could be DONE
2. Explain what went well
3. What kind of problems was happen, how the Team solved this
4. Team demonstrate LIVE what was DONE
5. Get input of the Priority for the next Iteration
6. Review the Timeline, budget.. (ROI)
7. Have a revised Product Backlog
1. Giải thích những gì có thể LÀM
2. Giải thích điều gì đã diễn ra tốt đẹp
3. Vấn đề gì đã xảy ra, Nhóm đã giải quyết vấn đề này như thế nào
4. Nhóm chứng minh TRỰC TIẾP những gì đã LÀM
5. Nhận đầu vào về Mức độ ưu tiên cho lần lặp tiếp theo
6. Xem lại Dòng thời gian, ngân sách.. (ROI)
7. Sửa đổi Product Backlog
Time Box
4 hours for a 4 week sprint
3 hours for a 3 week sprint
2 hours for a 2 week sprint
1 hours for a 1 week sprint
Activities Techniques
- Focus on discussion
Focus on shared learning, NO REPORTING
Focus on understanding
- Update the requirement changes
Hoạt động Kỹ thuật
- Tập trung thảo luận
Tập trung vào việc học tập chia sẻ, KHÔNG BÁO CÁO
Tập trung vào sự hiểu biết
- Cập nhật các thay đổi yêu cầu
PSPI (Potentially Shippable Product Increment)
We need to deliver with an efficient way the right product every sprint, that will
fulfill the need of the user and brings value
PSPI (Tăng sản phẩm có khả năng chuyển giao)
Chúng tôi cần cung cấp sản phẩm phù hợp một cách hiệu quả trong mỗi lần chạy nước
rút, điều đó sẽ
đáp ứng nhu cầu của người sử dụng và mang lại giá trị
17. Sprint Review-Pitfall
No live demo in real environment
Just make a demo on PowerPoint
- Too less preparation
- Late start with video conferences
Say it's nearly done...
Missing the updated priority and input for next Sprint
17. Sơ kết Sprint-Cạm bẫy
Không có bản demo trực tiếp trong môi trường thực
Chỉ cần làm demo trên PowerPoint
- Chuẩn bị quá ít
- Bắt đầu muộn với hội nghị truyền hình
Nói là gần xong rồi...
Thiếu mức độ ưu tiên và đầu vào được cập nhật cho Sprint tiếp theo
18. Sprint Retrospective
During each Sprint Retrospective, the Scrum Team plans ways to increase
product quality
Make the work more effective and enjoyable
Hồi tưởng nước rút
Trong mỗi buổi Cải tiến Sprint, Nhóm Scrum lên kế hoạch các cách để tăng
chất lượng sản phẩm
Giúp công việc trở nên hiệu quả và thú vị hơn
Participates
- PO
- DT
SM (will help to facilitate)
TODO
1. Inspect how the last Sprint (for the Scrum Team, the Process, Relationships
and Tools)
2. What went well
3. What should be improved
4. Create a plan for implementing improvements
1. Kiểm tra Sprint cuối cùng (đối với Nhóm Scrum, Quy trình, Các mối quan hệ)
và Công cụ)
2. Điều gì đã diễn ra tốt đẹp
3. Cần cải thiện điều gì
4. Lập kế hoạch thực hiện cải tiến
 Opportunity for continuous improvement
This MEETING give you the space to find improvements and to improve
-No team is already perfect
Appreciate People
Focus on a constructive attitude
"What can I do",
Cơ hội cải tiến liên tục
CUỘC HỌP này mang đến cho bạn không gian để tìm kiếm những cải tiến và cải thiện
-Không có đội nào hoàn hảo cả
Đánh giá cao mọi người
Tập trung vào thái độ mang tính xây dựng
"Tôi có thể làm gì",
19. Sprint Retrospective-Pitfall
- War room
- Blame people..
No action plan, no responsibility, only talking and no action
Forget to check previous impediments if they are already solved
Choose too many problems to solve at the same time and loose focus..
Cạm bẫy hồi tưởng nước rút
- Phòng chỉ huy
- Trách người..
Không có kế hoạch hành động, không có trách nhiệm, chỉ nói mà không hành động
Quên kiểm tra những trở ngại trước đó nếu chúng đã được giải quyết
Chọn quá nhiều vấn đề để giải quyết cùng lúc và mất tập trung..
20. RELEASE Planning
Timebox:
Is not an official mtg
No fixed time
Start the release planning when you realize you need it
The PO will work on this with Stakeholder and support of the Dev Team and
needed experts
Do as little planning as its necessary
 Define the time and the feature sets which are at least needed for the end-users
Participates:
PO (Responsible)
Stakeholder (Support)
Development Team (Will support with knowledge of estimation)
-SM (Will have to facilitate if needed)
Lập kế hoạch PHÁT HÀNH
Hộp thời gian:
Không phải là mtg chính thức
Không có thời gian cố định
Bắt đầu lập kế hoạch phát hành khi bạn nhận ra mình cần nó
PO sẽ giải quyết vấn đề này với Bên liên quan và sự hỗ trợ của Nhóm phát triển và
cần chuyên gia
Lập kế hoạch càng ít càng tốt
Xác định thời gian và bộ tính năng ít nhất cần thiết cho người dùng cuối
Tham gia:
PO (Chịu trách nhiệm)
Các bên liên quan (Hỗ trợ)
Nhóm phát triển (Sẽ hỗ trợ kiến thức về ước tính)
-SM (Sẽ phải tạo điều kiện nếu cần)
21. Product Roadmap
The Roadmap as a kind of release plan
Created with Team and Customer
It can Change during the Time (not fixed)
The PO is the owner and manager of this Map
Team will contribute
eg,
Date: Launch date. When will the release be available?
Name: The name of product version or major release.
Goal: The reason for creating the new version. - Why should it be developed?
Lộ trình sản phẩm
Lộ trình như một loại kế hoạch phát hành
Được tạo bởi Nhóm và Khách hàng
Nó có thể thay đổi theo thời gian (không cố định)
PO là chủ sở hữu và người quản lý Bản đồ này
Nhóm sẽ đóng góp
ví dụ,
Ngày: Ngày ra mắt. Khi nào bản phát hành sẽ có sẵn?
Tên: Tên của phiên bản sản phẩm hoặc bản phát hành chính.
Mục tiêu: Lý do tạo phiên bản mới. - Tại sao phải phát triển nó?
22. Five level model of Agile Planning
Vision
Roadmap
- Release
- Sprint
- day
Keep the planning iterative (and not restrictive)
Support self-organizing teams and empirical process control
Use the plan for insight and not direction
Mô hình lập kế hoạch linh hoạt năm cấp độ
Tầm nhìn
Lộ trình
- Giải phóng
- Tăng tốc
- ngày
Giữ kế hoạch lặp đi lặp lại (và không hạn chế)
Hỗ trợ các nhóm tự tổ chức và kiểm soát quy trình theo kinh nghiệm
Sử dụng kế hoạch để có cái nhìn sâu sắc chứ không phải định hướng
 23. Done vs Undone
DONE
-The minimal DoD means potentially shippable
- DoD is explicit
- DoD is visible
- Everybody follow
The DoD will grow
This will be valid for each Product Backlog Item
UnDONE
Identify what is undone
Undone will be visible and returned to the Product Backlog!
Don't collect UNDONE work and hide some thing not Done, be always
transparent!
Hoàn thành và Hoàn tác
XONG
-DoD tối thiểu có nghĩa là có khả năng chuyển giao được
- DoD rõ ràng
- DoD có thể nhìn thấy
- Mọi người theo dõi nhé
DoD sẽ phát triển
Điều này sẽ hợp lệ cho từng hạng mục Product Backlog
HOÀN TẤT
Xác định những gì được hoàn tác
Việc hoàn tác sẽ hiển thị và quay lại Product Backlog!
Đừng thu thập công việc KHÔNG LÀM và giấu một số việc chưa Hoàn thành, hãy luôn
minh bạch!
24. KISS
Keep
It
Simple
Stupid

-Giữ -Nó -Đơn giản -Ngốc nghếch

 25. Quality
Testing is an activity not a phase
Code Complete
"Tester should not try to break the system, they should help build the best
possible system
"Prevent bugs rather than finding bugs"
Kiểm tra là một hoạt động không phải là một giai đoạn
Mã hoàn thành
"Người kiểm tra không nên cố gắng phá vỡ hệ thống, họ nên giúp xây dựng hệ thống tốt
nhất
hệ thống có thể
"Ngăn chặn lỗi hơn là tìm lỗi"
26. CI/CD
- Continuous Integration
- Continuous Delivery
- Continuous Deployment
Keep a working system
Make a small changes
Get automatic tests
Hội nhập liên tục
- Giao hàng liên tục
- Triển khai liên tục
Giữ một hệ thống làm việc
Thực hiện một thay đổi nhỏ
Nhận bài kiểm tra tự động
27. DevOps
Communication
-Collaboration (Sự hợp tác)
Integration (Hội nhập)
Automation (Tự động hoá)
Measurement(Đo đạc)