MTHi the Class

Freeway to LearnPM – MTHi the Class

MTHi the Class hôm nay tự hào hướng về ngày kỷ niệm Giải Phóng Thủ Đô 10-10 khi ra mắt một khóa học có học phí bằng một ổ bánh mỳ Sài Gòn.

FREEWAY TO LEARNPM

Learn project management nearly for free! A course dedicated for last-year students and junior professional project managers
Self-pace e-learning course that is the best-in-class project management education by MTHi the Class – in A class by ourselves

✋ Đăng ký khóa học
https://mthi.vn/how-to-enroll-a-course/

✋ Demo 3in1 Slide+Test+Video
https://mthi.vn/how-to-enroll-a-course/demos/

Freeway to LearnPM – MTHi the Class Freeway to LearnPM Teacher Ngo Nhat Thi Categories Project Management 3 000 ₫ Overview Curriculum Instructor Freeway to LearnPM Learn project management nearly for free! A course dedicated for last-year students and junior professional project managers Self-pace e-learning course that is the best-...

Join MTHi the Class! Có 2 lớp khai giảng đầu tháng 10-2022 bao gồm:

@ Lớp AgileClassic for PMI-ACP khai giảng ngày 12-10-2022 ==> khóa học 8 tuần, tối thứ Tư và sáng thứ Bảy hằng tuần tại MTHi the Class, 480 Nguyễn Thị Minh Khai, Q.3, Tp HCM.

@ Lớp VirtualCamp for PMP đã khai giảng ngày 4-10 đang tiếp tục nhận học viên đến hết ngày 10-10-2022 ==> khóa học 12 tuần, tối thứ Ba và tối thứ Sáu hằng tuần trên kênh Skype.

✋ Đăng ký khóa học ở link:
https://mthi.vn/how-to-enroll-a-course/

✋ Demo 3in1 Slide+Test+Video xem ở link:
https://mthi.vn/how-to-enroll-a-course/demos/

https://mthi.vn

Khai giảng lớp PMP tháng 6
MTHi VirtualCamp for PMP từ 5-6 đến 11-9

https://mthi.vn/

Bản tiếng Việt Scrum Guide 2020

https://mthi.vn/11672/ban-tieng-viet-scrum-guide-2020/

BUSINESS-FACING TESTS
https://mthi.vn/11579/business-facing-tests/

Chúng ta đã nói về các bài kiểm thử do developer thực hiện, những bài kiểm thử cấp thấp đó giúp developer đảm bảo rằng họ đã viết code đúng. Nhưng làm thế nào để biết đúng thứ cần code? Trong các phương pháp quản lý dự án theo giai đoạn và theo cổng kiểm soát (phased, gated methodology), chúng ta cố gắng giải quyết vấn đề đó bằng cách thu thập các yêu cầu từ sớm và thêm càng nhiều chi tiết càng tốt. Trong các dự án agile, chúng ta đặt tất cả niềm tin vào các thẻ story (story card) và các bài kiểm thử mà khách hàng có thể hiểu để giúp viết code đúng. Các bài kiểm thử “khách hàng có thể hiểu được” chính là chủ đề của chương này.

Chúng ta sẽ bắt đầu một iteration mà không có nhiều thông tin hơn ngoài những gì viết trên thẻ story, giống như ví dụ trong hình dưới đây.

AGILE TESTING, UNIT TEST VÀ TDD
https://mthi.vn/11549/agile-testing-unit-test-va-tdd/

NỀN MÓNG CỦA AGILE TESTING
Các kiểm thử kỹ thuật hỗ trợ Developmet Team tạo thành nền tảng của phát triển và kiểm thử agile. Nội dung Quadrant 1 không chỉ là về kiểm thử. Các bài unit test và component test mà chúng ta nói đến trong Quadrant 1 không phải là bài kiểm thử đầu tiên được viết cho mỗi user story, nhưng chúng giúp định hướng thiết kế và phát triển. Nếu không có nền tảng về test-driven design (thiết kế được dẫn dắt bởi kiểm thử), các unit test và component test tự động cũng như quy trình continuous integration (tích hợp code liên tục) để chạy kiểm thử, thì thật khó để cung cấp giá trị một cách kịp thời. Tất cả các kiểm thử ở các Quadrant khác không thể bù đắp cho những bất cập trong phần này.
Team cần các công cụ và quy trình phù hợp để tạo và thực hiện các bài kiểm thử kỹ thuật dẫn dắt quá trình phát triển. Chúng ta sẽ nêu ra một số ví dụ về công cụ cần thiết trong phần cuối của chương này.
Mục đích của Kiểm thử thuộc Quadrant 1
Các bài unit test và bài component test đảm bảo chất lượng bằng cách giúp developer hiểu chính xác những gì code cần thực hiện và cung cấp hướng dẫn cho một thiết kế phù hợp. Chúng giúp team tập trung vào user story đang được phát triển và áp dụng cách tiếp cận đơn giản nhất mà vẫn có hiệu quả. Unit testing xác minh hành vi của các bộ phận nhỏ, chẳng hạn như một đối tượng (object) hoặc một phương thức (method). Component testing giúp củng cố thiết kế tổng thể của một phần có thể triển khai của hệ thống bằng cách kiểm tra sự tương tác giữa các lớp (class) hoặc phương thức (method).
Phát triển các bài unit test có thể được coi là một công cụ thiết kế thiết yếu khi team áp dụng TDD (Test-Driven Development). Khi một developer bắt đầu một nhiệm vụ viết code, cô ta sẽ viết một bài kiểm thử để nắm bắt hành vi của một đoạn mã nhỏ và sau đó làm việc trên code cho đến khi bài kiểm thử được pass. Bằng cách xây dựng code theo từng vòng lặp nhỏ test-code-test, developer có cơ hội suy nghĩ về chức năng mà khách hàng cần. Khi có câu hỏi nảy sinh, developer có thể hỏi Customer/Product owner. Developer có thể cặp đôi (pairing) với một chuyên viên kiểm thử để đảm bảo rằng tất cả các khía cạnh của đoạn code đó và giao tiếp của nó với các unit khác, đều được kiểm thử.
Thuật ngữ “test-driven development” (phát triển được dẫn dắt bởi kiểm thử) dễ làm những người thực hành hiểu nhầm và không biết rằng nó liên quan nhiều đến thiết kế hơn là kiểm thử. Code được phát triển theo cách viết kiểm thử trước (test-first) được thiết kế một cách tự nhiên để thỏa mãn tính có thể kiểm thử (testability). Các kiểm thử thuộc Quadrant 1 đều nhằm đạt đến phần mềm chuyên nghiệp với chất lượng nội bộ (internal quality) cao nhất có thể.
Khi team thực hành TDD số lượng lỗi phát sinh sau này được giảm thiểu. Hầu hết các lỗi cấp đơn vị được ngăn chặn bằng cách viết bài kiểm thử trước khi viết code. Suy nghĩ thông qua thiết kế bằng cách viết bài unit test có nghĩa là hệ thống có nhiều khả năng đáp ứng các yêu cầu của khách hàng hơn. Nếu như thời gian kiểm thử sau phát triển bị chiếm đầy bởi việc tìm và sửa lỗi (mà phần lớn những lỗi này lẽ ra đã được phát hiện sớm bởi các bài kiểm thử unit test của developer), thì team sẽ không còn thời gian để tìm ra các vấn đề nghiêm trọng hơn có thể ảnh hưởng xấu đến các chức năng nghiệp vụ. Càng có nhiều lỗi rò rỉ ra khỏi quá trình coding của chúng ta, việc nghiệm thu và phân phối sản phẩm sẽ càng chậm hơn và cuối cùng, chất lượng sẽ bị ảnh hưởng. Đó là lý do tại sao các bài kiểm thử bởi developer trong Quadrant 1 rất quan trọng. Mặc dù team nên áp dụng các phương pháp phù hợp với tình hình của mình, nhưng các team nếu không áp dụng các thực hành agile cốt lõi như nói trên rất khó hưởng lợi nhiều từ các giá trị và nguyên tắc agile.

AGILE TESTING QUADRANTS
https://mthi.vn/11527/agile-testing-quadrants/

Hình vẽ ở trên là sơ đồ của các Quadrant kiểm thử agile (Agile Testing Quadrants) cho thấy cách thức của từng loại trong bốn Quadrant phản ánh những lý do khác nhau mà chúng ta kiểm tra. Trên một trục, chúng ta chia thành các bài kiểm thử hỗ trợ development team và các bài kiểm thử đánh giá sản phẩm. Trục còn lại chia thành nhóm các bài kiểm thử về nghiệp vụ và về công nghệ.

Thứ tự mà chúng ta đã đánh số các Quadrant này không liên quan đến thời điểm các loại thử nghiệm khác nhau được thực hiện. Ví dụ: phát triển agile bắt đầu bằng các bài kiểm thử của khách hàng, các bài kiểm thử này sẽ cho team biết phải viết code gì. Thời gian của các loại thử nghiệm khác nhau tùy thuộc vào rủi ro của từng dự án, mục tiêu của khách hàng đối với sản phẩm, team đang làm việc với code kế thừa hay dự án hoàn toàn mới, và khi nào có sẵn nguồn lực để thực hiện thử nghiệm.

Nhóm các kiểm thử hỗ trợ development team
Các Quadrant bên trái bao gồm các bài kiểm thử hỗ trợ development team khi phát triển sản phẩm. Khái niệm kiểm thử để hỗ trợ các developer còn mới mẻ đối với nhiều người kiểm thử và là sự khác biệt lớn nhất giữa kiểm thử trên một dự án truyền thống và kiểm thử dự án agile. Thử nghiệm được thực hiện trong Quadrant 1 và 2 là về đặc tả yêu cầu và hỗ trợ thiết kế nhiều hơn những gì chúng ta thường nghĩ về thử nghiệm.

Quadrant 1

Quadrant 1 thể hiện thực hành test-driven development, là một thực hành cốt lõi của phương pháp phát triển agile. Unit testing xác minh chức năng của một tập hợp nhỏ của hệ thống, chẳng hạn như một đối tượng (object) hoặc phương pháp (method). Component testing xác minh hành vi của một phần lớn hơn của hệ thống, chẳng hạn như một nhóm các class cung cấp một số dịch vụ. Cả hai loại kiểm tra thường được tự động hóa nhờ sử dụng một trong số công cụ tự động kiểm thử tự động. Chúng ta gọi các bài kiểm thử này thuộc loại các bài kiểm thử của developer, bài kiểm thử đối mặt với developer hoặc bài kiểm thử về công nghệ. Chúng cho phép các developer biết chắc điều mà Kent Beck gọi là chất lượng code nội bộ.

Mục đích chính của các bài kiểm thử trong Quadrant 1 là thực hành test-driven deveopment hoặc test-driven design. Quá trình viết các bài kiểm thử trước hết giúp các developer thiết kế tốt cho code của họ. Những thử nghiệm này cho phép các developer tự tin viết code để cung cấp các tính năng của user story mà không phải lo lắng về việc thực hiện các thay đổi ngoài ý muốn đối với hệ thống. Họ có thể xác minh rằng thiết kế và phân tích kiến trúc của họ là phù hợp. Các bài unit test và component test được tự động hóa và được viết bằng ngôn ngữ lập trình giống như ngôn ngữ lập trình của ứng dụng. Một chuyên gia nghiệp vụ có lẽ không thể hiểu chúng bằng cách đọc trực tiếp, nhưng những bài kiểm thử này không nhằm mục đích sử dụng cho khách hàng. Trên thực tế, chất lượng code nội bộ không được thương lượng với khách hàng: nó được định nghĩa bởi các developer. Kiểm thử bởi developer thường là một phần của quy trình tự động chạy với mỗi lần check-in code, cung cấp cho nhóm phản hồi liên tục, tức thì về chất lượng code nội bộ.

VAI TRÒ THAY ĐỔI TRONG SCRUM
https://mthi.vn/11418/vai-tro-thay-doi-trong-scrum-2/

Khi sử dụng Scrum, chúng ta thừa nhận rằng không thể dự đoán hoàn hảo tất cả các nhu cầu của người dùng. Giống như các developer không còn có thể nói: “Đưa cho tôi tài liệu specifications hoàn chỉnh; sau đó hãy tránh sang bên trong khi tôi làm cho hệ thống thực hiện đúng những gì được yêu cầu trong đó”, tester không thể nói: “Đưa cho tôi tài liệu yêu cầu hoàn hảo và tôi sẽ đảm bảo hệ thống thực hiện mọi thứ trong đó.” Khi nói như thế các developer hoặc tester dường như đang từ bỏ trách nhiệm tối hậu là đảm bảo cho thành công cuối cùng của dự án. Mỗi người cần phải suy nghĩ về sản phẩm và đặt câu hỏi về từng tính năng và cách nó thêm vào (hoặc bỏ đi khỏi) tổng thể sản phẩm.

Vì các nhóm Scrum khi thu thập các yêu cầu đã chuyển từ viết ra các yêu cầu sang kể về chúng, các cuộc hội thoại với Product owner trở thành cách chính của tester để tìm hiểu cách một tính năng mới sẽ hoạt động. Tester có thể nói chuyện với Product owner về cách thức một tính năng hoạt động, thời hạn thực hiện công việc, tiêu chí nghiệm thu nào phải được thỏa mãn, v.v… Tester không bị giới hạn trong việc thu thập thông tin này chỉ từ Product owner. Khi thích hợp, tester cũng nên nói chuyện với người dùng, khách hàng và các bên liên quan khác. Cũng như các developer, làm việc trong một môi trường tương tác như vậy có thể gây khó chịu cho những tester đang bắt đầu dịch chuyển sang Scrum. Những tester trong nhóm Scrum sẽ cần phải làm quen với các cuộc trò chuyện thường xuyên và có ý nghĩa hơn với đồng nghiệp của họ và với những người bên ngoài nhóm dự án.

https://mthi.vn/11357/vai-tro-thay-doi-trong-scrum/

VAI TRÒ THAY ĐỔI TRONG SCRUM
Analyst
Với kiến ​​thức sâu sắc về sản phẩm và kỹ năng giao tiếp mạnh mẽ, một số analyst sẽ có xu hướng chuyển sang vai trò product owner. Điều này đặc biệt phổ biến trên các dự án lớn sử dụng hệ thống phân cấp gồm nhiều product owner. Ví dụ, một product manager có thể đóng vai trò là Chief product owner cho toàn bộ sản phẩm, dành phần lớn thời gian của mình để hướng về người dùng và thị trường. Mặt khác, một analyst có thể đóng vai trò là product owner cho một vài feature team khác nhau, làm việc với product manager để biến tầm nhìn của product manager trở thành các product backlog cho các feature team đó.

Nhiều nhóm dự án nhận thấy rằng việc có một analyst trong nhóm rất có lợi, mặc dù cách thức làm việc của analyst sẽ phải thay đổi. Các dự án được quản lý theo kiểu truyền thống, nhiệm vụ của analyst dường như phải vượt xa nhóm dự án càng xa càng tốt. Trong một dự án Scrum, phân tích một cách kịp thời trở thành mục tiêu. Mục tiêu mới của analyst là cần đi trước nhóm dự án chỉ một chút, ít nhất có thể, trong khi vẫn có thể cung cấp thông tin hữu ích cho nhóm về các tính năng hiện tại và trước mắt trong ngắn hạn.

https://mthi.vn/11339/gioi-thieu-ve-xp/

GIỚI THIỆU VỀ XP
XP (Extreme Programming) là một cách tiếp cận mới (câu này viết ra năm 2000!), hạng nhẹ để phát triển phần mềm. XP sử dụng phản hồi nhanh và giao tiếp băng thông cao để tối đa hóa giá trị thu được, thông qua một khách hàng tại chỗ, một phương pháp lập kế hoạch cụ thể và quá trình kiểm thử liên tục.

Hãy cùng xem xét cách phát triển phần mềm kiểu truyền thống.

Nhóm người dùng (hay nhóm khách hàng) dàn xếp với nhóm phát triển để có một chuyên gia phân tích (business analyst) được chỉ định cho dự án. Trong nhiều tuần và tháng kế tiếp, chuyên gia phân tích gặp gỡ nhóm người dùng trong vài giờ mỗi tuần. Chuyên gia phân tích tạo ra một bộ tài liệu yêu cầu, có thể bao gồm những thứ như Tuyên bố về tầm nhìn hoặc Trường hợp sử dụng (Use cases). Người dùng và người quản lý dự án (và có lẽ cả nhóm lập trình nữa) xem xét các tài liệu này và đàm phán với nhau về một release. Các lập trình viên tiếp nhận các mô tả kỹ thuật (functional specifications document), và vài tháng sau đó tạo ra một hệ thống ít nhiều làm được những gì nó dự định phải làm. Cuối cùng thường là có một cuộc họp thân mật trong đó mọi người phát hiện ra rằng đã có những thứ họ đã bỏ lỡ và nhận ra có những thay đổi kể từ sau khi các tài liệu được viết ra. Cuối cùng, khách hàng đến để thực hiện kiểm thử nghiệm thu và sau đó hệ thống được phát hành. Thường thì toàn bộ quá trình truyền thống này mất nhiều thời gian hơn là mọi người mong đợi, một số tính năng bị thiếu và chất lượng phần mềm không được như người dùng muốn. Hơn nữa, các tài liệu không còn được cập nhật.

Nhóm dự án áp dụng phương pháp XP thì khái quát như sau.

Trong quá trình phát triển, development team tạo ra một release của hệ thống sau khoảng từ 6 đến 8 tuần. Trong trường hợp tốt nhất, công tác phân tích và phát triển tiến hành song song và hỗ trợ lẫn nhau. Cách tiếp cận của XP nhấn mạnh đến sự tham gia và thử nghiệm của khách hàng: Khách hàng liên hệ với nhóm phát triển XP để bắt đầu một dự án. Nhóm lập trình yêu cầu khách hàng ngồi với nhóm của họ trong quá trình phát triển. Một dự án XP có ba giai đoạn.

Trump chứng kiến Space X phóng phi thuyền đưa phi hành gia lên quỹ đạo

Make America Great Again!
Tầm vóc vĩ đại của Elon Musk!

Trump chứng kiến Space X phóng phi thuyền đưa phi hành gia lên quỹ đạo (CAO) Hôm 31-5, Reuters đưa tin SpaceX– công ty tên lửa tư nhân của tỷ phú khởi nghiệp Elon Musk đã phóng phi thuyền đưa 2 phi hành gia Mỹ lên quỹ...

https://mthi.vn/11324/mot-scrummaster-gioi/

MỘT SCRUMMASTER GIỎI
Là người mới nhận vị trí ScrumMaster trong một dự án, bạn sẽ rất vất vả trong vai trò ScrumMaster với sự mâu thuẫn rõ ràng khi vừa là người lãnh đạo phục vụ cho team và đồng thời là người không có thẩm quyền. Nhìn kỹ lại mặc dù ScrumMaster không có thẩm quyền đối với các thành viên Scrum team, ScrumMaster có thẩm quyền đối với quy trình Scrum. Một ScrumMaster không thể nói: “Anh/chị bị sa thải vì không làm tròn nhiệm vụ”, bạn có thể nói “Tôi đã quyết định team chúng ta sẽ thử chạy sprint với timebox dài hai tuần trong tháng sau”.

ScrumMaster tương tự như một hướng dẫn viên thể lực giúp bạn gắn bó với chế độ tập thể thao và thực hiện tất cả các bài tập đúng cách. Một hướng dẫn viên thể lực giỏi sẽ tạo động lực đồng thời đảm bảo bạn không thể bỏ qua một bài tập khó. Quyền hạn của hướng dẫn viên thể lực là hạn chế và không thể bắt bạn thực hiện một bài tập mà bạn không muốn làm. Thay vào đó, hướng dẫn viên cần nhắc nhở bạn về các mục tiêu và phương pháp luyện tập bạn đã chọn để hoàn thành các mục tiêu đó.