Useful tools for your works / Một số công cụ hữu ích (phần 3)

Giới thiệu

Tiếp theo phần 2, chúng ta tiếp tục giới thiệu một số công cụ tiện lợi cho việc trao đổi trong dự án (công nghệ thông tin/phát triển phần mềm) trong phần 3 này.

Các công cụ hữu ích (phần 3)

mRemoteNG

Phần mềm nguồn mở, miễn phí, fork từ mRemote, quản lý kết nối remote, hỗ trợ nhiều giao thức hiện đại đủ dùng trong công việc như: VNC, SSH, sftp. Quản lý/hiển thị nhiều connection bằng tab, có thể lưu các thiết lập quản lý và mở lại bằng click đơn giản.
Khá nhiều shortcuts cho advance users.

Mindmap/freemind

Mindmap là "bản đồ tư duy", giúp việc suy nghĩ và suy luận rõ ràng, mạch lạc, đơn giản hơn, làm cho việc giải quyết vấn đề nhanh hơn, dễ dàng nhận ra nguyên nhân, kết quả, kết luận, các yếu tố liên quan.

LibreOffice

Bộ công cụ văn phòng miễn phí là mở, là bộ công cụ chuẩn, được khuyến nghị, thậm chí bắt buộc thay thế sử dụng M$ Office của Việt Nam và châu Âu.

Những chắc năng mà LibreOffice cung cấp đủ dùng trong công việc (phát triển phần mềm) hàng ngay. Calc thay thế Excel, Impress thay thế PowerPoint, Writer thay thế Words.

LibreOffice hiện chỉ có thể dùng offline, khác với M$ Office 365.

Nên sử dụng LibreOffice kết hợp với bộ phần mềm văn phòng online như Google Drive/Docs/Sheets/Slides/Forms.

Chức năng convert văn bản (sang/từ PDF), macro trong Calc khá mạnh.

Firefox

Trình duyệt thân thiện cho người phát triển phần mềm web. Theo cá nhân tôi, Firefox thân thiện với web developers hơn là Chrome. 

Khá nhiều extension Firefox giúp việc phát triển web thuận tiện hơn như: 

1. Firebug: Debug HTML/web app
2. Web Developer: Bộ công cụ phân tích, validate tối ưu mã nguồn, chỉnh sửa CSS,  
3. YSlow: Phân tích hiệu năng, tìm ra bottleneck, 
4. Greasemonkey: Tự động hóa tác vụ, 
5. JSONView: Xem JSON ở dịnh dạng đẹp hơn, 
6. FireShot: Chụp màn hình, dùng cho cả tester và developer, 
7. JS Deminifier: Formatting lại JS cho đẹp, 
8. RESTClient: Debug web service, 
9. IE Tab: Kiểm thử IE browser ngay trên Firefox, 
10. github extension, 
11. selenium*

SumatraPDF

Xem PDF file, nhẹ, miễn phí

Unikey.orghttp://www.unikey.org/

Gõ tiếng Việt. Hỗ trợ macro để gõ nhanh.

Chú ý: unikey.vn không phải website/nguồn chính thức của tác giả Unikey.

Google Japanese IME

Gõ tiếng Nhật, có thể định nghĩa macro (để gõ nhanh).

Auto-completion tự học từ hành vi của người dùng, theo tần suất sử dụng.

Giúp việc gõ tiếng Nhật nhanh và chính xác hơn đáng kể (có thể vài chục lần)

Google Chrome awesome screenshot extension

Chụp màn hình. 

Trên Windows, có thể dùng thêm greenshot (xem thêm:"những công cụ hữu ích trong công việc, phần 1")

Google Apps/Drive (Windows/Android/iOS)

Chia sẻ file trên mạng, có thể xem, sửa file trên hầu hết các thiết bị phổ biến do hỗ trợ cả Windows OS, Android, iOS.

Chú ý: Google Apps trên Windows tốt hơn hẳn Google trên các thiết bị khác. 

Chỉ nên làm việc với Google Apps trên PC/Windows (sẽ được hiệu suất cao hơn)

Việc review/đọc tài liệu trên các thiết bị cầm tay trên nền tảng Android/iOS khá thuận tiện.

Google Docs

Chức năng mạnh: Review/comment mode. Thao tác trên hầu hết các thiết bị. Export và import từ/vào nhiều định dạng khác nhau như .odt, .pdf, .txt, .rtf.

Google Sheets

Có thể hoàn toàn thanh thế M$ Excel hay LibreOffice.

Collaboration theo thời gian thưc, gõ tới đâu nhìn được tới đó từ trình duyệt khác.

Nhiều người có thể dùng edit được một file, một sheet, nhiều cell trên cùng một văn bản.

Console indicator rất tiện vì ta biết ai đang làm gì, ở đâu.

Google Calendar

Tạo reminder, goal ("mục tiêu": chức năng mới) và lịch (họp, đi chơi).

Nhắn/thông báo qua email, thêm người vào calendar theo email.

Dự định tiếp theo

Chúng tôi sẽ trình bày rõ hơn các chức năng nổi bật của Google Apps sử dụng trong công việc

Closing a Project: What you need to do as a Project Manager

Tình huống

Bạn là một project manager (PM) (hay Scrummaster (SM)) được điều động vào một dự án phát triển (phần mềm) thay thế PM/SM cũ.

Dự án đang ở giai đoạn cuối. Theo báo cáo từ PM/SM cũ, dự án "gần xong, một chút nữa là xong", nhưng một số cái (deliverables, specs, requirements...) không thể "chốt" hay close được với khách hàng. Mục tiêu được giao từ cấp trên là close dự án này càng sớm càng tốt để giải phóng (bớt) nhân sự, không để dự án dai dẳng, tốn công, tốn của và tốn thời gian.

Với tư cách là PM/SM, bạn nên/phải làm gì?

Dự án đang ở đâu?

Trả lời câu hỏi này để biết được hiện trạng của dự án. Một số câu hỏi cần đặt ra

1. Dự án cần làm những gì? 
1. Schedule/WBS (Work Breakdown Structure) ở đâu, đã làm được gì?
2. Product backlog/sprint backlogs ở đâu, đã làm được gì?
2. Những gì (chức năng/user story) đã hoàn thành? Những gì chưa hoàn thành? Những gì đang "treo" (đang được confirm)? Nên trả lời riêng câu hỏi này.
3. Dự án đang trong phase nào? (yêu cầu, thiết kế, lập trình, kiểm thử đơn vị, kiểm thử tích hợp, deploy, tạo tài liệu,...). Một số chức năng có thể ở phase này, hoặc ở phase khác. Cần liệt kê cụ thể.
4. Đầu vào của dự án gồm những gì? (tài liệu yêu cầu, user stories, thiết kế, nếu có)
5. Đầu ra của dự án gồm những gì? Đã làm được gì? Trạng thái (being confirmed, being reviewed, done...)
6. Kế hoạch và trạng thái (schedule, burndown chart)
7. 
   

Vấn đề của dự án là gì?

Cần họp toàn team, lắng nghe thông tin từ tất cả những người liên quan.

Risk và issue log là hai tài liệu quan trọng nhất cần có. Với những dự án quản lý kém, hai tài liệu này thường không tồn tại hoặc quản lý kém. Đặc biệt, với dự án không chạy tốt theo khung Scrum, thường hai tài liệu này không tồn tại và cần được tạo lại.

Lưu ý rằng trong danh sách issue log không chỉ chứa các vấn đề kỹ thuật mà cần bao gồm cả danh sách các vấn đề về nhân sự, communication, yêu cầu, thiết kế, kỹ thuật, năng lực của cả nhóm.

Cận biên tích hợp của dự án

Xác định những hệ thống, chức năng có tích hợp, liên kết với dự án chúng ta tiếp quản. 

Một pattern hay thấy ở các  dự án phần mềm là, từng module đơn lẻ đã hoàn thành nhưng phần tích hợp các module đó trong phạm vi nội bộ do nhóm phát triển đảm nhận không được ý thức tới, chưa làm, hoặc làm nửa vời, không có issue log.

Một pattern khác hay thấy hơn là phần tích hợp hệ thống/phần mềm chúng ta tiếp quản với hệ thống bên ngoài làm chưa tốt. Với phần này, cần xác định các hệ thống liên quan, những người chịu trách nhiệm (đầu mối) của các dự án đó, họp và xác định trạng thái, công việc tồn đọng, issue list.

Tiếp theo phải là gì?

Sau khi đã tiến hành ba bước trên, cần refine lại danh sách công việc còn lại cần làm, tạo schedule/WBS hay masterplan cho các sprint tiếp theo. Trả lời câu hỏi: Cần khoảng bao nhiêu thời gian (và tiền) (ở mức high level) để hoàn thành nốt công việc tồn đọng. Nếu tốt hơn, nên tạo plan cho từng sprint ở mức high level.

Tiếp theo phải là gì?

Tiến hành dự án theo cách thông thường mà bạn, với tư cách là PM/SM nghĩ là hợp lý để hoàn thành dự án với mức độ tự tin và quyết liệt cao nhất. Luôn chú ý tới communication và risk (là hai yếu tố khá "cao cấp" với PM/SM non tay)

Kết luận

Theo kinh nghiệm cá nhân, việc xác định issue log và các hệ thống cận biên cần tích hợp tới là các điểm nóng cần làm để có thể close được dự án.

Useful tools for your works / Một số công cụ hữu ích (phần 2)

Giới thiệu

Tiếp theo phần 1, chúng ta tiếp tục giới thiệu một số công cụ tiện lợi cho việc trao đổi trong dự án (công nghệ thông tin/phát triển phần mềm) trong phần 2 này.

Các công cụ hữu ích (phần tiếp theo)

Slack

Slack là công cụ chat tương tự chatwork. Có lẽ slack thích hợp hơn với dân kỹ thuật, nhiều shortcuts hơn, tích hợp bằng API với các hệ thống ngoài rất tốt.

Bản slack miễn phí lưu tối đa 10K tin nhắn, dung lượng file đủ dùng cho một nhóm 5, 10, 20 người chạy đồng thời 5 - 7 dự án, có thể tạo bao nhiêu channel cũng được (so sánh với số lượng group tối đa mà một user có thể join với free option là 14)

Rất recommend công cụ này, không chỉ cho dân kỹ thuật mà với cả người phi kỹ thuật

Redmine

Công cụ quản lý công việc (task), dự án nguồn mở và miễn phí. Nhiều dự án IT sử dụng Redmine khá hiệu quả.

Khi so sánh với những công cụ có phí như Team Foundation hay Jira, Redmine kém hơn về chức năng, sự thân thiện với người dùng nhưng đủ ở mức *cơ bản* cho việc quản lý một dự án công nghệ thông tin.

Với những nhóm ít tiền và muốn thử ticket/project management đơn giản thì redmine là lựa chọn hợp lý.

Dưới đây là một số chức năng chính của redmine:

1. Tích hợp với repo mã nguồn (subversion, git)
2. Quản lý theo ticket
3. Có thể sử dụng Agile/Scrum/Kanban với các plugin có sẵn
4. Code review với plugin và tạo thành ticket
5. Wiki, forum, file, knowledge base (dạng wiki)
6. Notification theo email

Clover 3

Mở nhiều tab với File Explorer trên Windows XP/7/8/10. Khá tiện. Shortcut hay dùng: Ctrl-1, 2, 3 để di chuyển tới tab số 1, 2, 3...

7zip

Nén, giải nén theo nhiều định dạng khác nhau. 7zip có chế độ "nén mà không nén" (tỉ lệ nén bằng 0%) thích hợp khi gộp nhiều file để chia sẻ, thuận tiện cho cả 2 chiều: nén và giải nén.

VirtualBox

Tạo máy ảo cho việc thử nghiệm OS mới, cài đặt môi trường phát triển, thử nghiệm.
Với chế độ bridged network, máy ảo tạo ra có thể chia sẻ cho các máy trong cùng mạng LAN. Miễn phí, nguồn mở, ít ổn định và nặng hơn so với VmWare nhưng đủ dùng cho việc phát triển thử nghiệm

CamStudio

Phần mềm quay phim màn hình. Một số use case cơ bản:

1. Quay movie làm evidence cho việc kiểm thử
2. Quay movie, chèn caption làm tutorial cho dự án

FileZilla (client)

FTP/SFTP client, GUI dễ sử dụng, nguồn mở và miễn phí. Lưu được ssh key, configuration

Vài điểm nhấn:

1. Hỗ trợ nhiều nền tảng: Windows, Linux. Nghĩa là nếu quen dùng FileZilla client thì có thể chuyển sang OS khác không bị lạ lẫm
2. Hỗ trợ FTP over SSL/TLS (dù ít dùng)
3. Hỗ trợ đa ngữ (tốt cho người Nhật)
4. Bookmark
5. Nhiều tab
6. Remote search (tìm kiếm trên máy chủ)
7. So sánh thư mục, folder
8. Edit được file trên máy chủ

Kế hoạch tiếp theo

Trong bài tiếp theo, chúng tôi dự định giới thiệu về các công cụ sau

1. mRemoteNG
2. Mindmap
3. LibreOffice
4. Firefox
5. SumatraPDF
6. Unikey
7. Google Japanese IME
8. Google Chrome awesome screenshot extension
9. Google Drive (Windows/Android/iOS)
10. Google Docs
11. Google Sheets
12. Google Calendar

Useful tools for your works / Một số công cụ hữu ích

Giới thiệu

Bài viết dưới đây giới thiệu một số công cụ tiện lợi cho việc trao đổi trong dự án (công nghệ thông tin/phát triển phần mềm).

Skype

Điểm mạnh: Dùng rộng rãi với voice chat và text chat. Chất lượng voice chat của Skype khi nhiều người đồng thời tham gia, tốc độ mạng không ổn định là tốt nhất trong các phần mềm voice chat hiện nay. Tiết kiệm khá nhiều tiền điện thoại. Một chức năng hay dùng khác: Chia sẻ màn hình, dùng màn hình đó để giải thích trong khi họp.

Điểm yếu: Các trao đổi trong instant message trôi rất nhanh và khó tìm lại (chức năng tìm kiếm yếu)

Mp3 Skype Recorder

Ghi âm lại hội thoại trên PC.
Với Android, cũng có thể ghi âm lại cuộc gọi nhưng cần root máy trước.

Greenshot

Phần mềm chụp lại màn hình bằng một nút "Print screen". Có thể setting để sau khi chụp toàn màn hình, hay chụp một vùng màn hình, output của screenshot tự động chuyển đến hai điểm: File ảnh trên một folder của ổ cứng và copy vào screenshot - tiện lợi cho việc cắt - dán vào các phần mềm khác (như Google Docs/Slides/Sheets)

Notepad++

1. Mở được rất nhiều, ít nhất 200 files đồng thời
2. Không cần save file, lần sau mở notepad++ những file đã mở lần trước vẫn hiện ra (session được lưu với cả unsaved file)
3. Hỗ trợ tiếng Việt, Unicode tốt
4. Tự động hóa tốt (macro)
5. Nhiều plugin
6. Highlight cho mã nguồn
7. Thân thiện với frontend web developer (để test web app)
8. Column mode: Chọn, dán theo cột (chứ không phải dòng)
9. Có thể dùng như một IDE cho lập trình
1. Auto-complete
2. Fold/unform hàm
3. 
   
10. Dễ zoom in/out
11. Search/Replace với regex (mạnh, nhanh, nhẹ)
12. Document map
13. Nhiều shortcuts

Chatwork

Concept của chatwork là "chat" cho "work" (công việc) chứ không phải để chơi. Những ý tưởng này được thực thi bởi người Nhật, rất thích hợp với người Nhật và những dự án dùng trong khu vực Đông/Đông Nam Á. 

Chatwork giúp việc quản lý trao đổi communication thuận tiện hơn.

Các điểm nhấn (cho bản có phí):

1. Tạo số nhóm (group) bất kỳ, ai cũng tạo được
2. Số người tham gia nhóm là bất kỳ
3. Số lượng tin nhắn lưu: Vô hạn
4. "Tag" được người liên quan. Người bị tag được thông báo khi bị tag, giúp giảm sai sót
5. Tạo "task" (TODO, công việc phải làm) cho chính mình hay người khác - là một cách remind công việc
6. TV conference: Chất lượng thấp, nên dùng Skype
7. Quoting văn bản
8. Pin point đến một tin nhắt bất kỳ bằng link

Điểm cần cải thiện:

1. API tốt hơn để liên kết với third party apps
2. Tagging tôt hơn

Các công cụ hữu ích (phần tiếp theo)

Trong phần tới, chúng tôi dự định giới thiệu các công cụ sau:

Slack

Redmine

Google Docs

Google Sheets

Google Calendar

Google Japanese IME

Google Chrome awesome screenshot extension

Google Drive (Windows/Android/iOS)

Clover 3

7zip


VirtualBox

CamStudio

FileZilla

Mindmap

mRemoteNG

LibreOffice

Firefox

SumatraPDF

Unikey

Why we have bugs / Vì sao có bug?

Giới thiệu

Một câu hỏi ngây thơ nhưng không đơn giản: Vì sao chương trình phần mềm có bug, bug ở đâu ra?

Bài viết sau đây trả lời câu hỏi này và một số câu hỏi liên quan.

Bối cảnh

- Chương trình nhiều lỗi, mỗi ngày phát sinh khoảng N = 5 lỗi và số lượng lỗi được fix hàng ngày là khoảng M = bug

- Sửa lỗi A thì xảy ra lỗi B1, B2...

- Mọi thành viên nhóm không biết (spec) thế nào là đúng hay sai

- Lượng thông tin cần để clear spec lớn

Ai hỏi câu này?

Tôi nhận được câu hỏi này từ các thành viên trong dự án. Tester và developer đều hỏi câu này dù họ làm phần mềm nhiều năm?

Vì sao phải trả lời câu hỏi này?

Đây là câu hỏi có vẻ đơn giản, nhưng câu trả lời không dễ. Với người ít kinh nghiệm làm phần mềm, họ trả lời "bug là bug". Với người nhiều kinh nghiệm hơn, ẩn ý từ câu hỏi này "bug từ nguồn nào tới để chúng ta/chúng tôi biết cách phòng tránh."

Nói thêm về quy trình phần mềm

Dù chúng ta phát triển phần mềm theo quy trình nào, những khái niệm sau luôn đúng.

- Mỗi công đoạn làm phần mềm trong quy trình đều có đầu vào vào đầu ra cụ thể

- Quá trình test phát hiện ra lỗi nhiều nhất

Công đoạn (chính) nào phát hiện được bug?

- (Các loại) test, như: unit test, function test, regression test, integration test, system test, user acceptance test

- Review (nói chung): Tài liệu, mã nguồn hay các loại input/output nói chung

Đầu vào của công đoạn coding là gì?

Đây là câu hỏi quan trọng hướng tới câu trả lời "bug từ đâu ra" của lập trình viên và tester. 

Tùy vào quy trình dự án, một số đầu vào điển hình của công đoạn coding là:

- Tài liệu thiết kế (basic design, detail design)

- Requirement definition

Tùy vào dự án, quy trình, đầu vào là khác nhau

Dựa vào đâu để biết đầu ra đúng hay sai?

"Đầu ra" ở đây được hiểu đơn giản là "mã nguồn", sản phẩm một hay nhiều chức năng phần mềm.

Việc kiểm tra đầu ra đúng hay sai cần dựa trên một cái gì đó đúng. Ta có thể chọn các đầu vào của việc coding làm tài liệu "đúng".

Test thế nào nếu không có "đầu vào" của việc coding chuẩn?

- Free test (test tự do, không theo một kịch bản nhất định. Mức độ test tùy vào kinh nghiệm của người test)

- Test phá (một dạng test tự do, tìm cách làm cho chương trình chết)

Nghĩa là, cứ lần mò mà test 

Nếu không có requirements definition hay tài liệu thiết kế rõ ràng) thì test thế nào?

Trả lời: Test phá (agile testing)

Nếu khi test, tôi tìm ra một điểm mới, không biết là đúng sai thì làm thế nào?

Hãy log lại và confirm với toàn team. Đây là cơ hội để cả team review lại kiến thức của họ về hệ thống

Làm thế nào để tìm bug khi không có tài liệu?

Câu trả lời là: Agile testing

Tôi là tester, phải làm gì khi không biết thế nào là đúng/sai?

- Agile testing

- Thật chủ động

- Làm việc chặt chẽ với người hiểu code và hiểu yêu cầu nghiệp vụ