Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 7

Các phương thức để đánh giá nỗ lực làm việc trong phát triển nhanh

Trong phần đăng mới nhất của loạt bài viết này, hãy tìm hiểu về đánh giá nỗ lực làm việc trong một môi trường nhanh. Do bản chất của sự phát triển phần mềm, đánh giá nỗ lực làm việc luôn khó khăn và thường không chính xác. Trong bài viết này, hãy khám phá một số phương thức hữu dụng có thể giúp đánh giá nỗ lực làm việc cho các dự án nhanh của bạn.

Mikko Kontio, Giám đốc, Softera

Mikko Kontio có một nền tảng về phát triển và tư vấn phần mềm. Ông hiện là Giám đốc tại Softera, một công ty phát triển phần mềm tập trung vào các cổng kinh doanh và giải pháp tính cước viễn thông.



30 10 2009

Giới thiệu

Loại bài này đã nghiên cứu các lợi ích của các quy trình nhanh và các yêu cầu đặt cho các tổ chức sử dụng chúng. Bạn đã học cách các tổ chức thích nghi với sự phát triển nhanh, về các kiểu khác nhau về các bên liên quan và cách áp dụng các câu chuyện của người dùng. Bạn đã duyệt các nghiên cứu về trường hợp và đã nhận thấy các câu chuyện của người sử dụng, cuộc thảo luận và mức ưu tiên có thể dẫn đến các phiên bản beta được phát triển nhanh. Và bạn đã xem xét lại các động cơ, hành vi của khách hàng và các mô hình định giá của mỗi dự án có ảnh hưởng đến sự thành công hiện tại và tương lai của một dự án phát triển như thế nào.

Bài viết này tìm ra cách để đánh giá các nỗ lực làm việc trong sự phát triển nhanh. Tìm hiểu về sự đánh giá nỗ lực làm việc nói chung và tại sao mọi người làm điều đó. Sau đó, đi sâu vào thế giới của sự đánh giá nhanh và tìm ra các kiểu đánh giá được thực hiện trong suốt quá trình phát triển. Bài viết này cũng đụng chạm tới chủ đề mới đây trong các diễn đàn thảo luận về sự điên rồ của các đánh giá và nó sẽ tiết kiệm được bao nhiêu thời gian để không phải đánh giá.


Đánh giá nỗ lực làm việc

Mọi người cố gắng đánh giá nỗ lực làm việc với ba lý do chính:

  • Để biết điều gì có thể được làm trong một khung thời gian nhất định.
  • Để tính toán xem có bao nhiêu thứ sắp được tính chi phí.
  • Để dự đoán xem tài nguyên nào và có bao nhiều tài nguyên (các nhà phát triển, những người thử nghiệm, v.v) cần thiết để xây dựng một cái gì đó.

Về logic, các doanh nghiệp định đầu tư xây dựng phần mềm cần có khả năng lập kế hoạch kinh phí và giải ngân cho các chi phí phát triển, để cho họ biết mình có khả năng gì.

Các chủ sở hữu sản phẩm (các đơn vị kinh doanh hoặc các nhóm người khác, những người đưa ra các tính năng sẽ có của sản phẩm) quan tâm đến các đánh giá nỗ lực làm việc để biết có thể nhận được khía cạnh nào trong lần phát hành tiếp theo. Các chủ sở hữu sản phẩm có thể có hạn phát hành cố định và họ sẽ muốn bắt đầu các chiến dịch tiếp thị để trợ giúp việc phát hành đó. Một số các đơn vị kinh doanh thích thực hiện theo cách khác với một tập các tính năng nhưng không định ra ngày phát hành cố định. Họ có thể có một đích, nhưng không định ngày trong đầu.

Nếu bạn quên tất cả các quy trình (như IBM® RUP® hoặc nhanh) và nghĩ về đánh giá nỗ lực làm việc như là luồng đơn giản hóa, thật hoàn toàn đơn giản để:

  1. Chia các tính năng (hay yêu cầu) thành các khối có kích thước hợp lý, đủ nhỏ để hiểu rõ.
  2. Cho mỗi khối một con số để cho biết kích thước so sánh với các khối khác hoặc trực tiếp đại diện cho các giờ làm việc.
  3. So sánh các khối với những thứ bạn đã làm trước đó, nhận được nỗ lực làm việc theo kích thước khối và thay thế tất cả các con số kích thước cho phù hợp.

Điều đó không quá phức tạp, nhưng có một vài bước ở đó bạn có thể chọn trong số nhiều cách tiến hành đánh giá khác nhau và bạn cần có cái gì đó để so sánh. Và, dĩ nhiên, hãy nhớ rằng không phải tất cả các nhà phát triển đều như nhau. Một số là những chuyên viên giỏi có 10 hoặc trên 10 năm kinh nghiệm và những người khác có thể chỉ có một năm kinh nghiệm về phát triển phần mềm. Có sự khác biệt rất lớn giữa hai người.

Đánh giá nỗ lực làm việc không phải là khoa học chính xác. Đích chính là sử dụng vừa đủ thời gian và năng lượng để có một đánh giá đủ tốt để dùng.

Các cách đánh giá

Có ba cách cơ bản để đánh giá nỗ lực làm việc đối với phát triển phần mềm:

Ý kiến chuyên gia
Dựa trên ý tưởng mà một chuyên gia sẽ biết do kinh nghiệm hay trực giác về những gì để xây dựng gì đó, phương thức dùng ý kiến chuyên gia là tốt hơn đối với các quy trình không nhanh. Trong phát triển nhanh, các thành viên trong nhóm nên thực hiện đánh giá vì nhóm hiếm khi chỉ gồm các chuyên gia.

Nếu bạn cần thu được đánh giá nhanh chóng, sử dụng chuyên gia là một phương thức tốt. Các nhà phát triển giỏi chuyên môn sẽ đọc các câu chuyện của người sử dụng, hỏi một vài câu hỏi và đưa ra một đánh giá dựa trên kinh nghiệm. Đã chứng minh được rằng loại đánh giá này hoàn toàn chính xác.

Không kết hợp
Với phương thức này, bạn tách một câu chuyện lớn thành hai hoặc nhiều câu chuyện nhỏ để dễ dàng hơn đánh giá. Ví dụ, nếu hầu hết các câu chuyện là dưới 10 ngày, sau đó thực hiện một đánh giá về một cái gì đó mà nó sẽ chiếm mất 80 ngày sẽ không thật chính xác. Việc chia tách một câu chuyện lớn thành nhiều câu chuyện nhỏ làm cho nó dễ dàng đánh giá hơn và cũng dễ dàng xử lý hơn.
Tương tự
Phương thức này đòi hỏi phải so sánh câu chuyện mới của người dùng hoặc tính năng, với một cái gì đó bạn đã đánh giá. Nếu câu chuyện này gấp hai lần kích thước, thì đánh giá phải lớn gấp đôi. Một lựa chọn khác là so sánh câu chuyện đó với một cái gì đó mà bạn đã xây dựng. Mục đích không phải là để so sánh tất cả các câu chuyện với một, mà với tập các câu chuyện đã đánh giá (hoặc đã thực hiện).

Đánh giá nỗ lực theo một cách nhanh

Phần này đụng chạm đến các khái niệm và các phương thức đánh giá nhanh, gồm mối quan hệ nỗ lực-chính xác, lên kế hoạch chơi bài, vận tốc và các ngày lý tưởng.

Mối quan hệ nỗ lực-chính xác

Điều quan trọng là phải hiểu rằng, do việc đánh giá nỗ lực không phải là khoa học chính xác, có một mối quan hệ nỗ lực-chính xác nhất định (vài người gọi nó là "đường cong") mà nó cho biết lúc không nên thực hiện thêm công việc do sự chính xác sẽ không cải thiện.

Giả sử bạn phải đánh giá nỗ lực làm việc của bốn câu chuyện của người dùng. Hãy xem xét sự khác nhau giữa sự đoán mò, không cần sự nỗ lực, với sự chính xác ở đâu đó giữa điểm ngắm và điểm xa tít, với kết quả tại một cuộc họp ngắn với nhóm phát triển. Cuộc họp sẽ cải thiện tính chính xác của các đánh giá rất nhiều, mặc dù các đánh giá sẽ vẫn không phải là tốt nhất mà chúng có thể có. Hãy tự hỏi các đánh giá phải chính xác như thế nào. Sau đó so sánh cuộc họp ngắn của nhóm phát triển với một cuộc hội thảo nửa ngày với nhóm đó. Cuộc hội thảo nửa ngày sẽ cải thiện tính chính xác một lần nữa. So sánh cuộc hội thảo nửa ngày với một cuộc hội thảo hai ngày. Sự chính xác thu được từ cuộc hội thảo hai ngày có thể tốt hơn, nhưng với chi phí thời gian thế nào? Điều quan trọng là nơi cho phép rút ra đánh giá trong mối quan hệ nỗ lực-chính xác.

Lên kế hoạch chơi bài

Khi lên kế hoạch chơi bài, toàn bộ nhóm tập hợp lại để đánh giá của các nỗ lực làm việc của một lần chạy nước rút mới (tiêu biểu). Tất cả mọi người liên quan đến việc phát triển cần có ở đó: các nhà phát triển, những người thử nghiệm, các nhà thiết kế cơ sở dữ liệu, v.v. Thật là tốt để giữ cho quy mô của nhóm chơi bài dưới 10 người. Nếu nhóm của bạn lớn hơn, hãy xem xét việc chia tách nhóm này thành hai. Chủ sở hữu sản phẩm này cũng phải tham gia chơi bài nhưng không được đánh giá nếu người đó không xây dựng phần mềm.

Đôi khi lập kế hoạch chơi bài cũng có thể giúp xác định kích thước của các mục hoặc các khía cạnh cần làm của sản phẩm (product backlog). Trong trường hợp này, các đánh giá được nới lỏng hơn. Mục đích là để cung cấp thông tin giúp chủ sở hữu sản phẩm dành ưu tiên cho công việc tồn đọng của sản phẩm.

Để giúp bảo đảm rằng cố gắng lên kế hoạch chơi bài của bạn có hiệu quả và thành công, có thể thử:

  • Mang lại thứ gì đó tốt để ăn, chẳng hạn như bánh quy. Đường cho năng lượng, bánh kẹo làm cho các thành viên trong nhóm cảm thấy tốt và lập kế hoạch chơi bài trở thành một cuộc họp đã biết trước từ lâu.
  • Không cho phép các nhà phát triển dùng máy tính xách tay tại cuộc họp. Thay vào đó, hãy đọc những câu chuyện của người sử dụng hoặc các mô tả tính năng từ một máy vi tính hoặc màn hình lớn. Các máy tính xách tay có xu hướng phân tâm các nhà phát triển; Họ luôn luôn tìm thấy cái gì đó thú vị để duyệt hoặc sửa lại

Trước khi ván bài bắt đầu, tất cả các thành viên trong nhóm nhận được một cỗ bài. Các quân bài (các thẻ) chứa các con số như 1, 2, 4, 8 và 16; một số người thích sử dụng kích cỡ áo phông như XS, S, M, L và XL. Các quân bài phải được chuẩn bị trước và các số, các chữ cái, hoặc kích cỡ áo phông nên đủ lớn để thấy qua bàn.

Để bắt đầu lập kế hoạch chơi bài, hoặc chủ sở hữu sản phẩm hay người điều hành khác đọc mô tả về câu chuyện của người dùng. Bất kỳ thành viên trong nhóm có thể đặt các câu hỏi về câu chuyện của người dùng. Sau khi trả lời các câu hỏi, mỗi thành viên trong nhóm chọn một quân bài đại diện cho quy mô của câu chuyện của người dùng. Sau đó tất cả mọi người lật các quân bài lên cùng một lúc. Thường thì các đánh giá ít khác biệt.

Những người đánh giá cao nhất và thấp nhất giải thích cách họ đánh giá. Họ có thể đã suy nghĩ khác về khía cạnh so với các thành viên khác trong nhóm và họ có thể đã đạt tới các thách thức mà những người khác đã không nghĩ tới. Sau các giải thích, nhóm phát triển có thể thảo luận xem các đánh giá thấp hoặc cao có mang lại những thông tin mới không, hoặc xem chúng đúng là không chính xác hay không. Các đánh giá thấp hoặc cao không bị coi là sai, cũng không xem những người đánh giá này là kém. Đây là một điểm quan trọng, bởi vì nếu không toàn bộ cuộc họp đánh giá sẽ không được xem là mở và các thành viên trong nhóm sẽ bắt đầu tránh cuộc họp. Các đánh giá thấp và cao chỉ là ý kiến khác nhau, cho phép vạch ra góc nhìn mới đối với vấn đề.

Kích thước và vận tốc

Các con số được sử dụng trong lập kế hoạch chơi bài đương nhiên có thể là giờ hoặc ngày, nhưng chúng cũng có thể đơn giản là các con số thể hiện kích thước. Các con số được gọi là các điểm của câu chuyện. Một câu chuyện của người dùng mà có hai điểm câu chuyện có thể đưa ra, ví dụ, một ngày để thực hiện cho một nhóm nào đó.

Nếu nhóm đó đã thực hiện 20 điểm câu chuyện trong lần lặp cuối cùng, họ sẽ có thể sẽ thực hiện khoảng 20 điểm câu chuyện trong lần lặp kế tiếp. Vận tốc của nhóm của là 20 điểm câu chuyện cho mỗi lần lặp. Tất nhiên, nếu chiều dài của lần lặp dài hơn, vận tốc sẽ lớn hơn. Theo thời gian vận tốc của nhóm sẽ cải thiện khi họ tìm hiểu các kỹ thuật mới và khi họ trở thành một đơn vị chặt chẽ hơn.

Các ngày lý tưởng

Nếu bạn hỏi một nhà phát triển mất bao lâu để thực hiện một tính năng, nhà phát triển có thể nói "năm ngày". Nhà phát triển có thể thực sự muốn nói, "Năm ngày nếu đây là việc duy nhất tôi sẽ làm, nhưng do tôi cũng phải làm rất nhiều thứ khác nên nó có thể sẽ mất 10 ngày". Năm ngày được gọi là một đánh giá theo các ngày lý tưởng. Điều quan trọng không để trộn lẫn các ngày lý tưởng và các ngày thực tế. Một số nhóm sử dụng các ngày lý tưởng để đánh giá các câu chuyện của người dùng và sau đó họ chuyển đổi các ngày lý tưởng sang thời gian thực với một yếu tố nhất định. Yếu tố này có thể được xác định bằng kinh nghiệm và thực hành.


Hoặc, không đánh giá gì hết

Có một lý thuyết thay thế để không thực hiện đánh giá nỗ lực nào cả. Gốc rễ của lý thuyết này là, do sự đánh giá lúc tốt nhất chỉ có một phần đúng, tại sao lại sử dụng thời gian và năng lượng để làm điều đó cho tất cả? Tại sao không sử dụng thời gian đó để phát triển phần mềm làm việc? Đúng, có các tình huống và các khách hàng mà ở đó bạn chỉ phải đánh giá nỗ lực làm việc. Nhưng cũng có các tình huống, các doanh nghiệp và các ứng dụng mà thời gian đó có thể được sử dụng để phát triển phần mềm mới.

Thủ thuật hay hướng dẫn, để không phải đánh giá gì cả là làm cho các lần lặp ngắn đi và các khía cạnh nhỏ đi, sau đó chỉ cần chọn các khía cạnh cho lần lặp kế tiếp mà nhóm phát triển nghĩ rằng nó có thể cung cấp. Kiểu tư duy này thực hiện tốt với sự phát triển phần mềm dựa vào sự cố gắng hay sự phát triển không có lợi lộc gì.


Tóm tắt

Trong mục này, chúng ta khám phá cách để đánh giá nỗ lực làm việc trong quá trình nhanh. Bạn đã học về ba cách cơ bản để đánh giá, cũng như cách thực hiện lên kế hoạch chơi bài và mối quan hệ nỗ lực-chính xác. Các con số sử dụng trong quá trình đánh giá là không thích hợp cho tất cả. Chúng ta cũng tìm ra ý tưởng không đánh giá nỗ lực làm việc nào cả. Trong một số trường hợp, thời gian sử dụng cho các đánh giá có thể được sử dụng để phát triển các tính năng mới.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

  • Tải về phiên bản đánh giá sản phẩm IBM và nhận được các bài thực hành của bạn trên các công cụ phát triển ứng dụng và các sản phẩm phần mềm trung gian từ IBM® DB2®, Lotus®, Rational®, Tivoli® và WebSphere®.

Thảo luận

  • Đọc những gì mà mọi người đang nói trong developerWorks blogs và dành tâm trí cho cộng đồng developerWorks.
  • Hãy xem blog của Scott Ambler - các chiến lược để điều chỉnh Phát triển phần mềm nhanh.
  • Tham gia vào diễn đàn kiến trúc CNTT để trao đổi các lời khuyên và các kỹ thuật và để chia sẻ các thông tin liên quan khác về chủ đề rộng lớn của kiến trúc CNTT.

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Rational
ArticleID=441883
ArticleTitle=Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 7
publish-date=10302009