Những trách nhiệm chính của một nhóm phát triển tự tổ chức (team developer) là gì?

Một họ các phương pháp phát triển phần mềm dựa theo các giá trị và nguyên tắc được định nghĩa bởi AgileAlliance.org.

Là biểu đồ thể hiện xu hướng của công việc còn lại theo thời gian trong một Sprint, một bản phát hành [Release], hoặc sản phẩm. Dữ liệu cho Biểu đồ Burndown được lấy từ Sprint Backlog và Product Backlog, với công việc còn lại được theo dõi trên trục tung và khoảng thời gian [các ngày trong một Sprint, hoặc nhiều Sprint] theo dõi trên trục hoành. Biểu đồ Burndown được dùng cho Bản phát hành [khi đó gọi là Release Burndown] hoặc cho Sprint [gọi là Sprint Burndown].

Một người nào đó quan tâm đến dự án nhưng không có  trách nhiệm trong dự án [không giữ các vai trò Nhóm Phát triển, Product Owner hay Scrum Master].

Một cuộc họp ngắn được tổ chức hàng ngày của mỗi Nhóm Phát triển, trong thời gian đó các thành viên của nhóm kiểm tra công việc của họ, đồng bộ hóa công việc và tiến độ của mình và báo cáo các vấn đề để giải quyết. Nhóm và Scrum Master có thể phải tiến hành các hoạt động tiếp theo Daily Scrum để thích ứng với công việc sắp tới và tối tưu hóa Sprint.

Định nghĩa về sự hoàn thành [Done Definition - Định nghĩa Hoàn thành] được đồng thuận giữa tất cả các bên và phù hợp với tiêu chuẩn, quy ước của tổ chức cũng như các chỉ dẫn khác. Khi một công việc được ghi nhận là  "Done" tại cuộc họp Sơ kết Sprint , nó phải phù hợp với định nghĩa về sự hoàn thành này.

Số giờ mà một thành viên của nhóm ước lượng để thực hiện một công việc nào đó. Ước lượng này được cập nhật hằng ngày khi thành viên đó thực hiện  công việc trong Sprint Backlog. Đây là con số ước tính tổng số giờ  còn lại để hoàn thành công việc, không kể đến số lượng người thực hiện công việc hay số giờ đã bỏ ra cho công việc ấy trong quá khứ.

Đây là phương pháp quản lý các tiến trình [process] không dựa trên giả định và tính toán lý thuyết [Predictive management] mà dựa trên các khảo sát kĩ lưỡng và thích nghi với các biến động trên thực tiễn.

Là phần tăng trưởng của sản phẩm được phát triển bởi Nhóm Phát triển trong mỗi Sprint. Đôi khi increment được dịch gần đúng là “gói phần mềm”, hay đơn giản là gói.

Một phần nhỏ nhưng hoàn chỉnh của  sản phẩm tổng thể hoặc hệ thống có thể được sử dụng bởi chủ sở hữu sản phẩm hoặc các bên liên quan.

Trong các phương pháp phát triển linh hoạt, iteration chỉ một phân đoạn với khoảng thời gian ngắn nhằm phát triển một phần nhỏ của hệ thống. Một dự án sẽ gồm nhiều phân đoạn lặp đi lặp lại.

Một phân đoạn [iteration], là một chu kỳ lặp đi lặp lại công việc tương tự nhằm tạo ra các phần tăng trưởng [increment] cho hệ thống. Sprint thường kéo dài từ một tuần tới một tháng.Trong suốt dự án, thời gian cho một Sprint là cố định. Từ “sprint” có nghĩa là giai đoạn nước rút, ám chỉ sự gấp gáp và tập trung cao độ trong khoảng thời gian ngắn để làm việc.

Một người nào đó thực hiện một trong ba vai trò của Scrum [Team, Product Owner hoặc Scrum Master], người đã có những cam kết và có quyền để thực hiện cam kết của mình.

Một danh sách ưu tiên của các yêu cầu với thời gian ước tính để biến chúng thành các tính năng  hoàn chỉnh của sản phẩm. Các hạng mục được ưu tiên hơn trong Product Backlog được ước lượng cẩn thận hơn, và thường chính xác hơn các phần khác. Danh sách này có thể thay đổi khi có sự thay đổi trong điều kiện kinh doanh hoặc công nghệ. Trong tiếng Anh, 'backlog' có nghĩa là phần việc tồn đọng, cần phải giải quyết.

Một  yêu cầu chức năng hay phi chức năng, và các vấn đề được sắp độ ưu tiên. Độ chính xác của ước lượng phụ thuộc vào tầm quan trọng và độ chi tiết của hạng mục đó. Phần có độ ưu tiên cao nhất  sẽ được chọn trong Sprint tiếp theo để làm việc.

Người chịu trách nhiệm quản lý Product Backlog để tối đa hóa giá trị của dự án. Chủ sở hữu sản phẩm có trách nhiệm đại diện cho lợi ích của tất cả mọi người có quyền lợi  trong dự án và sản phẩm được tạo ra sau dự án.

Là sản phẩm đầy đủ các chức năng theo yêu cầu của chủ sản phẩm, có khả năng bán ra thị trường hay chuyển tới người dùng.

Đây không không phải là từ viết tắt, mà là cơ chế trong trò chơi bóng bầu dục để đưa “bóng chết” vào cuộc chơi. Từ “scrum” có nghĩa là chen lấn, hàm ý sự hỗn độn, liên chức năng và tự quản cao độ trong các tình huống thực tiễn.

Người chịu trách nhiệm cho quy trình Scrum, bao gồm việc triển khai đúng quy tắc, và tối hóa lợi ích từ Scrum.

Đây là một nhóm liên chức năng gồm Product Owner, Scrum Master và Development Team [Nhóm Phát triển]. Nhóm Scrum sẽ cộng tác với nhau theo khung làm việc Scrum để hiện thực hóa mục tiêu của Product Owner.

Danh sách các nhiệm vụ xác định công việc của  nhóm trong một Sprint. Danh sách này được cập nhật trong suốt Sprint. Nhóm tự quản lý Sprint Backlog bằng việc cập nhật trạng thái thực thi các nhiệm vụ với người chịu trách nhiệm và thời gian còn lại để hoàn tất công việc tính tới thời điểm cập nhật.

Một trong những nhiệm vụ mà nhóm hoặc một thành viên xác định theo yêu cầu để chuyển đổi các yêu cầu trong Product Backlog thành chức năng của hệ thống.

Cuộc họp diễn ra trong phạm vi tám giờ đồng hồ để khởi động mỗi Sprint.  Họp lập kế hoạch được chia thành hai phân đoạn bốn giờ.Trong bốn giờ đầu tiên Product Owner trình bày các yêu cầu có độ ưu tiên cao nhất cho nhóm phát triển. Nhóm và Product Owner sẽ kết hợp để xác định số lượng các hạng mục sẽ được chọn để tiến hành phát triển trong Sprint tới. Sau bốn giờ đầu tiên, Nhóm và Product Owner xác định mục tiêu của Sprint sắp tới. Trong suốt bốn giờ thứ hai của cuộc họp, Nhóm lập kế hoạch để đạt được mục đích của Sprint bằng các kĩ thuật phân tích và thiết kế cần thiết, và sau đó ghi lại chi tiết công dưới dạng một bản kế hoạch có tên Sprint Backlog.

Đội sản xuất cùng với Product Owner đánh giá lại công việc của Sprint vừa kết thúc. Trong khi đánh giá, Đội sản xuất trình bày các phần việc đã hoàn tất, các chức năng đã hoàn thành; lắng nghe các phản hồi từ Product Owner và thảo luận về các chỉnh sửa [nếu có] sẽ thực hiện trong Sprint tiếp theo.

Trong phạm vi ba giờ, ScrumMaster sẽ tổ chức cho nhóm thực hiện công việc khảo sát lại toàn bộ quy trình làm việc của Sprint vừa qua để tìm ra các cải tiến trong Sprint tới, nhằm mang lại hiệu suất cao hơn cho nhóm.

Một nhóm liên chức năng [cross-functional] gồm các nhà phát triển [developers] tự quản lý để tiến hành chuyển đổi các Product Backlog item thành chức năng của hệ thống. Đây là một trong ba vai trò tạo nên Nhóm Scrum [còn gọi là Đội hình Scrum].

Là khoảng thời gian tối đa dành cho một hoạt động nào đó trong Scrum. Khi nói Daily Scrum là đóng hộp trong mười lăm phút thì có nghĩa là Đội dự án không thể dùng quá mười lăm phút cho cuộc họp hằng ngày Daily Scrum. Các Hộp thời gian trong Scrum có thể kể đến là Release Planning, Sprint Planning, Sprint, Daily Scrum, Sprint Review và Sprint Retrospective.

Người có sự quan tâm đến kết quả của một dự án [có tài trợ cho nó, sẽ sử dụng, hoặc sẽ bị ảnh hưởng bởi sản phẩm tạo ra từ dự án].

 Tìm hiểu thêm tại trang Agipedia.

Page 2

 Bản dịch cho bài viết “What is Definition of Done? [DoD]” của Dhaval Panchal CSM, CSPO, CSP, CSC, CST tại ScrumAlliance.org

Việc có một định nghĩa hoàn thành [ĐNHT] là cực kỳ quan trọng đối với nhóm Scrum hiệu năng cao. Sau đây là những đặc điểm mà bạn nên tìm thấy trong ĐNHT của nhóm mình. Việc xác minh ĐNHT của nhóm có đạt những tiêu chí này hay không sẽ đảm bảo rằng nhóm đang cung cấp các tính năng thực sự hoàn tất, không chỉ về mặt chức năng mà còn cả về chất lượng.

ĐNHT là một danh sách kiểm tra [checklist] các hoạt động có giá trị cần thiết để  sản xuất  phần mềm.

ĐNHT đơn giản là một danh sách các hoạt động [viết mã, chú thích cho mã, kiểm thử đơn vị, kiểm thử tích hợp, bản ghi chú phát hành, tài liệu thiết kế, v.v...] giúp thêm vào những giá trị có thể kiểm chứng và xác minh được cho sản phẩm. Việc tập trung vào các phần giá trị gia tăng cho phép Đội sản xuất dồn sức vào những công việc quan trọng phải hoàn thành để xây đựng phần mềm đồng thời loại bỏ các hoạt động lãng phí gây phức tạp hóa nỗ lực phát triển phần mềm.

ĐNHT như là một cơ chế báo cáo chủ đạo cho Đội sản xuất.

Việc báo cáo đôi khi đơn giản chỉ với một câu: “chức năng này đã hoàn thành”. Nhưng rốt cuộc, một chức năng hay một hạng mục Product Backlog là hoàn thành hay không hoàn thành? ĐNHT là một công cụ đơn giản để làm rõ thêm câu nói “chức năng này đã hoàn thành”. Việc sử dụng ĐNHT như là sự tham khảo trong các cuộc hội thoại kiểu này khiến cho một thành viên có thể cập nhật một cách hiệu quả thông tin tới các thành viên khác trong nhóm và cho Product Owner.

ĐNHT là thông báo thực.

Scrum đòi hỏi đội sản xuất cung cấp “sản phẩm phần mềm hoàn chỉnh chuyển giao được” khi kết thúc một Sprint. Sản phẩm phần mềm hoàn chỉnh chuyển giao được có thể được hiểu là những tính năng sẽ có ở bản phát hành, với những hạn chế lưu ý cho người dùng cuối căn cứ theo quyết định của Product Owner. Những sản phẩm đó thậm trí có thể được chuyển giao tới người dùng cuối trong vòng hai, ba ngày với lý do được hợp lý hóa bằng việc cho rằng nó ở trạng thái hoàn chỉnh chuyển giao được. Một cách lý tưởng là việc “hoàn chỉnh chuyển giao được” tương đương với ĐNHT.

Trên thực tế, nhiều đội phát triển phần mềm đang làm việc hướng tới trạng thái hoàn chỉnh có tiềm năng chuyển giao được. Mỗi đội này có thể có một ĐNHT khác nhau với nhiều cấp độ:

  • ĐNHT cho chức năng [User Story hay hạng mục ProductBacklog]
  • ĐNHT cho Sprint [các tính năng được phát triển trong sprint]
  • ĐNHT cho bản phát hành [trạng thái hoàn chỉnh chuyển giao được]

Có nhiều yếu tố ảnh hưởng đến việc một hoạt động có được đưa vào trong ĐNHT cho chức năng, cho sprint hay cho bản phát hành. Đánh giá cuối cùng dựa trên việc trả lời cho ba câu hỏi sau:

  • Chúng ta có thể làm việc này cho mỗi chức năng? nếu không thì...
  • Chúng ta có thể làm việc này cho mỗi sprint? nếu không thì...
  • Chúng ta phải làm việc này cho bản phát hành!

Chris Sterling khuyên rằng đối với những công việc không thể đưa vào trong Sprint, đội nên “thảo luận tất cả những điều gây cản trở họ nếu hoạt động này được lựa chọn trong mỗi sprint”.

Những nguyên nhân gốc rễ thường gặp đối với các trở ngại bao gồm:

  • Đội thiếu tập kỹ năng cần thiết để thực hiện theo đúng ĐNHT cho sprint hay cho chức năng.
  • Đội thiếu bộ các công cụ cần thiết [Ví dụ: môi trường tích hợp liên tục, tự động dựng, máy chủ v.v...]
  • Thành viên đội sản xuất thực hiện sprint của họ theo kiểu mini-waterfalls

[A ha! Đây lại là một cơ hội để “liên thủ” và chia sẻ trách nhiệm nhiều hơn trên các khối chức năng]

ĐNHT không bất biến.

ĐNHT thay đổi theo thời gian. Hỗ trợ việc tổ chức và khả năng đội sản xuất tháo gỡ các trở lực, có thể cho phép bổ sung thêm các hoạt động mới vào trong ĐNHT đối với chức năng hoặc Sprint.

ĐNHT là một danh sách kiểm tra có thể thẩm tra được.

Các tính năng được phân nhỏ thành các công đoạn [task] trong cả quá trình lên kế hoạch cho sprint cũng như trong suốt sprint. ĐNHT được sử dụng để xác định xem tất cả các khâu quan trọng có được hoạch toán [về số giờ còn lại]. Đồng thời, sau khi một chức năng hoặc sprint hoàn thành, ĐNHT được sử dụng như là một danh sách kiểm tra để xác minh xem tất cả các hoạt động gia tăng đã được hoàn tất hay chưa.

Điều quan trọng cần lưu ý là các ĐNHT nói chung tồn tại những hạn chế. Không phải tất cả các hoạt động gia tăng giá trị sẽ áp dụng được cho mỗi chức năng khi mà ĐNHT được coi như là một bản danh sách toàn diện. Đội sản xuất có ý thức tự giác quyết định việc áp dụng các hoạt động gia tăng giá trị trên từng tính năng cơ bản. Ví dụ, cho rằng hướng dẫn sử dụng người dùng cho chức năng cung cấp điểm tích hợp [như webservice chẳng hạn] tới hệ thống khác không thể áp dụng được cho một tính năng cụ thể; tuy nhiên đối với những tính năng khác trong hệ thống có thực hiện việc giao tiếp với con người thì hướng dẫn sử dụng cho người dùng là cần thiết.

Tổng kết

ĐNHT là trực giao với tiêu chuẩn chấp nhận của người dùng [chấp nhận về chức năng] đối với một tính năng. Nó là một danh sách kiểm tra toàn diện những thứ cần thiết, hoạt động gia tăng giá trị giúp khẳng định chất lượng của một chức năng hoặc phi tính năng của chức năng đó. ĐNHT là báo cáo thực để nắm bắt các hoạt động có thể được cam kết là thực sự hoàn thành bởi đội sản xuất tại các cấp độ khác nhau [tính năng, sprint, bản phát hành].

Người dịch: Nguyễn Ngọc Tú

Page 3

[Còn gọi là Tuyên ngôn Agile]

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ácvớ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.

 Dịch từ://agilemanifesto.org

Mười hai nguyên tắc phía sau Tuyên ngôn Agile


Chúng tôi tuân theo các nguyên tắc 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 chuyển giao sớm và liên tục các phần mềm có giá trị.
  2. Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Phần mềm chạy tốt là thước đo chính của tiến độ.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. Nhóm phát triển 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.

Đã kí:

Kent BeckMike BeedleArie van BennekumAlistair CockburnWard Cunningham

Martin Fowler

James GrenningJim HighsmithAndrew HuntRon JeffriesJon Kern

Brian Marick

Robert C. MartinSteve MellorKen SchwaberJeff Sutherland

Dave Thomas

Video liên quan

Chủ Đề