Làm thế nào để đối phó với các phong cách phát triển khác nhau (từ trên xuống so với từ dưới lên) trong một nhóm?


37

Giả sử bạn mới bắt đầu làm việc trong một nhóm rất nhỏ trong dự án {hiện tại tương đối nhỏ, mặc dù hy vọng sẽ lớn hơn sau này}. Lưu ý rằng đây là một dự án thực tế dự định sẽ được sử dụng bởi các nhà phát triển khác trong thế giới thực, chứ không phải một dự án học thuật nào đó có nghĩa là bị loại bỏ vào cuối học kỳ.
Tuy nhiên, mã chưa được phát hành cho người khác, vì vậy chưa có quyết định nào được đưa ra.

Phương pháp luận

Một trong hai bạn thích bắt đầu mã hóa và làm cho các mảnh khớp với nhau khi bạn đi trước khi bạn nhất thiết phải có một ý tưởng rõ ràng về cách chính xác tất cả các thành phần sẽ tương tác (thiết kế từ dưới lên). Một trong những bạn thích làm toàn bộ thiết kế trước tiên và tìm hiểu chi tiết về tất cả các thành phần và giao tiếp trước khi mã hóa một giải pháp.

Giả sử rằng bạn đang làm việc trên một hệ thống mới thay vì bắt chước các hệ thống hiện có, và do đó không phải lúc nào cũng rõ ràng thiết kế cuối phải như thế nào. Vì vậy, trong nhóm của bạn, các thành viên khác trong nhóm đôi khi có những ý tưởng khác nhau về những yêu cầu nào thậm chí cần thiết cho sản phẩm cuối cùng, chứ đừng nói đến việc làm thế nào để thiết kế nó.

Khi nhà phát triển từ dưới lên viết một số mã, nhà phát triển từ trên xuống từ chối vì các vấn đề tiềm ẩn trong tương lai được hình dung trong thiết kế mặc dù thực tế là mã có thể giải quyết vấn đề trong tay, tin rằng điều quan trọng hơn là phải thiết kế đúng trước khi thử mã hóa giải pháp cho vấn đề.

Khi nhà phát triển từ trên xuống cố gắng thiết kế đầy đủ và các vấn đề được hình dung trước khi bắt đầu viết mã, nhà phát triển từ dưới lên sẽ từ chối vì nhà phát triển từ dưới lên không nghĩ rằng một số vấn đề sẽ thực sự phát sinh trong thực tế và nghĩ rằng thiết kế có thể cần phải được thay đổi trong tương lai khi các yêu cầu và ràng buộc trở nên rõ ràng hơn.

Vấn đề

Vấn đề mà điều này dẫn đến là nhà phát triển từ dưới lên kết thúc lãng phí thời gian vì nhà phát triển từ trên xuống thường xuyên quyết định giải pháp mà nhà phát triển từ dưới lên đã viết nên bị loại bỏ do lỗi thiết kế, dẫn đến cần phải làm lại -viết mã.

Nhà phát triển từ trên xuống kết thúc lãng phí thời gian vì thay vì song song công việc, nhà phát triển từ trên xuống thường xuyên ngồi xuống để thiết kế chính xác với nhà phát triển từ dưới lên, nối tiếp hai đến điểm thậm chí có thể nhanh hơn cho 1 người làm việc hơn 2.

Cả hai nhà phát triển đều muốn tiếp tục làm việc cùng nhau, nhưng dường như sự kết hợp này thực sự giúp ích cho cả hai trong thực tế.

Mục tiêu

Các mục tiêu chung rõ ràng là để tối đa hóa hiệu quả mã hóa (tức là giảm thiểu lãng phí thời gian) và viết phần mềm hữu ích.

Câu hỏi

Nói một cách đơn giản, làm thế nào để bạn giải quyết vấn đề này và đối phó với tình huống này?

Giải pháp hiệu quả duy nhất tôi có thể nghĩ đến mà không lãng phí thời gian là để mỗi nhà phát triển làm theo phong cách riêng của họ cho thiết kế. Nhưng điều này khó hơn âm thanh khi bạn xem xét mã và thực sự cần phê duyệt các thay đổi của nhau và khi bạn đang cố gắng thiết kế một khung thống nhất cho người khác sử dụng.

Có cách nào tốt hơn?


12
Đối với tôi nghe có vẻ như anh chàng "từ trên xuống" muốn làm Big Design Up Front. Trong khi anh chàng "dưới cùng" chỉ muốn bắt đầu hack và đi đến giải pháp tăng dần.
Euphoric

24
Cả hai đều đúng. Bạn cần tìm một sự thỏa hiệp mà cả hai đồng ý. Một bên cần phải biết rằng một số thiết kế lên phía trước có thể tiết kiệm thời gian trong thời gian dài. Mặt khác cần phải học rằng tại một thời điểm, có lợi để ngừng suy nghĩ và bắt đầu làm việc.
Euphoric

8
@Euphoric: Tôi thích điều này. Một người nói cả hai đều sai, một người nói cả hai đều đúng, một người nói họ cần phải thỏa hiệp, một người nói họ nên chia nhỏ các nhiệm vụ thành nhiều phần và chỉ làm việc trên những thứ khác nhau. Thông điệp tôi thực sự nhận được là không ai thực sự biết cách tiếp cận đúng là gì!
Mehrdad

4
Từ "giao tiếp" đến với tâm trí.
Bryan Oakley

4
Ai là người quản lý? Ai đưa ra quyết định?
corsiKa

Câu trả lời:


54

Rõ ràng là cả hai đều sai.

Kẻ từ dưới lên đang hack mã và sẽ không bao giờ tạo ra thứ gì đó phải làm - nó sẽ là một cuộc hỗn chiến liên tục khi các yêu cầu chưa biết được xác định.

Anh chàng từ trên xuống có thể dành thời gian dài cho tầm nhìn kiến ​​trúc và không làm được gì hiệu quả.

Tuy nhiên, một nền tảng trung bình là lý tưởng - nếu bạn biết các mục tiêu bạn đang hướng tới (mà bạn đạt được từ một công việc thiết kế rộng) và tiếp tục với việc mã hóa nó (không có bất kỳ kế hoạch chi tiết nào) thì bạn sẽ gặt hái được phần thưởng của một hệ thống vừa có tổ chức vừa phát triển hiệu quả.

Nhân tiện, nó được gọi là Agile (không phải là phiên bản nhanh nhẹn của BS mà một số người thực hành trong đó các quy trình quan trọng hơn phần mềm làm việc) nhưng nhanh nhẹn thực sự có được khi làm việc hướng tới mục tiêu cuối cùng được mô tả và hiểu rõ.

Để khắc phục vấn đề ở đây, hãy thử một cách tiếp cận Agile (Kanban có lẽ là tốt nhất), điều này sẽ buộc cả anh chàng từ trên xuống phải làm một số việc, và sẽ buộc anh chàng từ dưới lên phải lên kế hoạch cho những gì anh ta đang cố gắng đạt được.


10
+1 cho phiên bản BS nhanh nhẹn. Ngày nay có rất nhiều người trở nên nhanh nhẹn ...
T. Sar - Tái lập Monica

17
Tôi không biết nếu câu trả lời của bạn chỉ nhận được sự ủng hộ vì lý do giật gân "cả hai đều sai" ngay từ đầu, nhưng phần còn lại của nó dường như dựa vào các giả định sai. Lưu ý trong câu hỏi tôi đã nói hai người thậm chí có thể làm việc hiệu quả hơn là làm việc cùng nhau. Vì vậy, chắc chắn không phải là trường hợp nhà phát triển từ trên xuống không hoàn thành công việc thực sự. Tương tự, nó cũng không giống như nhà phát triển từ dưới lên không sản xuất thứ gì đó làm những gì nó phải làm. Thay vào đó, hai phong cách chỉ đụng độ khi họ làm việc cùng nhau vì cách tiếp cận vấn đề.
Mehrdad

18
@Mehrdad tốt, hầu hết mọi người đều nhanh hơn khi làm việc cá nhân, nhưng bạn có được phần mềm tốt hơn khi làm việc cùng nhau - như một câu trích dẫn "nếu bạn muốn đi nhanh, hãy đi du lịch một mình. Nếu bạn muốn đi xa, hãy đi du lịch cùng nhau" . Vì vậy, bạn đã hỏi làm thế nào để làm cho những người này làm việc tốt với nhau - và tôi đã cho bạn một câu trả lời mà tôi nghĩ sẽ hiệu quả, nó ràng buộc cả hai hợp tác mà không buộc họ phải làm việc như một - một phương pháp phát triển chung mà cả hai sẽ hạnh phúc. Bạn nói rằng xung đột của họ đang ảnh hưởng đến năng suất của họ.
gbjbaanb

1
@Mehrdad Câu trả lời bạn cần nhưng không xứng đáng ngay bây giờ;)
Insane

2
@ThalesPereira "Phiên bản BS nhanh nhẹn" là gì?
Sjoerd222888

23

Hai nhà phát triển cần duy trì sự tôn trọng lẫn nhau dành cho nhau.

Người từ trên xuống cần phải tôn trọng thực tế rằng người từ dưới lên có thể đã nghĩ ra một cái gì đó thực sự hoạt động. Như một trong những giáo sư "định lượng" của tôi đã nói với tôi, "Một mô hình làm việc đáng giá 1000 lần đoán". Nếu đó là trường hợp, người từ trên xuống nên xem xét làm lại "thiết kế" của mình để phù hợp với công việc của người từ dưới lên.

Người từ dưới lên cũng nên tôn trọng "khuôn khổ" của người từ trên xuống và nhận ra rằng có thể tốt để tránh lãng phí công sức, giải quyết vấn đề sai, lạc đề, v.v ... Ít nhất là lập trình viên từ dưới lên người từ trên xuống đang cố gắng thực hiện và cố gắng giải quyết ít nhất các mối quan tâm của người từ trên xuống , như được thể hiện trong khung. Điều đó sẽ đúng ngay cả khi phần dưới-trên không đồng ý với các phần của chính khung.


7

Bạn có thể giảm thiểu việc mất thời gian của mỗi nhà phát triển nếu bạn chia các nhiệm vụ lớn thành nhiều nhiệm vụ nhỏ hơn và tập trung hơn. Để họ làm việc chặt chẽ với nhau để không ai trong số họ đi quá xa so với người khác. Chạy nước rút ngắn, và giao hàng nhỏ đi một chặng đường dài. Dễ dàng sửa một lỗi nhỏ hơn một lỗi lớn.

Nó có vẻ trái ngược với mục tiêu của bạn, nhưng lập trình cặp hoạt động. Có những thứ bạn sẽ không tự mình nắm bắt được ngay lập tức, đôi khi hàng giờ hoặc thậm chí vài ngày. Nếu không làm việc trực tiếp với các nhiệm vụ cùng nhau, hãy thử xem lại mã / đứng lên thường xuyên hơn trong suốt cả tuần.

Thông báo cho mọi người!

Nếu bạn đang thấy các nhà phát triển bỏ mã vì họ ở trong thế giới riêng của họ, bạn cần nắm bắt và hòa giải các xung đột càng nhanh và hiệu quả càng tốt. Sếp của bạn sẽ đánh giá cao điều đó và nhóm sẽ đánh giá cao việc không phải vứt bỏ công việc trong một tuần vì anh ta không biết anh chàng kia đang làm gì.

Bạn cũng nên xem họ làm việc cùng nhau như một phước lành. Việc họ đang làm việc cùng nhau và sửa chữa lỗi lầm của họ khi họ đi là một dấu hiệu tốt. Tôi đã viết được nửa chừng bài đăng của bạn với suy nghĩ "người đàn ông hai người này có thể ghét nhau ..." và tôi ngạc nhiên khi bạn nói họ muốn tiếp tục làm việc cùng nhau.

Tôi nghĩ rằng trích dẫn này là phù hợp với kịch bản của bạn.

"Nếu hai người đồng ý về mọi thứ, một trong số họ là không cần thiết." ~ Một vài ông già


7

Điều này thực sự có vẻ như một kịch bản lý tưởng với tôi. Sau đó, một lần nữa, tôi cả hai nhà phát triển cùng một lúc. Tôi muốn phác thảo "bức tranh lớn" dưới dạng ghi chú mà cuối cùng tìm đường vào một bộ theo dõi vấn đề. Sau đó, tôi bắt đầu suy nghĩ về các chi tiết thực hiện từ dưới lên. Bức tranh lớn phát triển khi tôi hiểu rõ hơn về việc các mảnh ghép sẽ khớp với nhau như thế nào, và các mảnh phát triển khi các yêu cầu thay đổi và tôi có được những ý tưởng mới.

Có lẽ đó là một mô hình tốt cho nhiều bộ não.


5
Tôi thấy các vấn đề của GitHub là một chiến thắng tuyệt vời để loại bỏ các ý tưởng ngẫu nhiên cho các tính năng trong tương lai, các vấn đề tiềm ẩn, ghi chú cho bản thân, v.v. Nó đưa chúng ra khỏi đầu tôi, nhưng theo cách mà tôi có thể tự tin có thể tìm thấy chúng sau này.
hBy2Py

6

Theo tôi, chúng là hồ sơ bổ sung và cuối cùng có thể làm rất tốt. Cả mã hóa và thiết kế đều là các giai đoạn cần thiết trong lập trình và bạn không muốn kết thúc trong một nhóm mà không ai muốn làm X, tất cả những gì bạn cần là một chút tổ chức (xem tôi cũng có thể có một từ táo bạo!)

Điều này có thể được thực hiện thông qua giám sát như những người khác đã chỉ ra, nhưng thậm chí còn được thực hiện tốt hơn bằng thỏa thuận chung về lịch trình lặp lại khi nào cần thiết kế và khi nào mã, và tránh nói chung để mã hóa những gì hiện đang được thiết kế.

Điểm thưởng, ngay khi một dự án được chia thành các mô-đun nhỏ hơn, lập trình viên từ trên xuống có thể thiết kế công cụ mà lập trình viên từ dưới lên hiện không làm việc, biến nó thành một giai đoạn mà cả hai đều làm theo ý mình. Tuy nhiên, điều này ngụ ý khả năng của cả hai để thực hiện các điều chỉnh cần thiết khi đến lúc kết hợp mọi thứ lại với nhau.


1
+1 vì giải pháp cuối cùng là một giải pháp khả thi trong một số trường hợp, nhưng thực sự nó không thực sự khả thi ở đây. Vấn đề là lập trình viên từ dưới lên cũng muốn đóng góp cho thiết kế và lập trình viên từ trên xuống cũng muốn đóng góp cho mã. Chia hai nhiệm vụ khôn ngoan sẽ có ý nghĩa trong một công ty nơi bạn có người quản lý, thủ tướng, nhà phát triển, v.v. nhưng trong một nhóm nhỏ như thế này, nơi mọi người đều muốn làm việc trên toàn hệ thống, điều đó sẽ khiến cả hai không hài lòng khi phân chia nhiệm vụ như thế
Mehrdad

2
Lý tưởng nhất là cả hai sẽ hoạt động trên cả thiết kế và mã hóa, đó là lý do tại sao có một lịch trình, ngay cả khi nhóm của bạn nhỏ, là tốt. Chỉ cần lập kế hoạch cho một số "cuộc họp" khi cả hai có thể quay vòng câu hỏi và đóng góp về cách thiết kế / triển khai các mô-đun và phân bổ thời gian cho nhiệm vụ tiếp theo và lên kế hoạch cho cuộc họp tiếp theo. Giống như Agile ngoại trừ bạn không cần phải gọi nó như vậy;)
Arthur Havlicek

Thật không may, trong những trường hợp như vậy, anh chàng từ trên xuống sẽ tạo ra các kế hoạch, và anh chàng từ dưới lên sẽ bỏ qua chúng. I E. cả hai sẽ tiếp tục làm việc riêng của họ.
gbjbaanb

5

Một lưu ý: bạn đã nói

Giả sử rằng bạn đang làm việc trên một hệ thống mới thay vì bắt chước các hệ thống hiện có, và do đó không phải lúc nào cũng rõ ràng thiết kế cuối phải như thế nào.

Đây là một phần của vấn đề: Trừ khi bạn đang làm việc trong một dự án nhỏ cho một vấn đề đã được giải quyết, thực sự không có một thiết kế cuối đúng . Có rất nhiều thiết kế có thể. Hãy nhớ rằng trừ khi bạn làm điều này để tăng cường bản ngã do vẻ đẹp của mã của bạn, mục tiêu cuối cùng là một ứng dụng hoạt động. Đó là nó. Làm thế nào bạn có được điều đó là không liên quan, và cách tốt nhất để cho hai người này đi nhanh là để họ làm việc cùng nhau, theo cách bổ sung.

Giống như những người khác đã nói, cả hai quan điểm có thể đúng theo những cách nhất định. Không có gì lạ thường khi hai nhà phát triển không đồng ý với thực tiễn, đặc biệt là đối với những thứ chủ quan như quy trình thiết kế và phát triển. Bạn đã có hai người ở đây đam mê những gì họ làm và hiểu biết về cách thực hiện: nắm lấy điều đó!

Có một tiềm năng lớn ở đây để bạn cho phép cả hai người làm việc theo cách riêng của họ, và vẫn kết hợp các phần để có được một ứng dụng làm việc.

  1. Tôi muốn hai người họ ngồi lại thảo luận, khuyến khích họ nhìn nhận nó từ quan điểm của người kia.

  2. Sau cuộc thảo luận đó, bạn có thể bắt đầu nói về việc lập kế hoạch: điều này nên được thực hiện với tư cách là một nhóm, với sự hiểu rằng không cần phải 'thừa nhận' cho người khác, nhưng sẽ phải thực hiện các thỏa hiệp. Có rất nhiều cách để lập kế hoạch kiến ​​trúc cho một cơ sở mã cho phép nó được mở rộng khá dễ dàng sau này, mà không cần đưa ra một tấn mã bổ sung.

  3. Một khi bạn có thể khiến họ đến với một loại đình chiến nào đó, hãy để họ chạy hoang dã! Hãy để ổ đĩa của anh chàng từ trên xuống xuống lập kế hoạch kiến ​​trúc, giao diện, phân cấp cao, v.v. Hãy để anh chàng 'từ dưới lên' nhảy vào và bắt đầu viết mã khi có một vài mô-đun được lên kế hoạch. Khiến họ đồng ý chính thức chấp nhận các phương pháp của người khác là tốt cho toàn bộ dự án: Lập kế hoạch cho phép thay đổi dễ dàng trong tương lai là tốt, nhưng không cần phải mã hóa ngay lập tức. Tạo giao diện và loại bỏ các phương thức để có được cấu trúc của mã và chấp nhận rằng một chút mã tốt cho tương lai sẽ không thực sự được viết cho đến khi cần.

  4. Yêu cầu họ xem xét cả thiết kế và mã thường xuyên, cùng nhau. Lặp lại qua các chu kỳ trong đó bạn đi sâu vào một số phân đoạn của kiến ​​trúc, lên kế hoạch chi tiết hơn và viết các phần đó.

  5. Đây có lẽ là điểm quan trọng nhất: Tạo điều kiện cho các điểm trong chu trình mà họ chỉ nói về quá trình, thay vì công việc đang được thực hiện. Suy ngẫm về sự năng động đang được xây dựng: có bốn câu hỏi bạn nên đặt ra. Điều gì đã diễn ra tốt đẹp mà chúng ta nên tiếp tục làm? Điều gì đã đi kém mà chúng ta nên ngừng làm? Chúng ta đang thiếu gì? Chúng ta có thể làm gì về những gì chúng ta đang thiếu?

Điều này sẽ mất một số công việc: bạn phải khiến họ đồng ý làm việc theo cách riêng của họ. Không dễ để một số người thừa nhận rằng không có một cách làm đúng, duy nhất. Điều quan trọng không phải là cách bạn làm việc, hoặc mã cuối cùng trông như thế nào; điều quan trọng là hai người có kỹ năng, hiểu biết này học cách làm việc tốt nhất với nhau. Đó không phải là thứ bạn có thể nói với họ; tất cả những gì bạn có thể làm là hướng dẫn họ thông qua một quá trình học cách tự làm. Giống như không có ai thiết kế đúng, không có ai đúng cách để mọi người làm việc.


4

Nói chung, theo kinh nghiệm của tôi trong sự nghiệp của tôi, không có đủ thiết kế phía trước. Và thiết kế xảy ra ở phía trước là chất lượng thấp . Điều này tệ đây. Chủ yếu là vì kết quả là (ở mức độ lớn hơn hoặc thấp hơn) ném bùn vào tường và nhìn thấy những gì gậy. Nợ kỹ thuật được nướng từ đi.

Từ trên xuống thường vượt trội so với từ dưới lên. Mặc dù tôi sẽ không loại trừ hoàn toàn từ dưới lên. Lý do cho điều này là từ trên xuống buộc bạn phải suy nghĩ về vấn đề rộng hơn và đặt câu hỏi tốt hơn . Điều này củng cố điểm đầu tiên ở trên ... dẫn đến thiết kế chất lượng cao hơn và thường ảnh hưởng lớn đến phần lớn công việc cấp thấp hơn. Điều này làm giảm đáng kể công việc lại thường cần thiết nếu các thành phần cấp thấp hơn được xây dựng trước.

Có một rủi ro không đáng kể là nếu các thành phần từ dưới lên được xây dựng trước, áp lực phát triển cố gắng tạo ra các yêu cầu kinh doanh cho các thành phần đã được thiết kế. Điều này cũng tệ. Yêu cầu kinh doanh nên thúc đẩy thiết kế, mà nên thúc đẩy việc thực hiện. Bất cứ điều gì đi theo cách khác sẽ dẫn đến kết quả kém hơn.


2
"Không đủ thiết kế lên phía trước. Và thiết kế xảy ra ở phía trước là chất lượng thấp." - Chất lượng thấp của thiết kế phía trước thường chính xác là lý do bạn không thấy nhiều như bạn muốn.
1172763

1
+1 cho "Yêu cầu kinh doanh nên thúc đẩy thiết kế". Trong trường hợp không có yêu cầu kinh doanh, bất kỳ thiết kế trả trước nào cũng chỉ là thủ dâm tinh thần, tuy nhiên không có yêu cầu kinh doanh thì việc hack đi sẽ gần như luôn lãng phí thời gian và tiềm năng làm nản lòng thời gian và công sức khi bạn phát hiện ra rằng mình đã lãng phí quá nhiều công sức vào việc gì đó là vô dụng
maple_shaft

1
@ user1172763 thiết kế chất lượng tốt> thiết kế chất lượng thấp> không thiết kế. Ngay cả công việc thiết kế kém nhất cũng chứa một số giá trị ít nhất là nó tập trung vào tầm nhìn, tức là nó hoạt động để hướng dẫn bạn đi đúng hướng. Không có kế hoạch có nghĩa là không có hướng có nghĩa là hỗn loạn cuối cùng.
gbjbaanb

4

Không phải cách tiếp cận là đủ. Dường như mỗi người trong số họ đều thông minh hoặc đủ kinh nghiệm để nhận ra những lần đến ngắn của cách tiếp cận khác (có thể họ đã bị đốt cháy?) Nhưng không thể thấy những lần đến ngắn của cách tiếp cận được chọn của riêng họ ...

Sự thật là, một cách tiếp cận hỗn hợp là cần thiết:

  • gần như không thể đưa ra thiết kế trả trước "đúng"; một mức độ thử nghiệm là cần thiết để xác định các điểm đau, nút cổ chai, ... (gợi ý: chúng không bao giờ là nơi bạn nghĩ chúng sẽ ở)
  • Gần như không thể đi bất cứ đâu chỉ bằng cách "đi", bạn có nhiều khả năng kết thúc ở một nơi nào đó mà bạn không muốn hoặc chỉ chạy trong vòng tròn, hơn bất cứ điều gì

Trộn cả hai, tuy nhiên, bạn có thể:

  • có một bản phác thảo thô đưa ra hướng dẫn và bộ xương của cơ sở hạ tầng
  • và phát triển các thành phần phù hợp với tầm nhìn này

Bởi vì không có hệ thống hiện có nào đáp ứng mục đích này tồn tại, điều quan trọng là phải nhận ra rằng:

  • thử nghiệm / tạo mẫu sẽ là cần thiết
  • lặp đi lặp lại, do đó, sẽ là cần thiết

Do đó, cần tập trung vào hệ thống "làm việc" càng sớm càng tốt, ngay cả khi điều này có nghĩa là bỏ qua các trường hợp góc, v.v ... Đây là khái niệm về "lát dọc mỏng": thay vì xây dựng nền móng của ngôi nhà , sau đó là các bức tường, sau đó là cấu trúc mái, ... và chỉ có được thứ gì đó có thể sử dụng được ở cuối (hoặc không bao giờ có được nó, hoặc nó cũng không thực sự có thể sử dụng được) ... tốt hơn là thay vào đó , trước tiên nên xây dựng một căn phòng được trang bị đầy đủ , như phòng tắm. Nó có thể sử dụng ngay lập tức và có thể được sử dụng để thu thập phản hồi.

Tuy nhiên, để phản hồi có giá trị, tốt nhất bạn nên xử lý phần cốt lõi trước tiên.


Vì vậy, những gì làm với đồng nghiệp của bạn?

Điều đầu tiên là cả hai cần phải hiểu nhu cầu hợp tác và cần phải đồng ý về con đường phía trước: liên tục bị quở trách, giống như họ, bị ràng buộc phải căng thẳng và ảnh hưởng đến động lực của một người. Tôi đã trình bày ở trên những gì tôi thấy là hoạt động tốt trong thực tế trên nhiều dự án, bạn có thể sử dụng nó làm đề xuất.

Sau đó, họ cần phải đồng ý về việc ai làm gì. Lưu ý rằng trong cách tiếp cận giữa mặt đất được gạch chân ở trên, cả hai nên thực hiện tốt các nhiệm vụ mà họ đánh giá cao.

Lưu ý rằng cả việc xây dựng các bộ xương và xây dựng các viên gạch được tiếp cận tốt nhất tăng dần.

  1. Cả hai nên có một bản phác thảo sơ bộ về bộ xương, và sau đó quyết định cùng nhau "cắt lát mỏng" nào để tập trung vào trước
  2. Anh chàng từ dưới lên nên bắt đầu làm việc với phần "lát mỏng" được hiểu rõ nhất
  3. Anh chàng từ trên xuống nên bắt đầu làm lộ bộ xương, lý tưởng nhất là giải quyết các phần chặn nhất trước tiên để hoàn thành lát cắt

Rửa sạch và lặp lại cho đến khi bạn làm cho lát cắt hoạt động; tích lũy thông tin phản hồi trên đường đi để điều chỉnh khi cần thiết.

Coi chừng: đây là một nguyên mẫu, cả hai cần phải sẵn sàng để vứt nó đi và bắt đầu lại từ đầu trên một thiết kế hoàn toàn khác.


Xóa 4 từ hàng đầu, chúng là một cú đấm không cần thiết (và hoàn toàn mâu thuẫn với câu trả lời cân bằng khác này).

1
@Tibo: Thật là khó tính, nếu chúng ta thậm chí không thể lay chuyển mọi người một chút ...: D
Matthieu M.

Đồng ý :) Tôi có xu hướng thích rung chuyển những người sống trong một tòa tháp ngà, hy vọng mọi thứ sẽ vỡ tan dưới chân họ. -1 -> +1 btw.

Cuối cùng, một người khác nhìn thấy sự khôn ngoan trong việc đưa ra một nguyên mẫu từ đầu đến cuối với chức năng tối thiểu nhưng toàn diện ra khỏi cửa càng sớm càng tốt. Cảm ơn câu trả lời này, tôi rất thích đọc nó.
Phân tích mờ

3

Những gì bạn cần là một nhà lãnh đạo (hoặc người giám sát), người hiểu về phát triển phần mềm và là người đưa ra quyết định về cách tiếp cận nào sẽ được sử dụng trong dự án. Nếu cần thiết, nhà lãnh đạo chỉ đạo các nhà phát triển làm việc theo một cách riêng, không phân biệt sở thích cá nhân của họ.

Giải pháp hiệu quả duy nhất tôi có thể nghĩ đến mà không lãng phí thời gian là để mỗi nhà phát triển làm theo phong cách riêng của họ cho thiết kế.

Trên thực tế, nó thể rất kém hiệu quả ... bởi vì rất có thể sẽ có rất nhiều xung đột và làm lại. Tệ hơn nữa, bạn có thể kết thúc với một thất bại tổng dự án.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.