Cách tốt nhất để lập kế hoạch lập trình cho các nhóm nhỏ? [đóng cửa]

Tôi là Giám đốc của một tổ chức khởi nghiệp nhỏ. Chúng tôi hiện có hai lập trình viên (một người có kinh nghiệm, một người ít kinh nghiệm) đang xây dựng một nền tảng ứng dụng web.

Một trong những thách thức lớn nhất cho đến nay là quy trình lập kế hoạch. Các lập trình viên thường chịu trách nhiệm lập kế hoạch cho công việc của họ, nhưng chúng tôi tiếp tục vượt quá thời hạn tự áp đặt của họ. Chẳng hạn, một nhiệm vụ mà họ ước tính sẽ mất 2 ngày, kết thúc là 8 ngày.

Đối với tôi thật khó để hỗ trợ họ trong việc lập kế hoạch, vì tôi thiếu bí quyết kỹ thuật để ước tính chính xác thời gian một nhiệm vụ nhất định sẽ kéo dài.

Bạn còn ý kiến ​​nào không:

1. Lý do cho điều này là gì, điều này là phổ biến cho các lập trình viên?
2. Tôi có thể làm gì để hỗ trợ họ trong kế hoạch? Có phương pháp hay công cụ nào hữu ích cho các lập trình viên trong các nhóm nhỏ không?

Các kỹ thuật chung có phần thông thường, điều quan trọng cần biết là chúng không đòi hỏi nhiều chuyên môn kỹ thuật.

Điểm khởi đầu với việc lập kế hoạch là xác định chính xác vấn đề cần giải quyết và có yêu cầu rõ ràng và rõ ràng. Nếu bạn không có điều đó, ước tính của bạn sẽ không chính xác. Có tài liệu này trong một số loại đặc tả tính năng trước khi bất kỳ ai bắt đầu viết mã sẽ có nghĩa là bất kỳ câu hỏi nào cần được hỏi sẽ được hỏi trước khi bắt đầu mã hóa. Đây là một trình tiết kiệm thời gian hiệu quả đáng ngạc nhiên. Quay trở lại và làm rõ các yêu cầu phá vỡ dòng chảy của một người như một lập trình viên và chờ phản hồi có thể chặn tiến trình.

Một khi bạn đã xác định được yêu cầu bạn cần xác định các nhiệm vụ công việc liên quan đến việc giải quyết nó. Đây là một bài tập phân chia và chinh phục cổ điển - bất kỳ nhiệm vụ nào có thể được chia nhỏ hơn nữa cần phải được chia nhỏ hơn nữa.

Trong một nhóm lớn hơn, bạn có thể sử dụng poker ước tính để có được ước tính dựa trên kinh nghiệm của mọi người tham gia. Điều đó không hoạt động tốt trong một nhóm nhỏ hơn, nhưng vẫn hữu ích khi có được ước tính độc lập từ cả hai nhà phát triển của bạn và có thể bao gồm một từ chính bạn - sự thiếu chuyên môn cụ thể của bạn có thể hữu ích ở đây vì giải thích cho bạn những gì nhiệm vụ liên quan từ quan điểm của họ, nhóm phát triển có thể sẽ nắm bắt vấn đề tốt hơn.

Với một nhóm nhỏ hơn, nó có thể giúp có được ước tính trường hợp tốt nhất / dự kiến ​​/ tồi tệ nhất cho mỗi nhiệm vụ, mang lại cho bạn một loạt các giá trị, nhưng nếu bạn nhận được nhiều ước tính vượt mức, bạn có thể nghiêng về trường hợp xấu nhất cho đến khi các nhà phát triển của bạn học để ước tính chính xác hơn.

Trong một cửa hàng nhỏ, các nhà phát triển thường kết thúc gấp đôi là sysadins, nhóm hỗ trợ và thậm chí cả người kiểm tra (mặc dù tất cả những điều họ có thể làm, kiểm tra là điều bạn nên cố gắng tránh bằng mọi giá) vì vậy bạn cần phải tính đến điều đó. Chỉ ra bao nhiêu thời gian của họ mà các nhà phát triển của bạn thực sự dành cho việc làm việc với các tính năng và yếu tố mới trong ước tính của bạn. Nếu một nhiệm vụ được ước tính là 2 ngày nhưng các nhà phát triển của bạn chỉ có thể làm việc trên sự phát triển mới 60% thời gian, thì bạn sẽ cần 4 ngày để hoàn thành. Bạn cũng có thể giúp với điều này bằng cách kiểm soát đường dẫn của các nhiệm vụ khác mà họ cần xử lý để quản trị viên hoặc nhiệm vụ hỗ trợ không khẩn cấp có thể được bó lại với nhau thay vì được xử lý trên cơ sở đặc biệt. Rất nhiều lập trình viên (chắc chắn bao gồm cả tôi trong số này) không phải là người quản lý thời gian tuyệt vời, vì vậy bất cứ điều gì bạn có thể làm để giúp một tay trong sự tôn trọng đó sẽ giúp ích. Đa tác vụ luôn dễ dàng hơn cho các lập trình viên so với đa tác vụ. Chặn thời gian trong ngày cũng có thể giúp với điều này.

Giữ một bản ghi - mỗi khi bạn có một phiên lập kế hoạch, ghi lại các ước tính và thực tế. Sau đó, bạn có thể sử dụng điều này a) như một hướng dẫn về việc tăng bao nhiêu ước tính của họ bằng cách lập kế hoạch và b) để giúp họ tinh chỉnh các kỹ năng ước tính của họ. Vào cuối mỗi lần lặp (hoặc bất cứ điều gì tương đương với bạn), toàn bộ nhóm nên xem lại công việc đã hoàn thành và tìm hiểu lý do tại sao phải mất nhiều thời gian hơn dự kiến ​​để có thể kết hợp trong các ước tính trong tương lai. Đây cần phải là một nhiệm vụ đáng trách - bạn dường như có thái độ đúng đắn ở đây nhưng câu trả lời này có thể sẽ xuất hiện trong một thời gian vì vậy tôi sẽ thực hiện quan sát. Nếu ai đó nói "Tôi đã phạm sai lầm ở đây", bạn có thể biến điều đó thành "những gì bạn có thể làm tốt hơn", nhưng nói với mọi người rằng họ quá chậm hoặc làm mọi thứ sai sẽ chỉ làm cho vấn đề tồi tệ hơn.

Tôi biết rằng không có viên đạn bạc nào cho loại vấn đề này nhưng yếu tố lớn nhất là giao tiếp - điều này thực sự dễ dàng hơn với một nhóm nhỏ hơn - và sử dụng phản hồi để tinh chỉnh các kỹ năng tập thể của bạn.

Lý do cho [ước tính của họ về 2 ngày mất 8 ngày], điều này có phổ biến đối với các lập trình viên không?

Đó là, nếu:

• Không thực sự rõ ràng những gì họ phải làm, vì vậy họ mất nhiều thời gian hơn để làm cho đúng (và sau đó họ nên nói như vậy, không đoán được sẽ mất bao lâu)
• Họ không quen với nhiệm vụ trong tay (sau đó họ nên đề cập đến điều đó và bao gồm nghiên cứu trong ước tính)
• Việc tích hợp tác vụ hoàn thành với sản phẩm lớn hơn mất nhiều thời gian hơn dự kiến ​​(điều này có thể có nghĩa là kiến ​​trúc của sản phẩm kém hơn)
• Nhà phát triển thích phát minh lại bánh xe và làm như vậy vấp phải những vấn đề đã được giải quyết bởi những người khác, có sẵn miễn phí trong thư viện
• Các thay đổi được giới thiệu bởi chủ sở hữu sản phẩm trong khi nhiệm vụ đang được thực hiện, đòi hỏi một cách tiếp cận khác và làm lại công việc đã được thực hiện
• Các nhà phát triển không làm việc trong môi trường năng suất (vì vậy khi ở nhà, họ đoán sẽ mất hai ngày, nhưng tại nơi làm việc, họ sẽ cần tám lần để bù đắp cho tất cả những phiền nhiễu)

Để đặt tên cho một vài điều.

Có lẽ tốt nhất là hỏi các nhà phát triển của bạn tại sao họ nghĩ rằng ước tính của họ bị tắt. :-)

Bạn sẽ không phải là người đầu tiên trong một cú đánh dài để cố gắng tìm ra cách tốt nhất để lên kế hoạch cho thời gian phát triển. Điều này một phần là do thực tế là rất khó để định lượng thứ gì đó mà bạn thực sự không thể nhìn thấy được xây dựng, và một phần là do tháng nhân vật huyền thoại , trái ngược với ý tưởng trực quan rằng nếu bạn có 2 lập trình viên, bạn nên có thể phát triển nhanh gấp đôi so với khi bạn có 1 lập trình viên.

Như bạn có thể đã nhận ra, nó phức tạp hơn thế nhiều. Một cách tiếp cận để ước tính thời gian phát triển khi làm tròn một nhóm các cá nhân có trình độ cao về những gì liên quan đến phát triển phần mềm và yêu cầu họ ước tính thời gian cần thiết để hoàn thành một dự án (giải thích chi tiết nhất có thể). Bạn lấy cao nhất trong tất cả các ước tính và bạn nhân đôi nó. Vâng, bạn đọc đúng. Bạn nhân đôiước tính cao nhất và bạn sẽ có một ước tính chính xác hợp lý. Tôi biết, bởi vì theo thời gian, đây là cách tôi có thể nói chính xác với sếp của mình mất bao lâu để tôi làm một việc gì đó. Tôi thu thập ý kiến ​​của các lập trình viên đồng nghiệp của tôi và ước tính cao nhất của tôi và nhân đôi. Nếu giá trị này có vẻ quá cao, hãy xem xét rằng việc kiểm tra chức năng mới là rất quan trọng và xem xét các sửa lỗi tiềm ẩn sau đó, và nó có vẻ như là một con số hợp lý hơn.

Theo kinh nghiệm cá nhân của tôi với tư cách là một lập trình viên, tôi có thể nói với bạn rằng nó giúp chia nhỏ các dự án thành các mốc quan trọng. Mất bao lâu để đạt được cột mốc 1, sau đó từ cột mốc 1 đến cột mốc 2, rồi cột mốc 2 đến cột mốc 3, v.v.? Khi chia nhỏ như thế này, câu trả lời thường chính xác hơn nhiều so với việc cố gắng ước tính toàn bộ dự án. Thật kỳ lạ, nếu bạn tổng hợp các ước tính của tất cả các mốc này, nó thường sẽ lớn hơn ước tính ban đầu cho toàn bộ dự án (nếu lập trình viên trung thực với chính mình), điều đó chỉ khiến tôi nghĩ rằng chi tiết đó là chìa khóa đây.

Có lẽ bạn thiếu bí quyết kỹ thuật, nhưng bạn vẫn nên cố gắng làm theo ở cấp độ tổng quát hơn. Lập trình viên không có vấn đề với sự lặp lại. Đó là những khúc quanh và lần lượt chiếm hết thời gian trong việc phát triển một chương trình. Vì vậy, rất có thể, càng nhiều chức năng mà bạn muốn đưa vào, chương trình sẽ càng trở nên phức tạp hơn và giả sử chức năng mới này không ảnh hưởng đến các phần mã được triển khai trước đó, việc phát triển sẽ theo tuyến tính theo số lượng công việc được làm. Nhiều khả năng, chức năng mới nặng nề ảnh hưởng đến phần thực hiện trước đây và do đó phát triển liên quan đến việc không chỉ thực hiện các chức năng mới nhưng sửa chữa các mã cũ, làm cho thời gian phát triển theo cấp số nhân.

Lời khuyên của tôi cho bạn là, không cần nói cho các lập trình viên cách thực hiện công việc của họ, hãy cố gắng nắm bắt cách thức chương trình hoạt động ở cấp độ chung và bạn sẽ sớm có thể thấy chức năng mới sẽ sửa đổi hành vi đó như thế nào và do đó cung cấp một ước tính hợp lý về thời gian cần thiết để làm điều đó. Kết hợp điều này với ước tính của họ (gấp đôi mức cao nhất) và bạn bắt đầu hiểu rõ hơn về cách ước tính thời gian phát triển.

Tôi hy vọng điều đó sẽ giúp!

Một trong những lý do ước tính thường bị loại bỏ là vì ước tính thực sự khá khó khăn và đòi hỏi kinh nghiệm và kiến ​​thức về hệ thống phải được thay đổi. Thông thường rất hữu ích để phá vỡ các bước lớn lên thành những bước nhỏ hơn.

Bây giờ bạn có nhiều khả năng của những người tôi sẽ đề cập đến hai:

• Lập kế hoạch chơi bài
• PERT (Chương trình đánh giá và đánh giá chương trình)

Lập kế hoạch chơi bài

Điều này hoạt động khá tốt trong các nhóm nhanh nhẹn.

Trích từ wikipedia:

• Người điều hành, người sẽ không chơi, chủ trì cuộc họp.
• Trình quản lý sản phẩm cung cấp một tổng quan ngắn. Nhóm nghiên cứu được trao một cơ hội để đặt câu hỏi và thảo luận để làm rõ các giả định và rủi ro. Một bản tóm tắt của cuộc thảo luận được ghi lại bởi Quản lý dự án.
• Mỗi cá nhân đặt một thẻ úp xuống đại diện cho ước tính của họ. Các đơn vị được sử dụng khác nhau - chúng có thể là thời lượng ngày, ngày lý tưởng hoặc điểm câu chuyện. Trong quá trình thảo luận, các số không được đề cập ở tất cả liên quan đến kích thước tính năng để tránh neo.
• Mọi người gọi thẻ của họ đồng thời bằng cách lật chúng lại.
• Những người có ước tính cao và ước tính thấp được cung cấp một hộp xà phòng để đưa ra lời biện minh cho ước tính của họ và sau đó thảo luận tiếp tục.
• Lặp lại quá trình ước tính cho đến khi đạt được sự đồng thuận. Nhà phát triển có khả năng sở hữu khả năng cung cấp có một phần lớn trong "phiếu bầu đồng thuận", mặc dù Người điều hành có thể thương lượng sự đồng thuận.
• Một bộ đếm thời gian trứng được sử dụng để đảm bảo rằng cuộc thảo luận được cấu trúc; Người điều hành hoặc Người quản lý dự án có thể bất kỳ lúc nào chuyển qua bộ hẹn giờ trứng và khi hết thời gian, tất cả các cuộc thảo luận phải chấm dứt và một vòng xì phé khác được chơi. Cấu trúc trong cuộc trò chuyện được giới thiệu lại bởi các hộp xà phòng.

Các bit quan trọng ở đây là làm rõ, thảo luận, đồng thời gọi ước tính, do đó không có sự thiên vị nào được đưa ra và sự đồng thuận.

Chứng nhận

Nó thường rất khó để đưa ra một ước tính chính xác. Những gì dễ dàng hơn là đưa ra một khả năng. PERT sử dụng 3 giá trị cho ước tính:

• thời gian lạc quan nhất để kết thúc (nếu có ít vấn đề phát sinh hơn dự kiến)
• hầu hết thời gian bi quan để kết thúc (nếu mọi thứ đều sai - không bao gồm những thảm họa lớn)
• nhiều khả năng thời gian để kết thúc (nếu mọi thứ diễn ra như mong đợi) <- đây là những gì các nhà phát triển của bạn có thể ước tính ngay bây giờ

Bằng cách cân ba ước tính đó, bạn sẽ có được ước tính đáng tin cậy hơn.

t_expected = (t_opt + 4 * t_likely + t_pes) / 6

Và / hoặc bạn có thể sử dụng ba giá trị này để xây dựng phân phối xác suất có thể phản ánh sự không chắc chắn của thế giới thực hơn nữa. Phân phối Beta và phân phối tam giác là những lựa chọn nổi bật. Sử dụng điều này bây giờ bạn có thể áp dụng các số liệu thống kê như "khả năng kết thúc vào ngày x với ước tính hiện tại" hoặc "nếu tôi muốn chắc chắn 95%, vào thời điểm nào thì nó sẽ kết thúc".

Trên thực tế, PERT bao gồm nhiều hơn những khía cạnh được đề cập ở đây, mà tôi đã bỏ qua vì lý do ngắn gọn.

Có một thực tế là nếu bạn không giữ các số liệu lịch sử thì bạn thậm chí không thể tiến gần đến việc đưa ra các ước tính hợp lý với mức độ chính xác hợp lý. Và hỏi một số công ty / người khác mất bao lâu thì họ cũng không giúp được gì. Vấn đề là mỗi công ty và nhà phát triển có cách làm việc riêng của họ. Do đó, mỗi công ty sẽ có những khoảng thời gian khác nhau để thực hiện cùng một nhiệm vụ. Mỗi nhà phát triển sẽ có những khoảng thời gian khác nhau để thực hiện cùng một nhiệm vụ.

Cách hành động tốt nhất của bạn là bắt đầu theo dõi thời gian và bằng cách nào đó tìm ra cách phân loại mức độ khó cho nhiệm vụ. Một số công ty sử dụng các dòng mã, một số tính năng sử dụng, một số chỉ đi theo cảm giác ruột. Ngoài ra, bạn cũng phải tính đến nếu điều này tương tự với thứ mà các nhà phát triển đã xây dựng hoặc một cái gì đó mới, như công nghệ mới, tính năng mới chưa từng được nhóm phát triển trước đây v.v ... Ngoài ra, nếu đó là một nhúng hoặc thực- hệ thống thời gian sau đó sự phức tạp thường tăng lên khá nhiều.

Trừ khi bạn thu thập dữ liệu thực, bất kể nhà phát triển của bạn cung cấp cho bạn ước tính bao nhiêu lần, họ thực sự sẽ chỉ rút số từ phía sau mỗi lần bạn hỏi họ. Đúng, thu thập dữ liệu thực sự là một nỗi đau và lúc đầu, nó không cung cấp nhiều thông tin hữu ích, nhưng theo thời gian, nó thực sự bắt đầu cung cấp các ước tính chính xác hợp lý.

Tôi cũng muốn chỉ ra rằng các ước tính thường chỉ tốt trong bức tranh lớn và không dành cho các phép đo ngắn hạn. Ví dụ: nhà phát triển ước tính 2 ngày nhưng phải mất 8. Nhà phát triển không tính đến việc phải thiết lập môi trường thử nghiệm và phát triển trình giả lập hoặc có một công nghệ hoàn toàn mới mà họ phải học hoặc họ mắc kẹt với một lỗi họ không thể tìm ra hoặc chức năng yêu cầu tái cấu trúc hệ thống hiện có. Bạn không thể luôn dự đoán những điều đó cho các nhiệm vụ nhỏ. Tuy nhiên, trong toàn bộ dự án, 6 ngày thêm đó có thể bị cuốn trôi bởi các nhiệm vụ khác mất ít hơn 6 ngày.

Tôi đã là một nhà phát triển duy nhất trong một vài dự án nhỏ của riêng tôi và có một số kinh nghiệm công nghiệp làm việc với một nhóm lớn. Tôi đã nhận thấy rằng các kỹ thuật mà một công ty lớn sử dụng không nhất thiết phải làm việc cho một nhóm nhỏ. Tại một thời điểm tôi đã làm nhiều kế hoạch và tài liệu hơn là viết mã. Tôi khuyên bạn nên cố gắng tìm ra cách làm việc tốt trước bằng cách thử các kỹ thuật khác nhau (các câu trả lời khác cung cấp một số hiểu biết tuyệt vời) và các công cụ, điều này sẽ khiến bạn mất thời gian và công sức nhưng sau này bạn sẽ được lợi từ nó. Một số công cụ / kỹ thuật tôi thấy hữu ích là:

-Pivotal Tracker - Chương trình tuyệt vời để theo dõi các câu chuyện và khuyến khích phá vỡ các nhiệm vụ, nó nhanh chóng được nhập vào các câu chuyện và tự động suy ra vận tốc. https://www.pivotaltracker.com/ .

-Gdocs cho tài liệu vì rất dễ có nhiều người dùng chỉnh sửa và thảo luận cùng một lúc.

-Trong một công ty tôi từng làm việc cho chúng tôi đã từng có một cuộc họp cho mỗi câu chuyện mà chúng tôi khởi xướng, cuộc họp này phải bao gồm một lập trình viên cao cấp vì anh ta sẽ đánh giá được một nhiệm vụ sẽ kéo dài bao lâu. Anh ta cũng sẽ giỏi hơn trong việc đánh giá phần khó khăn có thể là gì trong một nhiệm vụ.

Tóm lại tôi tin rằng chìa khóa để làm việc trong các nhóm nhỏ là có một chế độ lập kế hoạch vững chắc, nhanh chóng và trôi chảy. Ngoài ra, bất kỳ khó khăn nào với câu chuyện đều có thể được xác định sớm để lập kế hoạch cho một nhiệm vụ sẽ ghi nhớ điều đó (điều này có thể dẫn đến việc xây dựng một cái gì đó khác biệt).

Hi vọng điêu nay co ich