Kata Potter

Mô tả bài toán

Một bộ các cuốn sách về người anh hùng nước Anh tên là Harry gồm 5 cuốn. (Cơ bản chỉ có 5 cuốn tính đến thời điểm ra đời Kata này) Trẻ em trên khắp thế giới hâm mộ Harry, và dĩ nhiên các nhà xuất bản cũng vậy. Do đó để khuyến khích bạn đọc (và để tăng doanh số bán hàng) các nhà xuất bản đã đưa ra chính sách về giá nhằm tận dụng sự lôi cuốn của người anh hùng Harry.

Mỗi cuốn sách về Harry có giá 8 EUR. Tuy nhiên nếu bạn mua 2 cuốn khác nhau (trong bộ sách 5 cuốn) bạn sẽ được giảm giá 5%. Nếu bạn mua 3 cuốn khác nhau sẽ được giảm 10%. Và giảm 20% nêu mua 4 cuốn khác nhau. Bạn sẽ được giảm 25% nếu mua trọn bộ gồm 5 cuốn.

Lưu ý, nếu bạn đặt hàng 4 cuốn nhưng chỉ thuộc 3 loại khác nhau, bạn chỉ được giảm 10% cho 3 cuốn khác hay đó, cuốn còn lại bạn vẫn phải trả đúng giá 8 EUR.

Cơn bão Harry Potter đã tràn qua các quốc gia và các bậc phụ huynh đang xếp hàng dài ở những hiệu sách để mau bộ truyện này. Bạn có nhiệm vụ viết chương trình để tính tiền cho các cửa hiệu sách theo các chính sách về giá được mô tả ở trên, chương trình đảm bảo người mua được lợi nhất về giá khi mua sách.

Ví dụ, tính giá bán của đơn hàng gồm các cuốn sách như sau:

2 cuốn Tập 1
2 cuốn Tập 2
2 cuốn Tập 3
1 cuốn Tập 4
1 cuốn Tập 5

Đáp án:

Giá bán = ( (4 x 8) – 20% [Tập 1, Tập 2, Tập 3, Tập 4] ) + ( (4 x 8) – 20% [Tập 1, Tập 2, Tập 3, Tập 5] = 25.6 * 2 = 51.20 EUR

Gợi ý:

Bạn có thể nhận thấy Kata này khá dễ để triển khai. Bạn có thể bắt đầu với test-case cho đơn hàng không có cuốn sách nào, 1 cuốn sách, 2 cuốn sách cùng tập, 2 cuốn sách khác tập, v.v… và sẽ không hề khó khăn nếu triển khai việc này với baby step và nâng dần độ phức tạp.

Tuy nhiên, sai sót sẽ dễ xảy đến khi bạn bắt tay tính toán số tiền mà sẽ cho rằng đơn hàng trên cần phải thanh toán. Đơn hàng không có giá trị là 5 x 8 x 0,75 + 3 x 8 x 0,90 = 51.6 EUR mà thực tế sẽ là 4 x 8 x 0,8 + 4 x 8 x 0,8 = 51.2 EUR. Mẹo ở đây là bạn phải viết mã đủ thông minh để lưu ý việc tính với trường hợp trên thì 2 bộ sách 4 cuốn sẽ rẻ hơn 1 bộ sách 5 cuốn và 1 bộ sách 3 cuốn.

Bạn sẽ phải đưa ra một số giải thuật thông minh để tối ưu hóa giá mua cho một đơn hàng. Đừng quá đòi hỏi một giải pháp tối ưu đầy đủ cho bài toán này. Cố gắng giải quyết bài toán này chỉ với mục tiêu chia sẻ nó cho người khác. Hãy tin rằng bạn có thể khái quát hóa và cải thiện giải pháp của mình khi có thêm các yêu cầu mới.

Gợi ý các test-case

Các test-case căn bản:

  • assert_equal(0, price([])) : đơn hàng không có cuốn nào, 0 EUR
  • assert_equal(8, price([0])): đơn hàng có 1 cuốn Tập 1, 8 EUR
  • assert_equal(8, price([1])): đơn hàng có 1 cuốn Tập 2, 8 EUR
  • assert_equal(8, price([2])): đơn hàng có 1 cuốn Tập 3, 8 EUR
  • assert_equal(8, price([3])): đơn hàng có 1 cuốn Tập 4, 8 EUR
    assert_equal(8, price([4])): đơn hàng có 1 cuốn Tập 5, 8 EUR
  • assert_equal(8 * 2, price([0, 0])): đơn hàng có 2 cuốn Tập 1, 16 EUR
  • assert_equal(8 * 3, price([1, 1, 1])): đơn hàng có 3 cuốn Tập 2, 24 EUR

Các test-case một loại giảm giá:

  • assert_equal(8 * 2 * 0.95, price([0, 1])): đơn hàng có 1 cuốn Tập 1, 1 cuốn Tập 2, giảm giá 5% còn 15,2 EUR.
  • assert_equal(8 * 3 * 0.9, price([0, 2, 4])): đơn hàng có 1 cuốn Tập 1, 1 cuốn Tập 3 và 1 cuốn Tập 5, giảm giá 10% còn 21,6 EUR.
  • assert_equal(8 * 4 * 0.8, price([0, 1, 2, 4])): đơn hàng có 1 cuốn Tập 1, 1 cuốn Tập 2, 1 cuốn Tập 3 và 1 cuốn Tập 5, giảm giá 20% còn 25,6 EUR.
  • assert_equal(8 * 5 * 0.75, price([0, 1, 2, 3, 4])): đơn hàng có 1 cuốn Tập 1, 1 cuốn Tập 2, 1 cuốn Tập 3, 1 cuốn Tập 4 và 1 cuốn Tập 5, giảm giá 25% còn 30 EUR.

Các test-case có vài loại giảm giá:

  • assert_equal(8 + (8 * 2 * 0.95), price([0, 0, 1])): đơn hàng có 2 cuốn Tập 1, 1 cuốn Tập 2, giá bán còn 23,2 EUR.
  • assert_equal(2 * (8 * 2 * 0.95), price([0, 0, 1, 1])): đơn hàng có 2 cuốn Tập 1, 2 cuốn Tập 2, giá bán còn 30,4 EUR.
  • assert_equal((8 * 4 * 0.8) + (8 * 2 * 0.95), price([0, 0, 1, 2, 2, 3])): đơn hàng có 2 cuốn Tập 1, 1 cuốn Tập 2, 2 cuốn Tập 3 và 1 cuốn Tập 4, giá bán còn 40,8 EUR.
  • assert_equal(8 + (8 * 5 * 0.75), price([0, 1, 1, 2, 3, 4])): đơn hàng có 1 cuốn Tập 1, 2 cuốn Tập 2, 1 cuốn Tập 3, 1 cuốn Tập 4 và 1 cuốn Tập 5, giá bán còn 38 EUR.

Các test-case biên:

  • assert_equal(2 * (8 * 4 * 0.8), price([0, 0, 1, 1, 2, 2, 3, 4])): đơn hàng có 2 cuốn Tập 1, 2 cuốn Tập 2, 2 cuốn Tập 3, 1 cuốn Tập 4 và 1 cuốn Tập 5, giá bán còn 51,2 EUR.
  • assert_equal(3 * (8 * 5 * 0.75) + 2 * (8 * 4 * 0.8), price([0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 3, 4, 4, 4, 4])): đơn hàng có 5 cuốn Tập 1, 5 cuốn Tập 2, 4 cuốn Tập 3, 4 cuốn Tập 4 và 4 cuốn Tập 5, giá bán còn 141.2 EUR.

Nguồn: http://codingdojo.org/KataCatalogue/

Kata NumbersInWords

Mô tả bài toán

Trong cuộc sống khi mọi người muốn viết số tiền, đặc biệt là một con số cụ thể. Khi viết séc, hóa đơn hoặc hợp đồng, ví dụ một số quốc gia yêu cầu phải viết kèm số tiền bằng chữ để tránh sai sót hoặc gian lận. Do đó khi bạn chuyển 745$ cho ai đó qua séc bạn phải viết như sau:

745.00 $, bằng chữ là “Bảy trăm bốn mươi lăm đô la”

Bước 1

Hãy xây dựng chương trình (method, function) để chuyển đổi số thành chữ.

Bước 2

Xây dựng chương trình chuyển đổi chữ sang số.

Bước 3

Xây dựng tổng hợp các chức năng đó với đầy đủ các kiểm thử.

Nguồn: http://codingdojo.org/KataCatalogue/

Kata FooBarQix

Kata này yêu cầu xây dựng một hàm nhận vào một số để tính toán và trả về một chuỗi thỏa mãn quy tắc sau:

Level 1

Các quy tắc:

  • Nếu số đó chia hết cho 3 thì thêm vào chuỗi từ “Foo”
  • Nếu số đó chia hết cho 5 thì thêm vào chuỗi từ “Bar”
  • Nếu số đó chia hết cho 7 thì thêm vào chuỗi từ “Qix”
  • Nếu số đó chứa chữ số 3, 5, 7, thì thêm vào chuỗi các từ “Foo”, “Bar”, “Qix”.

Ví dụ:

1 => 1
2 => 2
3 => FooFoo (chia hết cho 3, chứa số 3)
4 => 4
5 => BarBar (chia hết cho 5, chứa số 5)
6 => Foo (chia hết cho 3)
7 => QixQix (chi hết cho 7, chứa số 7)
9 => Foo
10 => Bar
12 => Foo
13 => Foo
15 => FooBarBar (chia hết cho 3, chia hết cho 5, chứa số 5)
21 => FooQix (Chia hết cho 3, chia hết cho 7)
33 => FooFooFoo (Chia hết cho 3, chứa hai số 3)
51 => FooBar (Chia hết cho 3, chứa số 5)
53 => BarFoo (Chứa số 5 và số 3)

Level 2

Kata này có thêm một yêu cầu mới đó là đánh dấu vị trí của số 0 bằng cách thêm vào chuỗi ký tựu “*”.

Ví dụ:

101 => 1*1
303 => FooFoo*Foo
105 => FooBarQix*Bar
10101 => FooQix**

Kata DictionaryReplacer

Kata này yêu cầu xây dựng một chức năng đơn giản để thay thế một\một số vị trí nào đó trong chuỗi. Ý tưởng của bài toán này xuất phát từ những chia sẻ của Corey Haines về luyện tập viết mã (aac2009.confreaks.com/06-feb-2009-20-30-lightning-talk-under-your-fingers-corey-haines.html).

Hãy tạo một phương thức nhận vào một chuỗi và một bộ từ điển. Thay thế các vị trí (key) trong chuỗi với các key có trong từ điển. Mỗi key trong chuỗi được đánh dấu bằng cặp ký tự $.

VD về test-case:

  • Test-case 1:
    • Input:
      • Chuỗi: “”
      • Từ điển: null
    • Output: “”
  • Test-case 2:
    • Input:
      • Chuỗi: “\$temp\$“
      • Từ điển: [“temp”, “temporary”]
    • Output: “temporary”
  • Test-case 3:
    • Input:
      • Chuỗi: “\$temp\$ here comes the name \$name\$“
      • Từ điển: [“temp”, “temporary”], [“name”, “John Doe”]
    • Output : “temporary here comes the name John Doe”

Những quy tắc của coderetreat

,

Nhóm nào cũng tuân thủ

  1. Lập trình cặp (Pair Programming): Bạn đã có ai để cặp chưa? Đừng lo, tới sự kiện bạn sẽ kiếm được cạ của mình. Nhưng đừng vội mừng kiếm được cạ rất ưng ý, bởi sau mỗi phiên đối tác của bạn sẽ phải ra đi. Autumn Coderetreat 2017 có 5 phiên (session) làm việc vậy nên bạn có cơ hội cặp với 5 người khác nhau đấy!
  2. Phát triển Hướng Kiểm thử (Test Driven Development – TDD): Bạn đã biết phương pháp code này chưa? Nếu chưa, chớ ngại ngần trong việc đi tìm đối tác biết TDD, cùng lắm là sau 1 phiên làm việc (45′) là bạn TDD nhoay nhoáy thôi! Còn bạn đã thực hành TDD rồi, hãy thực hành nó hoặc dạy cho đối tác của mình về nó nhé. “Một người thạo, hai người vui” :o)
  3. Thiết kế Đơn giản (Simple Design): 4 quy tắc về Thiết kế Đơn giản bạn đã biết rồi chứ? Hãy thực hành nó nhé. Nếu không, chúng cũng không khó khăn để bạn tuân thủ đâu. Cứ đọc kỹ bên dưới là bạn sẽ rõ thôi. Bằng không, đối tác của bạn hoặc các facilitator sẽ giúp bạn hiểu và thực hành chúng.

Cặp nào, quy tắc ấy

Ngoài 3 quy tắc mà nhóm nào cũng phải tuân thủ ở trên, coderetreat còn định nghĩa một loạt các quy tắc khác để các nhóm sử dụng cho các phiên làm việc của mình. Những tuy tắc này là tùy chọn đối với mỗi nhóm, phụ thuộc vào mong muốn nhóm đó muốn rèn luyện kỹ năng\kỹ thuật nào trong lập trình. Dưới đây là danh sách các quy tắc tùy chọn này, đầu phiên làm việc nhóm thảo luận rồi chọn một hoặc một số trong những quy tắc này và tuân thủ chúng suốt phiên làm việc của mình.

  1. No conditional statements
  2. No loops
  3. No mouse
  4. No keyboard shortcut
  5. No naked primitives
  6. Paper only
  7. Text editor only
  8. Max 8|6|4 lines per method
  9. TDD as if you meant it
  10. Other

 

Tìm hiểu nhanh về CodeRetreat

,

Codetreat là gì?

“Retreat” đang là xu hướng. Nhiều người sẽ nghĩ đó là một cuộc trải nghiệm sự tĩnh tâm trong một tu viện. Các lập trình viên thì biết đến thuật ngữ CodeRetreat: Một hình thức học tập đã được thực chứng, nơi bạn tập trung toàn bộ thời gian, khả năng của mình cho việc viết và thiết kế ra những mã tốt mà không chịu áp lực của công việc thường ngày. Qua đó bạn có cơ hội cải tiến kỹ năng, nâng cao kiến thức của mình trong phát triển phần mềm – Bạn được làm điều này mà không bị vướng bận bởi các dự án hiện tại và các deadline bủa vây bạn hằng ngày.

Coderetreat là sự kiện thực hành lập trình chuyên sâu trong một ngày, các hoạt động trong sự kiện tập trung vào những nguyên tắc cơ sở của phát triển và thiết kế phần mềm. Bằng việc tạo cho các nhà phát triển cơ hội để tham gia thực hành có chủ ý, tránh xa những áp lực phải “làm xong hết mọi thứ”, format của coderetreat đã chứng tỏ nó có hiệu quả cao trong việc nâng cao kỹ năng. Luyện tập các nguyên tắc cơ sở của thiết kế theo mô-đun và hướng đối tượng, các nhà phát triển có thể cải thiện khả năng viết mã với chi phí tối thiểu cho sự thay đổi theo thời gian.

Coderetreat không phải là một cuộc hội thảo về công nghệ! Các quy tắc làm việc của sự kiện này hoàn toàn khác, người tham dự tích cực tham gia vào việc viết mã: thực hành rất nhiều, lắng nghe đôi chút.

Cha đẻ của CodeRetreat là Corey Haines, ông và một số bạn bè khác đã đưa ra ý tưởng này từ năm 2009. Bạn có thể tham khảo thêm các thông tin khác về Coderetreat trên trang web http://coderetreat.org

Tại sao tôi nên tham dự?

  1. Có cơ hội thực hành và học những nguyên tắc và kỹ năng căn bản\nền tảng của software craftsmanship (nghề thủ công phần mềm) như Thiết kế Đơn giản (Simple Design), Thiết kế Tiến hóa (Evolutionary Architecture\Emergent Design), Thiết kế Theo Mô đun (Modular Design), Phát triển Hướng Kiểm thử (Test Driven Development – TDD), Các nguyên tắc của OOP, Clean Code, Refactoring, v.v.;
  2. Được tham gia vào Thực hành có Chủ ý , tránh xa những áp lực của công việc thường ngày. Nâng cao kỹ năng của một thợ thủ công phần mềm và khả năng tạo ra các sản phẩm phần mềm có chất lượng cao, giảm thiểu chi phí thay đổi theo thời gian;
  3. Thoát khỏi áp lực deadline\dự án để thoải mái thử nghiệm những ý tưởng mới;
  4. Có cơ hội cải thiện tiến kỹ năng, nâng cao kiến thức của mình trong phát triển phần mềm;
  5. Được giao lưu học hỏi từ người khác, người có kinh nghiệm hơn và thể hiện mình;
  6. Cơ hội gặp gỡ và thảo luận với những thợ thủ công phần mềm cũng như những người quan tâm tới nghề thủ công phần mềm tới từ nhiều nơi trong một phạm vi rộng lớn
  7. Và hơn thế nữa… !

 

Chín thói quen xấu cần bỏ nếu muốn theo ngành CNTT

1. Không chịu đọc tài liệu trước khi dùng

Đây là một trong những thói quen tệ hại nhất nhưng lại thường gặp nhất. Có lẽ thói quen này nảy sinh từ tính thân thiện của “giao diện đồ hình” (GUI) khiến cho người dùng bồi đắp thói quen mò mẫm mà không cần đọc hướng dẫn nhưng cũng sử dụng được máy. Việc này không có gì đáng ngại đối với người dùng (rất) bình thường. Tuy nhiên, nếu bạn có ý định theo đuổi ngành CNTT một cách nghiêm túc thì hãy bỏ ngay thói quen tai hại này bởi vì đây là rào cản lớn nhất cho sự phát triển. Kiến thức vững chắc không phải… mò mà ra. Tài liệu hướng dẫn không phải vô cớ mà được viết ra.

2. Đọc lướt

Đây cũng là một thói quen tệ hại và phổ biến không kém. Ngay trên những diễn đàn, với những ý kiến và chỉ dẫn bằng tiếng Việt rất cô đọng, rành mạch và dễ hiểu nhưng vẫn có quá nhiều người chỉ đọc lướt để rồi quay lại tiếp tục thắc mắc. Đây là thói quen cực kỳ nguy hiểm bởi vì nó rèn cho trí não thói quen đọc lướt. Việc này dẫn đến chỗ kiến thức thu thập một cách hời hợt, tạm bợ và chắp vá. Nếu những ý kiến bằng tiếng Việt rất cô đọng, rành mạch và dễ hiểu nhưng vẫn không chịu khó đọc kỹ và suy gẫm thì việc tham khảo, tổng hợp các sách tiếng nước ngoài gần như là vô khả thi.

3. Bắt chước mà không suy nghĩ

Khi bắt đầu làm quen với những thứ trong ngành CNTT, cách dễ nhất là bắt chước làm theo từng bước. Nếu cứ nhắm mắt làm theo nhưng không hề suy nghĩ lý do tại sao mình làm như vậy, không thử đặt câu hỏi những gì xảy ra đằng sau những “bước” ấy thì không chóng thì chày sẽ tạo cho mình một thói quen tai hại: bắt chước không suy nghĩ không tư duy như một cỗ máy. Từ chỗ làm theo từng bước có sẵn mà không suy nghĩ đến chỗ biến thành thói quen thì khả năng nhận định và tư duy sẽ bị thui chột. Chẳng những vậy, thói quen này kiềm hãm sự thẩm thấu kiến thức xuyên qua hàng loạt những câu hỏi. Tự đặt câu hỏi chính là cách buộc trí não mình làm việc và là viên đá đầu tiên để dấn thân vào chỗ phát triển trí tụệ.

4. Sợ khó

Sợ khó tưởng chừng quá thông thường trên mọi lãnh vực nhưng trong lãnh vực CNTT thì thói quen “sợ khó” là thói quen giết chết ngay bước đầu làm quen và phát triển. Chẳng có ngành nghề thực thụ, đòi hỏi trí tuệ mà lại dễ dàng hết. Thói quen “sợ khó” biểu hiện từ chuyện đơn giản như học ngoại ngữ (để có thể tham khảo thêm tài liệu ngoại ngữ) cho đến chuyện tự mình đối diện với những khó khăn trong khi trau dồi kiến thức và kinh nghiệm. Thói quen này lâu dần ăn sâu và dẫn đến chỗ không muốn và không thể giải quyết được điều gì nếu chỉ cảm thấy có trở ngại. Nên tránh xa câu này: vạn sự khởi đầu nan, gian nan bắt đầu nản.

5. Viện cớ

Quá trình tích lũy kiến thức luôn luôn có những khó khăn và trở ngại. Nếu chính bản thân mình không tự kỷ luật và tự nghiêm khắc thì chẳng còn ai trên đời này kỷ luật và nghiêm khắc giúp mình. Từ chỗ không kỷ luật và không nghiêm khắc, chỉ cần một thời gian rất ngắn có thể dẫn đến sự đổ vỡ, sợ hãi, chán nản và để bào chữa cho sự đổ vỡ thường là những viện cớ. Viện cớ chỉ để ẩn nấp sau cái cớ nhưng sự thật sụp đổ vẫn tồn tại. Tránh xa những câu như “nhà em nghèo”, “hoàn cảnh khó khăn”, “vì em là newbie” mà nên biết rằng vô số những người khác cũng như mình và thậm chí còn khó khăn hơn mình. Nên nhớ rằng, ngay khi dùng cái cớ để viện thì lúc ấy mình đã chính thức thất bại rồi.

6. “Đi tắt đón đầu”

Trên đời này chẳng có loại tri thức đích thực nào hình thành từ “đi tắt” và “đón đầu” cả. “Mì ăn liền” có cái ngon của nó nhưng chính “mì ăn liền” không thể hình thành một bữa ăn thịnh soạn và đầy đủ. Tri thức đích thực cũng như thức ăn, nó cần điều độ, liều lượng và thời gian để… tiêu hoá. Tư duy và thói quen “đi tắt” luôn luôn dẫn đến những lổ hổng khủng khiếp trong kiến thức. Những lổ hổng ấy xem chừng không nhiều và không quan trọng khi kiến thức còn ít ỏi và nhu cầu công việc còn sơ khai. Tuy nhiên, một khi đối diện với những khó khăn và phức tạp trong công việc và trong đời sống thì những thứ “đi tắt đón đầu” là nguyên nhân sâu xa của những đổ vỡ và thất bại. Hãy nhớ: đừng đi tắt và đừng đón đầu bởi vì chẳng có cái đường tắt nào trong hành trình đi tìm tri thức.

7. “Nghe nói là…”

Cụm “nghe nói là…” là một cụm phổ biến đến độ chóng mặt. Bất cứ một ngành khoa học hay có liên quan đến khoa học không thể dựa trên “nghe nói” mà luôn luôn cần dựa trên các bằng chứng khoa học và những bằng chứng ấy cần chính xác và cụ thể. Chính vì có thói quen “nghe nói” mà đánh rớt những cơ hội tìm tòi và kiểm chứng; những cơ hội quý báu để trau dồi kiến thức và kinh nghiệm. Cái gì không rõ thì nên tìm tòi và đừng “nghe nói” mà phải được thấy, được phân tích và được kiểm chứng. Không bỏ được thói quen này thì cách tốt nhất đừng bén mảng gần bất cứ ngành khoa học nào vì chỉ chuốc lấy sự thất bại và lãng phí.

8. Niềm tin và hy vọng

Trong khoa học, khi nói đến kết quả và sự kiến tạo hoặc thậm chí con đường đi đến sự kiến tạo và kết quả thì hoàn toàn không có chỗ cho “niềm tin” và “hy vọng” một cách mù mờ. Thói quen “restart” lại máy hay “restart” lại chương trình với “hy vọng” nó sẽ khắc phục sự cố đã trở thành thói quen cố hữu. Nếu không có điều kiện thay đổi nào khác thì có “restart” một triệu lần và hy vọng một triệu lần thì kết quả vẫn y hệt nhau. Đừng “tin” và đừng “hy vọng” vào sự thay đổi của kết quả nếu như chính bạn không kiểm soát và thay đổi để tạo thay đổi trong kết quả. Tất cả mọi hoạt động từ lập trình cho đến quản lý hệ thống, quản lý mạng, bảo mật, reverse engineering…. thậm chí đối với người dùng bình thường, khi kết quả không như ý, sự điều chỉnh là điều cần thiết thay vì lặp lại y hệt hành động và chỉ… hy vọng.

9. Không vì trí tuệ mà vì… “đẳng cấp”

Lắm bạn lao vào ngành này không phải là vì trí tuệ, vì kiến thức, vì đóng góp một cái gì đó ích lợi cho xã hội mà là vì… đẳng cấp mơ hồ nào đó. Nếu tiếp tục lao vào và chọn lấy một muc tiêu mơ hồ thì sẽ không bao giờ đi đến đích được. “Đẳng cấp” là một thứ mơ hồ, vô ích và đầy cá nhân tính nhưng khi nó biến thành thói quen và mục tiêu để nhắm tới thì nó chẳng mang lại được gì ngoài sự thất bại ngay từ đầu vì hoàn toàn không có một phương hướng nào cả. Trau dồi kiến thức hoàn toàn khác với việc xoa dịu mặc cảm (“đẳng cấp”).

Nguồn : tapchilaptrinh.vn

“Cần dạy Agile càng sớm càng tốt!”

 

Nguồn nhân lực ngành IT vẫn luôn là câu chuyện nóng hổi suốt nhiều năm nay. Sáng nay AgileBreakFast được hân hạnh tiếp chuyện cùng anh Nguyễn Tuân, Giám đốc Đào tạo của FPT-Aptech Hà Nội xoay quanh công việc nuôi dưỡng nhân lực cho ngành phát triển phần mềm. Chúng ta sẽ cùng anh Tuân trao đổi những góc nhìn về Agile, Scrum, Lean và công việc đào tạo lập trình.

ABF: Xin chào anh Tuân, ABF rất hân hạnh được trò chuyện cùng anh về Agile, Scrum và đào tạo lập trình viên .

NT: Xin chào AgileBreakFast, tôi rất vui lòng. Agile và đào tạo lập trình luôn là niềm yêu thích của tôi.

ABF: Theo dõi các hoạt động của FPT-Aptech Hà Nội vài năm gần đây thì mọi người đều thấy các anh đang rất bền bỉ thúc đẩy giảng dạy, học tập và thực hành Agile. Vì sao vậy thưa anh?

NT: Chúng tôi nhận thấy việc học lập trình của các bạn sinh viên về cơ bản là tốt nhưng lại thường gặp vấn đề về kỹ năng làm việc nhóm. Trước khi đưa Agile vào giảng dạy và sử dụng trong các đồ án cuối kỳ của sinh viên, chúng tôi có áp dụng một số phương pháp truyền thống như Waterfall nhưng kết là sinh viên gặp rất nhiều vấn đề trong kỹ năng làm việc nhóm, quản lý dự án, phản ứng chậm với yêu cầu điều chỉnh và đặc biệt là hiệu quả thấp. Rất may là chúng tôi được cộng tác với các chuyên gia của Agile từ rất sớm, băt đầu từ khoảng giữa năm 2008.

ABF: Xin anh hãy kể ra những hoạt động nổi bật nhất được không?

NT: Chúng tôi đã 3 năm liên tiếp đồng hành cùng AgileVietnam.org tổ chức AgileTour tại FPT-Aptech trong các sự kiện thường niên. Rất nhiều các Workshop về Agile để đào tạo cho giảng viên và sinh viên được tổ chức. Sinh viên sẽ có nhiều trải nghiệp thực tế với Agile thông qua 4 Project trong suốt khoá học 2 năm.

ABF:Theo anh, tại sao những lập trình viên cần sớm được biết đến Agile?

NT: Nói đến lao động tức là nói đến năng suất hiệu quả công việc. Agile giúp cho tăng năng suất hiệu quả làm việc hiển nhiên càng biết sớm càng tốt.

ABF:Có người cho rằng học Agile rất khó, phải lập trình viên “già dơ” mới học được. Điều này có đúng không thưa anh?

NT: Tôi không nghĩ như vậy, trong giới Agile có một định nghĩa vui là ScrumBut để chỉ việc thực hành Scrum không chuẩn, hay sửa đổi quy tắc. Đối tượng hay ScrumBut nhất lại thường là đối tượng “già dơ”, vì họ đã trải qua một số các quy trình làm phần mềm nào đó và khá khó để có thể khiến họ tuân thủ đúng Scrum chuẩn. Với người mới học lập trình thì điều này ít xảy ra vì không bị ảnh hưởng bởi các yếu tố trên, do đó việc học Agile ở sinh viên còn thuận lợi hơn so với người đã có nhiều năm kinh nghiệm.

ABF: Các anh dạy Agile như thế nào?

NT: Sau khi kết thúc mỗi kỳ học(4 kỳ) sinh viên sẽ được làm dự án với các yêu cầu ngặt nghèo như một sản phẩm thật. Bài toán thật, khách hàng thật, môi trường thật và quy trình thì sử dụng Agile. Các sinh viên sẽ được chia nhóm từ 3-5 sinh viên một nhóm. Các nhóm sẽ được huấn luyện về Agile trước trong vòng 1 tuần, sau đó là áp dụng vào sản phẩm của các em. Trong suốt quá trình đó sẽ có sự đồng hành của giáo viên đóng vai trò là Product Owner, toàn bộ quá trình này là 1,5 tháng.

ABF: Anh nói là “quy trình Agile”, liệu cách nói này có khiến người khác hiểu nhầm Agile là “quy trình” không? Agile, ngoài quy trình còn là gì nữa?

NT: Vâng chính xác là các phương pháp của Agile, cụ thể là chúng tôi sử dụng Scrum Framework, như các bạn đã biết Agile có XP, Scrum, Lean Software Development, AgileUP, Crystal, FDD, DSDM… đều hướng tới yếu tố linh hoạt, hiệu quả làm việc, tinh giảm chi phí, giảm thiểu sai sót, gia tăng sự cộng tác. Chúng tôi sử dụng Scrum vì Scrum phù hợp với tiêu chí của chúng tôi là gọn nhẹ, linh hoạt, đề cao tinh thần teamwork và có thể hoàn thành tốt project trong thời gian ngắn.

ABF: Liệu sinh viên IT có thể tự học Agile mà thành thạo được không? Hay phải tham gia các nhóm dự án chuyên nghiệp?

NT: Cái khó nhất của Agile là thực hành, áp dụng vào sản phẩm chứ không chỉ hiểu và biết nên môi trường tốt nhất vẫn phải là các dự án thực tế, tất nhiên không nhất thiết phải là các nhóm dự án chuyên nghiệp. Nhưng điều quan trọng là cần có huấn luận viên tham gia cùng nhóm dự án.

ABF: Liên quan đến chuyện học lập trình, theo anh phải mất bao lâu thì một lập trình viên mới thạo nghề được?

NT: 10.000 giờ thực hành có chủ đích là con số tiêu chuẩn để trở thành chuyên gia. Tại FPT-Aptech sau 2 năm học có sự tập trung tốt các bạn sinh viên của chúng tôi có thể sẵn sàng làm việc tốt được.

ABF: Riêng Agile, phải mất bao lâu thì có thể thạo được các kĩ thuật cơ bản?

NT: Nếu được tiếp cận với Agile “chuẩn”, được huấn luyện với các chuyên gia của Agile và quan trọng hơn là được áp dụng thực tế có sự kèm cặp của huấn luận viên thì có thể chỉ sau một dự án là đã có thể thạo rồi.

ABF: Liệu có cần đến 10.000 giờ nữa để thành “nghệ nhân phần mềm” (software craftsman) không, thưa anh?

NT: Vâng tất nhiên rồi, mọi công việc đều cần có thời gian cần thiết để thẩm thấu, để tinh thông nghề. Gladwell đưa ra quy tắc 10 năm/10.000 giờ của một người làm nghề liên tục có chủ đích.  Quy tắc này có tác dụng ngay lập tức khi liên hệ với những người giỏi chuyên môn thực hành liên tục trong nghề của mình. Tuy nhiên không phải là cứ làm việc liên tục đủ 10 năm thì bạn sẽ trở thành nghệ nhân trong nghề đó, điều này khó có thể đạt được nếu anh làm một việc lặp đi lặp lại trong từng ấy năm. Nó đòi hỏi thêm năng lực tự học, học tập liên tục, học tập chuyên sâu để đạt được kỹ năng tinh thông về nghề nghiệp.

ABF: Nhưng Agile nó như kĩ năng mềm, trong khi công nghệ (ví như các nền tảng Java/.NET/iOS…) mới trực tiếp tạo ra sản phẩm. Vậy vai trò thực sự của Agile là gì?

NT: Đó chính là vấn đề mấu chốt của chúng tôi khi chưa áp dụng Agile tại FPT-Aptech. Sinh viên có kỹ năng thực hành tốt, nhưng thực tế thì hiệu quả làm sản phẩm, làm việc nhóm kém hiệu quả. Agile có khả năng linh hoạt tốt, việc điều chỉnh hoặc thay đổi trong sản phẩm theo yêu cầu của khách hàng hoàn toàn có thể đáp ứng tốt, bên cạnh đó hoạt động trong Teamwork gắn kết chặt chẽ, thông tin thông suốt rõ ràng. Không có điểm mù trong dự án hoàn toàn là white box chứ không phải black box như mô hình waterfall điều này giúp cho việc nhận diện vấn đề sớm để có phương án xử lý. Ngay cả với lập trình viên làm việc độc lập thì kỹ năng giải quyết vấn đề (problem-solving) là kỹ năng “mềm” quan trọng nhất, kỹ năng này đòi hỏi người lập trình viên phải có cái nhìn bao quát về vấn đề của bài toán rồi đưa ra các phân tích, đánh giá chi tiết, từ đó có được giải pháp tốt nhất.

ABF: Chúng tôi thấy xu hướng các bạn thích làm ra sản phẩm ngay, cả lập trình viên cũng vậy, chứ ít quan tâm tới những thứ mang tính “luyện công” như TDD, các kĩ thuật Refactoring, Design Pattern hay Scrum. Theo anh điều này có hại gì cho việc phát triển năng lực lâu dài của lập trình viên?

NT:  Điều chúng tôi chú tâm là thúc đẩy việc học tập liên tục cho sinh viên. Đây là năng lực quan trọng nhất để có thể thích nghi được với sự thay đổi của công nghệ. Ban đầu việc đạt được đến mức tạo ra sản phẩm với người lập trình viên mới là mức cơ bản. Nhưng về lâu dài nếu không đầu tư vào các kỹ thuật như bạn nói thì năng lực lập trình khó mà đạt đến độ “tinh hoa”, vì khi đã đi vào vòng xoáy làm việc, hết dự án này sang dự án khác thì điều kiện để đạt được kỹ năng “nghệ nhân” là rất khó. Giống như tôi đã nói ở trên thì quy tắc 10 năm/10.000 giờ của Glawell là phải thực hành có chủ đích.

ABF: Học Agile là để làm ra những sản phẩm sáng tạo, mang lại giá trị cho người dùng. Trong đó, có những giá trị có thể giúp cho người lập trình viên giàu có. Liệu chúng ta có nên khuyến khích các sinh viên khởi nghiệp từ sớm không?

NT: Nên khởi nghiệp càng sớm càng tốt kể cả là 99,9 % khởi nghiệp là thất bại thì giá trị bạn học dược, kinh nghiệm và 0,1 phần trăm thành công là giá trị vô giá mà bạn đạt được.

ABF: Liệu thất bại có đáng sợ không, dễ vượt qua không?

NT: Khi bạn làm một việc với sự quyết tâm cao nhất, tâm huyết nhất, kỳ vọng vào sự thành công và tiêu đến những đồng tiền cuối cùng của mình, thậm chí nợ nần; thì sự thất bại hiển nhiên là đáng sợ chứ! Tuy nhiên điều đó còn tuỳ thuộc rất nhiều vào sự nhìn nhận của mỗi nhóm phát triển, mỗi cá nhân. Nếu có sự phân tính, đánh giá, để giúp tìm ra vấn đề của sản phẩm từ đó điều chỉnh để có được sự chuẩn bị tiếp theo tốt hơn thì không có gì đáng sợ cả :).

ABF: Thế mà giới khởi nghiệp lại có khẩu quyết “Fail Fast, Fail Often” (thất bại sớm, thất bại thường xuyên)?

NT: Lean Startup khuyến khích việc làm quen với thất bại sớm, từ đó giảm thiểu nỗi lo sợ thất bại. Chuẩn bị cho sự thất bại để từ bài học thất bại dẫn đến bài học thành công.

ABF: Liệu học Lean Startup có giúp gì cho sự khởi nghiệp của sinh viên IT không?

NT: Rất cần thiết! Lean Startup hiện giờ là cách tốt nhất để phát triển ý tưởng mới và là phương thức giúp cho các bạn sinh viên sớm tìm ra các rủi ro các vấn đề nhận định sai lầm của mình về thị trường để từ đó có được sự chuẩn bị tốt hơn. Điều cốt lõi của Lean Startup là giúp đưa nhanh sản phẩm ra thị trường, từ đó có thể đo đạc được hiệu quả tính khả thi và cải tiến. Điều này sẽ tiết kiệm được chi phí thời gian và tiền bạc.

ABF: Anh ấn tượng gì về hiện tượng Hà Đông FlappyBird? Liệu những ấn tượng Hà Đông có tác động gì vào đội ngũ nhà giáo IT không?

NT: Hiện tượng Hà Đông như một minh chứng rõ ràng cho thấy rằng lập trình là cơ hội rất lớn để chúng ta có thể chơi ngang ngửa với các bạn lập trình viên khác ở các nước có công nghệ thông tin phát triển. FlappyBird đã trở thành huyền thoại không chỉ ở Việt Nam còn là hiện tượng của cả thế giới làm Game di động, không quá lời khi nhiều hãng báo chí nói rằng Hà Đông đang dạy lại thế giới cách làm game di động. Tôi nghĩ là có tác động khá tích cực đến giảng viên IT, tạo ra sự phấn khích trong nghề là điều rất quan trọng đối với chúng tôi nó truyền cảm hứng đến sinh viên của mình.

ABF: Liệu việc đưa Agile vào đào tạo sớm trong nhà trường, cùng với cơ chế khuyến khích startup có góp phần tạo thêm nhiều câu chuyện FlappyBird nữa không?

NT: Tôi cho là có.

ABF: Gần đây có hai sự kiện đáng chú ý: doanh nghiệp có tiếng rời bỏ Việt Nam là Atlassian và eXo Platform. Một số cho rằng nguyên nhân là do thiếu vắng nhân lực chất lượng cao? Anh đánh giá điều này như thế nào?

NT: Tôi không rõ chính xác nguyên nhân chính là gì! Nhưng nhân lực chất lượng cao đúng là chúng ta đang thiếu, thiếu rất nhiều. Việc đào tạo nhân lực CNTT hiện nay của chúng ta chưa chú trọng nhiều vào việc đào tạo nhân lực chất lượng cao, chưa trang bị cho họ nhưng kỹ năng để có thể thích nghi và ứng biến với sự thay đổi nhanh chóng của công nghệ. Với các công ty phần mềm cũng vậy, họ chưa chú trọng nhiều đến việc xây dựng văn hoá học tập, khuyến khích nhân viên phát triển năng lực cá nhân. Một loạt các vị trí nhân lực chất lượng cao bị bỏ trống ở các công ty phần mềm phần nào nói lên điều này.

ABF: Agile có thực sự là một cơ hội tốt để nâng tầm tay nghề chuyên viên phát triển người Việt không?

NT: Agile là cơ hội rất tốt cho việc phát triển tay nghề, tôi nghĩ khá nhiều người, nhiều công ty đã nhìn ra hiệu quả của nó. Theo dõi trong vài năm trở lại đây các sự kiện AgileTour, ScrumDay, CodeRetreat tôi thấy số lượng các CTO, CEO, các lập trình viên tham dự càng ngày càng đông. Cộng đồng Agile tại Việt Nam hoạt đông rất tích cực, có thể nói Agile không còn là khái niệm quá xa lạ không chỉ các công ty công nghệ mà còn ở các công ty về y tế, giáo dục, truyền thông. Tôi có một anh bạn làm cố vấn Marketing tại một tập đoàn đa ngành nghề đã áp dụng Agile Marketing trong công việc và thu được là rất tốt. Hiện tại doanh nghiệp bên anh ấy làm việc rất Agile.

ABF: Anh là một giảng viên có hơn 10 năm dạy lập trình, chắc hẳn có nhiều sinh viên đáng nhớ. Anh có thể kể ra một trường hợp sinh viên nào mà anh rất ấn tượng về cách lĩnh hội các công nghệ và tri thức mới không?

NT: Tôi nhớ một bạn sinh viên khá cá biệt. Học hành nói chung là chểnh mảng. Nhưng lại có ưu điểm là tiếng Anh rất khá, nghe nói điểm IELTS cao lắm, thực tế thì giỏi thật.  Tôi nói với cậu ấy là em đã có một lợi thế rất lớn mà rất nhiều các bạn khác mới chỉ ở xuất phát điểm thôi. Tôi có đưa cho cậu ấy một cuốn eBook là tài liệu đọc thêm và giao cho nhiệm vụ cộng tác với một bạn học khá trong lớp dịch 1 chương trong nội dung bài học sắp tới để chia sẻ với các bạn trong lớp, khuyến khích trình bày bằng Powerpoint. Kết quả khá tốt, được các bạn và thầy giáo khuyến khích, bạn ấy hăng hái nhận dịch luôn vài chương nữa. Điều tôi rất vui là cuối cùng đó lại là một trong nhưng sinh viên rất triển vọng. Giờ cậu ấy đang làm bên Mỹ, hài lòng với lựa chọn của mình. Tôi vẫn thường đưa ví dụ này ra nói với các bạn sinh viên khoá sau, bên cạnh những yếu tố quan trọng khác, thì Tiếng Anh phải học cẩn thận, coi như là điều kiện cần để giúp bản thân nâng cao tri thức, tiếp cận với thế giới công nghệ dễ dàng hơn.

ABF: Xin anh cho biết là việc liên tục đuổi theo những sự phát triển của IT  có khiến các giảng viên mệt mỏi không?

NT: Chúng tôi không đuổi theo mà chúng tôi đón đầu công nghệ nên không thể nói là mệt :D. Trong ngành IT của chúng tôi chuyển động đều là tụt hậu rồi. Làm việc và giảng dạy trong ngành IT có thể coi là một cơ hội rất tốt để tiếp cận “sớm” với tri thức mới, nên đó lại là lợi thế của giảng viên IT.

ABF: Nhân câu chuyện về Agile, anh có nhắn gửi gì tới những sinh viên của mình không?

NT: Tôi vẫn thường nói với các bạn sinh viên của mình học tập là một quá trình lâu dài và liên tục. Ngay cả khi các em đã đi làm thì tinh thần này vẫn phải duy trì. Đó là một việc không dễ đòi hỏi sự kiên trì, cần nhiều các hạnh động cụ thể để thích nghi và duy trì. Với sự thay đổi nhanh chóng của công nghệ, thì những thứ là số một của ngày hôm nay có thể là tối thiểu của ngày mai. Nên khả năng thích nghi và nâng cấp bản thân để phù hợp với các quy trình, công nghệ… là rất quan trọng.

ABF: Xin cảm ơn anh!

Nguồn : tapchilaptrinh.vn

Việt Nam đang rất cần nhân lực Agile

Agile là một trong những chìa khóa cho sự thành công của các doanh nghiệp CNTT trên toàn cầu. Việt Nam mới chỉ bắt đầu hội nhập với xu thế này, nhưng đang thiếu nhân lực trầm trọng.

Trong hơn một thập kỉ đầu thế kỉ XXI này, ngành CNTT đã có những bước chuyển mình mạnh mẽ. Song hành với đó là sự đổi mới phương pháp quản trị và sản xuất theo hướng Agile/Scrum hiện đại. Kinh nghiệm trên thế giới cho thấy, việc chuyển đổi phương thức làm việc sang Agile/Scrum đóng vai trò quan trọng trong gia tăng năng suất lao động, tăng hiệu quả dự án và đổi mới sáng tạo.

Báo cáo CHAOS của Standish Group năm 2015 chỉ rõ, Agile có thể giúp tỉ lệ thành công của các dự án tăng gấp ba lần so với phương thức hoạt động truyền thống. Năng suất nhóm Agile có thể tăng từ 3-7 so với các nhóm truyền thống. Những sản phẩm công nghệ đột phát ngày nay hầu như đều được làm ra từ những nhóm Agile đầy đam mê và sáng tạo.

Agile là một cách gọi vắn tắt những phương pháp làm việc (như Scrum, Kanban, hay eXtremeProgramming), quản lí và phát triển sản phẩm dựa trên những nguyên lí được mô tả trong Tuyên ngôn Phát triển phần mềm Linh hoạt với chủ trương nhấn mạnh tính sáng tạo của cá nhân và nhóm, chuyển giao sớm giá trị cho người dùng, cộng tác chặt chẽ giữa các bên liên quan và thích ứng tốt với sự thay đổi của môi trường. Những nguyên lí này không có mục đích gì hơn là định nghĩa một “văn hóa” làm việc mới, với sự ưu tiên cho cộng tác, làm việc nhóm hiệu quả, hướng-giá-trị, để tạo lập và duy trì sự linh hoạt (Agility) cho mỗi tổ chức nhằm gia tăng lợi thế cạnh tranh bền vững trong nền kinh tế sáng tạo thế kỉ 21.

Nhiều doanh nghiệp trên toàn cầu đã và đang dịch chuyển mạnh mẽ sang Agile/Scrum, từ các gã khổng lồ Google, Facebook, Microsoft tới những startup còn đang chuẩn bị gây dựng tên tuổi. Theo nghiên cứu của VersionOne năm 2014, đã có 94% các tổ chức ở khu vực Âu Mĩ được khảo sát cho biết là đã phần nào đó sử dụng Agile trong công việc.

Tại Việt Nam, nhiều tên tuổi lớn như FPT, Viettel, VNG hay những doanh nghiệp nhỏ mới khởi sự cũng đã sớm bắt kịp xu thế áp dụng Agile/Scrum. Cộng đồng AgileVietnam cũng đã ghi nhận hàng trăm công ty đang nỗ lực chuyển đổi phương thức phát triển phần mềm sang Agile/Scrum. Nhìn nhận chung của giới chuyên gia và lãnh đạo các doanh nghiệp phần mềm Việt Nam là rất ủng hộ trào lưu này. Ông Đỗ Văn Khắc, Phó Tổng giám đốc FPT Software nhận định: “Agile có thể rút ngắn thời gian chuyển giao sản phẩm, dễ dàng thay đổi tính năng để đáp ứng nhu cầu của thị trường. Ở Việt Nam thì còn mới, chứ trên thế giới thì CNTT không thể không dùng Agile“. Đứng ở góc độ đào tạo nhân lực, ông Nguyễn Tuân, Giám đốc Đào tạo của FPT Aptech thì cho rằng: “Để cập nhật với công nghệ phát triển mới hiện nay, chúng ta cần phải dạy Agile trong các trường CNTT càng sớm càng tốt”. Ông Phạm Anh Đới, huấn luyện viên Scrum tại Học viện Agile, một chuyên gia của ScrumAlliance (Certified Scrum Professional) nhấn mạnh thêm về vai trò của việc đào tạo: “Một trong những điều đảm bảo thành công cho việc triển khai Agile/Scrum cho doanh nghiệp là tham dự các chương trình đào tạo chuyên nghiệp. Nhiều người tham dự các khóa học Certified ScrumMaster mà tôi biết tại Hà Nội, Tp.Hồ Chí Minh và Đà Nẵng đang có những đóng góp rất tích cực vào sự phát triển của các doanh nghiệp, và sự nghiệp cá nhân cũng đang có những bứt phá đáng chú ý”.

Sự chuyển dịch phương thức làm việc kéo theo nhu cầu về nhân lực Agile/Scrum lên cao trong những năm trở lại đây. Theo khảo sát “Các kỹ năng và mức lương ngành công nghệ thông tin năm 2015” của hãng đào tạo hàng đầu thế giới Global Knowledge, chứng chỉ Certified ScrumMaster (CSM) nằm ở vị trí thứ 6 của Top 10 kĩ năng được trả lương cao nhất. Đây là chứng chỉ do hiệp hội Scrum quốc tế Scrum Alliance cấp thông qua chương trình đào tạo chất lượng cao trên quy mô toàn thế giới. CSM chứng nhận những chuyên gia Scrum/Agile đủ kiến thức và kinh nghiệm để triển khai phương pháp phát triển phần mềm hiện đại Scrum cho công ty nhằm đạt được hiệu suất cao, chất lượng sản phẩm đột phá. Hiện nay, thành viên có chứng chỉ này của Scrum Alliance đã đạt gần 350 nghìn người và đang tiếp tục tăng nhanh. Nhiều người sở hữu chứng chỉ này không chỉ có ưu thế về thu nhập, mà còn phát triển nhanh và bền vững nấc thang nghề nghiệp trong ngành CNTT.

Nhu cầu Agile là rất lớn, nhưng nguồn cung nhân lực chất lượng cao về Agile/Scrum tại Việt Nam hiện nay lại rất khan hiếm. Ông Dương Trọng Tấn – Giám đốc Học viện Agile, một đơn vị đào tạo Agile tiên phong tại Việt Nam, cho biết: “Nhu cầu nhân lực Agile nói chung, ScrumMaster nói riêng hiện nay tương đối lớn. Tuy nhiên ScrumMaster chuyên nghiệp thì vô cùng thiếu vì thiếu vắng các đơn vị đào tạo chuyên nghiệp. Hiện nay chủ yếu nhân lực là do các doanh nghiệp tự đào tạo. Nhiều công ty thân thiết của chúng tôi có đặt vấn đề giới thiệu ScrumMaster tại Hà Nội và Tp.Hồ Chí Minh nhưng chúng tôi thường phải nói lời xin lỗi. Hơn bao giờ hết, chúng ta cần một lực lượng ScrumMaster đủ đông và đủ mạnh để đáp ức khả năng phát triển cao của ngành. Chúng tôi đang phải nỗ lực hết mình để cung cấp nhân lực Agile chất lượng cao cho các đối tác”.

lớp đào tạo scrum của học viện agile tại hà nội

Một lớp đào tạo Scrum của Học viện Agile tại Hà Nội

Việt Nam đang mong muốn vươn mình trở thành nước mạnh về công nghệ thông tin. Nhiều dự án và phong trào đang muốn biến Việt Nam thành quốc gia khởi nghiệp tiếp theo. Để điều đó trở thành hiện thực, chúng ta cần có thêm nhiều chuyên gia CNTT tiếp cận tốt với công nghệ mới, kiến thức chuyên sâu để thực sự đương đầu với thách thức và nắm bắt những cơ hội phía trước. Agile là một xu thế không thể bỏ qua vào lúc này.

Nguồn : tapchilaptrinh.vn

ScrumMaster, cái tay này làm việc gì?

ScrumMaster không quản lí nhân sự, không quản lí tiến độ, cũng chẳng quản lí công việc được gán cho ai, càng không quản lí tiền bạc, hay yêu cầu. Vậy thế cái tay này làm cái gì?

Trong những lớp học tôi dạy về Scrum, phần nhiều học viên cứ nghĩ là ScrumMaster chẳng có việc gì để làm. Nên trong các ý kiến thảo luận, họ thường để một ai đó – như Product Owner, hay Developer, Tester. – kiêm nhiệm. Cực chẳng đã mới để một người làm ScrumMaster độc lập, vì sợ tốn rì-suộc (resource) hehe.

Kì thực thì có vài ScrumMaster mới nhận cái công việc này sẽ thấy ngập lụt, “ôi sao nhiều việc thế”, “thế này thì làm sao nổi” hehe..

Vậy thì hằng ngày cái vị ScrumMaster này làm những gì? Xin liệt kê ra đây vài cái bạn xem có nhiều không nhé:

1. Tổ chức các cuộc họp

Chả có mô hình làm việc nào lại có lắm kiếu họp thế: Họp kế hoạch, Họp sơ kết, Họp Cải tiến, Họp viết Yêu cầu, Họp Scrum Hằng ngày, rồi đủ các kiểu họp đột xuất khác. ..

Đó là cấu thành rất cơ bản để vận hành cơ chế Thanh tra – Thích nghi. Thực ra chúng không phải là “họp” theo nghĩa truyền thống, mà là thời gian cộng tác. Giữ cho các  cuộc họp này đầy đủ, đúng giờ và hữu ích không hề là việc dễ.

2. Chọc ngoáy liên tục (còn gọi là thanh tra quy trình)

Giữ “con mắt cú vọ” trên tất cả các phương diện của dự án, ScrumMaster sẽ phải dùng hàng tá các câu hỏi để phát lộ vấn đề, phát lộ ý tưởng, để giúp nhóm nhanh chóng đạt được mục tiêu Sprint.

Để “quan sát” ta có thể bắt đầu với:

  • Mình có nhìn thấy taskboard không?
  • Khách hàng có biết việc gì đang diễn tra trên bảng không?
  • Có gì được cập nhật từ hôm qua đến nay không?
  • Có nhìn thấy burndown\burnup không?
  • Có điểm nào bất thường trên burndown chart không?
  • ….

Để điều tra, “đào bới” thêm, ta có thể dùng các câu hỏi Socratic:

  • Tôi nhận thấy <tình huống>, chúng ta sẽ làm gì?
  • Tôi quan sát thấy <tình huống>, nó có quan trọng không?
  • Tôi thấy <cảm giác>, bạn có thấy điều đó?
  • Chúng ta sẽ cố tìm lý do của <tình trạng>?
  • Bạn nghĩ chúng ta cần làm gì?
  • Ai có ý tưởng gì về <tình trạng>?
  • Điều này có hiệu quả không?
  • Bạn đã quyết định điều gì?
  • Bạn nên làm gì [với tình huống\vấn đề này]?

Danh sách câu hỏi loại này có thể nối dài thêm nữa, phục thuộc vào bối cảnh, sự phức tạp và khả năng thanh tra của ScrumMaster. Tuy vậy, việc này rất mất thời giờ, mất năng lượng và đòi hỏi cả cơ bắp lẫn trí tuệ.

Để điều tra nguyên nhân của vấn đề, ScrumMaster còn phải thành thạo và liên tục sử dụng 5WHYs (Hỏi 5 lần tại sao) để tìm ra cách thúc đẩy nhóm tiến lên.

3. Loại bỏ trở ngại

Nếu như phần (2) chỉ với mục đích “bới bèo ra thật nhiều bọ” (thật nhiều vấn đề của nhóm) thì cái thực sự mà ScrumMaster quan tâm là đầu tư công sức để loại bỏ các trở lực đó. Qua đó giúp nhóm hiệu suất hơn, nhanh chóng đạt được mục tiêu Sprint.

Vấn đề thì muôn hình muôn vẻ, cho nên việc này cũng muôn hình muôn vẻ. Mà có nhóm làm việc nào thực sự lại ít vấn đề? Cho nên ScrumMaster sẽ luôn chân luôn tay. Thậm chí không kiểm soát nổi vấn đề nếu không có phương pháp làm việc khoa học.

4. Tìm kiếm cải tiến

  • ProductOwner của tôi làm việc thế nào?
  • Nhóm Phát triển đang làm việc thế nào?
  • Các kỹ thuật đang được dùng thế nào?
  • Tổ chức đang làm việc ra sao?
  • Ai cần được huấn luyện về cái gì?
  • Quy trình có dư thừa cái gì không?
  • Có thể mua sắm hay làm mới công cụ gì để tăng năng suất và gia tăng không khí vui vẻ không?

Đó là vài câu hỏi thường trực. Cải tiến là thứ cần phải làm liên tục, chứ không phải đợi đến buổi họp Cải tiến Sprint mới động não. Trong khi Developer, ProductOwner bận rộn với công việc của họ, thì ScrumMaster sẽ phải âm thầm nhưng chăm chỉ nghiên cứu, phân tích và tìm ra các cải tiến để hỗ trợ nhóm.

5. Huấn luyện (Coaching) Scrum cho nhóm

Ở những nhóm mới làm việc kiểu Scrum, mọi người thường chưa nắm rõ các quy tắc (dù ít ỏi) và ràng buộc của Scrum, nên có thể mắc sai lầm. Nhiệm vụ của ScrumMaster là giúp các thành viên hiểu rõ, thực hành tốt và gặt hái thành công từ Scrum. Mà việc này thì phải theo sát, không thể lơ là.

Trong nhiều trường hợp, ScrumMaster còn phải chịu trách nhiệm tổ chức các “community of practices”, xây dựng và bảo trì kho tri thức Agile cho các thành viên của nhóm và trong phạm vi rộng hơn.

Không thể có Agile mà không có học tập. Nên việc này rất tiên quyết. À, thế nhưng bạn có biết việc học diễn ra bao lâu chưa? Bạn đã nghe con số 10.000 giờ thực hành có chủ đích liên tục chưa?

Trong cấu hình của Nhóm Scrum, có một tay có thể rất lười nhác, nhưng lại có quyền lực lớn là ProductOwner hoặc khách hàng. Tay này có khi chỉ chầu chực là phá hỏng luồng làm việc của nhóm với những bug cần fix gấp, hay những tính năng tuyệt cú mèo “anh vừa mới nghĩ ra”. Cần phải huấn luyện Scrum cho tay này để anh em phối hợp nhịp nhàng. Đấy cũng là nhiệm vụ rất mệt nhọc của Scrum Master.

6. Chụp ảnh, quay phim, ghi ghi chép chép, dán dán dính dính

Mấy việc này không có tên, nhưng nó là những việc quan trọng không kém.

ScrumMaster có đôi mắt cú vọ để thanh tra mọi thứ, nhưng lại có một bộ nhớ của con người. Mà cái này dung lượng vừa bị giới hạn, lại có tính chất phần nhiều giống như RAM chứ không như ROM. Vậy nên phải thu thập dữ liệu, phân loại để chuẩn bị phân tích.

Không có dữ liệu thực tế, quyết định cải tiến có thể sẽ không phát huy tác dụng.

Mà mấy cái việc không tên này, cũng giống như mấy việc nội trợ ở nhà ấy; chẳng thể gọi là gì, nhưng thử mó tay vào mà xem, “đi đời” vài tiếng như chơi đấy.

7. Động viên, hỗ trợ nhóm

Bản thân công việc loại bỏ trở ngại cho nhóm đã là một lực thúc đẩy nhóm tiến lên. Tuy vậy, đôi khi ScrumMaster còn phải làm nhiều hơn nữa. Động viên, thử thách, thúc đẩy nhóm Scrum cũng là công việc quan trọng của ScrumMaster.

Hôm nay mình đã làm điều gì để khiến ai đó được “kích hoạt” không?

Hôm nay mình làm cho\tạo điều kiện cho ai làm cho nhóm vui vẻ không?

Có trò gì để khiến những chú “trâu ” kia thư giãn một chút không?

v.v.

8. Thôi , bạn thêm giúp tôi vào danh sách này nhé, còn dài lắm. Vả lại tôi có phải là ScrumMaster của các bạn đâu, nên làm sao biết được là sẽ cần phải làm những gì nữa?

Mời bạn điền tiếp!

Dương Trọng Tấn 

Nguồn : tapchilaptrinh.vn