Nghiên cứu phương pháp luận agile và đề xuất áp dụng triển khai bệnh án điện tử

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƢỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
------------------------------------

PHẠM TRUNG THÀNH

NGHIÊN CỨU PHƢƠNG PHÁP LUẬN AGILE VÀ
ĐỀ XUẤT ÁP DỤNG TRIỂN KHAI BỆNH ÁN ĐIỆN TỬ

LUẬN VĂN THẠC SỸ KỸ THUẬT
CÔNG NGHỆ THÔNG TIN

Hà Nội – 2015

Học viên: Phạm Trung Thành

Luận văn thạc sĩ


BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƢỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
------------------------------------

PHẠM TRUNG THÀNH

NGHIÊN CỨU PHƢƠNG PHÁP LUẬN AGILE VÀ
ĐỀ XUẤT ÁP DỤNG TRIỂN KHAI BỆNH ÁN ĐIỆN TỬ

Chuyên ngành: CÔNG NGHỆ THÔNG TIN

LUẬN VĂN THẠC SỸ KỸ THUẬT

CÔNG NGHỆ THÔNG TIN

NGƢỜI HƢỚNG DẪN KHOA HỌC:
TS. PHÙNG VĂN ỔN

HÀ NỘI - 2015


LỜI CAM ĐOAN
Luận văn thạc sỹ này do tôi nghiên cứu và thực hiện dƣới sự hƣớng dẫn
của Thầy giáo TS. Phùng Văn Ổn. Với mục đích học tập, nghiên cứu để nâng
cao kiến thức và trình độ chuyên môn nên tôi đã làm luận văn này một cách
nghiêm túc và hoàn toàn trung thực.
Để hoàn thành bản luận văn này, ngoài các tài liệu tham khảo đã liệt kê,
tôi cam đoan không sao chép toàn văn các công trình hoặc thiết kế tốt nghiệp
của ngƣời khác.
Hà Nội, tháng 9 năm 2015
Học viên

Phạm Trung Thành

Phạm Trung Thành

-3-

Luận văn Thạc sĩ


LỜI CẢM ƠN
Những kiến thức căn bản trong luận văn này là kết quả của ba năm (20132015) tôi có may mắn đƣợc các thầy cô giáo trong Trƣờng Đại học Bách Khoa

Hà Nội, Viện Công nghệ Thông tin và Truyền Thông và một số Viện khác trực
tiếp giảng dạy, đào tạo và dìu dắt.
Tôi xin bày tỏ lời cảm ơn chân thành tới các thầy cô giáo trong Viện Công
nghệ thông tin và Truyền thông, Phòng Đào tạo sau đại học Trƣờng Đại học
Bách Khoa Hà Nội đã tạo điều kiện thuận lợi cho tôi trong thời gian học tập tại
trƣờng.
Tôi xin bày tỏ lòng biết ơn chân thành, lời cảm ơn sâu sắc nhất đối với
thầy giáo TS. Phùng Văn Ổn đã trực tiếp hƣớng dẫn, định hƣớng cho tôi giải
quyết các vấn đề trong luận văn.
Tôi cũng xin cảm ơn các bạn, các anh chị em lớp CHBK2013B1 đã đồng
hành và cùng giúp đỡ tôi trong quá trình học tập và làm luận văn.
Luận văn cũng xin đƣợc là lời chia vui với ngƣời thân, đồng nghiệp, bạn
bè và các bạn đồng môn hai lớp cao học CHBK2013B1 và CHBK2013B2.

Phạm Trung Thành

-4-

Luận văn Thạc sĩ


MỤC LỤC
MỞ ĐẦU ...................................................................................................... 11
1.

CƠ SỞ KHOA HỌC VÀ THỰC TIỄN CỦA ĐỀ TÀI ..................... 12

2.

MỤC ĐÍCH CỦA ĐỀ TÀI (CÁC KẾT QUẢ CẦN ĐẠT ĐƢỢC) .. 12

3.

BỐ CỤC LUẬN VĂN....................................................................... 13

CHƢƠNG I. PHƢƠNG PHÁP LUẬN AGILE ........................................ 14
I.1

TUYÊN NGÔN AGILE (AGILE MANIFESTO) ......................... 15

I.2

ĐẶC TRƢNG AGILE ................................................................... 16

I.2.1 Tính lặp (Iterative) ...................................................................... 17
I.2.2 Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary) ............ 17
I.2.3 Tính thích ứng (hay thích nghi – adaptive) ................................. 17
I.2.4 Nhóm tự tổ chức và liên chức năng ............................................ 18
I.2.5 Quản lý tiến trình thực nghiệm (Empirical Process Control) ..... 18
I.2.6 Giao tiếp trực diện (face-to-face communication) ...................... 18
I.2.7 Phát triển dựa trên giá trị (value-based development) ................ 19
I.3

CÁC NGUYÊN TẮC VÀ GIÁ TRỊ TRONG AGILE .................. 19

I.3.1 Cá nhân và Sự tƣơng tác ............................................................. 20
I.3.2 Phần mềm Chạy tốt hơn là Tài liệu đầy đủ ................................. 22
I.3.3 Cộng tác với khách hàng hơn là thƣơng thảo hợp đồng ............. 22
I.3.4 Phản hồi với thay đổi hơn là bám sát kế hoạch .......................... 23
I.3.5 Agile là chiếc ô – Các phƣơng pháp dƣới chiếc ô này ............... 24

CHƢƠNG II. HTTT BỆNH VIỆN VÀ BỆNH ÁN ĐIỆN TỬ .............. 26
II.1

HIỆN TRẠNG ỨNG DỤNG CNTT TRONG CÁC BỆNH VIỆN26

II.1.1

Cơ cấu hoạt động ngành........................................................... 26

II.1.2

Hiện trạng và các tồn tại .......................................................... 27

II.1.3

Các giải pháp đã triển khai và khó khăn vƣớng mắc ............... 32

II.1.4

Kết luận .................................................................................... 35

II.2

BỆNH ÁN ĐIỆN TỬ VÀ HTTT BỆNH VIỆN ............................ 35

II.2.1

Cấu trúc Bệnh án điện tử.......................................................... 35

II.2.2

HTTT Bệnh viện quản lý BADT ............................................. 37

Phạm Trung Thành

-5-

Luận văn Thạc sĩ


II.3

KIẾN TRÚC TỔNG THỂ HTTT BỆNH VIỆN ............................ 39

II.3.1

Mô hình tổng thể Hệ thống ...................................................... 41

II.3.2

Hạ tầng phần cứng và mạng ..................................................... 45

II.4

GIẢI PHÁP CHI TIẾT ................................................................... 47

II.4.1

Hệ thống dịch vụ quản lý Bệnh nhân ....................................... 47

II.4.2

Hệ thống dịch vụ quản lý hàng đợi yêu cầu ............................ 49

II.4.3

Hệ thống dịch vụ quản lý Viện phí .......................................... 52

II.4.4

Hệ thống dịch vụ quản lý Khám chữa bệnh............................. 56

II.4.5

Hệ thống dịch vụ quản lý Hồ sơ bệnh án ................................. 57

II.5

MÔ HÌNH PHẦN MỀM ................................................................ 59

II.5.1

Nền tảng công nghệ.................................................................. 59

II.5.2

Các quy chuẩn áp dụng ............................................................ 60

CHƢƠNG III. MÔ HÌNH AGILE TRIỂN KHAI BỆNH ÁN ĐIỆN TỬ . 61
III.1 ĐẶT VẤN ĐỀ ................................................................................ 61

III.2 MÔ HÌNH AGILE CHO PHẦN MỀM ......................................... 62
III.2.1 Tuân thủ “Tuyên ngôn Agile”.................................................. 63
III.2.2 Đảm bảo “12 nguyên tắc Agile” .............................................. 64
III.2.3 Các quy chuẩn áp dụng ............................................................ 66
III.3 MÔ HÌNH AGILE CHO TRIỂN KHAI ........................................ 67
III.3.1 Tuân thủ các nguyên lý Agile .................................................. 68
III.3.2 Mô hình triển khai .................................................................... 69
III.4 TRIỂN KHAI BỆNH ÁN ĐIỆN TỬ THEO AGILE .................... 72
KẾT LUẬN .................................................................................................. 74
TÀI LIỆU THAM KHẢO............................................................................ 77

Phạm Trung Thành

-6-

Luận văn Thạc sĩ


THUẬT NGỮ
Viết tắt

Mô tả

1.

Methodology

Phƣơng pháp luận, mô hình quản lý phần mềm

2.

Agile

Phƣơng pháp luận nhanh/gọn, trong quản lý phần
mềm

3.

QTDA

Quản trị dự án

4.

BADT

Bệnh án điện tủ

5.

HSBA

Hồ sơ bệnh án

6.

CSYT

Cơ sở y tế

7.

BV

Bệnh viện

8.

SYT

Sở Y tế

9.

BYT

Bộ Y tế

10.

CNTT

Công nghệ thông tin

11.

HTTT

Hệ thống thông tin

12.

NCC

Nhà cung cấp

13.

HIS

Hospital Information System – HTTT Bệnh viện

14.

SOA

Service-oriented Architecture – Kiến trúc phần
mềm hƣớng dịch vụ

15.

BPM

Business Process Management – là khoa học về
quản trị về nâng cao hiệu xuất của tổ chức bằng
việc áp dụng tối ƣu và quản trị các quy trình
nghiệp vụ

16.

BPMN

Business Process Model and Notation – mô hình
biểu diễn quy trình nghiệp vụ của tổ chức dƣới
dạng các lƣợc đồ hình khối

17.

WCF

Windows Communication Foundation – Nền
tảng giao tiếp (dịch vụ) trên nền Microsoft
Windows và IIS

18.

WF

Windows Workflow Foundation – Nền tảng
luồng nghiệp vụ trên nền Microsoft Windows

19.

Service

Dịch vụ phần mềm, đƣợc cung cấp dƣới dạng các
dịch vụ Web (Web Service)/WCF, là chuẩn cung
cấp phƣơng pháp truyền thông chuẩn toàn cầu
giữa các ứng dụng mà không phụ thuộc nền tảng

STT

Phạm Trung Thành

-7-

Luận văn Thạc sĩ


STT

Viết tắt

Mô tả
(Windows, *NIX, Browsers, Smart devices,..)

20.

Interface

Các giao diện nghiệp vụ phần mềm đƣợc cung
cấp bởi các Service dƣới dạng tập hợp các lời gọi
hàm từ xa (RPC), các hệ thống cần giao tiếp với
nhau sẽ kết nối vào các dịch vụ và yêu cầu dịch
vụ thực hiện công việc đã đƣợc định nghĩa từ các
giao diện này

21.

ESB

Enterprise Service Bus – là một mô hình kiến
trúc phần mềm sử dụng cho việc thiết kế và triển
khai việc truyền thông/giao tiếp giữa các ứng
dụng trong tổ chức đƣợc thiết kế theo SOA

22.

Site

Site – là một đơn vị độc lập trong chuỗi bệnh
viện, có tƣ cách pháp nhân, vị trí địa lý cũng nhƣ
mô hình hoạt động tƣơng đối độc lập với các đơn
vị còn lại

23.

Center

Center – Trung tâm/SYT/Bộ Y Tế quản lý chung
các bệnh viện con trong chuỗi. Chuỗi bệnh viện
sẽ bao gồm liên tiếp nhiều site hoạt động độc lập
với nhau. Thông qua Center sẽ có mối quan hệ
lỏng để đảm bảo sự liên thông dữ liệu trong toàn
hệ thống. Center sẽ có đƣợc dữ liệu của toàn hệ
thống theo gần thời gian thực (độ trễ thấp) để
đảm bảo cung cấp cho các site liên quan và việc
tổng hợp/thống kê ở tổng thể toàn hệ thống.

Phạm Trung Thành

-8-

Luận văn Thạc sĩ


LỜI NÓI ĐẦU
Khoa học và ứng dụng của chuyên ngành quản lý dự án và phƣơng pháp
luận quản trị dự án – Project Management Methodology, là một trong những
lĩnh vực trọng yếu và có thể nói là xƣơng sống của xã hội, giúp việc thực thi
một tập hợp các công việc bởi một tập thể nhằm đạt đƣợc một kết quả dự kiến
trong một thời gian xác định; trong tất cả các lĩnh vực của đời sống hằng ngày
từ kinh tế, chính trị chúng ta có thể thấy đƣợc dự án hiển hiện ở bất cứ nơi nào.
Chính vì vậy việc thực hiện một dự án tốt, có phƣơng pháp đúng đắn sẽ đảm
bảo không những dự án thành công, mà còn mang lại hiệu quả to lớn, làm tiền
đề cho những dự án tƣơng tự sẽ đƣợc tiếp tục, theo đó thúc đẩy cho ngành/lĩnh
vực đƣợc phát triển cũng nhƣ mang lại thành công chung cho xã hội.
Trong khi đó, việc áp dụng phần mềm vào trong các lĩnh vực thực sự là
một công việc khó khăn và phức tạp, sự phức tạp này ở trong tất cả các đối
tƣợng tham gia vào dự án từ đối tƣợng thụ hƣởng (end-users), đối tƣợng tài trợ
(sponsors), đối tƣợng thực hiện (members), quy trình nghiệp vụ (business
process) cho tới bản thân các cấu thành của phần mềm (software components).
Chính vì vậy quản trị dự án phần mềm thực sự là một nghệ thuật, nếu không thì
việc thất bại sẽ nhìn thấy rất sớm từ khi mới bắt đầu dự án, hoặc dự án sẽ chỉ
đƣợc đóng hình thức mà hoàn toàn không có giá trị thực.
Quản trị dự án (QTDA) đã đƣợc nghiên cứu và ứng dụng rộng rãi, đạt
đƣợc rất nhiều kết quả khả quan ở trên thế giới cũng nhƣ ở Việt Nam. Từ đòi
hỏi phát sinh trong thực tiễn, QTDA đã đƣợc nghiên cứu và ứng dụng từ mức
tổng quát rồi đi vào chi tiết cho rất nhiều chuyên ngành hẹp – đã trở thành
chuẩn cho chuyên ngành (industry standard), theo đó mang lại thành quả cao

cho các nhà quản lý của các lĩnh vực tƣơng ứng – từ chính nhu cầu của các cấp
lãnh đạo này, cho tới việc QTDA thực sự mang lại kết quả tốt cho tổ chức mà
làm cho việc ứng dụng CNTT trở thành một tất yếu và phát triển mạnh mẽ ở tổ
chức đấy.
Đối với lĩnh vực y tế, cả trên thế giới lẫn ở Việt Nam, việc nghiên cứu
QTDA cho dự án phần mềm chuyên sâu còn rất hạn chế. Một vài nơi có ứng
dụng nhƣng đều dựa trên kinh nghiệm và yêu cầu thực tế góp nhặt lại của chính
tổ chức đấy, rồi áp dụng theo mô hình QTDA tổng quát để đƣa vào áp dụng mà
chƣa có cơ sở khoa học.
Phƣơng pháp luận Agile mới ra đời ở trên thế giới mới đƣợc hơn 10 năm
nay, nhƣng đã nhanh chóng phổ dụng và chứng minh đƣợc rất nhiều ƣu việt,

Phạm Trung Thành

-9-

Luận văn Thạc sĩ


đặc biệt càng phù hợp với môi trƣờng và năng lực CNTT còn hạn chế của
những nƣớc thuộc thế giới thứ 3 cũng nhƣ ở Việt Nam. Điều này lại càng phù
hợp với việc áp dụng cho lĩnh vực y tế, nơi mà ứng dụng CNTT còn nhiều bất
cập, manh mún, dàn trải.
Xuất phát từ nhu cầu trên, tôi chọn đề tài: “Nghiên cứu phƣơng pháp luận
Agile và đề xuất áp dụng triển khai Bệnh án điện tử” cho luận văn của mình.

Phạm Trung Thành

-10-

Luận văn Thạc sĩ


MỞ ĐẦU
Nghiên cứu phƣơng pháp luận Agile, để từ đó đƣa ra các phƣơng pháp
luận khoa học, giúp cho các đơn vị cung cấp sản phẩm CNTT có đƣợc mô hình
và giải pháp phù hợp, giúp cho các Cơ sở Y tế/Khám chữa bệnh có đƣợc định
hƣớng và tự tin trong ứng dụng CNTT. Thay vì ứng dụng dàn trải không định
hƣớng, mới chỉ coi CNTT là hiện đại, bị bắt buộc thực hiện theo yêu cầu, theo
chƣơng trình đề án áp xuống từ trên, thì biết tập trung ứng dụng CNTT vào
khai thác tối đa hiệu quả của phần mềm – theo đó mang lại hiệu quả, chất
lƣợng và giá trị cho cả 3 thực thể Cơ sở y tế/Khám chữa bệnh, Bác sĩ/Chuyên
gia Y tế và Bệnh nhân, trong khoa học về quản lý hiệu quả theo mô hình quản
trị dự án Agile.
Đƣa ra đƣợc các đầu vào số liệu cần thiết, theo lộ trình ứng dụng CNTT
của tổ chức Khám chữa bệnh để dần xây dựng đƣợc một hệ thống cho áp dụng
các phƣơng pháp tối ƣu trong QTDA phần mềm để tiến tới hệ thống phần mềm
tổng thể HIS.
Đƣa ra các phƣơng pháp luận cho việc khai thác các số liệu, cùng lộ trình
tập hợp số liệu, theo đó các nhà quản lý của tổ chức Khám chữa bệnh có đƣợc
các quyết định phù hợp (hỗ trợ ra quyết định), từ đó điều chỉnh hành vi của các
tác nhân, tổ chức; dự báo cho sự tăng trƣởng và phát triển của tổ chức; lên kế
hoạch cho sự nâng cao chất lƣợng của toàn hệ thống.
Thực hiện khảo sát, tham vấn/tƣ vấn quy trình/mô hình, ứng dụng Agile ở
một số tổ chức khám chữa bệnh, làm việc trực tiếp với các nhà quản lý ở các tổ
chức đó để lấy phản hồi và điều chỉnh hệ thống cũng nhƣ phƣơng pháp luận
cho phù hợp thực tiễn. Theo đó kết quả đầu ra không những là phƣơng pháp
luận của Agile mà còn là một mô hình thực tế, đã đƣợc thử nghiệm, ứng dụng
và phản hồi từ chính thực tế, giúp đem khoa học Agile/ERP thực sự đi vào thực
tiễn.

Agile/HIS – tham vọng để đặt nền tảng cho một lý thuyết mới, cho một
lĩnh vực rất hẹp trên một nền lý thuyết cũ, lớn mà đã ứng dụng thành công
trong thực tế. Đề tài này ngoài việc thể hiện phạm vi vừa đủ với một đề tài luận
văn Cao học, cũng vừa có khả năng ứng dụng thành công trong thực tế và cũng
bắt kịp xu thế của Việt Nam hiện tại cũng nhƣ trong tƣơng lai gần, đó là mong
muốn của toàn dân, mong muốn của cả hệ thống chính trị, là có một hệ thống
Y tế toàn diện, hƣớng tới ngƣời dân, ai cũng có quyền đƣợc chăm sóc sức khỏe
toàn diện và hƣớng tới tƣơng lai “giàu tính nhân văn” cho ngành Y tế ở Việt
Nam.

Phạm Trung Thành

-11-

Luận văn Thạc sĩ


Với những ý nghĩa thực tiễn đó, luận văn này sẽ nghiên cứu và trình bày
phƣơng áp luận Agile và áp dụng vào triển khai hệ thống quản lý Bệnh viện tổng
thể từ đó làm cơ sở để áp dụng Bệnh án điện tử triệt để vào cho Bệnh viện.
1. CƠ SỞ KHOA HỌC VÀ THỰC TIỄN CỦA ĐỀ TÀI
Trong thực tế thì việc thực hiện dự án ở các cơ sở y tế thƣờng đƣợc đi
theo một trong 2 hƣớng:
- Bài bản: Đƣợc các hãng ERP/Healthcare lớn đƣa vào, họ sẽ áp theo quy
trình QTDA kinh điển của thế giới nhiều chục năm nay là RUP (Rational
Unified Process) vào thực hiện cho các dự án triển khai. Việc áp dụng quy
trình thƣờng sẽ nặng nề và tốn kém nhân lực và kinh phí, yêu cầu các chuyên
gia cao cấp nhiều năm kinh nghiệm, cũng nhƣ đòi hỏi phía đơn vị thụ hƣởng
cũng cần phải có năng lực CNTT tƣơng ứng
- Chắp vá: Thƣờng các đơn vị triển khai CNTT ở Việt Nam áp dụng, vì

năng lực của tự thân họ và cũng nhƣ năng lực/kinh phí dành cho CNTT của
đơn vị thụ hƣởng còn khiêm tốn. Nên phƣơng án này đƣợc áp dụng hết sức tự
nhiên, theo nhu cầu (không bài bản) của đơn vị thụ hƣởng cũng nhƣ năng lực
CNTT còn khiêm tốn của các nhà cung cấp nội địa.
Agile là một khái niệm tƣơng đối mới với lĩnh vực phần mềm và mới chỉ
đƣợc áp dụng trong lĩnh vực hẹp là gia công phần mềm cho nƣớc ngoài, thƣờng
bởi vì chính những khách hàng đặt hàng và yêu cầu các đơn vị gia công ở Việt
Nam cần tuân theo để việc QTDA đƣợc thực hiện khoa học và bài bản. Việc áp
dụng Agile trên thế giới mới đƣợc hơn 10 năm nay, nhƣng đã nhanh chóng phổ
dụng và chứng minh đƣợc rất nhiều ƣu việt, đặc biệt càng hợp với môi trƣờng và
năng lực CNTT còn non yếu của những nƣớc thuộc thế giới thứ 3 cũng nhƣ ở Việt
Nam. Điều này lại càng phù hợp với việc áp dụng cho lĩnh vực y tế, nơi mà hội tụ
rất nhiều tri thức của xã hội, nhƣng CNTT hiện đƣợc coi là yếu kém so với các
lĩnh vực tƣơng đồng và luôn là mối quan tâm đặc biệt của các cơ quan quản lý nhà
nƣớc nhằm thúc đẩy ứng dụng CNTT cho ngành y tế.
2. MỤC ĐÍCH CỦA ĐỀ TÀI (CÁC KẾT QUẢ CẦN ĐẠT ĐƢỢC)
- Nghiên cứu lý thuyết và ứng dụng về Agile trong việc QTDA triển khai
hệ thống ERP tổng thể. Tổng hợp lại các phƣơng pháp luận mang tính khái
quát trong từng bƣớc ứng dụng Agile vào cho các tổ chức.
- Khảo sát, đánh giá và tổng hợp về ứng dụng CNTT trong các bệnh viện
ngành y tế (Hệ thống thông tin Bệnh viện – HIS – Hospital Information
System) cũng nhƣ đánh giá về xu hƣớng chung của ngành Y tế ở Việt Nam
Phạm Trung Thành

-12-

Luận văn Thạc sĩ


trong tƣơng lai gần cũng nhƣ sự quan tâm và đầu tƣ của Xã hội cho Y tế của

Việt Nam, theo đó định vị đƣợc chuyên đề cần nghiên cứu trong bức tranh ứng
dụng CNTT tổng thể trong chuyên ngành Y.
- Đƣa ra mô hình tổng quan về phƣơng pháp luận Agile trong mối quan hệ
với HIS, theo đó đánh giá mức độ quan trọng của Agile trong HIS.
- Đƣa ra các mô hình thu thập và các mô hình tổng hợp thông tin, cũng
nhƣ các phƣơng pháp khai phá (data mining), tổng hợp thông tin dƣới vai trò
của ngƣời lãnh đạo của tổ chức. Từ đó hình thành đƣợc một mô hình khung
cho Agile.
- Đƣa ra mô hình và lộ trình ứng dụng về Agile, thực hiện thử nghiệm, sau
đó tiến hành khảo sát để lấy phản hồi, dựa vào đó tiến hành đánh giá lại rồi bổ
sung để hoàn thiện phƣơng pháp luận của đề tài.
- Tổng hợp lại để đúc kết thành cơ sở khoa học của đề tài và đánh giá về xu
hƣớng ứng dụng. Cuối cùng thực hiện đánh giá kết quả đã đạt đƣợc, hoàn thiện
phƣơng pháp và đƣa ra định hƣớng nghiên cứu chuyên sâu hơn nữa cho đề tài.
3. BỐ CỤC LUẬN VĂN
Ngoài phần mở đầu và kết luận, Luận văn đƣợc chia ra làm 3 chƣơng cụ
thể nhƣ sau:
Chƣơng I. PHƢƠNG PHÁP LUẬN AGILE
Giới thiệu phƣơng pháp luận Agile cũng nhƣ các thành công trong việc
khắc phục những điểm yếu trong quy trình phát triển và triển khai phần mềm
tới cho khách hàng, theo đó là một trong những cơ sở để hình thành lý thuyết
cốt lõi cho đề tài này.
Chƣơng II. HTTT BỆNH VIỆN VÀ BỆNH ÁN ĐIỆN TỬ
- Khảo sát, đánh giá và tổng hợp về ứng dụng CNTT trong các bệnh viện
ngành y tế (Hệ thống thông tin Bệnh viện – HIS – Hospital Information
System), cũng nhƣ đánh giá về xu hƣớng chung của ngành Y tế Việt Nam
trong tƣơng lai gần.
- Trình bày kiến trúc của HTTT Bệnh viện và Bệnh án điện tử, kiến trúc
điển hình để có thể áp dụng cho các Bệnh viện ở Việt Nam.

Chƣơng III. ÁP DỤNG MÔ HÌNH AGILE TRIỂN KHAI BỆNH ÁN
ĐIỆN TỬ
Trình bày về áp dụng phƣơng pháp luận Agile, vào xây dựng và triển khai
HTTT Bệnh viện trong việc khắc phục các điểm yếu, các vấn đề của ngành
đƣợc nêu ở chƣơng 2.
Phạm Trung Thành

-13-

Luận văn Thạc sĩ


CHƢƠNG I.

PHƢƠNG PHÁP LUẬN AGILE

Phát triển phần mềm linh hoạt (Agile software development – gọi tắt là
Agile) là một triết lí cùng với nhóm các phƣơng pháp và phƣơng pháp luận
phát triển phần mềm dựa trên các nguyên tắc phát triển phân đoạn lặp
(iterative) và tăng trƣởng (incremental), theo đó nhu cầu và giải pháp tiến hóa
thông qua sự hợp tác giữa các nhóm tự quản và liên chức năng. Agile thƣờng
sử dụng cách lập kế hoạch thích ứng (adaptive planning), việc phát triển và
chuyển giao theo hƣớng tiến hóa; sử dụng các khung thời gian ngắn và linh
hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển. Ngày
nay, triết lí Agile đã vƣợt xa khỏi khu vực truyền thống của mình là phát triển
phần mềm để đóng góp sự thay đổi trong cách thức làm việc, quản lí, sản xuất
ở các ngành khác nhƣ sản xuất (manufacturing), dịch vụ, sales, marketing, giáo
dục v.v.

Mức độ phổ biến của các phương pháp [7]

Thuật ngữ “Agile” chính thức đƣợc sử dụng rộng rãi theo cách thống nhất
kể từ khi “Tuyên ngôn Agile” đƣợc giới thiệu ra công chúng năm 2001. Nhờ
tính linh hoạt, đa dạng và hiệu quả cao, các phƣơng pháp Agile ngày càng trở
thành sự lựa chọn hàng đầu của các khách hàng, nhà phát triển, các công ty
phát triển phần mềm. Theo khảo sát của hãng nghiên cứu thị trƣờng Forrester,
mức độ phổ biến của Agile hiện đang ở mức cao nhất, và gấp nhiều lần so với
các phƣơng pháp truyền thống nhƣ thác nƣớc hay CMMi (xem biểu đồ trên).
Phạm Trung Thành

-14-

Luận văn Thạc sĩ


Hơn thế, một số phƣơng pháp Agile có xuất xứ và đƣợc sử dụng hiệu quả ngoài
phạm vi phát triển phần mềm.
I.1 TUYÊN NGÔN AGILE (AGILE MANIFESTO)
Vào tháng 02 năm 2001, mƣời bảy (17) nhà phát triển phần mềm đã gặp
gỡ nhau ở Snowbird, Utah Resort để thảo luận về các phƣơng pháp phát triển
phần mềm gọn nhẹ và linh hoạt. Họ đã cùng nhau công bố “Tuyên ngôn phát
triển phần mềm linh hoạt” (“Manifesto for Agile Software Development” – gọi
tắt là “Tuyên ngôn Agile”) để định nghĩa cách hiểu về phát triển phần mềm
linh hoạt. Đây là cột mốc quan trọng của Agile. Dù trƣớc đó, các phƣơng pháp
Agile nhƣ XP, Scrum, v.v. đã đƣợc sử dụng thành công ở rất nhiều nơi, nhƣng
phải tới khi có sự xuất hiện của “Tuyên ngôn Agile”, cùng với sự ra đời của
các hiệp hội chuyên ngành Agile nhƣ Agile Alliance hay Scrum Alliance, các
phƣơng pháp Agile mới có một sự phát triển vƣợt bậc. Văn bản này rất ngắn,
dễ hiểu, và rất quan trọng vì nó đƣa ra các giá trị cốt lõi nhất mà toàn bộ các
nhà lý thuyết cũng nhƣ những ngƣời thực hành Agile tuân thủ; mặc dù các
phƣơng pháp họ đề xuất hoặc sử dụng trong thực tiễn có thể rất khác nhau.

Toàn văn Tuyên ngôn Agile nhƣ sau:

Tuyên ngôn Phát triển phần mềm linh hoạt [8]
Chúng tôi đã phát hiện ra cách phát triển phần mềm tốt hơn bằng cách
thực hiện nó và giúp đỡ người khác thực hiện.
Qua công việc này, chúng tôi đã đi đến việc đánh giá cao:
Cá nhân và sự tƣơng tác hơn là quy trình và công cụ;
Phần mềm chạy tốt hơn là tài liệu đầy đủ;
Cộng tác với khách hàng hơn là đàm phán hợp đồng;
Phản hồi với các thay đổi hơn là bám sát kế hoạch.
Mặc dù các điều bên phải vẫn còn giá trị, nhưng chúng tôi đánh giá cao
hơn các mục ở bên trái.
Bên cạnh đó, các nhà phát triển còn nhấn mạnh mƣời hai nguyên lý phía
sau Tuyên ngôn Agile để giúp các nhà phát triển có đƣợc gợi ý trong thực hành
và vận dụng các phƣơng pháp Agile trong thực tiễn. Các nguyên lý đƣợc liệt kê
sau đây:
1) Ƣu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc
Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình

Phạm Trung Thành

-15-

Luận văn Thạc sĩ


phát triển. Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế
cạnh tranh của khách hàng.
2) Thƣờng xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài
tuần đến vài tháng, ƣu tiên cho các khoảng thời gian ngắn hơn.

3) Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày
trong suốt dự án.
4) Xây dựng các dự án xung quanh những cá nhân có động lực. Cung
cấp cho họ môi trƣờng và sự hỗ trợ cần thiết, và tin tƣởng họ để hoàn
thành công việc.
5) Phƣơng pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển
và trong nội bộ nhóm phát triển là hội thoại trực tiếp.
6) Phần mềm chạy tốt là thƣớc đo chính của tiến độ.
7) Các quy trình linh hoạt thúc đẩy phát triển bền vững. Các nhà tài trợ,
nhà phát triển, và ngƣời dùng có thể duy trì một nhịp độ liên tục
không giới hạn.
8) Liên tục quan tâm đến các kỹ thuật và thiết kế tốt để gia tăng sự linh
hoạt.
9) Sự đơn giản – nghệ thuật tối đa hóa lƣợng công việc chƣa xong, là căn
bản.
10) Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ đƣợc
làm ra bởi các nhóm tự tổ chức.
11) Đội sản xuất sẽ thƣờng xuyên suy nghĩ về việc làm sao để trở nên hiệu
quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho
phù hợp.
Các nguyên lý này, cùng với năm điểm cốt lõi trong "Tuyên ngôn Agile"
sẽ dẫn đƣờng cho các nhà thực hành Agile (Agile practictioner) vận dụng tốt
các phƣơng pháp Agile vào thực tiễn.
I.2 ĐẶC TRƢNG AGILE
Có rất nhiều phƣơng pháp Agile với các hƣớng tiếp cận rất khác nhau.
Bên cạnh các cách thức tổ chức công việc, thiết lập quy trình, các phƣơng pháp
Agile còn nghiên cứu và đƣa vào sử dụng các công cụ và kỹ thuật đặc thù nhƣ
công cụ tích hợp liên tục (continuous integration), kiểm thử đơn vị, mẫu thiết
kế, tái cấu trúc, phát triển hƣớng kiểm thử (TDD), phát triển hƣớng hành vi
(BDD), hay lập trình theo cặp v.v. để đảm bảo và gia tăng tính linh hoạt. Tuy

vậy các phƣơng pháp này chia sẻ nhiều đặc trƣng giống nhau cộng tác nhóm
chặt chẽ, tổ chức các nhóm tự quản, liên chức năng, tính đáp ứng cao trong
suốt vòng đời của dự án.
Phạm Trung Thành

-16-

Luận văn Thạc sĩ


I.2.1 Tính lặp (Iterative)
Dự án sẽ đƣợc thực hiện trong các phân đoạn lặp đi lặp lại. Các phân đoạn
(đƣợc gọi là Iteration hoặc Sprint) này thƣờng có khung thời gian ngắn (từ một
đến bốn tuần). Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các
công việc cần thiết nhƣ lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai,
kiểm thử (với các mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm.
Các phƣơng pháp Agile thƣờng phân rã mục tiêu thành các phần nhỏ với quá
trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và không thực hiện việc lập
kế hoạch dài hạn. Có phƣơng pháp nhƣ Scrum thậm chí sử dụng phƣơng pháp
lập kế hoạch just-in-time trong quá trình phát triển. Khi đó, thậm chí công việc
lập kế hoạch, làm mịn kế hoạch đƣợc thực hiện liên tục trong suốt quá trình
làm việc.
-ơ
Các phân đoạn lặp đi lặp lại trong Agile
I.2.2 Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary)
Cuối các phân đoạn, nhóm phát triển thƣờng cho ra các phần nhỏ của sản
phẩm cuối cùng. Các phần nhỏ này thƣờng là đầy đủ, có khả năng chạy tốt,
đƣợc kiểm thử cẩn thận và có thể sử dụng ngay (gọi là potentially shippable
product increment of functionality). Theo thời gian, phân đoạn này tiếp nối
phân đoạn kia, các phần chạy đƣợc này sẽ đƣợc tích lũy, lớn dần lên cho tới khi

toàn bộ yêu cầu của khách hàng đƣợc thỏa mãn. Khác với mô hình phát triển
Thác nƣớc – vốn chỉ cho phép nhìn thấy toàn bộ các chức năng tại thời điểm
kết thúc dự án, sản phẩm trong các dự án Agile lớn dần lên theo thời gian, tiến
hóa cho tới khi đạt đƣợc trạng thái đủ để phát hành.
I.2.3 Tính thích ứng (hay thích nghi – adaptive)
Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, và việc
lập kế hoạch cũng đƣợc điều chỉnh liên tục, nên các thay đổi trong quá trình
phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hƣớng về mục
tiêu v.v.) đều có thể đƣợc đáp ứng theo cách thích hợp. Ví dụ, trong Scrum –
phƣơng pháp phổ biến nhất hiện nay, trong khi nhóm phát triển sản xuất ra các
gói phần mềm, khách hàng có thể đƣa thêm các yêu cầu mới, chủ sản phẩm
(Product Owner) có thể đánh giá các yêu cầu này và có thể đƣa vào làm việc
trong phân đoạn (đƣợc gọi là Sprint trong Scrum) tiếp theo. Theo đó, các quy
trình Agile thƣờng thích ứng rất tốt với các thay đổi.

Phạm Trung Thành

-17-

Luận văn Thạc sĩ


I.2.4 Nhóm tự tổ chức và liên chức năng
Cấu trúc nhóm Agile thƣờng là liên chức năng (cross-functionality) và tự
tổ chức (self-organizing). Theo đó, các nhóm này tự thực hiện lấy việc phân
công công việc mà không dựa trên các mô tả cứng về chức danh (title) hay làm
việc dựa trên một sự phân cấp rõ ràng trong tổ chức. Các nhóm này cộng tác
với nhau để ra quyết định, theo dõi tiến độ, giải quyết các vấn đề mà không chờ
mệnh lệnh của các cấp quản lý. Họ không làm việc theo cơ chế “mệnh lệnh và
kiểm soát” (command and control). Nhóm tự tổ chức có nghĩa là nó đã đủ các

kỹ năng (competency) cần thiết cho việc phát triển phần mềm, do vậy nó có thể
đƣợc trao quyền để tự ra quyết định, tự quản lí và tổ chức lấy công việc của
chính mình để đạt đƣợc hiệu quả cao nhất.
I.2.5 Quản lý tiến trình thực nghiệm (Empirical Process Control)
Các nhóm Agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì
tính toán lý thuyết hay các tiền giả định (prescription). Việc phân nhỏ dự án
thành các phân đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển
thu thập dữ kiện cho phép điều chỉnh các chiến lƣợc phát triển của mình. Nói
cách khác, Agile rút ngắn vòng đời phản hồi (short feedback life cycle) để dễ
dàng thích nghi và gia tăng tính linh hoạt. Theo thời gian, các chiến lƣợc này sẽ
tiến gần đến trạng thái tối ƣu, nhờ đó nhóm có thể kiểm soát đƣợc tiến trình, và
nâng cao năng suất lao động.
I.2.6 Giao tiếp trực diện (face-to-face communication)
Một số mô hình phát triển phần mềm dựa rất nhiều vào công việc giấy tờ,
từ việc thu thập yêu cầu ngƣời dùng, viết đặc tả hệ thống, các thiết kế hệ thống
v.v. Agile không phản đối công dụng của công việc tài liệu hóa, nhƣng đánh
giá cao hơn việc giao tiếp trực diện thay vì gián tiếp thông qua giấy tờ. Về yêu
cầu của khách hàng, Agile khuyến khích nhóm phát triển trực tiếp nói chuyện
với khách hàng để hiểu rõ hơn về cái khách hàng thực sự cần, thay vì phụ
thuộc nhiều vào các loại văn bản. Trong giao tiếp giữa nội bộ nhóm phát triển
với nhau, thay vì một lập trình viên (thực hiện việc mã hóa) và một kỹ sƣ (thực
hiện việc thiết kế) giao tiếp với nhau thông qua bản thiết kế, Agile khuyến
khích hai ngƣời này trực tiếp trao đổi và thống nhất với nhau về thiết kế của hệ
thống và cùng nhau triển khai thành các chức năng theo yêu cầu.
Bản thân các nhóm Agile thƣờng nhỏ (ít hơn mƣời hai ngƣời, một nhóm
lớn thƣờng đƣợc phân nhỏ với cơ chế hợp tác đặc thù để luôn luôn có thông
lƣợng giao tiếp tối đa) để đơn giản hóa quá trình giao tiếp, thúc đẩy việc cộng
tác hiệu quả. Các dự án lớn muốn dùng Agile thƣờng phải phân thành nhóm

Phạm Trung Thành

-18-

Luận văn Thạc sĩ


nhỏ đồng thời làm việc với nhau hƣớng đến một mục tiêu chung. Việc này có
thể đòi hỏi một số nỗ lực đáng kể trong việc điều phối các mức ƣu tiên giữa các
nhóm.
Các nhóm phát triển thƣờng tạo ra các thói quen và cơ chế trao đổi trực
diện một cách thƣờng xuyên. Một trong các cơ chế thƣờng thấy là các cuộc họp
tập trung hàng ngày (daily meeting, Daily Scrum, standup meeting). Tại đây,
tất cả các thành viên đƣợc yêu cầu nói rõ cho nhóm của mình biết mình đã làm
gì, đang làm gì, sắp làm gì và đang gặp phải khó khăn nào trong quá trình làm
việc. Khi cơ chế này đƣợc thực hiện hiệu quả, nhóm luôn luôn nắm đƣợc tình
hình công việc của mình, có các hành động thích hợp để vƣợt qua các trở lực
để thực hiện thành công mục tiêu của dự án.
I.2.7 Phát triển dựa trên giá trị (value-based development)
Một trong các nguyên tắc cơ bản của Agile là “phần mềm chạy tốt chính
là thƣớc đo của tiến độ”. Nguyên tắc này giúp nhóm dám loại bỏ đi các công
việc dƣ thừa không trực tiếp mang lại giá trị cho sản phẩm. Ví dụ, một nhóm
thấy rằng có thể không cần phải viết ra tất cả các thiết kế của hệ thống, mà họ
chỉ cần phác thảo các thiết kế này lên bảng, rồi cùng nhau triển khai các chức
năng của hệ thống. Nhƣng nếu nhƣ chủ sản phẩm quyết định rằng, khi chuyển
giao sản phẩm, nhóm phát triển phải kèm theo thiết kế chi tiết của hệ thống vì
chúng chiếm 20% giá trị của dự án theo yêu cầu của khách hàng, và vì khách
hàng cần nó để chứng minh tính đúng đắn của các chức năng, và để phát triển
tiếp các phân hệ tiếp theo của sản phẩm thì nhóm phát triển sẽ phải thực hiện
việc tài liệu hóa đầy đủ.
Để vận hành đƣợc cơ chế “làm việc dựa trên giá trị”, nhóm Agile thƣờng

làm việc trực tiếp và thƣờng xuyên với khách hàng (hay đại diện của khách
hàng), cộng tác trực tiếp với họ để biết yêu cầu nào có độ ƣu tiên cao hơn,
mang lại giá trị hơn sớm nhất có thể cho dự án. Nhờ đó các dự án Agile thƣờng
giúp khách hàng tối ƣu hóa đƣợc giá trị của dự án. Một cách gần nhƣ trực tiếp,
Agile gia tăng đáng kể độ hài lòng của khách hàng.
I.3 CÁC NGUYÊN TẮC VÀ GIÁ TRỊ TRONG AGILE
Phát triển Linh hoạt (Agile Development) làm một thuật ngữ có nguồn
gốc từ Tuyên ngôn phát triển phần mềm linh hoạt (Agile Manifesto - Tuyên
ngôn Agile), tuyên ngôn này đƣợc soạn thảo năm 2001 bởi một nhóm gồm các
nhà sáng tạo Scrum, Extreme Programming (XP), Dynamic Systems
Development Method (DSDM - Phƣơng pháp phát triển hệ thống linh động),
và Crystal; đại diện của phát triển hƣớng-tính-năng (feature-driven) và một vài
Phạm Trung Thành

-19-

Luận văn Thạc sĩ


nhà lãnh đạo khác trong lĩnh vực công nghiệp phần mềm. Tuyên ngôn Agile đã
tổng kết ra một số giá trị và nguyên tắc chung, phổ quát cho tất cả các phƣơng
pháp luận về linh hoạt đang tồn tại độc lập tại thời điểm đó. Văn bản này đƣa
ra bốn giá trị cốt lõi cho phép các nhóm đạt đƣợc hiệu suất cao.





Cá nhân và sự tƣơng tác
Cung cấp phần mềm chạy tốt

Cộng tác với khách hàng
Phản hồi với các thay đổi

Các giá trị cốt lõi này còn đƣợc hỗ trợ bởi 12 nguyên tắc nhƣ đã trình bày
ở phần trƣớc.
Những giá trị đó không chỉ là thứ mà các tác giả của Tuyên ngôn Agile dự
định cung cấp ra để phục vụ cho tuyên ngôn để rồi sau đó đi vào quên lãng.
Chúng là các giá trị căn cứ vào để làm việc. Bản thân mỗi phƣơng pháp linh
hoạt đều tiếp cận các giá trị trên theo các cách thức khác nhau, nhƣng tất cả các
phƣơng pháp này đều có tiến trình và thực hành cụ thể để nuôi dƣỡng một hoặc
nhiều trong số các giá trị đó.
I.3.1 Cá nhân và Sự tƣơng tác
Cá nhân và sự tƣơng tác giữa họ là cốt yếu để nhóm đạt đƣợc hiệu suất
cao. Các nghiên cứu về “bão hòa truyền thông” trong một dự án cho thấy rằng,
khi không có vấn đề trong truyền thông, nhóm có thể thực hiện công việc tốt
hơn 50 lần so với mức trung bình trong lĩnh vực của mình. Để tạo điều kiện
cho truyền thông, các phƣơng pháp linh hoạt thƣờng xuyên sử dụng chu trình
thanh-tra-và-thích-nghi. Chu trình này có thể diễn ra hàng phút với lập trình
cặp (pair-programming), hàng giờ với tích hợp liên tục (continuos integration),
hàng ngày với standup metting (đứng họp), hàng phân đoạn với các buổi họp
sơ kết và cải tiến.
Tuy nhiên, chỉ tăng tần suất phản hồi và giao tiếp là không đủ để loại bỏ
các vấn đề về truyền thông. Chu kỳ thanh-tra-và-thích-nghi làm việc tốt chỉ khi
các thành viên trong nhóm thể hiện những hành vi quan trọng sau:






Tôn trọng giá trị của mỗi cá nhân
Trung thực trong truyền thông
Minh bạch về dữ liệu, hoạt động, và quyết định
Tin tƣởng vào sự hỗ trợ của mỗi cá nhân với nhóm
Cam kết với nhóm và các mục tiêu của nhóm

Để thúc đẩy các hành vi này, nhà quản lý linh hoạt phải cung cấp một môi
trƣờng hỗ trợ, các nhà huấn luyện phải tạo điều kiện thuận lợi, và các thành
Phạm Trung Thành

-20-

Luận văn Thạc sĩ


viên của nhóm phải thể hiện chúng. Chỉ khi đó nhóm mới có thể phát huy đƣợc
hết tiềm năng của mình.
Đạt tới các hành vi đó khó khăn hơn rất nhiều so với việc hình thành
chúng. Hầu hết các nhóm tránh né sự thật, sự minh bạch, và tin tƣởng vào các
chuẩn mực văn hóa hoặc có những kinh nghiệm tiêu cực từ các xung đột xuất
phát từ truyền thông trung thực trƣớc đây. Để chống lại những khuynh hƣớng
này, ban lãnh đạo và thành viên nhóm phải tạo điều kiện cho những xung đột
tích cực. Làm nhƣ vậy không chỉ giúp tạo ra hành vi sinh lợi mà còn đem lại
các lợi ích khác:
 Cải tiến quy trình phụ thuộc vào nhóm trong việc tạo ra danh sách các
trở ngại hoặc vấn đề trong tổ chức, đối mặt với chúng một cách trung
thực, và sau đó loại bỏ chúng một cách có hệ thống tùy theo độ ƣu
tiên.
 Đổi mới chỉ xảy ra với việc tự do trao đổi các ý tƣởng mâu thuẫn lẫn
nhau, một hiện tƣợng đƣợc nghiên cứu và viết thành tài liệu bởi

Takeuchi và Nonaka, những ngƣời cha đỡ đầu của Scrum.
 Việc hƣớng các nhóm tới mục tiêu chung đòi hỏi nhóm phải đối mặt
và giải quyết các vấn đề về xung đột.
 Cam kết làm việc cùng nhau sẽ xảy ra chỉ khi mọi ngƣời đồng ý với
mục tiêu chung và sau đó đấu tranh cho sự tiến bộ của bản thân cũng
nhƣ nhóm.
Ý cuối cùng ở trên nói về cam kết là đặc biệt quan trọng. Đó là khi mà các
cá nhân và các nhóm đƣợc cam kết mà họ cảm thấy có trách nhiệm với việc
cung cấp các giá trị cao, đó là điểm mấu chốt đối với các nhóm phát triển phần
mềm. Các phƣơng pháp linh hoạt tạo điều kiện cho việc cam kết bằng cách
khuyến khích các nhóm đƣa ra một danh sách các công việc đƣợc ƣu tiên hóa,
để họ tự quản lý công việc của mình, và tập trung vào cải tiến về cách thực
hiện các công việc đó. Thực hành là nền tảng của tự-tổ-chức (selforganization), đó là động lực để đạt đƣợc kết quả trong một nhóm Agile.
Để tạo ra các nhóm có hiệu suất cao, các phƣơng pháp linh hoạt coi trọng
cá nhân và sự tƣơng tác hơn là quy trình và công cụ. Thực tế cho thấy rằng, tất
cả các phƣơng pháp linh hoạt tìm kiếm sự gia tăng trong truyền thông và cộng
tác thông qua việc kiểm tra thƣờng xuyên các chu trình thanh-tra-và-thích-nghi.
Tuy nhiên, các chu trình đó chỉ thực sự làm việc tốt khi mà các nhà lãnh đạo
Agile khuyến khích các cuộc xung đột tích cực, thứ cần thiết để xây dựng một
nền tảng vững chắc cho sự trung thực, tính minh bạch, lòng tin, sự tôn trọng, và
cam kết từ các nhóm Agile của họ.
Phạm Trung Thành

-21-

Luận văn Thạc sĩ


I.3.2 Phần mềm Chạy tốt hơn là Tài liệu đầy đủ
Phần mềm chạy tốt là một trong những khác biệt lớn mà phát triển linh

hoạt mang lại. Tất cả các phƣơng pháp linh hoạt thể hiện Tuyên ngôn Agile
bằng cách nhấn mạnh việc cung cấp một phần nhỏ của phần mềm chạy tốt tới
khách hàng sau một khoảng thời gian nhất định.
Tất cả các nhóm Agile phải xác lập những gì họ muốn nói là “phần mềm
chạy tốt”, cái thƣờng đƣợc biết nhƣ là định nghĩa hoàn thành. Ở mức độ cao,
một phần của chức năng hoàn thành chỉ khi các tính năng của chúng vƣợt qua
tất cả các kiểm thử và có thể đƣợc vận hành bởi ngƣời dùng cuối. Ở mức thấp
nhất, các nhóm phải vƣợt qua đƣợc kiểm thử đơn vị (unit test) và kiểm thử hệ
thống. Các nhóm tốt nhất còn bao gồm việc kiểm thử tích hợp, kiểm thử hiệu
năng, và kiểm thử chấp nhận của khách hàng trong định nghĩa hoàn thành đối
với một phần chức năng. Thông qua nguồn dữ liệu phong phú từ các dự án,
một công ty CMMI cấp độ 5 cho thấy việc xác định kiểm thử chấp nhận cùng
với các tính năng, triển khai một loạt các tính năng và theo độ ƣu tiên, ngay lập
tức chạy các kiểm thử chấp nhận với mỗi tính năng, và sửa bất cứ một lỗi nào
có độ ƣu tiên cao nhất sẽ tăng gấp đôi tốc độ sản xuất và giảm các sai sót đến
40%. Điều này có đƣợc từ một công ty có tỷ lệ sai sót thấp nhất thế giới.
Tuyên ngôn Agile khuyến nghị các nhóm cung cấp phần mềm chạy tốt
sau một khoảng thời gian nhất định. Đồng thuận với định nghĩa hoàn thành là
một trong những cách thực tế để nhóm Agile mang lại hiệu suất và chất lƣợng
cao, cái cần thiết để hoàn thành mục tiêu này.
I.3.3 Cộng tác với khách hàng hơn là thƣơng thảo hợp đồng
Trong hai thập kỷ qua, tỉ lệ thành công của các dự án tăng hơn hai lần trên
toàn thế giới. Điều này đƣợc cho là vì các dự án nhỏ hơn và mức độ chuyển
giao thƣờng xuyên đã cho phép khách hàng cung cấp các thông tin phản hồi về
phần mềm hoạt động một cách đều đặn hơn. Các tác giả của bản Tuyên ngôn
đã làm sáng tỏ điều này khi họ nhấn mạnh rằng việc để khách hàng tham gia
vào quá trình phát triển phần mềm là hết sức cần thiết để dẫn tới thành công.
Các phƣơng pháp phát triển linh hoạt đã thúc đẩy giá trị này bằng cách
đƣa vào một đồng minh tích cực của khách hàng làm việc sát cánh với đội phát
triển. Lấy một ví dụ, một nhóm Scrum đầu tiên có hàng ngàn khách hàng. Sẽ là

không khả thi nếu cho phép tất cả khách hàng tham gia vào quá trình phát triển
sản phẩm, vì vậy họ chọn ra một vị đại sứ của khách hàng, đƣợc gọi là Product
Owner (chủ sản phẩm), để đại diện cho không chỉ tất cả khách hàng trong
trƣờng hợp này mà còn bao gồm cả quản lý, dịch vụ khách hàng, và các bên

Phạm Trung Thành

-22-

Luận văn Thạc sĩ


liên quan khác. Chủ sản phẩm có trách nhiệm cập nhật danh sách yêu cầu về
sản phẩm sau mỗi bốn tuần thời điểm mà nhóm Scrum phát hành phiên bản sản
phẩm chạy tốt, có tính đến yếu tố thực tế cùng phản hồi của khách hàng và các
bên liên quan. Điều này cho phép khách hàng có thể giúp định hình sản phẩm
phần mềm đang đƣợc tạo ra.
Một nhóm XP đầu tiên đã bắt đầu với một dự án CNTT nội bộ. Họ có thể
có sẵn ngƣời sử dụng đầu cuối của công ty trong nhóm làm việc với họ hàng
ngày. Khoảng 10% thời gian, các tƣ vấn viên và nhóm nội bộ có thể tìm đƣợc
một ngƣời dùng cuối có thể làm việc với nhóm từng ngày. 90% thời gian còn
lại, họ phải cử ra ngƣời đại diện cho khách hàng. Ngƣời này, đƣợc nhóm XP
gọi là Customer (khách hàng), làm việc trực tiếp với ngƣời dùng cuối để cung
cấp một danh sách các tính năng rõ ràng cùng độ ƣu tiên cho phép đội phát
triển có thể thực hiện.
Cộng tác với khách hàng (hoặc đại diện của khách hàng) trên cơ sở hàng
ngày là một trong những lý do lý giải tại sao các dữ liệu trong ngành công
nghiệp cho thấy rằng các dự án linh hoạt có tỉ lệ thành công cao hơn gấp đôi so
với các dự án truyền thống tính trung bình trên toàn thế giới. Các phƣơng pháp
phát triển linh hoạt đã nhận ra điều đó, và do vậy, chúng đã tạo ra một vị trí đặc

biệt trong đội hình phát triển để dành riêng cho vị khách hàng đại diện này.
I.3.4 Phản hồi với thay đổi hơn là bám sát kế hoạch
Phản hồi với thay đổi là điều cần thiết cho việc tạo ra một sản phẩm làm
hài lòng khách hàng cũng nhƣ mang lại những giá trị kinh doanh. Dữ liệu
ngành công nghiệp cho thấy hơn 60% các yêu cầu về sản phẩm hay dự án bị
thay đổi suốt quá trình phát triển phần mềm. Ngay cả khi các dự án truyền
thống kết thúc đúng thời gian, đúng kinh phí, với tất cả các tính năng theo kế
hoạch, nhƣng khách hàng thƣờng không hài lòng vì những gì họ thấy không
thật sự đúng nhƣ những gì họ muốn. Luật Humphrey nói rằng khách hàng
không bao giờ biết những gì họ muốn cho đến khi họ thấy phần mềm hoạt
động. Nếu khách hàng không nhìn thấy phần mềm hoạt động cho đến khi kết
thúc dự án, sẽ là quá muộn cho việc kết hợp các thông tin phản hồi của họ ở
thời điểm này. Các phƣơng pháp phát triển linh hoạt tìm kiếm sự phản hồi của
khách hàng trong suốt dự án để có thể kết hợp thông tin phản hồi và thông tin
mới ngay khi sản phẩm đang đƣợc phát triển.
Tất cả các phƣơng pháp phát triển linh hoạt đều đƣợc tích hợp sẵn những
tiến trình thay đổi các kế hoạch trong một khoảng thời gian đều đặn dựa trên
những thông tin phản hồi từ phía khách hàng cũng nhƣ bên đại diện của khách
hàng. Các kế hoạch đƣợc thiết kế để sao cho luôn cung cấp giá trị kinh doanh
Phạm Trung Thành

-23-

Luận văn Thạc sĩ


cao nhất trƣớc hết. Bởi vì 80% giá trị nằm trong 20% các tính năng, một dự án
phát triển linh hoạt chạy tốt có xu hƣớng kết thúc sớm, trong khi hầu hết các dự
án truyền thống thƣờng kết thúc trễ. Kết quả là, khách hàng thì vui vẻ hơn, và
các nhà phát triển thì thích thú với công việc của họ hơn. Các phƣơng pháp

phát triển linh hoạt dựa trên những hiểu biết đó, để thành công hơn chúng phải
có kế hoạch để thay đổi. Đó là lý do tại sao chúng thiết lập các quy trình, chẳng
hạn nhƣ Sơ kết và Cải tiến, đƣợc thiết kế đặc biệt để thay đổi các ƣu tiên
thƣờng xuyên dựa trên thông tin phản hồi của khách hàng và giá trị kinh doanh.
I.3.5 Agile là chiếc ô – Các phƣơng pháp dƣới chiếc ô này
Phát triển linh hoạt bản thân nó không phải là một phƣơng pháp. Nó là một
thuật ngữ chung mô tả rất nhiều các phƣơng pháp linh hoạt. Tại thời điểm ký
kết Tuyên ngôn Agile năm 2001, những phƣơng pháp này bao gồm: Scrum,
XP, Crystal, FDD, và DSDM. Kể từ thời điểm đó, Lean cũng đã nổi lên nhƣ là
một phƣơng pháp linh hoạt có giá trị do vậy cũng đƣợc đƣa vào trong chiếc ô
của các phƣơng pháp Agile trong hình minh họa dƣới đây.

Agile là chiếc ô [9]
Mỗi phƣơng pháp phát triển linh hoạt có một cách tiếp cận hơi khác nhau
để thực hiện các giá trị cốt lõi trong tuyên ngôn Agile, cũng giống nhƣ các
ngôn ngữ máy tính có các biểu hiện tính năng cốt lõi trong lập trình hƣớng đối
tƣợng theo những cách khác nhau. Một cuộc khảo sát gần đây cho thấy rằng,
khoảng 50% học viên theo học phƣơng pháp phát triển linh hoạt nói rằng đội
của họ đang làm Scrum, 20% khác nói rằng họ đang làm Scrum với các thành
phần của XP. Khoảng 12% nói rằng họ chỉ áp dụng XP. Do có hơn 80% áp
dụng phát triển linh hoạt trên toàn thế giới là sử dụng Scrum và XP, nên bản
MSF cho phát triển phần mềm linh hoạt phiên bản 5.0 tập trung vào quy trình
cốt lõi và thực tiễn áp dụng của Scrum và XP.

Phạm Trung Thành

-24-

Luận văn Thạc sĩ

Scrum là một khung làm việc (framework) cho các quy trình phát triển
linh hoạt. Nó không bao gồm các vấn đề thực hành, kỹ thuật cụ thể. Ngƣợc lại,
XP lại tập trung vào các kỹ thuật thực hành cụ thể nhƣng không có một bộ
khung làm việc tổng thể cho quá trình phát triển. Điều đó không có nghĩa rằng
Scrum khuyên bạn không nên áp dụng các phƣơng pháp thực hành cụ thể hay
là XP thì không có quy trình. Ví dụ, ban đầu Scrum áp dụng tất cả các phƣơng
pháp thực hành mà bây giờ đƣợc biết đến nhƣ là XP. Tuy nhiên, khung làm
việc Scrum cho việc phát triển phần mềm đƣợc thiết kế để có đƣợc một nhóm
nghiên cứu bắt đầu trong hai ba ngày, trong khi thực hành kỹ thuật phải mất
nhiều tháng để thực hiện. Vì vậy, nó để lại câu hỏi khi nào (hay không) để thực
hiện các thực hành cụ thể đối với mỗi đội. Hai đồng tác giả của Scrum là Jeff
Sutherland và Ken Schwaber khuyến nghị rằng Nhóm Scrum bắt đầu ngay lập
tức và tạo ra danh sách các trở ngại và kế hoạch cải tiến quy trình. Khi việc
thực hành về kỹ thuật đƣợc xác định là trở ngại, nhóm nên xem xét các phƣơng
pháp thực hành của XP nhƣ là một cách để cải tiến. Các nhóm tốt nhất sử dụng
Scrum bổ sung với thực hành XP. Scrum giúp XP về mặt quy mô, XP giúp
Scrum làm việc tốt hơn.
Bảng sau cho thấy những thuật ngữ quan trọng tƣơng ứng giữa Scrum và
XP:
Scrum

XP

Chủ sản phẩm (Product Owner)

Khách hàng (Customer)

Scrum Master

Huấn luyện viên XP (XP coach)

Nhóm

Nhóm

Sprint

Phân đoạn (iteration)

Họp Kế hoạch Sprint (Sprint
Planning)

Trò chơi lập kế hoạch (Planning
Game)

Phạm Trung Thành

-25-

Luận văn Thạc sĩ