PV: Cảm ơn bà đã tham gia với chúng tôi. Bà có thể cho chúng tôi biết một chút về bản thân?

Tôi bắt đầu cuộc sống như một lập trình viên, thực sự thì tôi nghiên cứu Toán học và công việc đầu tiên của tôi là lập trình. Và khi đó, họ chỉ mới bắt đầu có các chương trình khoa học máy tính, tôi đã có một bài toán lớn, tham gia lập trình và làm việc với các hệ thống chuyển mạch tại phòng thí nghiệm B, sau đó tôi quay trở lại trường và có bằng Thạc sĩ Toán học, rồi tôi làm việc tại Đại học Wisconsin một vài năm, viết các chương trình máy tính chạy thí nghiệm vật lý. Điều đó mang lại cho tôi toàn bộ ý tưởng về việc sử dụng những chiếc minicomputer để thực thi các hệ thống điều khiển, tôi đã làm một thiết bị điều khiển xe tự động cho General Motors, chúng được phát triển cho sân bay hoặc một cái gì đó như thế. Và sau đó tôi có một công việc tại 3M làm các hệ thống điều khiển tiến trình. Và tôi đã làm việc đó trong hai mươi năm.

Sau một thời gian, tôi theo đuổi những hệ thống điều khiển cho một dây chuyền sản xuất, tôi đã trở thành người quản lý CNTT ở đó, và chúng tôi đã bị hấp dẫn bởi những thứ như phương thức Just-in-time, mà cuối cùng đã trở thành Lean Manufacturing. Vì vậy, dây chuyền của chúng tôi là một trong những thành phần chủ đạo trong 3M về Lean Manufacturing và bởi vì tôi là người quản lý hệ thống, và đó là một hệ thống vì vậy tôi đã có rất nhiều thứ để làm, với việc đưa một số các công cụ sản xuất thực sự tinh gọn vào 3M. Sau đó, tôi có một công việc phát triển sản phẩm tại 3M và 3M phát triển các sản phẩm cho cuộc sống, họ thực sự làm tốt điều đó và do vậy tôi đã học được rất nhiều về phát triển sản phẩm. Vì thế, bây giờ tôi có phần mềm, tôi có Lean, và tôi có phát triển sản phẩm :D. Vậy nên khi tôi rời 3M, tôi quyết định rằng mình vẫn còn quan tâm đến việc làm ra những thứ thú vị, tôi kết hợp ba điều đó để nói làm thế nào bạn có thể sử dụng các nguyên tắc Tinh gọn trong phát triển phần mềm. Và đó là những gì tôi đã viết từ trước đến nay.

PV: Vâng, chúng tôi biết những cuốn sách của bà và Tom, chúng chắc chắn là những cuốn sách giới thiệu Lean cho những nhóm phát triển phần mềm, vì vậy trước tiên cám ơn rất nhiều vì đã tham gia cùng chúng tôi và tôi biết cuốn sách thứ ba sắp ra đời sau hai cuốn sách đó.

Đúng vậy, chúng tôi vừa hoàn thành bản thảo cuối cùng gửi cho nhà xuất bản Addison-Wesley, vì vậy vào tháng 9(2009) này cuốn “Leading Lean Software Development” sẽ ra lò.

PV: Tuyệt vời, vậy bà có thể cho chúng tôi biết một chút về cuốn sách?

Ah, Có vẻ như cứ sau ba năm chúng tôi cho ra một cuốn sách. Và lý do là từ việc bắt đầu bằng cách viết một cuốn sách sau đó cho ra cuốn sách đầu tiên, ý tôi có lẽ là sẽ nói về nó hoặc điều gì đó tương tự, tôi nghĩ  việc đi và mang đến những lớp học và những hội thảo là thực sự thú vị và sau khoảng ba năm đi đến các công ty và những buổi hội thảo hay diễn thuyết, chúng tôi đã học được vô số thứ. Chúng tôi đã học được giống như từ một cuốn sách về những thứ giá trị nào đó. Vì vậy chúng tôi viết tiếp cuốn sách tiếp theo với tựa đề “Implementing Lean Software Development”, cuốn sách đã không lặp lại cuốn đầu tiên nhưng là những gì chi tiết hơn về cách mà bạn sẽ đi theo, đó là những gì mà chúng tôi đã học từ những thứ mà chúng tôi dạy, chúng tôi học.

Vào khoảng một năm trước, Tom đã nói với tôi “Anh nghĩ có một cuốn sách khác ở đây, và có lẽ em phải hoãn các buổi diễn thuyết và lên lịch cho thời gian rảnh rỗi để có thể bắt tay vào viết cuốn sách mới và nó sẽ có tựa đề là “Leading Lean Software Development”, khi đó tôi trả lời “Không, em chưa sẵn sàng, có quá nhiều việc phải làm để viết một cuốn sách”. Vì vậy, chúng tôi đã nói chuyện với những người đứng đầu các bộ phận đang vật lộn với những khó khăn, họ đã thử áp dụng Agile và nó luôn làm mọi thứ tốt hơn nhưng không đạt được những thứ mà họ kỳ vọng ban đầu, chúng tôi đã chứng kiến rất nhiều người đang mắc kẹt và cuối cùng tôi nói “Ok, em đoán chúng ta phải ra một cuốn sách giá trị nữa để nói về những nhà lãnh đạo, những người đang cố gắng hình dung ra cách khiến mọi thứ hoạt động”, vì vậy đó là những gì mà cuốn sách mới đề cập.

PV: Vậy, cuốn sách mới “Leading Lean Software Development” được viết cho các nhà lãnh đạo, điều đó có nghĩa là gì? Các lãnh đạo dự án, các nhà quản lý chương trình, các nhà quản lý bậc C?

Tất cả họ. Tôi không nghĩ bạn có thể có một sự triển khai Lean tốt nếu không có sự tham gia của đội ngũ lãnh đạo. Một trong những vấn đề với Lean, nếu bạn muốn coi đó là vấn đề, ít nhất trong văn hóa phương tây, nhiều ý tưởng là phản trực giác. Và vì vậy nếu cho rằng chúng tôi mang đến những lớp học dành cho các nhóm phát triển, họ sẽ nói “Đó là một trong những lớp học kỳ cục nhất mà tôi từng tham dự bởi vì chúng tôi không thể làm thế, và tổ chức của chúng tôi không cho phép như vậy”. Chúng tôi nghe thấy điều đó rất nhiều và vì vậy chúng tôi đã nhận ra rằng nếu chúng tôi không thể lôi kéo đội ngũ lãnh đạo tham gia với ít nhất là những vấn đề phản trực quan trong Lean, sẽ là rất khó khăn cho Lean và Agile có thể thâm nhập vào tổ chức của họ.

PV: Rất thú vị. Vậy điều này ràng buộc những thứ chúng ta đã từng nói cách đây nhiều năm, những điều mà cộng đồng đã nói về “mở rộng quy mô” của Agile trong tổ chức?

Tôi cho rằng. Nếu bạn bắt đầu từ dưới lên khi đó tôi đoán bạn phải mở rộng nó. Nhưng chúng tôi đã làm việc với những tổ chức lớn và họ không sử dụng từ “mở rộng quy mô”. Họ nói “Đó là chính chúng ta và chúng ta muốn làm điều đó. Làm thế nào để thực hiện điều đó?” có một ví dụ trong chương sáu của của cuốn sách trình bày về một trường hợp của IBM. IBM là một tổ chức rất lớn, tôi không biết có lẽ khoảng hai mươi lăm hoặc ba mươi lăm nghìn lập trình viên và họ làm Agile trong các công ty và họ không gọi nó là một sự quy mô, họ gọi đó là “Agile ở IBM” và thực tế họ đã dán cho nó một cái biển hiệu quảng cáo nhỏ “Agile ở IBM”.

PV: Vậy bây giờ nó là mới. Những công ty lớn không gọi nó là mở rộng quy mô, đó đơn giản chỉ là thực hiện.

Đúng vậy, và IBM đã phát triển các nhà huấn luyện theo tư tưởng riêng, họ phát triển theo cách riêng thông qua cách họ nói về nó, một cái gì đó phù hợp với văn hóa của họ và họ hiểu bất cứ điều gì họ đã có được trong toàn tổ chức. Nhưng khi họ làm điều đó về cơ bản họ định nghĩa Agile như là những phân đoạn ngắn ổn định với các phản hồi đều đặn từ các bên liên quan, và đó là một định nghĩa thú vị. Ngắn, bạn có thể hình dung ra ngắn có nghĩa là gì, nhưng thường có nghĩa là 2-4 tuần. Ổn định, giống như là cách làm thế nào để đạt được cái “hoàn thành”. Điều gì đó giúp bạn có thể thu về các phản hồi của khách hàng. Và các bên liên quan ám chỉ những người mà khách hàng sẽ trả hoặc sử dụng hoặc hưởng lợi từ những giá trị mang lại hoặc hỗ trợ cho phần mềm của bạn.

Và mỗi phân đoạn bạn sẽ nhận được các phản hồi từ phía các thành phần đó, vậy làm điều đó như thế nào? Vâng, đó là cách các nhóm quan tâm tới công việc bạn làm nhưng họ phải làm điều gì đó thú vị, một trong những thứ mà họ đã làm là tạo ra một phiên bản truy cập sớm nơi mà khi kết thúc phân đoạn họ đẩy phần mềm lên cho khách hàng download, những người này phải ký vào một bản thỏa thuận đặc biệt và sau đó họ thiết lập các nhóm thảo luận, trực tiếp giữa khách hàng sử dụng phần mềm và đội phát triển, không bị can thiệp bởi đội tiếp thị quảng bá. Và họ thật sự nhận được những lời như “Bạn biết đấy, hầu hết những thứ bạn làm đều ngon nhưng bạn phải thêm vào ba tính năng nữa nếu không đây là một sản phẩm vất đi”. Và sau đó nhóm phát triển sẽ nói “Ồ, chúng tôi rất sẵn lòng”, và họ đã làm điều đó với một dịch vụ trong WebSphere, xin lỗi tôi không nhớ rõ lắm.

Một trong những sản phẩm WebSphere được phát triển ở Anh, tại Vương Quốc Anh, và họ đã nhận được phản hồi này và họ đã phải thay đổi quyết định và kết quả là không hoàn thành, ý tôi là từ trước đến giờ hệ thống quản trị cho rằng “Phải cam kết với những gì mà bạn sẽ chuyển giao” và họ phát hiện ra rằng họ không thể làm điều đó vì nếu bạn có được phản hồi của khách hàng, bạn phải lắng nghe và nếu bạn định tiếp nhận nó bạn phải có một phân đoạn ổn định để họ có thể xem xét. Vậy nếu bạn nghĩ về ngắn-ổn định-phân đoạn với các phản hồi của khách hàng trong mỗi phân đoạn, điều đó sẽ dẫn đến những hành động tốt cho phần còn lại của đội phát triển bởi vì nó sẽ ổn định, điều đó cũng dẫn đến sự tương tác trực tiếp giữa lập trình viên và khách hàng tạo ra việc thực thi trong một không gian cho phép sự thay đổi, ở đó cũng nảy sinh nhiều thứ có ích từ việc định nghĩa như vậy. Vậy nên như mọi công ty, họ phải huấn luyện, họ phải có chương trình, đội ngũ nhân lực có thể sử dụng nó nếu họ muốn. Nhưng hãy đoán xem? Khi họ sử dụng nó họ sẽ thu được những kết quả tốt hơn. Đó không phải là “mở rộng quy mô Agile, đó là làm Agile trong một công ty lớn”.

PV: Đó là việc làm Agile trong một công ty lớn, ở đó không có vấn đề về “mở rộng quy mô”. Vậy tôi đoán rằng bằng cách giải thích như vậy rất nhiều câu chuyện và những điểm nhấn là nội dung chính của cuốn sách.

Đúng vậy, đó là tình huống được đề cập trong cuốn sách, nhưng cũng là bài học về việc lắng nghe khách hàng, chấp nhận bỏ thời gian cho những thứ thay đổi. Chúng tôi đã tìm ra rằng quản trị là một vấn đề quan trọng khi bạn muốn triển khai Agile trong bất cứ môi trường nào. Một vấn đề quan trọng khác là kiến trúc. Một trong những nơi mà chúng tôi nhận thấy ở rất nhiều các nhóm Agile gặp phải rắc rối là nằm ở môi trường kiến trúc theo khối, bởi Agile khuyến khích phản hồi với sự thay đổi, thích nghi với những ý kiến của khách hàng, và kiến trúc khối không giúp gì bạn cả, nó khiến mọi thứ rất khó khăn. Vì vậy có một vấn đề bất ổn lớn nếu bạn không có được một kiến trúc tốt ít phụ thuộc.

Và nếu bạn không có nó, bạn sẽ phải làm gì, kêu ca rằng “Ôi, xin lỗi tôi không thể làm Agile” hoặc điều mà bạn phải hình dung ra là cách làm sao để có được một kiến trúc ít phụ thuộc dần dần. Và đó là điều căn bản. Có một thứ khác chúng tôi tìm ra khi chúng tôi nói chuyện với rất nhiều nhà quản lý phát triển, đó là trong khi họ có rất nhiều các phương pháp quản lý dự án theo Agile nhưng họ không có các kỹ thuật thực hành để đồng hành với chúng. Và thử đoán xem? Đó thực sự không tốt chút nào. Nếu bạn không có những kiểm thử tốt ở những điểm nhạy cảm khi thay đổi, nếu bạn có một kiến trúc tệ và nó có quá nhiều ràng buộc, Agile lúc này là rất khó khăn, nếu bạn không có những người có được những kỹ năng trong việc hình dung ra những điều bạn cần trước khi bạn tiến hành, có rất nhiều các mẫu hình phát triển tốt, đó là những thứ bạn cần ở đây, bạn cần phải có các kỹ thuật thực hành vững để Agile có thể hoạt động.

Và nếu bạn khởi đầu với mệnh đề “Hãy xem chúng ta có thể làm gì trong vòng một tháng” bạn có thể nhanh chóng bị lún sâu, bạn phải thấy được những gì bạn có thể làm trong vòng một tháng, bên cạnh là những kỹ thuật thực hành rất quan trọng để có thể đưa ra được những đoạn mã chất lượng cũng trong khoảng thời gian đó.

PV: Vậy thử hình dung giả định rằng: nếu Bà làm Agile mà không có các phương pháp thực hành bà có thể sẽ gặp những phàn nàn từ khách hàng.

Nếu bạn thử Agile mà không có các phương pháp thực hành. Tôi có vài điều thú vị trong cuốn sách này, nó giống như một nghiên cứu về lịch sử phát triển phần mềm, bắt đầu vào những năm 68 với hội thảo Neil... và tiếp tục từ đó đến nay. Và nếu bạn xem điều gì đã diễn ra, hãy quay trở lại thế hệ ngôn ngữ lập trình thứ tư. Tom đã thực sự làm việc cho một công ty gọi là ForthGen. Ngôn ngữ lập trình thế hệ thứ tư là những thứ không còn tồn tại, vậy tại sao lại thế?

Ban đầu chúng khá hữu ích, nhưng đoán xem? Chúng tạo ra một khối lượng mã nền mà về cơ bản là không thể sửa đổi được. Bởi vì nó cho rằng “Ồ, bây giờ chúng ta sẽ dành điều đó cho người dùng” và người sử dụng đã làm điều đó, rất nhiều thứ được tung ra cùng nhau, không có các kiểm thử bền vững, không có các kĩ thuật thực hành chắc chắn. Trên thực tế rất nhiều ngôn ngữ bậc siêu cao dễ dẫn đến những đoạn mã không thể kiểm tra được. Vì vậy thậm chí ngày nay chúng ta thấy mọi người sử dụng các bộ sinh mã tự động và chúng có thể tốt trong chín tháng đầu tiên, một năm, và tất cả đột nhiên xuất hiện một đống mã không kiểm thử được và trở nên vô cùng phức tạp mà không phụ thuộc vào loại ngôn ngữ, bạn sẽ tạo ra các rắc rối nhanh hơn, cho dù là ngôn ngữ bậc thấp hay ngôn ngữ bậc cao nếu bạn tạo ra những mã không thể kiểm chứng trong một khoảng thời gian nhất định, chín tháng, sáu tháng, hoặc tương tự, bạn sẽ tạo ra vô số các đoạn mã không thể bảo trì cũng như thay đổi và cực kỳ khó để quay trở lại và làm nó và điều này không phụ thuộc vào thứ ngôn ngữ mà bạn chọn.

Điều quan trọng nếu bạn có một kiến trúc ở đó bạn có các vấn đề quan tâm riêng rẽ, bạn bố trí những phần có thể thay đổi cạnh nhau và những thứ không thay đổi ở một chỗ khác, và nếu bạn có những người mới không có kỹ năng hiểu được những thứ đẹp đẽ được xây dựng trong mã nguồn, chẳng mấy chốc bạn sẽ nhận được một mớ mã lệnh không thể kiểm thử và khi đó bạn có thể gọi đó là đống “di sản để lại”. Và bạn có thể gặp nó trong bất cứ ngôn ngữ nào rất nhanh chóng nếu bạn không có những kỹ thuật thực hành vững chắc. Cuốn “Clean Code” của Bob Martin là một cuốn sách thực sự tốt bởi nó đề cập đến cách mà bạn có thể tạo ra đoạn mã lệnh có thể đọc, có thể thao tác và có thể thay đổi theo thời gian. Và bạn phải để tâm đến điều này nếu bạn muốn có thứ gì đó thực sự tốt không quan tâm là dùng ngôn ngữ gì.

Vậy nếu bạn lao vào thực hành các phương pháp Agile, tất cả những gì chúng làm là khiến người ta nhanh chóng phát triển ra những đoạn mã vượt qua hết các kiểm thử ở hiện tại, bạn sẽ ổn trong một năm rồi sau đó chúng tạo lại ra một đống mã di sản tương tự khác. Điều này không lâu dài và bền vững được. Bạn có thể hoàn thành chính xác thời gian nhưng bạn có thể nói cách duy nhất chúng tôi có thể đạt được tốc độ thực tế là đi cùng với chất lượng. Với chất lượng được xây dựng trong mã và khi đó bạn có thể sẽ nhanh hơn và kết thúc là những mã có chất lượng khả chuyển cao. Nếu bạn không đạt được những mã khả chuyển chất lượng cao trong Agile thì sau một khoảng thời gian bạn sẽ tìm thấy mình ngập trong một mớ hỗn độn. Cũng như chuyện xảy ra với rất nhiều ngôn ngữ qua vài thập kỷ cuối trong phần mềm. Vâng, bạn có thể tạo ra thứ gì đó nhanh nhưng nếu bạn không tạo ra điều đó cùng với chất lượng đi kèm cũng như một kiến trúc đúng đắn thì nó sẽ không đem lại sự bền vững và lâu dài.

PV: Chất lượng bên trong không chỉ là code đã được kiểm thử, nó phải được kiểm chứng và có thiết kế tốt, và linh hoạt.

Vấn đề không chỉ là kiểm thử, kiến trúc tốt, các phương pháp thực hành tốt hay những thứ mà chúng ta biết mà còn là những điều mà những sinh viên mới ra trường không biết. Chúng tôi nói về vấn đề này trong sách với tên gọi Thực hành chủ ý (Deliberate Practice), Thực hành chủ ý được đề xướng bởi Andrews Erickon đến từ Stockholm, ông ta đã nghiên cứu những người tài năng có tay nghề cao, những nghệ sĩ violin, và những nhóm người khác, và ông đã phát hiện ra điều mà có lẽ không khiến bạn ngạc nhiên, nhưng tất cả những tài năng đó là những người đã thực hành chăm chỉ nhất. Nhưng ông ấy thực sự là người đã đặt tên cho nó, một loại thực hành, thực hành có chủ ý cũng là thực hành, hãy tưởng tượng về một vận động viên cố gắng đạt thành tích tốt, hoặc các nhạc công, bạn tập trung vào những yếu điểm, thực hành những kỹ năng mà mình muốn cải thiện, ví dụ như một tay golf có vấn đề với cú Swing vì vậy anh ta sẽ luyện tập dưới sự hướng dẫn của một giáo viên hoặc huấn luyện viên người sẽ cung cấp những phản hồi tức thì xem anh ta có làm đúng hay không.

Do vậy thực hành có chủ ý là tất cả, rèn luyện các kỹ năng còn yếu với người có thể cung cấp cho bạn những phương pháp thực hành đúng đắn và cải thiện nó cùng với rất nhiều phản hồi. Andrew Erickson đã khám phá ra rằng những tài năng đã bỏ ra mười nghìn giờ hay mười năm luyện tập thực hành có chủ ý để có được mức độ ưu tú. Bài báo gốc của ông đã được xuất bản vào năm 1993 và loạt nghiên cứu sau đó đã đưa ra một con số bí ẩn 10000 giờ hoặc 10 năm. Bạn không thể bỏ ra ba giờ một ngày trong mười năm và bạn không thể thực hành chú tâm nhiều hơn ba hay bốn giờ một ngày. Vì vậy thực hành có chủ ý theo thời gian có nghĩa là một ai đó sẽ càng ngày càng tốt hơn cho đến khi họ thực sự lão luyện và điều đó không chỉ áp dụng trong thể thao, trong y học, điều đó có cả trong kỹ thuật, phát triển phần mềm và bất cứ lĩnh vực nào.

Nếu bạn nghĩ về điều đó và bạn nhìn vào đoạn mã thật sự tốt, và bạn biết có một sự khác biệt lớn trong bản thân người viết ra đoạn mã đó, có thể năng suất và hiệu quả gấp mười lần so với những người khác, điều này là do đâu? Tài năng. Điều này là do đâu? Thực hành. Kỹ năng. Và sự phát triển kỹ năng, chúng ta đã bỏ ra quá ít thời gian để nói về điều đó trong phát triển phần mềm. Nhưng ở 3M nơi tôi làm việc, chúng tôi có hai loại nhân viên quản lý, chúng tôi có những tiêu chí dể chọn những nhà quản lý năng lực, những người trong công ty của chúng tôi là những quản lý trực tiếp, nhưng kỹ năng quản lý là thứ có thể được dạy và phát triển. Tôi chưa từng là một nhân viên kỹ thuật được làm việc với những người có tay nghề, thực sự lão luyện về kỹ thuật. Vì vậy, nếu bạn có một chỉ dẫn và đồng thời có một công việc đủ thách thức bạn, thì bạn phải có những phản hồi. Bạn phải biết việc mình đang làm là tốt hay không.

Những người thực hành có chủ ý, như các nhạc công hoặc vận động viên, họ bị ám ảnh bởi việc trở nên tốt hơn trong lĩnh vực của họ. Chúng ta thực hiện điều này trong phần mềm như thế nào? Có một nơi mà nó thực sự hoạt động tốt đó là lĩnh vực mã nguồn mở. Nếu tôi đang làm mã nguồn mở và có đưa mã của tôi cho một cộng tác viên và người này nói “tởm quá!” hoặc “ngon đấy!” và tôi học thật sự nhanh xem mình có làm đúng điều gì đó và chuyển lại cho cộng tác viên, bạn biết điều gì không, tất cả cộng đồng chỉ trích nó. Và điều này thực hiện trong từng bó nhỏ, không lớn, đó là loại mà tôi đang cố gắng để làm, vì ở đó có một lượng nhất định các phê bình liên tục từ các chuyên gia trong cộng đồng nguồn mở.

Tôi nghe nói nếu bạn thật sự muốn được tốt trong việc phát triển phần mềm hãy thử với mã nguồn mở. Bây giờ ở đâu cung cấp các thực hành có chủ ý trong phát triển phần mềm? Thay vì những thói quen thông thường, những thứ đã tốt ta thường làm nhiều hơn, và đó không phải là thực hành chủ ý. Vì vậy tài năng thực sự đến từ việc có những thứ thực sự tốt, nếu chúng ta quay trở lại với cuốn sách Clean Code của Bob. Ông ta nói về cách để phát triển kỹ năng cấu trúc mã nguồn cho các nhà phát triển một cách đơn giản, đó chỉ là làm những thứ đúng đắn. Và bất cứ ai đọc nó sau này biết chính xác điều mà người ta đã nghĩ. Đó chính là thứ mà ông ta gọi là “mã sạch”. Bây giờ nếu bạn có những mã nguồn như vậy, bạn có thể quay trở lại sau một vài năm và nói “Ồ vâng, đó chính là những gì tôi đã từng nghĩ” rồi một ai đó khác có thể nhìn vào đó và biết nó là cái gì và đó là thứ mã có thể thay đổi được. Làm thế nào bạn biết cách để đạt được điều đó? Bạn cần phải thực hành và bạn cần những chỉ dẫn kỹ năng về cách đạt được điều đó.

PV: Vậy các kỹ thuật thực hành là thực sự quan trọng, nếu không có chúng bạn có thể “sôi hỏng bỏng không”

À, không hẳn là như vậy. Tôi chưa từng thấy việc triển khai Agile nào mà không đòi hỏi cải tiến dựa trên năng lực thực hành hiện tại. Vì Agile luôn giúp cho một công ty tốt hơn lên nhưng liệu đó có phải là điều mà công ty đó thực sự muốn trở thành? Không phải không có những kỹ thuật chắc chắn. Liệu có thể tạo ra một khối lượng mã lớn mà sẽ nhanh chóng trở thành các di sản? Điều đó có thể.

PV: Và khi đó chúng ta sẽ về đúng nơi mà ta bắt đầu.

Đúng vậy, và điều đó là có thể kể cả bạn không có những kỹ thuật nền tảng tốt. Việc chỉ có một đội và hi vọng họ sẽ hình dung ra nó khác với việc có một nhà lãnh đạo toàn năng, một đội tinh nhuệ, hay những thứ tương tự.

PV: Và những kỹ năng đó, không có đường tắt nào để đạt được chúng, sẽ mất thời gian và công sức. Không chỉ là bỏ ra chút thời gian, Nếu bạn có mười năm luyện tập không có nghĩa là bạn sẽ có nó.

Không, mười năm không đồng nghĩa với kỹ năng, ta không tính như vậy. Nó có nghĩa đạt được tốt nhất những gì vốn đã tốt của bạn. Tôi không xem xét lĩnh vực phát triển phần mềm đơn khối, mà là nói chung. Không có gì là sai với thứ chung chung, nhưng tôi đang tìm kiếm một mẫu người có thể tạm đặt là T, những người có khả năng chuyên sâu trong một lĩnh vực sở trường nhất định, có thể là cơ sở dữ liệu, thiết kế tương tác người dùng, có rất nhiều lĩnh vực mà bạn cần những kỹ năng chuyên sâu.

Bạn cũng cần có người làm việc chặt trẽ với luồng lên và những người khác, vì nếu đó là thiết kế tương tác người dùng cho cách tôi thực hiện các giao dịch và những thứ tương tự. Khi đó những người T mà có khả năng làm việc với cả luồng lên và luồng xuống với những người khác nhưng trong phạm vi mà họ thông thạo và nó nằm trong những lĩnh vực mà việc thực hành có chủ ý là đặc biệt quan trọng.

PV: Bà nói về cuốn sách Clean Code của Martin rất nhiều lần. Đó có phải là kỹ nghệ lập trình hiện tại đang là chủ đề mà bà muốn nói tới?

Vâng, họ đang nói về một thực tế là bạn cần phải trở thành một bậc thầy và điều đó tốn thời gian. Và nó là một khái niệm, trước hết bạn tìm hiều nó nghĩa là gì và rồi bạn có thể như người học việc, tập sự, và bạn giống như vừa mới qua một trường học không chuyên về điều đó. Nhưng hãy nghĩ về những chiếc máy bay mà bạn đang bay, nghĩ về những phụ lái, họ về cơ bản là đang đóng vai trò tập sự thường là mất hàng chục năm trước khi họ có thể thực sự trở thành phi công chính. Và bạn không cần điều này để thay đổi.

Và tôi nghĩ việc lập trình phần mềm phức tạp khó ngang với bay máy bay cộng thêm vào đó là những lần mà nhiều mạng sống có thể bị đe dọa.

PV: Bà có thể cho chúng tôi biết về những ý tưởng khác mà bà muốn chia sẻ trong cuốn sách?

Vâng, có một người khác mà chúng tôi đi qua, đó là John Seddon người viết về các tổ chức dịch vụ và dịch vụ tinh gọn, anh ta đến từ Vương Quốc Anh. Anh ta nói về nhu cầu sai và nhu cầu giá trị. Nhu cầu sẽ đến khi bạn có một tổ chức cung cấp một nhóm dịch vụ như phát triển phần mềm, và có hai loại nhu cầu sẽ đến với tổ chức của bạn: một là bạn muốn cung cấp cho các khách hàng nhiều giá trị hơn, và đó là nhu cầu giá trị, nhưng sau đó những thứ này lại được gọi là nhu cầu sai. Nhu cầu sai là nhu cầu được tạo ra trong tổ chức của bạn từ chính những sai lầm của mình. Như việc bạn viết một vài phần mềm mà nó không hoạt động.

Nó chứa một khuyết điểm nên nó là nhu cầu sai hoặc nó khó có thể hiểu và được gọi ra bởi vì họ không thấy điều đó. Các cuộc gọi hỗ trợ đa số là từ những nhu cầu sai, bất cứ thứ gì bạn cung cấp mà không rõ ràng để hiểu hoặc có một cơ số mã lệnh là nhu cầu sai thay vì nhu cầu giá trị. Nên điều đầu tiên phải làm là sắp xếp những thứ đó ra thành hai nhóm và đối xử chúng một cách riêng biệt. Nhu cầu sai là xấu, nên bị loại bỏ, bạn không cần cố gắng làm nó nhanh hơn và không nên để nó ở vị trí hàng đầu. Thường mọi người trong các lớp học của chúng tôi sẽ cố gắng thử làm một bản đồ chuỗi giá trị. Và một trong số các bản đồ giá trị mà tôi thấy hầu hết các lần là “Hãy làm một bản đồ chuỗi giá trị về quá trình kiểm soát thay đổi của chúng tôi”. Và chúng luôn phản lại tôi như “Tốt, tại sao bạn lại để nó ở vị trí đầu tiên?” Nhưng bây giờ tôi tìm từ để diễn tả về nó, những yêu cầu thay đổi thực sự là những nhu cầu sai.

Chúng là nhu cầu sai bởi vì bạn quyết định quá sớm, rằng bạn phải thay đổi, hoặc bạn quyết định điều sai lầm. Bạn không có một cách hiểu mạch lạc về những gì là cần thiết. Vậy điều bạn nên làm trước yêu cầu thay đổi là nói “Tại sao chúng ta có những yêu cầu thay đổi? Quy trình nào đòi hỏi chúng ta phải thay đổi? Tai sao chúng ta không hình dung ra cách để ra quyết định đúng lúc để chúng ta không phải thay đổi?” Nhu cầu sai được phát hiện, đó là về quy trình cho phép chúng tôi phát hiện các khiếm khuyết trong các lĩnh vực. Do vậy khi người ta bắt đầu xem xét hồ sơ các nhu cầu, nhu cầu sai và nhu cầu giá trị và chuẩn đoán. Họ sẽ thấy đa phần là những nhu cầu sai, không phải là nhu cầu giá trị.

Và đó là những thứ tệ hại, những thứ làm bạn tự vấn rằng “Tại sao tôi có những nhu cầu sai? Làm sao để tôi loại bỏ chúng?” Bạn không nên nói rằng không thể loại bỏ chúng. Vâng, việc loại bỏ chúng là có thể trong một tuần, hoặc một tháng hoặc thậm chí một năm, nhưng nhu cầu sai là thứ gì đó bạn cố để tìm ra nguyên nhân và dập tắt chúng. Trong khi đó, tất nhiên bạn phải phản ứng càng nhanh càng tốt. Nhưng bạn muốn loại bỏ nhu cầu thất bại để có nhiều thời gian hơn cho nhu cầu giá trị. Bằng cách phân định rõ ràng trong đầu thành khi nào bạn có các yêu cầu, và chúng thuộc loại nào, sẽ giúp bạn quyết định xem bạn có nên hay không nên bỏ thời gian vào những yêu cầu đó. Và nếu bạn tốn thời gian vào chúng khi đó bạn cần làm gì đối với cách làm việc của bạn để có thể mất ít thời gian hơn vào những thứ như vậy.

PV: Nhu cầu sai không chỉ là thứ gì đó phải sửa chữa và khi đó nó là một cảnh báo và một cơ hội nếu bạn làm cho công việc của mình hiệu quả hơn.

Đúng vậy, nhu cầu sai là một cảnh báo rằng quy trình của bạn cẩn cải tiến. Và nó có thể cải tiến đáng kể để có thể không còn sản sinh ra những nhu cầu sai nữa.

PV: Thật tuyệt vời, đó là điều khác biệt và cách ấn tượng để nhìn nhận nó.

Và bạn chỉ nghĩ về nó, bạn nghĩ “Chà, có một cơ hội ở đây nếu tôi chỉ nghĩ về điều này với một chút khác biệt”

PV: Vâng, tôi có thể thấy rằng phần nhiều trong thầu hết mọi thứ mà tôi có thể nhận ra trong phạm vi nào đó thực sự là những nhu cầu sai, ngay cả khi người ta có những quy trình cứng rắn.

Vâng, khi nó đến, nó là nhu cầu sai thuần khiết :D

PV: Vâng cám ơn bà đã dành thời gian tham gia buổi nói chuyện thú vị này.

Ồ, không có chi :D

Nguồn: www.infoq.com | Người dịch: Nguyễn Ngọc Tú