Agile testing các thử thách của tổ chức (phần 2)

Part II - Organizational Challenges
Khi tổ chức quyết định áp dụng Agile thì quá trình kiểm thử hay nhóm QA thường chiếm
nhiều thời gian để chuyển đổi. Các nhóm QA độc lập ở nhiều tổ chức, do vậy khi chuyển
sang mô hình Agile mới, họ khó thích nghi với văn hóa mới. Trong Part II, chúng ta nói
về những thay đổi và rào cản mà bạn phải đối mặt khi chuyển đổi sang Agile.
Đào tạo (Training) là phần to và quan trọng nhất trong quá trình chuyển đổi sang Agile
và nó thường bị quên lãng. Nó cũng khó để thấy các quy trình hiện tại như đánh giá
(Audits) và khung cải tiến (Improvement Framework) sẽ làm việc trong môi trường Agile
như thế nào. Đi từ nhóm QA độc lập đến nhóm agile là một sự thay đổi lớn.

Chapter 3 - Cultural Challenges

Nhiều tác nhân tổ chức có thể ảnh hưởng đến một dự án, nó có thể sử dụng An Agile
hay a traditional phased hay gated approach. Văn hóa tổ chức và nhóm có thể ngăn cản
sự chuyển đổi mềm dẻo đến phương thức Agile. Trong chương này, chúng ta thảo luận
về các tác nhân (factors) có thể ảnh hưởng trực tiếp đến vai trò của Tester trong nhóm
Agile.

3.1. Organizational Culture
Văn hóa tổ chức được định nghĩa là các giá trị (values), các quy tắc (norms) và các giả
định (assumptions). Văn hóa của tổ chức sẽ quyết định cách giao tiếp, hướng tương
tác, và tạo quyết định như thế nào, và nó dễ dàng thấy được qua việc quan sát hành vi
của employee.
Văn hóa của một tổ chức có thể ảnh hưởng đến sự thành công của một nhóm Agile.
Các nhóm Agile phù hợp nhất với các tổ chức cho phép suy nghĩ độc lập. Ví dụ như,
nếu một công ty có kiến trúc phân lớp và khuyến kích phong cách (kiểu) quản lý chỉ huy
thì các nhóm Agile chắc chắn sẽ đối nghịch lại điều này. Các kinh nghiệm trong quá khứ
của tổ chức cũng ảnh hưởng đến sự thành công của một nhóm Agile mới. Nếu một
công ty đang cố gắng áp dụng agile và có kết quả không tốt, mọi người sẽ không cố
gắng áp dụng lại và đưa ra trích dẫn tại sao không hiệu quả. Họ có thể không bao giờ
thực hiện nó lại lần nữa.

Chúng ta sẽ nói chính xác về Văn hóa tổ chức ảnh hưởng như thế nào đến việc các
tester làm việc trong môi trường Agile. Thư mục chứa tài nguyên giải quyết các khía
cạnh văn hóa ảnh hưởng đến nhóm.

3.1.1. Quality Philosophy (Triết lý chất lượng)
Xem xét triết lý chất lượng của tổ chức nằm trong các mục làm thế nào để xác định mức
độ chấp nhận của chất lượng phần mềm. Nó cho phép chất lượng kém không? Nó có


nhớ các yêu cầu chất lượng của khách hàng không hay nó chỉ quan tâm đến việc bàn
giao sản phẩm cho khách hàng nhanh nhất có thể?
Khi một tổ chức thiếu triết lý chất lượng tổng thể và ép nhóm đưa ra sản phẩm mà
không quan tâm đến chất lượng thì các tester cảm thấy bị gò ép. Lúc đó mọi sự cố gắng
phát triển Agile của nhóm sẽ đối mặt với những thách thức khó khăn.
Một số tổ chức có những nhóm kiểm thử độc lập, mạnh mẽ và đầy năng lực. Những
nhóm đó, và quản lý của họ có thể nhận thấy việc phát triển Agile sẽ làm mất đi năng
lực của họ. Họ sợ rằng Agile trái với triết lý chất lượng của họ. Đánh giá triết lý chất
lượng của tổ chức và triết lý của các nhóm thi hành nó.
Các công ty có nhân viên đề cao chất lượng sẽ dễ dàng để chuyển đổi sang Agile. Nếu
một nhóm nào đó đã sở hữu chất lượng, thì họ phải học cách chia sẻ chúng với những
người khác để thành công.
a. Whole-team Ownership of Quality (toàn team sở hữu chất lượng)
Trong chương 1 “What Is Agile Testing, Anyway?”, chúng ta đã nói cách tiếp cận toàn
nhóm đến chất lượng. Đối với nhiều nhóm tester và QA, điều này có nghĩa thay đổi suy
nghĩ về việc sở hữu chất lượng đến việc có một vai trò xác định trong việc xác định và
duy trì chất lượng. Một sự thay đổi mạnh mẽ như vậy sẽ là khó khăn có nhiều nhóm
tests và QA.
Những tester làm việc trong môi trường truyền thống sẽ có một khoảng thời gian khó
khăn để điều chỉnh sang vai trò và hoạt động mới của họ. Nếu họ đến từ tổ chức mà
việc phát triển và QA có mối quan hệ đối nghịch với nhau, nó có thể khó để thay đổi từ

một suy nghĩ độc lập đến một phần không thể thiếu của nhóm. Nó có thể khó cho cả lập
trình viên và tester để học cách tin tưởng lẫn nhau.
b. Skills and Adaptability (Các kỹ năng và khả năng thích nghi)
Như đã quan sát thì phần lớn các lập trình viên không thể thích nghi với các thực hành
Agile - Nhưng các tester xây dựng kịch bản kiểm thử dựa vào tài liệu yêu cầu thì sao?
Họ có thể đưa ra các câu hỏi khi code được build không? Testers không thay đổi cách
tiếp cận sẽ làm cho việc kiểm thử khó có thể làm việc chặt chẽ với phần còn lại của
nhóm phát triển.
Các tester chỉ sử dụng manual testing (kiểm thử thủ công) trên giao diện người dùng sẽ
không hiểu được phương pháp tự động. Những tester đó cần rất nhiều động lực để đối
mặt với vai trò thay đổi của họ, hay bởi sự thay đổi này có nghĩa phải phát triển thêm
một tập các kỹ năng mới ngoài phạm vi lợi thế của họ.
c. Factors that help (các nhân tố có thể giúp)
Mặc dù có nhiều vấn đề về văn hóa (cultural issues) cần xem xét, hầu hết các nhóm QA
đều tập trung và cải tiến quy trình, và các dự án Agile khuyến khích cải tiến liên tục và


khả năng thích nghi thông qua việc áp dụng các công cụ như Retrospectives. Hầu hết
các chuyên gia đảm bảo chất lượng đều khao khát nắm giữ những gì họ học được và
làm cho nó tốt hơn. Những người này đủ khả năng thích nghi để không chỉ tồn tại mà
phát triển mạnh mẽ trong dự án Agile.
Nếu tổ chức tập trung vào việc đào đạo, nó sẽ khuyến khích cải tiến quy trình liên tục.
Nó sẽ có thể làm theo Agile nhanh chóng hơn tổ chức đặt nhiều giá trị vào việc họ phản
ứng lại khủng hoảng như thế nào hơn là việc cải tiến quy trình của họ.
Nếu bạn là một tester trong một tổ chức không có triết lý chất lượng hiệu quả, bạn có
thể đấu tranh để các thực hành chất lượng được chấp nhận. Phương pháp tiếp cận
Agile sẽ đưa cho bạn một cơ chế giới thiệu các thực hành hướng chất lượng tốt.
Các tester cần thời gian và đào đạo, như tất cả mọi người cần học để làm việc trong
một dự án Agile. Nếu bạn đang quản lý một nhóm bao gồm các testers, hãy chắc chắn
ủng hộ họ. Các tester thường không được đưa vào ngay từ đầu dự án Greenfield và nó

chỉ phù hợp với một nhóm làm việc với nhau trong nhiều tháng. Để giúp tester điều
chỉnh, bạn có thể cần nhờ đến một huấn luyện viên kiểm thử Agile có kinh nghiệm
(experienced Agile testing coach). Thuê ai đó đã từng làm việc trong nhóm Agile và có
thể phục vụ như một người cố vấn và giáo viên sẽ giúp các tester tích hợp với văn hóa
Agile mới, cho dù họ có chuyển sang Agile cùng với nhóm hiện tại hay tham gia vào
nhóm phát triển Agile mới.

3.1.2. Sustainable Pace (tốc độ bền vững / tốc độ ổn định)
Những nhóm kiểm thử agile truyền thống thường quen với việc kiểm thử nhanh và
mạnh mẽ vào cuối dự án. Trong giai đoạn kiểm thử cuối dự án (End-of-Project) này, một
số tổ chức thường xuyên yêu cầu nhóm của họ làm việc 50, 60, hay có thể nhiều giờ
hơn mỗi tuần để kịp tiến độ (deadline). Tổ chức thường xem xét làm thêm giờ (overtime)
như một thước đo của cam kết cá nhân. Các mâu thuẫn sẽ được Agile values sẽ được
giải quyết bằng cách cho phép con người có thể làm việc tốt nhất ở bất cứ thời gian
nào.
Trong các dự án Agile, khuyến kích làm việc với tốc độ bền vững. Điều này có nghĩa các
nhóm làm việc với tốc độ thích hợp để duy trì tốc độ không đổi (constant velocity) cho
phép duy trì tiêu chuẩn chất lượng cao. Các nhóm Agile mới có xu hướng quá lạc quan
về việc họ có thể thực hiện và đăng ký quá nhiều việc. Sau một iteration hoặc hai, họ
học được cách đăng ký đủ việc để không phải làm thêm mà vẫn hoàn thành công việc.
40 giờ một tuần là tốc độ bền vững cho các nhóm XP, nó là khối lượng effort bỏ ra, nếu
đưa vào từ tuần này đến tuần khác, cho phép mọi người hoàn thành hầu hết các công
việc trong chặng đường dài mà vẫn cung cấp giá trị tốt.
Các nhóm có thể phải làm việc với tốc độ không ổn định trong giai đoạn ngắn hiện tại và
sau đó, nhưng nó chỉ là ngoại lệ, không phải tiêu chuẩn (norm). Nếu overtime cần thiết
trong các giai đoạn ngắn, toàn bộ nhóm có thể làm việc ngoài giờ. Nếu nó là ngày cuối
cùng của một sprint và một số stories không được kiểm thử, toàn bộ nhóm sẽ phải ở lại


muộn để kết thúc việc kiểm thử.

3.1.3. Customer Relationships (Các quan hệ khách hàng)
Trong phát triển phần mềm truyền thống, mối quan hệ giữa nhóm phát triển và khách
hàng của họ giống như mối quan hệ giữa vendor-supplier. Mặc dù nếu khách hàng là
người trong nội bộ tổ chức, nó vẫn có cảm giác như hai công ty riêng biệt hơn là hai
nhóm làm việc vì mục tiêu chung.
Phát triển Agile phụ thuộc vào sự tham gia của khách hàng hoặc ít nhất là người ủy
quyền của họ. Các nhóm Agile mời khách hàng cộng tác, làm việc ở cùng nơi nếu có
thể, và nhất trí với quy trình phát triển. Cả hai đề học hỏi điểm mạnh và điểm yếu của
nhau.
Sự thay đổi trong quan hệ này cần được sự đồng thuận của cả hai phía, bất kể khách
hàng có ở trong hay ngoài tổ chức. Một mối quan hệ mở là tác nhân quan trọng dẫn đến
thành công của dự án Agile, nơi mà mối quan hệ giữa nhóm khách hàng và nhóm phát
triển giống như đối tác của nhau hơn là một mối quan hệ vendor-supplier
Có một vài đại diện domain experts, trong khi giữa thông báo liên tục cho các
stakeholders, là một phương pháp để giữ thành công trong sự hợp tác giữa developercustomer. Customers là tác nhân thành công của dự án Agile. Họ đưa ra thứ tự ưu tiên
sẽ được xây dựng và là tiếng nói cuối cùng trong chất lượng sản phẩm. Các tester làm
việc với khách hàng để nghiên cứu yêu cầu và định nghĩa acceptance tests. Các hoạt
động kiểm thử là chìa khóa để phát triển mối quan hệ giữa nhóm phát triển và khách
hàng. Đó là lý do tại sao chuyên môn kiểm thử rất cần thiết cho các nhóm Agile.

3.1.4. Organization Size
Kích cỡ của một tổ chức tác động lớn đến việc các dự án chạy như thế nào và cấu trúc
của công ty như thế nào. Tổ chức lớn hơn, cấu trúc phân cấp được hướng đến. Kênh
giao tiếp top-down được phát triển, cấu trúc báo cáo trở nên thích hợp và ít phù hợp với
việc hợp tác giữa kỹ thuật và thương mai.
a. Communication Challenges
Một số quy trình Agile đưa ra hướng thuận tiện cho việc giao tiếp trong nhóm
Nếu làm việc trong một tổ chức lớn trong đó nhóm kiểm thử độc lập với nhóm lập trình,
hãy tìm hướng để giữ việc kết nối ổn định

Vấn đề khác thường xảy ra với các công ty lớn là khách hàng không thể tham gia liên
tục. Nó là trở ngại lớn để tập hợp các yêu cầu và examples và tìm kiếm sự đồng thuận
của khách hàng vào vòng đời phát triển. Giải pháp là có các tester hay analyst với kinh
nghiệm về lĩnh vực hoạt động như đại diện khách hàng.
b. Conflicting Cultures within the Organization
Nếu nhóm Agile phải hợp tác với các nhóm khác sử dụng phương thức khác như


phased hoặc gated development, bạn sẽ phải đối mặt với một tập các thử thách.
Nhóm của bạn cũng có thể gặp sự chống đối của nhóm chuyên gia khi họ cố gắng bảo
vệ ý kiến cá nhân của họ.
Nếu các đối tác thứ 3 đang làm việc trên cùng hệ thống với nhóm bạn, văn hóa của họ
cũng có thể là nguyên nhân gây mâu thuẫn.
c. Advanced Planning
Nếu bạn phải hợp tác với nhóm khác, bạn cần sử dụng thời gian trong quá trình lên kế
hoạch release, hoặc trước khi bắt đầu iteration, để làm việc với họ
d. Act now, Apologize Later
Nó chỉ thường xảy ra trong một tổ chức lớn. Vòng soáy quan liêu có thể làm cho nhóm
của bạn hoàn thành công việc chậm chạp.
Nếu không có kênh nào để lấy những thứ bạn cần, hay có thể tester chưa bao giờ nói
chuyện trực tiếp với khách hàng trước đó. Hãy cố gắng tổ chức cuộc họp, hoặc tìm ai
đó là đại diện của khách hàng

3.1.5. Empower your Team (trao quyền cho nhóm)
Trong dự án Agile, điều quan trọng cho nhóm phát triển là cảm giác được trao quyền tạo
quyết định. Nếu bạn là một manager và bạn muốn nhóm agile thành công, giúp họ cảm
thấy tự do hoạt động và sáng tạo. Văn hóa tổ chức nên thích nghi với sự thay đổi này
để giúp dự án Agile được thành công

3.2. Barriers to Successful Agile Adoption by Test/QA Teams

(Các trở ngại thành công trong việc áp dụng Agile của nhóm test/QA)

3.2.1. Loss of Identify
Các tester luôn cố gắng duy trì nhóm QA độc lập vì nhiều lý do, nhưng lý do chính là sự
sợ hãi, đặc biệt:
• Sợ mất định danh QA
• Sợ rằng nếu họ báo cáo cho quản lý phát triển, họ sẽ không được hỗ trọ, lập
trình viên có quyền ưu tiên hơn
• Sợ họ bị mất đi các kỹ năng làm việc trong nhóm Agile và sẽ mất đi công việc
của họ
• Sợ khi họ phân tán vào các nhóm phát triển họ sẽ không nhận được hỗ trợ họ
cần
• Sợ họ và quản lý của họ sẽ bị xóa bỏ trong tổ chức mới
Chúng ta thường nghe QA managers hỏi “Công ty của tôi đang hoàn thành phát triển
Agile. Vai trò của tôi trong đó như thế nào?”. Nó liên quan trực tiếp đến các nỗi sợ “Loss
of identify”


3.2.2. Additional Roles
Chúng ta biết rằng các nhóm mới thường bị thiếu chuyên gia hay một người am hiểu về
lĩnh vực. Có thể bạn cần ai đó có kinh nghiệm trong kiểm thử với một nhóm Agile. Hoặc
bạn cần một chuyên gia kiểm thử hiệu năng. Nó sẽ chiếm thời gian để phân tích vai trò
mà bạn cần để thành công.
Để mọi người trong nhóm thực sự hiểu được vai trò của họ hãy sử dụng thời gian và
đào tạo.

3.2.3. Lack of Training
Nếu chúng ta đặt các tester vào một đơn vị phát triển mà không có đào đạo; thì chỉ trong
3 tháng, toàn bộ testers sẽ nghỉ việc vì họ không thể hiểu được vai trò mới của họ trong
dự án.

3.2.4. Not Understanding Agile Concepts
Không phải nhóm Agile nào cũng giống nhau. Nó nhiều phương pháp khác nhau để
phát triển Agile như XP, Scrum, Crystal, FDD, DSDM, OpenUP ... . Họ có thể thực hiện
các phương pháp khác nhau này, nhưng nếu họ không theo bất cứ Giá trị và nguyên tắc
cốt lõi của Agile nào, thì đó không phải là phát triển Agile.

3.2.5. Past Experience/Attitude
Một số tổ chức phát triển đã có những thành công nhất định, họ bị mắc kẹt trong những
quan điểm cũ và mô hình thành công của họ. Ngay cả khi họ cố gắng làm một điều gì
mới, họ cũng dễ trở lại với các thói quen cũ khi bị căng thẳng.
Một vài ví dụ về những người chống lại thay đổi do kinh nghiệm cũ và nhận thức về
“theo như vậy - The way things are”:
• Một tester ngồi ở vị trí của mình và không nói các vấn đề của mình với
programmer. Anh ta phàn nàn rằng các programmer không hiểu những gì anh ta
muốn.
• Một tester không thể rũ bỏ được thái độ hiện tại của mình mà các programmers
thì không biết làm cách nào để viết code tốt hay làm thế nào để kiểm thử nó.
Thái độ hạ mình của anh ta là rõ ràng, và trách nhiệm của anh ta bị thách thức.
• Một khách hàng đập tay khi các programmer không làm những thứ anh ta muốn,
bởi họ “luôn luôn” làm những thứ họ muốn.
Khi đối mặt với việc chuyển đổi sang phát triển Agile, những người như thế thường để
lại mà không cho quy trình mới một cơ hội. Phát triển Agile không dành cho tất cả mọi
người, nhưng đạo tạo và thời gian để thử nghiệm có thể giúp điều chỉnh thái độ. Yêu
cầu mọi người là một phần của giải pháp và làm việc với nhau để tìm ra những quy
trình, những thực hành tốt nhất phù hợp với tình huống cụ thể của họ. Nhóm tự quản
(seft-organizing) là công cụ mạnh mẽ để trấn an tất cả các thành viên của nhóm phát
triển về việc họ có thể kiểm soát mục tiêu của mình.

3.2.6. Cultural Differences among Roles

Mỗi thành viên trong nhóm Agile mới tạo ra sự chuyển đổi ở những khía cạnh khác
nhau. Các programmer thường sử dụng để viết mã production và release nó ngay khi có
thể. System administrator và database expert (quản trị hệ thống và chuyên gia dữ liệu)


có thể được làm việc trong silo riêng của họ, thực hiện các yêu cầu theo tiến độ của
riêng họ. Các tester thực hiện vào cuối dự án và không tương thnhiều với các
programmer.
Không có gì ngạc nhiên khi sự chuyển đổi có thể đáng sợ. Nhóm có thể tạo các quy
định (rules) và hướng dẫn (guideline) để giúp họ giao tiếp và làm việc tốt với nhau.
Xác định những điều cần thiết với những người thực hiện các hoạt động khác nhau, hãy
tìm cách cung cấp nó. Khách hàng cần một số cách để biết tiến trình phát triển như thế
nào và các điều kiện mong muốn của họ có được đáp ứng không. Những người phát
triển cần biết các mức độ ưu tiên thương mại và yêu cầu. Các tester cần hướng để nắm
bắt examples và chuyển chúng vào trong kiểm thử. Toàn bộ thành viên nhóm muốn cảm
thấy họ có giá trị và thành viên nhóm hạng nhất. Mỗi thành viên nhóm cũng cần cảm
thấy an toàn và tự do để đưa ra các issues và thử những ý tưởng mới. Hiểu được tầm
nhìn của các vai trò giúp nhóm thông qua việc chuyển đổi.

3.3. Introducing Change
Khi thực hiện bất kỳ thay đổi nào, đều có tác dụng phụ. Giai đoạn đầu tiên có thể hỗn
loạn; nhóm của bạn không chắc chắn về quy trình mới, một số nhóm trung thành với
thói quen cũ và một số người không chắc chắn và gây rối. Mọi người thường nhầm giai
đoạn hỗn loạn này do hiện trạng mới. Để tránh điều này, giải thích sự thay đổi của mô
hình và đặt kỳ vọng. Mong đợi và chấp nhận hỗn loạn khi thực hiện quy trình Agile. Tìm
các khu vực khó khăn nhất, và xác định cần thực hiện gì để giải quyết vấn đề để bạn có
thể thoát ngay lập tức ra khỏi hỗn loạn.

3.3.1. Talk about Fears
Khi bạn bắt đầu phát triển lặp, sử dụng retrospectives để cung cấp cho mọi người nơi

để nói về nỗi sợ hãi của họ và nơi để họ đưa ra các Feedback. Giúp mọi người biết sự
sợ hãi là hoàn toàn bình thường. Được mở rộng; dạy họ nói ra những sợ hãi và sự khó
chịu của mình. Thảo luận về nguồn gốc của nỗi sợ hãi, học hỏi từ các cuộc thảo luận,
tạo các quyết định và tiến lên. Nỗi sợ là phản ứng bình thường khi thay đổi. Buộc mọi
người làm những thứ họ không muốn, gây bất lợi cho việc thay đổi tích cực.

3.3.2. Give Team Ownership
Một tác nhân thành công quan trọng là nhóm có quyền sở hữu và có khả năng tùy chỉnh
phương pháp của họ. Mọi người có thể thay đổi thái độ và nhận thức nếu họ được giúp
đỡ ngay.
Lisa đã có thể quan sát Mike Cohn làm việc với đội ngũ của mình như là một huấn luyện
viên. Là một nhóm tự tổ chức, nhóm nghiên cứu đã xác định và giải quyết các vấn đề
riêng của mình. Mike đã chắc chắn họ đã có thời gian và nguồn lực để thử nghiệm và
cải thiện. Ông đã đảm bảo rằng các doanh nghiệp hiểu rằng chất lượng quan trọng hơn
số lượng hoặc tốc độ. Mỗi đội bóng, thậm chí một nhóm tự tổ chức, cần có một nhà lãnh
đạo hiệu quả có thể tương tác với đội ngũ quản lý của tổ chức.


3.3.3. Celebrate Success (ca tụng sự thành công)
Thực hiện thay đổi có thể chiếm thời gian và sự bực bội. Vì vậy hãy chắc chắn chào
mừng toàn bộ thành công với những thành quả của nhóm bạn. Vỗ lưng bạn khi hoàn
thành mục tiêu đó là viết các test cases ở mức cao (high-level) cho toàn bộ stories vào
ngày thứ tư của vòng lặp (iteration). Nhóm cùng nhau làm chơi game, ăn trưa khi thực
hiện công việc trong iteration. Thừa nhận là quan trọng nếu bạn muốn hướng đến sự
thay đổi.
Đưa các tester vào nhóm phát triển cho phép họ tiếp tục báo cáo với QA manager là
một cách dễ dàng để chuyển đổi sang phát triển Agile. Tester có thể tìm cách để biến
quan hệ đối lập với developer thành hợp tác. Họ có thể cho biết họ có thể giúp nhóm
hiểu yêu cầu của khách hàng như thế nào và mang lại giá trị kinh doanh thích hợp. Họ
có thể giữ những hoạt động ưa thích để xây dựng tương tác nhóm tốt hơn. Có nhiều

bánh quy (cookies) hay chocolate có sẵn cho đồng đội (teammates) là hướng tốt để
giúp họ đi ra bàn của bạn! Kiên nhẫn và cảm giác vui vẻ là một lợi thế lớn.

3.4. Management Expectations
Khi chúng ta nghĩ về các thách thức liên quan đến việc áp dụng Agile, chúng ta thường
nghĩ đến nhóm thực tế và những vấn đề mà nó gặp phải. Tuy nhiên, để áp dụng Agile
thành công, quản lý tham gia vào là rất quan trọng. Trong các dự án theo giai đoạn,
quản lý cập nhật thường xuyên và đóng các văn bản vào cuối mỗi giai đoạn. Những
người quản lý cấp trên có thể không hiểu làm thế nào họ có thể đánh giá các dự án
Agile. Họ có thể sợ mất kiểm soát hay thiếu sót “tiến trình”.

3.4.1. Cultural Changes for Managers
Trong một dự án Agile, thay đổi được kỳ vọng. Trong vòng đời của dự án waterfall,
Janet nhớ đã nghe thấy nội dung “Chức năng này đã hoàn thành 90%” trong nhiều tuần.
Kiểu chỉ số này không có nghĩa trong dự án Agile. Không có sự thỏa hiệp để đánh dấu
kết thúc một giai đoạn và “độ chín” của một dự án không được tính bằng cột/mốc (gate)
Các số liệu hữu ích được xác định bởi mỗi nhóm dự án. Trong Scrum, Sprint và các
biểu đồ release burndown kiểm tra mức độ hoàn thành story và đưa cho manager thước
đo tiến độ. Các số liệu kiểm thử có thể sử dụng để kiểm tra mức độ bao phủ của kiểm
thử (test corverage) nhưng không đưa ra tài liệu hoàn chỉnh.
Thật khó với một số manager để hiểu rằng việc quyết định về mặt kỹ thuật và quản lý
công việc là việc riêng của nhóm. Nó không còn là quyết định của manager nữa. Nhóm
(bao gồm cả khách hàng) sẽ định nghĩa mức độ cần thiết của chất lượng để phát hành
ứng dụng thành công.
Nhóm Agile ước lượng và làm việc trong các khung thời gian ít hơn là nhóm truyền
thống. Thay vì việc phòng bị trước các tình huống bất ngờ, nhóm cần lên kế hoạch để
đủ thời gian cho thiết kế tốt và thực hiện mà vẫn đảm bảo technical debt không tăng.
Thay vì quản lý các hoạt động của nhóm ở mức thấp, managers của nhóm Agile cần tập
trung vào việc loại bỏ trở ngại cho các thành viên nhóm để họ có thể làm việc tốt nhất.

Các bên liên quan thương mại (Business stakeholders) không thích bất ngờ. Nếu đã
thuyết phục họ đưa đủ thời gian và nguồn lực để thực hiện quá trình chuyển đổi, họ sẽ
thấy phát triển Agile cho phép họ lập kế hoạch chính xác hơn và đạt được mục tiêu kinh
doanh theo từng bước ổn định.
Đôi khi, việc quản lý thực sự điều hướng việc quyết định bắt đầu thực hiện phát triển
Agile. Các trưởng nhóm kinh doanh (business leaders) ở công ty Lisa chọn phát triển
Agile để giải quyết khủng hoảng phần mềm. Để hiệu quả, họ cần có một tập các kỳ vọng
về quản lý khác nhau. Họ cần nhạy cảm với khó khắn của các thay đổi lớn, đặc biệt là
trong một tổ chức đã không hoạt động tốt.
Trong tất cả các trường hợp, các managers cần kiên nhẫn trong quá trình dài chuyển
đổi nhóm Agile chất lượng cao. Việc của họ là đảm bảo cung cấp đủ nguồn lực cần thiết
và cho phép các cá nhân trog nhóm học hỏi làm thế nào để thực hiện công việc với chất
lượng cao.
Nếu bạn là một QA manager, hãy chuẩn bị giúp tester vượt qua nỗi sợ của họ với hoạt
động từ định nghĩa, các giai đoạn kiểm thử liên tục đến các vòng lặp nhanh chóng mặt
mà họ phải thực hiện trong một phạm vi rộng lớn mỗi ngày. Giúp họ thích ứng với việc
kiểm thử không còn là hoạt động riêng xảy ra sau khi phát triển, mà hai hoạt động kiểm
thử và coding được tích hợp với nhau.
Nếu bạn là tester hay một thành viên của nhóm khác mà không nhận được hỗ trợ trong
quá trình chuyển đổi sang phát triển Agile, hãy nghĩ về những khó khăn mà quản lý của
bạn có thể gặp phải trong quá trình tìm hiểu phát triển Agile. Giúp họ hiểu bạn cần hỗ
trợ những gì.

3.4.2. Speaking the Manager’s Language
Những nhà quản lý doanh nghiệp hiểu rõ gì nhất? Đó là ROI (lợi nhuận trên vốn đầu tư Return On Investment). Để nhận hỗ trợ từ quản lý của bạn, đóng khung yêu cầu của
bạn trong bối cảnh mà họ có thể hiểu được. Tốc độ của nhóm bạn chuyển thành các
tính năng mới làm cho việc kinh doanh thuận lợi hơn. Nếu bạn cần thời gian và kinh phí
để học và thực hiện một công cụ kiểm thử tự động, giải thích với quản lý về thời gian
làm thêm và các kiểm thử hồi quy được tự động sẽ giúp nhóm bạn đi nhanh hơn, phát

hành nhiều chức năng hơn trong mỗi vòng lặp.
Giống như toàn bộ thành viên của nhóm Agile, manager cần học các khái niệm mới và
tìm cách phù hợp với các thành viên trong nhóm. Sử dụng biểu đồ lớn để đảm bảo họ
có thể thực hiện theo tiến trình của mỗi vòng lặp và release. Tìm hướng tối đa hóa ROI.
Thông thường, các doanh nghiệp sẽ yêu cầu tính năng phức tạp và tốn kém hơn trong
khi có những giải pháp đơn giản nhanh chóng hơn mà vẫn mang lại giá trị tương tự.
Hãy chắc rằng đã giải thích công việc của nhóm ảnh hưởng đến giai đoạn cuối như thế
nào. Phối hợp với họ để tìm cách tốt nhất cho các bên liên quan để thể hiện các yêu cầu
cho mỗi tính năng mới.
Các hạn chế về ngân sách (budget limitations) là thực tế mà hầu hết các nhóm phải đối


mặt. Khi nguồn lực bị giới hạn, nhóm cần sáng tạo hơn. Phương pháp tiếp cận toàn
nhóm giúp điều này. Có lẽ giống với nhóm của Lisa, nhóm bạn bị hạn chế về ngân sách
mua phần mềm, và do đó, bạn có xu hướng tìm các công cụ kiểm thử tự động mã
nguồn mở. Một công cụ sử dụng ngôn ngữ giống ứng dụng sẽ không giúp tester không
biết lập trình, trừ khi họ hợp tác với lập trình viên để tự động hóa các kiểm thử. Tận
dụng chuyên gia trong nhóm sẽ giúp bạn làm việc trong điều kiện giới hạn về kinh
doanh.
Với toàn bộ thử thách mà nhóm bạn phải đối mặt, hãy thử những hướng mới để phát
triển nhóm và quản lý để xây dựng một sản phẩm có giá trị. Đồng thời, bất kể phương
pháp phát triển nào, bạn vẫn phải đảm bảo một số quy trình, như sự phù hợp để kiểm
tra các yêu cầu và nhận được sự quan tâm cần thiết.

3.5. Change Doesn’t Come Easy
Phát triển Agile có thể nhanh chóng mặt, nhưng thay đổi thì không. Các nhóm mới với
Agile sẽ làm chậm một số thực hành chính mà họ đã cam kết sử dụng. Chúng ta thấy
nhiều tester đang thất vọng về vòng đời phát triển “Agile” của họ thường là vòng đời
phát triển mini-waterfall. Những tester này vẫn đang bị ép buộc; nó xảy ra thường xuyên
hơn. Các vòng lặp nhiều hơn trước khi các story được kiểm thử. Lập trình viên từ chối

hoặc không thể làm theo các thực hành chính như TDD hay làm cặp (pairing). Nhóm đổ
trách nhiệm cho chất lượng của các tester, người có thể thay đổi quy trình.
Không có phép thuật mà bạn có thể sử dụng để giúp nhóm bạn tạo ra những thay đổi,
nhưng chúng ta có một số lời khuyên cho tester, người sẽ đưa nhóm họ thay đổi theo
chiều hướng tích cực.

3.5.1. Be Patient (Hãy kiên nhẫn)
Những kỹ năng mới như TDD thì khó. Tìm hướng giúp nhóm bạn có thời gian để làm
chủ nó. Tìm những thay đổi bạn có thể làm độc lập trong thời gian chờ đợi. Ví dụ, trong
khi các lập trình viên học về việc viết unit tests, bạn có thể giúp đỡ bằng cách thực hiện
GUI test tool. Giúp nhóm thực hiện các bước nhỏ. Nhớ rằng khi mọi người hoảng sợ, họ
sẽ quay trở lại thói quen cũ, mặc dù những thói quen đó không tốt. Hãy tập trung vào
những phần tích cực nhỏ.

3.5.2. Let Them Feel Pain (Hãy giúp họ nhận thấy khó khăn)
Đôi khi bạn cần xem các tai nạn xe lửa. Nếu đề xuất của bạn về cải tiến bị từ chối và
nhóm thất bại, đưa đề xuất của bạn ra một lần nữa và hỏi nhóm về việc cân nhắc có cố
gắng thực hiện nó trong một vào vòng lặp không. Mọi người hầu hết bằng lòng thay đổi
ở những phần mà họ cảm thấy khó khăn nhất.

3.5.3. Build Your Credibility (Xây dựng tín nhiệm của bạn)
Giờ bạn có thể làm việc với các lập trình viên. Hãy cho họ viết bạn có thể giúp họ như
thế nào. Giúp họ thấy những issues hơn là việc đưa ra bug report. Hỏi họ về việc review
code với bạn trước khi họ check-in nó. Khi họ nhận thấy bạn đang góp phần tạo gia giá


trị thực, họ sẽ lắng nghe ý kiến của bạn.

3.5.4. Work on your Own Professional Development
Đọc sách báo, đi họp nhóm và dự các hội nghị, học công cụ mới hay ngôn ngữ script.

Bắt đầu học ngôn ngữ mà ứng dụng đang được code, và hỏi lập trình viên nếu bạn có
thể làm cặp với họ hoặc họ sẽ chỉ dẫn cho bạn. Nếu đồng nghiệp của bạn sẽ tôn trọng
mong muốn của bạn về việc nâng cao kỹ năng. Nếu nhóm sử dụng cục bộ (local user)
bằng lòng lắng nghe bài trình bày của bạn về Agile testing hay một bản tin phần mềm
xuất bản bài viết tự động của bạn, đồng nghiệp có thể thấy bạn có thứ gì đó đáng nghe.

3.5.5. Beware the Quality Police Mentality (cẩn thận với tâm lý cảnh giác với chất
lượng)
Hãy là một cộng tác viên, không phải một chấp hành viên. Nếu lập trình viên không theo
coding standards, nó không phải công việc của bạn để đảm bảo họ làm như vậy. Đưa ra
vấn đề của bạn với toàn nhóm và yêu cầu giúp đỡ từ họ. Nếu họ lờ đi vấn đề nghiêm
trọng (critical problem) thì điều đó thực sự đang gây tác hại cho nhóm, bạn cần đi đến
người huấn luyện (coach) hoặc manager để được giúp đỡ. Nhưng làm điều này trong
mạnh “Làm ơn giúp tôi tìm một giải pháp” hơn là “Làm cho những người này cư xử lại”.
Nếu bạn nhìn thấy một vấn đề, rất có thể người khác cũng nhìn thấy nó.

3.5.6. Vote with Your Feet (bỏ phiếu bằng cách giơ tay)
Bạn trở nên kiên nhẫn. Bạn cố gắng mọi phương pháp mà bạn đã nghĩ đến, nhưng
quản lý của bạn không hiểu được phát triển Agile. Lập trình viên thì vẫn làm lỗi, code thì
không thể “vượt qua tường” kiểm thử, và code đó được phát hành bất chấp nỗ lực của
bạn, gồm cả việc làm 14 giờ một ngày. Không ai quan tâm đến chất lượng, và bạn cảm
thấy bất lực. Đó là thời gian để tìm nhóm tốt hơn. Một số nhóm thấy vui với hướng của
họ và chỉ đơn giản là không cảm thấy khó để muốn thay đổi. Lisa đã làm việc với nhóm
tốt để xử lý hỗn loạn, bởi cơ hội tìm ra nguyên nhân tại sao máy chủ bị hỏng và trở
thành anh hùng. Mặc dù một dự án thành công sử dụng các thực hành Agile, họ muốn
quay lại thói quen cũ, và cuối cùng Lisa đã từ bỏ sự cố gắng để thay đổi họ.

Summary
Trong chương này, chúng ta nói về các vấn đề văn hóa có thể ảnh hưởng đến các tester
như thế nào và nhóm của họ tạo ra chuyển đổi thành công để áp dụng phát triển Agile

•
•
•
•
•
•

Hãy xem xét văn hóa tổ chức trước khi đưa ra bất kỳ thay đổi nào.
Testers sẽ tích hợp dễ dàng với nhóm Agile khi toàn bộ tổ chức đánh giá cao
chất lượng, nhưng tester sẽ phải đấu tranh với tư tưởng “quality police”.
Một số tester có thể gặp khó khăn khi điều chỉnh việc toàn bộ nhóm sở hữu chất
lượng, nhưng phương pháp toàn nhóm giúp vượt qua những khác biệt văn hóa.
Nhóm khách hàng và nhóm phát triển nên làm việc gần nhau và chúng cho thấy
tester có thể là chìa khóa cho việc thúc đẩy mối quan hệ này.
Tổ chức lớn hướng đến các nhóm chuyên gia cô lập nhiều hơn, sẽ đối mặt với
những khác biệt văn hóa của từng vùng như thông tin liên lạc và hợp tác.
Những rào cản chính đến thành công của tester khi áp dụng Agile bao gồm sự
sợ hãi, mất bản sắc, thiếu đào tạo, kinh nghiệm tiêu cực trước đó với quy trình


•
•
•
•
•

phát triển mới và khác biệt văn hóa giữa các vai trò.
Để giúp giới thiệu các thay đổi và thúc đẩy giao tiếp, chúng tôi đề nghị các thành
viên nên thảo luận về nỗi sợ hãi và chào mừng mọi thành công, không vấn đề

nhỏ nhứ thế nào.
Các hướng dẫn như “Test bill of rights” cung cấp cho tester sự tự tin để đưa ra
các issues và giúp họ cảm thấy an toàn để học và đưa ra ý tưởng mới.
Managers đối mặt với những thách thức văn hóa của riêng họ, và họ cần hỗ trợ
và đào tạo để giúp tester thành công trong nhóm Agile.
Tester có thể giúp nhóm thích nghi với các kỳ vọng của manager bằng cách cung
cấp thông tin mà manager cần để theo dõi tiến độ và xác định ROI.
Thay đổi thì không đến dễ dàng, hãy kiên nhẫn, cải thiện kỹ năng của bạn và
bạn có thể giúp được đội của mình.

Chapter 4 - Team Logistics
Việc giao tiếp mặt đối mặt (face-to-face communication) của các nhóm Agile là tác nhân
quan trọng để dự án thành công. Việc sử dụng tiếp cận toàn nhóm (whole-team) cũng
được khuyến khích. Điều này có nghĩa các tester cần làm gì? Chương này nói về một
số vấn đề về cấu trúc nhóm và logic vật lý (team structure and physical logictics). Có
nhiều cách để gắn kết nhóm hơn việc di chuyển bàn và ghế.

4.1. Team Structure
Có các nhóm chức năng riêng biệt có thể làm khó các nhóm Agile. Liên lạc liên tục thì
quan trọng. Các thành viên nhóm cần làm việc gần với những người khác; công việc sẽ
gần như hoàn thành hay ở trong cùng vị trí vật lý.
Chúng ta sử dụng “QA team” và “test team” có thể hoán đổi cho nhau. Nó có thể chỉ rõ
“QA team” thực sự thực hiện đảm bảo chất lượng hay không, nhưng mục này trở nên
thông dụng để gắn với test team, vì vậy cung ta cũng có thể sử dụng nó.

4.1.1. Independent QA Teams
Nhiều tổ chức nhỏ và lớn, có nhóm QA hay test độc lập rất quan trọng để nhận được
đánh giá trung thực về chất lượng sản phẩm. Chúng ta thường hỏi câu hỏi “Có nơi nào
mà tổ chức kiểm thử trong tiếp cận toàn nhóm?” và “nếu như vậy, vai trò của nó là gì?”
Có một số lý do mà chúng tôi muốn giữ QA team độc lập với development team:

• Điều quan trọng là phải có kiểm tra và vai trò kiểm tra độc lập.
• Nhóm có thể cung cấp một cái nhìn khách quan và bên ngoài liên quan đến chất
lượng sản phẩm
• Nếu tester làm việc gần với các developers, họ sẽ bắt đầu nghĩ giống developer
và mất đi tầm nhìn của khách hàng.
• Nếu tester và developer báo cáo cho cùng một người, có một nguy cơ là mức độ


ưu tiên trở thành cung cấp bất kỳ code nào hơn là cung cấp mã đã được kiểm
thử.
Các nhóm thường nhầm “độc lập - independent” với “riêng biệt - separate”. Nếu cấu trúc
báo cáo, ngân sách, và các quy trình được lưu trữ trong các vùng chức năng khác
nhau, sự phân chia programmer và tester là không tránh khỏi. Nó có thể dẫn đến xích
mích, cạnh tranh và thái độ “so với họ, chúng tôi…”. Thời gian lãng phí vào những cuộc
họp trùng lặp, các programmer và tester không chia sẻ một mục tiêu chung và không tồn
tại việc chia sẻ thông tin.
Có nhiều lý do để có một QA manager và một nhóm tester độc lập. Tuy nhiên, chúng tôi
đề nghị thay đổi lý do cũng như cấu trúc. Thay gì giữ các tester riêng biệt như một nhóm
độc lập để kiểm thử ứng dụng sau coding, hãy nghĩ về nhóm như một cộng đồng các
tester. Cung cấp một tổ chức học tập để giúp testers phát triển nghề nghiệp và nơi để
họ có thể chia sẻ ý kiến và giúp đỡ những người khác. Nếu QA manager trỏ thành
trưởng nhóm thực hành trong tổ chức, người đó có thể dạy những kỹ năng để các tester
trở nên mạnh mẽ hơn và có khả năng đối phó với môi trường thay đổi không ngừng.
Chúng tôi không tin việc tích hợp tester với các nhóm dự án ngăn các tester làm tốt
công việc của họ. Trong thực tế, tester trong các nhóm Agile cảm thấy mạnh hơn với vai
trò hỗ trợ khách hàng và họ cũng có thể ảnh hưởng tư duy chất lượng đến các nhóm
khác.

4.1.2. Integration of Testers into an Agile Project
Tiếp cận toàn nhóm (whole-team) trong phát triển Agile đã làm cho nhiều tổ chức thông

qua việc phát triển Agile để giải tán nhóm QA độc lập và gửi tester của họ đến làm việc
với các nhóm dự án. Điều này rất tuyệt, nhưng một số tổ chức đã thấy nó không hoạt
động hiệu quả. Nhiều tổ chức, không phải tất cả, các tester của họ nghỉ việc khi họ thấy
họ không biết họ sẽ làm gì trong phát triển Agile.
Các developers được đào tạo về lập trình cặp (pair programming), phát triển điều
hướng kiểm thử (test-driven development), và các thực hành Agile khác, trong khi tester
thường không được đào tạo gì. Nhiều tổ chức không nhận ra rằng testers cũng cần đào
tạo về kiểm thử cặp (pair testing), làm việc với các yêu cầu không đầy đủ và thay đổi, tự
động hóa và toàn bộ các kỹ năng mới cần thiết. Điều quan trọng là tester nhận được
đào tạo và huấn luyện để họ có được các kỹ năng và sự hiểu biết để giúp họ thành
công, như làm việc với khách hàng như thế nào để viết các kiểm thử business-facing.
Các programmer cũng phải huấn luyện để hiểu được tầm quan trọng của các kiểm thử
business-facing và tiếp cận toàn nhóm và tự động hóa các kiểm thử.
Janet đã giúp tích hợp một vài nhóm kiểm thử độc lập vào dự án Agile. Cô nhận thấy
rằng nó có thể mất sáu tháng để hầu hết các tester bắt đầu cảm thấy tự tin về công việc
với quy trình mới.
Làm việc cặp giữa programmer và tester có thể chỉ cải tiến giao tiếp về chất lượng sản


phẩm. Các developer cần phải quan sát hành vi của ứng dụng trên máy của tester nếu
hành vi đó không được tái hiện trên môi trường phát triển. Các tester có thể ngồi với
developer để tái hiện lại vấn đề, nó sẽ dễ dàng và nhanh chóng hơn là việc họ cố gắng
ghi lại các bước trong defect (khuyết điểm). Tương tác này giảm thời gian cho việc giao
tiếp không bằng lời nói.
Chúng tôi nghe một số ý kiến từ các tester trong dự án như sau:
• “Gần gũi hơn với sự phát triển sản phẩm làm cho tôi trở thành tester tốt hơn”
• “Đi ăn trưa với các developer xây dựng một nhóm tốt hơn, muốn và thích làm
việc cùng với nhau hơn”
Một lợi thế lớn của một nhóm dự án được tích hợp là chỉ có một ngân sách và một lịch
trình.Thời gian “kiểm thử” không bị cắt nếu toàn bộ chức năng không được hoàn thành.

Nếu không có thời gian để kiểm thử chức năng mới, sau đó không có thời gian để phát
triển nó ở nơi đầu tiên. Tiếp cận toàn nhóm chịu trách nhiệm về chất lượng rất mạnh
mẽ, khi chúng tôi nêu trong cuốn sách này.
Các tester cần phải là thành viên chính thức của nhóm phát triển, và các việc kiểm thử
cần được chú ý như các việc khách. Một lần nữa, tiếp cận toàn nhóm để kiểm thử đi
một chặng đường dài hướng đến việc đảm bảo các việc kiểm thử được hoàn thành vào
cuối mỗi vòng lặp và khi phát hành. Hãy chắc chắn sử dụng retrospectives để đánh giá
những gì tester cần tích hợp với nhóm Agile mới của họ và những kỹ năng nào họ cần
để đạt được. Ví dụ, tester có thể cần hỗ trợ nhiều hơn từ programmers, hoặc từ một
chuyên gia về một kiểu kiểm thử nào đó.
Một tiếp cận thông minh để lập kế hoạch thay đổi tổ chức đến phát triển Agile là làm cho
tất cả các khác biệt được chuyển đổi thành công. Hãy hỏi các QA manager và
development manager để tìm ra vai trò của họ trong tổ chức Agile mới. Giúp họ có kế
hoạch làm thể nào họ sẽ giúp testers và developers trở nên có hiệu quả trong nhóm
Agile mới. Đưa ra các đào tạo về các thực hành Agile mà nhóm chưa biết. Đảm bảo
toàn bộ nhóm có thể giao tiếp với nhau. Đưa ra khung làm việc để mỗi nhóm biết được
nó đi như thế nào và thấy được hướng để thành công.

4.1.3. Agile Project Teams
Nhóm dự án Agile thường được coi là nhóm đa (liên) chức năng, bởi mỗi nhóm có các
thành viên từ nhiều nguồn gốc khác nhau. Sự khác biệt giữa nhóm đa chức năng truyền
thống và một nhóm Agile là cách tiếp cận toàn nhóm. Các thành viên không chỉ “đại diện
cho” chức năng của họ trong nhóm mà trở thành thành viên đúng nghĩa trong nhóm lâu
như dự án hay tồn tại vĩnh viễn (xem hình 4-1)
Vì các dự án khác nhau về kích thước, các nhóm dự án cũng có thể có cấu trúc khác
nhau. Tổ chức với các dự án lớn hay nhiều dự án xảy ra đồng thời sử dụng cấu trúc ma
trận thành công. Con người từ các lĩnh vực khác nhau kế hợp để tạo thành một nhóm
ảo trong khi vẫn báo cáo với cơ cấu tổ chức riêng của họ. Trong một tổ chức lớn, một
vùng các tester có thể di chuyển từ dự án này đến dự án khác. Một số chuyên gia, như
các kiểm thử bảo mật hay hiệu năng (security or performance tester), có thể chia sẻ đến

một vài nhóm. Nếu bạn bắt đầu một dự án, xác định toàn bộ nguồn lực mà dự án cần.
Xác định số lượng tester cần và kỹ năng yêu cầu trước khi bắt đầu. Tester bắt đầu với
nhóm và giữ công việc cho đến khi dự án hoàn thành, và họ sẽ đi đến dự án tiếp theo.
Trong khi các tester là một phần của nhóm, công việc hằng ngày của họ được quản lý
giống với công việc của nhóm dự án. Một tester có thể đưa các ý tưởng mới trong cộng
đồng tester lớn, nơi mà các tester đến từ các nhóm dự án khách nhau trong tổ chức
lớn. Toàn bộ tester có thể chia sẻ kinh nghiệm, ý tưởng. Trong tổ chức sẽ đánh giá hiệu
suất, QA manager (nếu có) có thể nhận đánh giá và nhận ý kiến từ các nhóm dự án.

Như với bất kỳ nhóm mới nào, nó sẽ chiếm một thời gian để nhóm trở nên ổn định. Nếu
chiều dài của dự án ngắn và nhóm thì thay đổi liên tục, tổ chức cần phải nhận thức
được rằng vòng lặp thứ nhất và thứ hai của mỗi dự án sẽ bao gồm các thành viên trong
nhóm mới được sử dụng để làm việc với nhau. Cấu trúc lại tổ chức nếu cần thiết, và
nhớ rằng bao gồm cả các khách hàng của bạn. Những nhóm tốt nhất là những nhóm
học cách làm việc cùng nhau và phát triển niềm tin vào nhau.

4.2. Physical Logistics
Nhiều tổ chức đang nghĩ việc áp dụng Agile là cố tạo ra các nhóm dự án cùng vị trí trong
môi trường phát triển mở. Để hỗ trợ giá trị và nguyên tắc Agile, các nhóm làm việc tốt
hơn khi họ sẵn sàng tiếp cận tất cả các thành viên trong nhóm, dễ dàng nhìn thấy các
bảng xếp hạng tiến độ dự án và một môi trường thúc đẩy giao tiếp.
Tester và customer ngồi gần với programmer là sự giao tiếp cần thiết. Nếu đội cùng vị
trí, nhóm có thể đầy sáng tạo.
Kích thước nhóm đưa ra các thách thức khác nhau cho tổ chức. Các nhóm nhỏ có
nghĩa phạm vi nhỏ, vì vậy nó dễ dàng để định vị trí các thành viên. Các nhóm lớn có thể
trên toàn cầu, và các công cụ giao tiếp ảo là cần thiết. Các nhóm lớn cùng vị trí thường
có nghĩa phải cải tạo không gian hiện có, mà một số tổ chức không muốn làm. Hiểu
những khó khăn của bạn, và cố gắng tìm các giải pháp cho vấn đề mà nhóm bạn gặp

phải chức không phải chấp nhận những thứ như “The way it is.”
Các nhóm cùng vị trí không luôn luôn sống trong thế giới hoàn hảo, và các nhóm phân
phối có một tập các thử thách. Nhóm phân phối cần kỹ thuật để giúp họ giao tiếp và
cộng tác. Teleconferencing, Video conferencing, webcams, và instant messaging là một
số công cụ có thể thúc đẩy sự hợp tác thời gian thực cho nhóm tại nhiều vị trí khác
nhau.
Cho dù nhóm cùng vị trí hay ở những chỗ khác nhau, những câu hỏi thường được đặt
như nguồn lực nào là cần thiết trong một nhóm Agile và làm thế nào để có được chúng.
Chúng tôi sẽ thảo luận trong phần tiếp theo.


4.3. Resources
Thành viên nhóm Agile mới và manager của họ có nhiều câu hỏi về bản chất của nhóm.
Chúng ta có thể sử dụng cùng các tester mà chúng ta đã có với các dự án truyền thống,
hoặc chúng ta cần thuê tester kiểu khác? Chúng ta cần bao nhiêu tester? Chúng ta cần
những người có kỹ năng đặc biệt? Trong chương này, chúng ta nói một chút về những
câu hỏi này.

4.2.1. Tester-Developer Ratio
Có nhiều cuộc thảo luận về tỷ lệ “đúng” của số lượng tester và số lượng developer. Tỷ lệ
này được sử dụng bởi các tổ chức để xác định cần bao nhiêu tester cho một dự án để
họ có thể thuê cho phù hợp. Như với các dự án truyền thống, không có tỷ lệ “đúng”, và
mỗi dự án cần phải được đánh giá riêng. Số tester cần thiết sẽ thay đổi và phụ thuộc
vào sự phức tạp của ứng dụng, tập kỹ năng của tester và các công cụ được sử dụng.
Chúng tôi đã làm việc trong nhiều nhóm khác nhau với tỷ lệ tester/developer từ 1:20 đến
1:1. Dưới đây là một vài kinh nghiệm của chúng tôi.
Thay vì tập trung vào một tỷ lệ, nhóm cần đánh giá các kỹ năng kiểm thử mà họ cần và
tìm nguồn lực thích hợp. Một nhóm chịu trách nhiệm kiểm thử có thể liên tục đánh giá
xem nó có chuyên môn và băng thông cần thiết không. Sử dụng retrospective để xác
định liệu thuê nhiều tester có giải quyết được vấn đề hay không.

4.2.2. Hiring an Agile Tester
Như chúng ta thảo luận ở chương 2 “Ten Principles for Agile Testers”, Có một số phẩm
chất mà một tester cần có để phù hợp với một nhóm Agile. Chúng tôi không muốn đi
vào chi tiết về kiểu tester cần thuê, vì nhu cầu của mỗi nhóm là khác nhau. Tuy nhiên,
chúng tôi cho rằng thái độ là yếu tố quan trọng.
Chúng tôi cần phải xem xét nhiều hơn chỉ là vai trò tester và programmer thực hiện
trong nhóm. Không vấn đề chúng ta đang cố gắng bù vai trò nào. Quan trọng nhất vẫn
là làm thế nào để người đó phù hợp với nhóm. Với tiếp cận toàn nhóm Agile, chuyên gia
trong nhóm có thể được yêu cầu bước ra ngoài lĩnh vực chuyên môn của họ và thu
được trong các hoạt động khác. Mỗi thành viên nhóm cần có sự tập trung mạnh vào
chất lượng và cung cấp giá trị thương mại. Hãy xem xét nhiều hơn về các kỹ năng kỹ
thuật khi bạn đang mở rộng nhóm.

4.4. Building a Team
Chúng ta đã nói về tiếp cận toàn nhóm (whole-team approach). Nhưng thay đổi như thế
không xảy ra. Chúng tôi nhận được câu hỏi như “Làm thế nào để chúng ta có được một
nhóm ổn định?” hay “làm thế nào để chúng ta thúc đẩy tiếp cận toàn nhóm?” Một trong
những câu hỏi lớn là “Làm thế nào để chúng ta giữ được động lực và tập trung của mọi
người vào mục tiêu cung cấp giá trị thương mại?”


4.4.1. Self-Organizing Team (nhóm tự quản)
Theo kinh nghiệm của chúng tôi, nhóm đưa ra tiến độ tốt nhất khi họ được trao quyền
để xác định và giải quyết các vấn đề của riêng họ. Nếu bạn là một manager, hãy chống
lại việc áp đặt tất cả ý tưởng tốt của bạn vào nhóm. Có những vấn đề, như vấn đề về
nhân sự, được giải quyết tốt nhất bởi các manager, và có lúc một huấn luyện viên cần
cung cấp sự khích lệ mạnh mẽ và dẫn dắt nhóm khi nó cần sự lãnh đạo (leadership).
Phải mất thời gian cho nhóm Agile mới để học làm thế nào để phân mức độ ưu tiên và
giải quyết các vấn đề của nó, nhưng nó vẫn có thể chấp nhận để nhóm tạo ra lỗi

(mistakes) và vấp ngã một vài lần.
Chúng tôi nghĩ rằng một đội hoạt động tốt phải phát triển chính bản thân nó. Nếu bạn là
một tester, bạn có một vị trí tốt để giúp nhóm có được phản hồi (feedbacks) nhanh, sử
dụng các thực hành như retrospectives để định mức độ ưu tiên và địa chỉ cho các vấn
đề, và tìm những kỹ thuật giúp nhóm tạo ra phần mềm tốt hơn.

4.4.2. Involving Other Teams (Gồm nhiều nhóm)
Bạn có thể cần các nhóm khác để nhóm bạn hoạt động thành công. Hãy thiết lập các
cuộc họp; tìm hướng giao tiếp càng nhiều càng tốt. Sử dụng Scrum của Scrum để giữ
nhiều nhóm phối hợp, hay chỉ tham gia như các nhóm khác. Nếu bạn đưa vào một
chuyên gia để giúp kiểm thử bảo mật (security testing), làm cặp với chuyên gia và tìm
hiểu càng nhiều càng tốt, và giúp họ học về dự án của bạn.
Nếu nhóm nằm rải rác ở các địa điểm và múi giờ khác nhau, tìm cách để có thể giao
tiếp trực tiếp càng nhiều càng tốt. Có lẽ các đại diện từ mỗi nhóm có thể điều chỉnh giờ
của họ một hoặc hai lần một tuần để họ có thể hội nghị (teleconference) một lần một
tuần. Thực hiện cuộc gọi thay cho một email khi có thể. Nhóm của Lisa điều chỉnh thời
gian họp lên kế hoạch (planning meeting) để gộp một thành viên nhóm từ xa đã làm việc
muộn vào ban đêm. Họ lên lịch họp một thời gian, nơi ngày của anh ta trùng với ngày
của nhóm.

4.4.3. Every Team Member has Equal Value (mỗi thành viên trong nhóm thì
ngang nhau)
Mỗi thành viên nhóm có giá trị ngang nhau. Nếu tester hay bất kỳ thành viên nhóm nào
cảm thấy bị loại ra hay ít có giá trị, tiếp cận toàn nhóm (whole-team approach) sẽ bị tiêu
diệt. Đảm bảo tester được mời đến tất cả các cuộc họp. Nếu bạn là một tester và ai đó
quên không mời bạn đến cuộc họp, hãy mời chính mình. Những tester không có kỹ
thuật có thể nghĩ họ sẽ được đưa ra khỏi chỗ hoặc quá tải trong một cuộc họp thiết kế
(a design meeting), nhưng đôi khi họ đặt câu hỏi tốt mà các chuyên gia không nghĩ đến.
Các tester có quyền yêu cầu và nhận sự giúp đỡ. Nếu bạn là một tester bị kẹt trong vấn
đề tự động hóa, hãy cam đảm đề nghị thành viên nhóm giúp đỡ. Người đó có thể bận

lúc bấy giờ, nhưng anh ta/cô ý phải cam kết giúp đỡ bạn trong một khoảng thời gian
hợp lý. Nếu bạn là một manager hay leader trong nhóm, hãy chắc chắn nó được thực
hiện và nêu vấn đề cho nhóm nếu ngược lại.


4.4.4. Performance an Rewards (Thưởng cho hiệu quả công việc)
Việc đo đạc và đánh giá hiệu quả dựa trên cơ sở cá nhân có nguy cơ phá hoại hợp tác
nhóm. Chúng tôi không muốn programmer cảm thấy cô ấy không nên thực hiện việc
kiểm thử (testing task) bởi cô ấy muốn tập trung vào việc cung cấp mã sản phẩm.
Chúng tôi không muốn quản trị hệ thống (system administrator) không quá bận rộn để
đảm bảo hoàn thành mục tiêu cá nhân của cô ấy, khiến cô ấy không thể giúp đỡ khi xảy
ra vấn đề với môi trường kiểm thử.
Ngược lại, một người thực hiện tốt luôn cố gắng làm việc tốt nhất với nhóm mà không bị
đánh bại bởi phần còn lại của nhóm không kéo lại với nhau. Đây là thời điểm mà một
manager cần bước lên và giúp nhóm tìm ra hướng đi. Nếu lỗi lớn được đưa lên
production, không ai nên đổ lỗi cho tester. Thay vào đó, toàn nhóm nên phân tích điều gì
đã xảy ra và bắt đầu các bước để ngăn ngừa tái phát.
Nhóm phát triển (development team) cần giữ những yêu cầu nghiệp vụ trong đầu. Thiết
lập mục tiêu cho việc kinh doanh, tăng lợi nhuận, và làm cho khách hàng hạnh phúc
hơn. Làm việc chặt chẽ với doanh nghiệp để thành công của bạn và cũng là giúp cho cả
công ty thành công.
Như chúng tôi đã đề cập trong chương 3 “Cultural challenges”, ăn mừng mỗi khi thành
công, tuy nhỏ. Một lễ kỷ niệm có thể là một high-five, một bữa ăn trưa do công ty cung
cấp, hay có thể cho phép nghỉ sớm hơn một chút. Scrum Master trong nhóm Lisa đưa ra
các ngôi sao vàng trong cuộc họp hằng ngày (stand-up meeting) cho những thành tích
đặc biệt. Sự thừa nhận của mọi người giúp bạn và nhóm của bạn.
Nhóm có thể tìm ra hướng mới lạ để nghi nhận các đóng góp của mọi người trong
nhóm. Trong các cuộc họp xem xét và trình bày vòng lặp (Iteration review và
demonstration meeting), cả nhóm phát triển và nhóm khách hàng đều có mặt, là một
thiết lập tốt để công nhận cả hai thành tích cá nhân và nhóm.

4.4.5. What can you do? (Bạn có thể làm gì?)
Nếu bạn là một tester mới trong nhóm Agile, đặc biệt là nhóm Agile mới, bạn cần phải
làm gì để giúp nhóm vượt qua các thách thức của tổ chức và thành công? Bạn có thể
thích nghi với nhóm và đóng góp các kỹ năng và kinh nghiệm của bạn như thế nào?
Đặt ra 10 nguyên tắc mà chúng tôi đã mô tả trong chương 2 để làm việc. Cam đảm là
phần đặc biệt quan trọng. Hãy đứng dậy và nói chuyện với mọi người; hỏi xem bạn có
thể giúp được gì. Tiếp cận các thành viên nhóm và nhóm khách bằng cách giao tiếp trực
tiếp. Chú ý những trở ngại và yêu cầu nhóm giúp loại bỏ chúng.
Phát triển Agile hiệu quả, bởi nó loại bỏ các chướng ngại vật ra khỏi đường đi và giúp
nhóm làm việc tốt nhất. Chúng tôi có thể cảm thấy tự hào và hài lòng, cá nhân cũng như
toàn nhóm. Khi chúng tôi làm theo các nguyên tắc Agile, chúng tôi hợp tác tốt, sử dụng


phản hồi để giúp cải tiến việc chúng tôi làm, và luôn luôn tìm kiếm hướng mới và tốt hơn
để hoàn thành mục tiêu. Tất cả có nghiaxchungs tôi liên tục nâng cao chất lượng của
sản phẩm.

Summary
Trong chương này, chúng tôi tìm các cách để xây dựng nhóm và cấu trúc để kiểm thử
và phát triển Agile thành công.
• Hãy xem xét tầm quan trọng của cấu trúc nhóm; trong khi các tester cần một suy
nghĩ độc lập, đặt họ vào một nhóm riêng có thể phản tác dụng.
• Các tester cần truy cập vào một cộng đồng các tester rộng lớn để học hỏi và đưa
ra các ý tưởng mới. Nhóm QA có thể tạo ra cộng đồng này trong tổ chức.
• Điều quan trọng là toàn nhóm được ngồi cùng nhau, để thúc đẩy sự hợp tác;
nếu nhóm bị chia tách, cung cấp các công cụ để thúc đẩy liên lạc.
• Hãy trả tiền cho thái độ.
• Không có tỷ lệ tester-developer chính xác. Câu trả lời đúng là “Nó phụ thuộc vào
tình hình của bạn.”

• Các nhóm cần tự quản, xác định và tìm các giải pháp cho vấn đề của mình, và
tìm kiếm hướng cải tiến. Họ không thể chờ ai đó nói với họ phải làm gì.
• Quản lý nên thưởng cho hiệu suất theo hướng thúc đẩy nỗ lực của nhóm để
mang lại giá trị thương mại, chứ không nên phạt thành tích cá nhân nếu nhóm
gặp khó khăn.
• Các tester có thể sử dụng các nguyên tắc Agile để cải thiện kỹ năng bản thân và
tăng giá trị của họ trong nhóm. Họ cần chủ động và tìm cách đóng góp cho
nhóm.

Chapter 5 - Transitioning Typical Processes
Chuyển đổi các quy trình đặc thù
Có nhiều quy trình trong dự án truyền thống không chuyển đổi được sang Agile, bởi
chúng yêu cầu nhiều văn bản (documentation) hay một phần cố hữu thuộc về phased và
gated process, và yêu cầu đóng ở cuối mỗi giai đoạn.
Giống như bất cứ điều gì, không có quy tắc cứng nhắc và nhanh chóng để chuyển các
quy trình của bạn sang quy trình nhẹ và nhanh nhẹn hơn. Trong chương này, chúng ta
thảo luận về một vài quy trình, và đưa cho bạn sự thay thế và hướng dẫn làm thế nào
để làm việc với chúng trong dự án Agile. Bạn sẽ thấy nhiều ví dụ và chi tiết những thay
đổi trong phần III, IV, V.

5.1. Seeking Lightweight Processes
Tìm kiếm các quy trình hạng nhẹ
Khi các nhóm học làm thế nào để sử dụng các quy trình Agile, một số quy trình truyền
thống có thể xóa bỏ sự lộn xộn. Hầu hết các tester đều quen làm việc với phương pháp
phát triển theo giai đoạn (phased) và cột mốc (gated) truyền thống để tạo ra và sử dụng


số liệu, nghi lại các lỗi (defects) trong hệ thống theo dõi lỗi (formal defect tracking
system), và viết kế hoạch kiểm thử (test plan) chi tiết. Những điều đó phù hợp chỗ nào
với phát triển Agile?

Nhiều tổ chức phần mềm nên tuân thủ hệ thống đánh giá và mô hình quy trình chất
lượng. Những yêu cầu đó không thường biến mất bởi bạn chỉ mới bắt đầu sử dụng các
thực hành phát triển Agile. Trong thực tế, một số người lo lắng rằng phát triển Agile sẽ
không thương thích các mô hình và các chuẩn như CMMI và ISO 9000.
Nó có thể thú vị hơn để nói về những thứ mới và khác khi kiểm thử trong dự án Agile,
nhưng chúng tôi vẫn cần hướng để đo đạc tiến độ (measure progress), theo dõi lỗi
(track defects) và kế hoạch kiểm thử (plan testing). Chúng ta cũng cần chuẩn bị làm việc
với mô hình chất lượng của tổ chức. Điều quan trọng là giữ các quy trình đủ nhẹ để giúp
chúng ta cung cấp giá trị một cách kịp thời. Hãy bắt đầu bằng cách nhìn vào số liệu.

5.2. Metrics
Số liệu có thể gây tranh cãi, và chúng ta sử dụng nhiều thời gian để nói về nó. Số liệu
có thể là nơi đưa ra những nguồn lực bị lãng phí, những nhóm mục đích của các con số
(metrics can be a pit of wasted effort, numbers for the sake of numbers). Đôi khi chúng
được sử dụng theo cách có hại, mặc dù chúng không phải xấu. Chúng có thể hướng
dẫn nhóm bạn và giúp đo đạc tiến độ của bạn so với các mục tiêu. Chúng ta hãy xem
làm thế nào để sử dụng các số liệu để giúp Agile tester và nhóm của họ.

5.2.1. Lean Measurements (Những đo lường lean)
Những học viên phát triển phần mềm Lean tìm cách giảm số lượng các thước đo và tìm
các thước đo thúc đẩy hành vi đúng đắn. Thực hành phát triển phần mềm Lean: từ ý
tưởng đến tiền mặt (Implementing Lean Software Development: From Concept to Cash),
của Mary và Tom Poppendiek, là nguồn tuyệt vời để dạy làm thế nào để áp dụng những
bước đầu lean vào kiểm thử của bạn và phát triển các nguồn lực (effort).
Theo Poppendiecks [2007], phép đo đạc lean cơ bản là thời gian cần đi “từ ý tưởng đến
tiền mặt”, từ yêu cầu tính năng của khách hàng đến phần mềm được phát hành. Họ gọi
phép đo này là “chu kỳ thời gian - cycle time”. Tập trung vào khả năng của nhóm để
cung cấp giá trị thương mại mới “lặp lại nhiều lần và đáng tin cậy”. Sau đó, nhóm cố
gắng liên tục cải tiến quy trình của họ và giảm thời gian chu kỳ.
Việc đo lường như thời gian chu kỳ đòi hỏi toàn bộ nhóm có thể khiến bạn hướng đến

thành công hơn là các phép đo bị hạn chế trong những vai trò và nhóm riêng biệt. Nó
thường mất bao nhiêu lâu để sửa một lỗi (defect)? Nhóm có thể làm gì để giảm độ trễ,
lượng thời gian cần thiết? Những số liệu kiểu này khuyến khích phối hợp để tạo ra các
cải tiến.
Đo lường lean khác, theo Poppendiecks giải thích trong sách của họ là lợi nhuận tài
chính. Nếu nhóm đang phát triển một sản phẩm có lợi, cần phải hiểu rằng làm thế nào


để nó đạt được lợi nhuận tốt nhất. Ngay cả khi nhóm đang phát triển phần mềm nội bộ
hay một số sản phẩm phi lợi nhuận khác, nó vẫn cần xem xét ROI để đảm bảo nó cung
cấp giá trị tốt nhất. Xác định mục tiêu thương mại và tìm hướng đo những gì mà nhóm
cung cấp. Công ty đang cố gắng để thu hút khách hàng mới đúng không? Giữ việc theo
dõi bao nhiêu tài khoản mới được đăng ký như tính năng mới cần phát hành.
Phát triển lean tìm cách để hài lòng khách hàng, nó nên là mục tiêu của toàn bộ phát
triển phần mềm. Poppendiecks đưa ra ví dụ về cách đơn giản, bạn có thể đo lường xem
liệu khách hàng có hài lòng không.
Chúng tôi thích số liệu lean, bởi chúng phù hợp với mục tiêu của chúng tôi để cung cấp
giá trị thương mại. Tại sao chúng tôi quan tâm đến các số liệu? Chúng ta đi đến phần
tiếp theo.

5.2.2. Why We Need Metrics (Tại sao chúng ta cần các số liệu)
Có nhiều lý do tốt để tập hợp và theo dõi các số liệu. Cũng có một số lý do xấu. Bất cứ
ai cũng có thể sử dụng những số liệu tốt theo cách khủng khiếp, chẳng hạn như sử
dụng chúng như cơ sở để đánh giá hiệu suất của mỗi thành viên nhóm. Tuy nhiên,
không phải số liệu, mà bạn đo đạc tiến độ của bạn như thế nào?
Khi số liệu được sử dụng như các thông báo hướng dẫn - nói với nhóm khi nó bỏ theo
dõi hay cung cấp phản hồi mà nó là theo dõi đúng - chúng là tập hợp đáng giá. Số
lượng unit tests của chúng ta tăng lên mỗi ngày? Tại sao code coverage lại giảm từ
75% đến 65%? Nó có thể là lý do tốt - Có lẽ chúng ta đã thoạt khỏi mã không sử dụng
nữa nhưng được bao phủ bởi các kiểm thử. Các số liệu có thể cảnh báo cho chúng ta

về các vấn đề, nhưng nếu tách ra chúng thường không có giá trị.
Số liệu để đo các cột mộc (milestones) theo hành trình để đạt được mục tiêu của nhóm
rất hữu ích. Nếu mục tiêu là tăng độ bao phủ của mã kiểm thử đơn vị (unit test code
coverage) lên 3%, chúng ta có thể chạy độ bao phủ mã (code coverage) mỗi lần chúng
ta check-in để đảm bảo chúng ta không buông lơi các kiểm thử đơn vị (unit tests). Nếu
chúng ta không đạt được cải tiến mong đợi, điều quan trọng là đưa ra lý do tại sao hơn
là than thở về mức thưởng bị giảm. Thay vì tập trung vào thước đo cá nhân, chúng ta
nên tập trung vào mục tiêu và hướng đến việc đạt được mục tiêu đó.
Số liệu giúp nhóm, khách hàng theo dõi tiến độ trong vòng lặp (interation) và trong lần
phát hành (release) hoặc epic. Nếu chúng ta đang sử dụng burndown chart, và chúng ta
đang đưa lên thay vì xuống, đó là một cờ đỏ để dừng lại, hãy nhìn vào những điều đang
xảy ra, và chắc chắn rằng chúng ta hiểu và giải quyết các vấn đề. Có lẽ nhóm đã thiếu
thông tin về story. Số liệu, bao hàm các burndown charts, sẽ không được sử dụng như
hình thức trừng phạt hay nguồn đổ lỗi. Ví dụ, các câu hỏi như “Tại sao ước lượng của
bạn quá thấp?”, hoặc “Tại sao bạn không thể hoàn thành các stories?” sẽ tốt hơn đến từ
nhóm và được diễn đạt như “Tại sao ước lượng của chúng ta lại thấp?” và “Tại sao
chúng ta không hoàn thành stories?”


Số liệu, sử dụng đúng cách, có thể thúc đẩy một nhóm. Nhóm của Lisa theo dõi số
lượng các kiểm thử đơn vị chạy trong mỗi lần build. Các mộc lớn (big milestones) - 100
kiểm thử (tests), 1000 kiểm thử, 3000 kiểm thử - là lý do để ăn mừng. Số lượng kiểm
thử đơn vị tăng lên mỗi ngày là phản hồi tốt cho nhóm phát triển và khách hàng. Tuy
nhiên, điều quan trọng là nhận ra bản thân các con số không có ý nghĩa gì cả. Ví dụ, các
kiểm thử được viết ra một cách nghèo nàn, hoặc để có sản phẩm được kiểm thử tốt, có
lẽ chúng ta cần 10,000 kiểm thử. Các con số không hữu ích khi đứng riêng biệt.
Khi bạn cố gắng để tìm xem cần phải đo đạc cái gì, đầu tiên hãy hiểu vấn đề mà bạn
cần giải quyết là gì. Khi bạn biết được vấn đề gặp phải, bạn cần đưa ra một mục tiêu.
Những mục tiêu này có thể đo đạc được. “Giảm thời gian đáp ứng trung bình của ứng
dụng XYZ xuống 1.5 giây với 20 người dùng đồng thời” tốt hơn “Cải tiến hiệu năng của

ứng dụng XYZ”. Nếu mục tiêu của bạn có thể đo đạc được, các phép đo mà bạn cần thu
thập để theo dõi sẽ rõ ràng.
Hãy nhớ sử dụng số liệu như một động lực và không dập xuống tinh thần của nhóm. Xin
nhắc lại một lần nữa: Tập trung vào mục tiêu, không phải số liệu. Có lẽ bạn không sử
dụng số liệu chính xác để đo cho dù bạn đạt được mục tiêu của nhóm, hay có thể bạn
không giải thích chúng trong ngữ cảnh. Số lượng báo cáo lỗi (defect) tăng có nghĩa
nhóm đang làm việc kiểm thử tốt hơn, không có nghĩa họ đang viết nhiều mã nguồn lỗi
hơn. Nếu số liệu của bạn không giúp bạn hiểu tiến độ hướng tới mục tiêu của bạn, có
thể bạn đang có các số liệu sai.

5.2.3. What not to Do with Metrics (không nên làm gì với số liệu)
Câu nói phổ biến của Mark Twain, “Có ba loại nói dối: Nói dối, nói dối bị nguyền rủa, và
thống kê” (there are three kinds of lies: lies, damned lies, and statistics). Mục tiêu đo đạc
là tốt; nếu bạn không thể đánh giá chúng theo một số cách nào đó, bạn không thể nói có
nếu bạn không đạt được chúng. Mặt khác, sử dụng số liệu để đánh giá hiệu quả cá
nhân hay nhóm thì thực sự nguy hiểm. Theo thống kê có thể được xoắn vào bất kỳ giải
thích và sử dụng trong các cách bất lợi.
Đưa ra số dòng mã (line of code), một thước đo phần mềm truyền thống. Có nhiều dòng
mã thì là tốt, có nghĩa nhóm hoạt động có hiệu quả, hoặc là xấu, có nghĩa nhóm đang
viết những đoạn mã không hiệu quả.
Như thế nào về số lượng lỗi được tìm thấy? Nó có nghĩa khi đánh giá tester bằng số
lượng lỗi họ tìm thấy không? Làm thế nào để giúp họ hoàn thành tốt hơn công việc của
mình? Là an toàn để nói nhóm phát triển tạo ra số lượng lỗi trên số dòng code cao hơn
đang làm công việc rất tệ không? Hay nhóm tìm nhiều lỗi hơn thì làm việc tốt hơn? Ngay
cả khi nghĩ nó xảy ra, làm thế nào để thúc đẩy đó cho nhóm để đánh mạnh vào các con
số? Sẽ làm cho các thành viên nhóm bắt đầu viết mã không khuyết điểm?

5.2.4. Communiting Metrics
Chúng tôi biết rằng bất cứ điều gì chúng ta đo được đều bị giới hạn để thay đổi. Bao
nhiêu kiểm thử đang chạy và pass? Bao nhiêu ngày cho đến khi chúng ta cần “build on

the sheft”? Toàn bộ build đều pass? Số liệu chúng ta không thể thấy và dễ giải thích là


không có giá trị. Nếu bạn muốn theo dõi số lượng các kiểm thử pass, chắc chắn rằng số
liệu được nhìn theo hướng đúng, với đúng người. Bảng xếp hạng lớn được nhìn theo
cách hiệu quả nhất là hiển thị các số liệu mà chúng ta biết.
Số liệu của bạn có được đánh giá xấu không? Đừng đo vì lợi ích của các số liệu sản
phẩm. Nghĩ về những gì mà bạn học được từ những số đó. Phần tiếp theo, chúng ta
xem xét lợi nhuận đầu tư mà bạn có thể mong đợi từ các số liệu.

5.2.5. Metrics ROI
Khi bạn xác định các số liệu mà bạn cần, hãy chắc chắn bạn có thể lấy chúng với giá cả
hợp lý. Nếu build liên tục của bạn cung cấp các số liệu có ích, nó sẽ mang lại giá trị tốt.
Bạn đang chạy build, và nếu nó đưa cho chúng ta thêm thông tin, cái này là nước sốt
(gravy). Nếu bạn cần thêm nhiều công việc để lấy thông tin, hãy hỏi chính bạn nếu nó
quá rắc rối.
Nhóm của Lisa đã thử theo dõi thời gian thực tế dành cho mỗi story so với thời gian ước
lượng. Họ đã học được gì khác ngoài việc ước lượng? Không nhiều. Một số nhóm có
kinh nghiệm thấy họ có thể bỏ qua sprint burndown chart bởi bảng công việc cho họ đủ
thông tin để đánh giá tiến độ của họ. Họ có thể sử dụng thời gian để ước lượng công
việc và tính giờ còn lại vào những hoạt động hiệu quả hơn.
Điều này không có nghĩa chúng tôi khuyên bạn dừng theo dõi các phép đo. Những
nhóm mới cần hiểu tốc độ và tỷ lệ burndown của họ, để họ có thể cải tiến dần dần.
Tỷ lệ lỗi (defect) là số liệu phần mềm truyền thống, và chúng không có nhiều giá trị với
một nhóm nhằm đến zero defects. Không có nhiều giá trị trong việc biết tỷ lệ lỗi được
tìm thấy và được sửa trong thời gian phát triển, bởi việc tìm và sửa chúng là một phần
không thể thiếu trong sự phát triển. Nếu một tester đưa ra defect cho programmer, và
một kiểm thử đơn vị đã được viết ra và lỗi được sửa theo hướng đúng, thường không
cần ghi lại defect. Mặt khác, nếu nhiều defect đi đến production mà không bị phát hiện
ra, có thể có giá trị trong việc theo dõi số để biết nếu nhóm được cải tiến.

Khi bắt đầu viết lại ứng dụng lỗi, nhóm của Lisa đặt mục tiêu không nhiều hơn 6 lỗi
nghiêm trọng trong code mới sau khi code được đưa lên production trong khoảng thời
gian 6 tháng. Có một mục tiêu thẳng thắn, dễ dàng để theo dõi giuips tạo động lực cho
nhóm tìm ra cách để loại bỏ lỗi trong quá trình phát triển và vượt qua mục tiêu này.
Hình dung lợi nhuận đầu tư mỗi số liệu và quyết định có nên theo dõi hay duy trì nó
không. Nguồn lực sử dụng để tập hợp nó khẳng định giá trị mà nó mang lại không? Nó
có dễ dàng truyền đạt và hiểu không? Như mọi khi, làm cái gì cho tình hình của bạn.
Thử nghiệm với việc giữ số liệu cụ thể cho một vài sprint và đánh giá liệu nó có trả hết
không (pay off).
Một số liệu thông thường liêu quan đến chất lượng phần mềm là tỷ lệ defect. Trong
phần tiếp theo, chúng ta xem xét lý do để theo dõi các defect, hay không theo dõi các
defect, và chúng ta có thể học gì từ chúng.


5.3. Defect Tracking
Một trong các câu hỏi được hỏi bởi nhóm Agile mới là “Chúng ta vẫn theo dõi bugs trong
defect tracking system chứ?” không có câu trả lời đơn giản, nhưng chúng tôi sẽ đưa ra
đề suất cho vấn đề này và đề nghị một số thay đổi để bạn có thể xác định những gì phù
hợp với nhóm bạn.

5.3.1. Why should We Use a Defect Tracking System (DTS) - Tại sao chúng ta
nên sử dụng một hệ thống theo dõi lỗi (DTS)
Có nhiều tester đã sử dụng defect tracking như hướng duy nhất để truyền đạt các vấn
đề (issues), và nó dễ sử dụng với các công cụ tương tự nhau. Một DTS là nơi thích hợp
để theo dõi không chỉ defect mà cả độ ưu tiên (priorities), mức độ nghiêm trọng
(severities) và trạng thái (status), và ai được giao việc (assigned) xử lý defect. Nhiều
học viên Agile nói rằng chúng tôi không cần làm điều này nữa, chúng tôi có thể theo dõi
defect theo thẻ (card) hay một số cơ chế đơn giản khác. Chúng tôi có thể viết một kiểm
thử để đưa ra lỗi (failure), sửa mã, và giữ kiểm thử trong bộ hồi quy của chúng tôi.
Tuy nhiên, có nhiều lý do để sử dụng các công cụ ghi lại defect và chúng được sửa

chữa như thế nào. Hãy cùng khám phá một trong số chúng.
a. Convenience (sự tiện lợi)
Một trong những mối quan tâm về việc không giữ DTS là không có nơi để giữ tất cả các
chi tiết của lỗi (bug). Các tester ghi lại lỗi với nhiều thông tin, như làm thế nào để tái hiện
(reproduce) nó, nó được tìm thấy trong môi trường nào, hay đã sử dụng hệ điều hành
(operating system) hoặc trình duyệt (browser) nào. Toàn bộ thông tin không thể vừa trên
một thẻ (card), bạn nắm bắt những chi tiết đó như thế nào? Nếu bạn chỉ dựa vào thẻ,
bạn cũng cần trao đổi. Nhưng với trao đổi, những chi tiết đó sẽ bị mất đi, và đôi khi
tester quên chính xác những gì đã được thực hiện, đặc biệt nếu các lỗi đã được tìm một
vài ngày trước khi programmer giải quyết vấn đề.
Một DTS cũng là nơi phù hợp để giữ tất cả các tài liệu bổ sung, chẳng hạn như màn
hình hay những tập tin (file) được tải lên
b. Knowledge Base (dựa vào tri thức)
Chúng tôi đã nghe lý do để theo dõi defect như, “Chúng ta cần thấy các báo cáo lỗi cũ”.
Chúng tôi cố gắng nghĩ các lý do tại sao bạn nên nhìn vào các báo cáo cũ, và như
chúng tôi làm việc trong chương này, Janet tìm thấy một ví dụ.
Janet’s Story
Khi tôi đang kiểm thử thuật toán tại WestJet, tôi tìm thấy một bất thường. Tôi đã hỏi Sandra,
một tester khác, nếu cô ấy đã từng gặp vấn đề này trước đó. Sandra mơ hồ nhớ lại nó nhưng
không chính xác. Cô ấy nhanh chóng tìm kiếm trong Bugzilla và tìm thấy vấn đề ngay lập tức.
Nó đã bị đóng như không hợp lệ (invalid) vì doanh nghiệp đã quyết định nó không thích hợp
để sửa, và mức ảnh hưởng thấp.
Việc này đã giúp tôi tránh việc đặt câu hỏi hoặc nhập lại lỗi và nhận được là nó lại bị đóng.
Bởi các thành viên trong nhóm gồi gần nhau, câu chuyện của chúng tôi dẫn tới cuộc thảo


luận khác với nhà phân tích nghiệp vụ trong nhóm. Cuộc thảo luận này làm dấy lên những ý
tưởng về một trang FAQ, một danh sách các vấn đề nổi bật, hoặc một cái gì đó theo dòng sẽ
cung cấp cho các tester mới tìm thấy những vấn đề đã được xác định, nhưng mà quyết định
đã được thực hiện là không giải quyết chúng.

Câu chuyện này cho thấy mặc dù cơ sở dữ liệu lỗi có thể được sử dụng như cơ sở tri
thức, có thể có các cơ chế khác để giữ các quyết định nghiệp vụ và thông tin nền tảng
của họ. Nếu một vấn đề mất theo dõi đủ lâu, có lẽ chúng ta nên viết nó và đưa nó ra lại
một lần nữa. Các trường hợp có thể đã thay đổi, và các doanh nghiệp có thể quyết định
nó đáng để sửa chữa.
Các loại loại lỗi hay bị gián đoạn và mất thời gian lâu để theo dõi thì thích hợp khi sử
dụng DTS. Những lỗi này thể hiện không thường xuyên, và thường có khoảng thời gian
trống để điều tra việc thiếu sót thông tin. Một DTS là nơi thông tin được nắm bắt những
gì đã làm cho đến nay. Nó cũng có thể chứa các bản ghi, dấu về và nhiều hơn nữa. Đây
có thể là thông tin hữu ích khi ai đó trong nhóm có thời gian để xem xét các vấn đề hay
vấn đề trở nên quan trọng hơn.
Thông tin trong các báo cáo lỗi có thể được sử dụng sau cho một vài mục đích. Đây là
câu chuyện của nhóm Lisa về việc làm thế nào để sử dụng thông tin của nó.
Lisa’s Story
Một developer của nhóm phục trên một vòng xoay “hỗ trợ production” ở mỗi vòng lặp. Yêu
cầu hỗ trợ Production đến từ phía nghiệp vụ cho các bản sửa lỗi của sai lầm trong quá khứ
(past mistakes) hay những vấn đề trên production cần can thiệp bằng tay. “Người hỗ trợ
production” tìm kiếm vấn đề và ghi lại nó đã được sửa lỗi trong báo cáo lỗi chưa. Những chú
thích thường gồm trạng thái SQL (SQL statement) và thông tin nguyên nhân. Nếu bất cứ ai
gặp phải lỗi tương tự hoặc tình huống sau đó, giải pháp dễ dàng được tìm thấy trong DTS.
Nếu một số kiểu vấn đề xảy ra thường xuyên, nhóm sử dụng DTS để nghiên cứu và phân
tích. Mặc dù nhóm thì nhỏ, chúng tôi đối phó với nhiều mã di sản (legacy code), và chúng tôi
không thể dựa vào trí nhớ của mọi người để theo dõi mọi vấn đề và sửa chữa.
Nhớ lại nguyên nhân của defect và những gì được thực hiện để làm xong yêu cầu đặc
biệt sẽ khó khăn hơn khi nhóm đặc biệt lớn và không cùng vị trí. Các khách hàng cũng
không quan tâm đến các giải pháp cho vấn đề của họ.
c. Large or Distributed Teams
Nếu các dự án lớn mà các defect được tìm thấy bởi một nhóm có thể ảnh hưởng đến
nhóm khác. DTS có lẽ là lựa chọn tốt. Tất nhiên, để có ích, toàn bộ thành viên của nhóm
phải truy cập vào nó. Liên lạc mặt đối mặt (face-to-face communication) luôn là lựa chọn

đầu tiên, nhưng khi hoàn cảnh không cho phép như vậy, chúng ta cần hỗ trợ từ một
DTS.
d. Customer Support
Khi có các defects được báo cáo từ khách hàng sau khi phát hành, khách hàng luôn
muốn biết khi nào chúng được sửa chữa. Nó vô giá cho bộ phận hỗ trợ và hỗ trợ kỹ
thuật để biết những gì được sửa chữa trong lần phát hành. Họ cũng có thể tìm những
defect vẫn còn nợ ở thời gian phát hành và cho khách hàng biết. Một DTS làm cho nó