Trong môi trường Agile, người chịu trách nhiệm về kiến ​​trúc phần mềm


19

Trong một nhóm nhanh nhẹn, người chịu trách nhiệm đưa ra các quyết định thiết kế và kiến ​​trúc cấp cao có ảnh hưởng đến toàn bộ hệ thống, không chỉ là công việc đang được thực hiện trong giai đoạn nước rút hiện tại?

Có thể chủ sở hữu sản phẩm, chủ scrum, nhóm scrum hoặc người khác?

nhập mô tả hình ảnh ở đây


10
Điều này ... thật vô nghĩa ...
Telastyn

3
Sự hiện diện của tồn đọng Sản phẩm và Sprint không ảnh hưởng đến ai chịu trách nhiệm về kiến ​​trúc phần mềm. Một câu hỏi tốt hơn có thể là: Trong môi trường Agile, ai chịu trách nhiệm về kiến ​​trúc phần mềm?
Bộ sạc

Tôi đã cố gắng cập nhật câu hỏi để ít nhất có thể hiểu được. Không chắc chắn 100% nếu tôi hiểu đúng ...
Thất vọngWithFormsDesigner

Câu trả lời:


24

"Kiến trúc phần mềm được thực hiện bởi toàn bộ nhóm. Thực tiễn này không loại bỏ sự cần thiết của kiến ​​trúc sư phần mềm, nó chỉ có nghĩa là kiến ​​trúc sư đóng góp cho cuộc thảo luận với quan điểm rộng hơn và có thể có kinh nghiệm hơn, tuy nhiên tất cả các thành viên của nhóm đóng góp vào kiến trúc của phần mềm. "


5
Pure Agile có xu hướng từ chối các vai trò từ trên xuống truyền thống như "người quản lý dự án" và "kiến trúc sư hệ thống", thay vào đó, thích cấu trúc lại các vai trò đó và phân phối các trách nhiệm truyền thống của họ trong toàn đội.
Jonathan Eunice

6
@JonathanEunice: Làm thế nào điều này có thể thực tế khả thi? Không phải mọi nhà phát triển cũng là một kiến ​​trúc sư giỏi.
Giorgio

2
@JonathanEunice: Vì vậy, câu hỏi được hỏi DWD thực sự có ý nghĩa. Tôi không hiểu tất cả các downvote.
Giorgio

3
@DaveHillier: Có thể các dự án này lớn nhưng kiến ​​trúc đủ đơn giản: các nhà phát triển chỉ phải điền vào các phần trong một lược đồ khá đơn giản, lặp đi lặp lại (ví dụ: viết hàng trăm biểu mẫu tương tự trong ứng dụng dựa trên web với mô hình miền hiện có) . Mặt khác, tôi biết rằng ngay khi một ứng dụng đủ phức tạp, bạn cần có người chăm sóc kiến ​​trúc (thường trả trước) nếu không bạn sẽ phải chịu một mớ hỗn độn lớn.
Giorgio

6
"Thiết kế trả trước lớn" là lập luận nhanh nhẹn điển hình để đưa ra kết luận rằng không nên có thiết kế trả trước nào cả: một cách tiếp cận được đưa ra đến cùng cực, cực đoan đã được chứng minh và cực đoan ngược lại được đề xuất như một giải pháp. Tôi đồng ý rằng một thiết kế trả trước lớn hiếm khi là một cách tiếp cận tốt, nhưng một số quyết định kiến ​​trúc cơ bản phải được đưa ra trước để tránh tái cấu trúc lớn hoặc viết lại hoàn toàn sau này. Đây không phải là một hoạt động có thể được ứng biến "khi người ta cảm thấy mã đang trở nên quá lộn xộn và cần tái cấu trúc". Kinh nghiệm giúp tìm một sự cân bằng tốt.
Giorgio

19

Kiến trúc sư, tất nhiên, nhưng có lẽ không phải là loại kiến ​​trúc sư truyền thống.

Tôi không có nghĩa là loại kiến ​​trúc sư phẫu thuật chính làm tất cả những suy nghĩ và sau đó để những con khỉ làm tất cả các gõ. Tôi có nghĩa là một lập trình viên chính có kinh nghiệm, người hiểu được sự đánh đổi chi phí / lợi ích của các quyết định khó đảo ngược và là người tư vấn cho các đội về những việc cần làm.

Các kiến ​​trúc sư hiệu quả rất khó tìm, nhưng nó có thể là một vị trí tuyệt vời, và vì vậy bạn có thể có ít nhất một lập trình viên có kinh nghiệm, chu đáo có thể làm tốt điều đó. Một người như vậy cần phải

  • Đưa ra quyết định kiến ​​trúc tốt, tất nhiên, nhưng cũng
  • Biết cách đưa ra lời khuyên hiệu quả, để người khác cảm thấy thoải mái khi thực hiện, và cũng
  • Từ từ ủy thác các quyết định kiến ​​trúc cho các đội

Điểm cuối cùng này đi rất nhiều người lên. Khi những người theo chủ nghĩa có ý nghĩa tốt nói những điều như "Nhóm sở hữu kiến ​​trúc", họ có "quyền" đó, nhưng tôi thấy lời khuyên gần như hoàn toàn vô nghĩa trong ứng dụng của nó. Nếu bạn tin tưởng các đội chịu trách nhiệm về kiến ​​trúc của riêng họ, thì bạn sẽ không đặt câu hỏi ngay từ đầu, bây giờ bạn sẽ làm gì?! Do đó, tôi cho rằng bạn đặt câu hỏi vì có một số lo ngại rằng

  • Không ai chịu trách nhiệm và chúng tôi sẽ có một kiến ​​trúc nghèo nàn, hoặc
  • Những người sai sẽ chịu trách nhiệm và chúng ta sẽ có một kiến ​​trúc nghèo nàn, hoặc
  • Bất cứ ai chịu trách nhiệm sẽ trở thành vật tế thần và bạn đang hy vọng tránh điều đó

Nếu bạn cần ai đó chịu trách nhiệm, thì hãy đưa nó cho bất cứ ai muốn chấp nhận nó. Nghiêm túc. Người đó ít nhất quan tâm. Cung cấp cho người đó các tài nguyên họ cần để thực hiện công việc và giúp đỡ họ khi họ cần. Có lẽ không quan trọng người đó có năng lực như thế nào, bởi vì nếu họ quan tâm, thì họ sẽ cố gắng học những gì họ cần học. Đương nhiên, một người như vậy cần được hỗ trợ dưới dạng những cuốn sách hay để đọc và một cộng đồng đồng nghiệp và cố vấn mà họ có thể yêu cầu giúp đỡ và tư vấn.

Nếu bạn lo lắng rằng người sai phải chịu trách nhiệm, thì tôi hy vọng bạn biết ai là "người phù hợp" và sẽ đấu tranh để cài đặt họ như một kiến ​​trúc sư. Một cuốn sách như Bán hàng chiến lược mới sẽ giúp bạn tìm hiểu các kỹ thuật bán hàng để thực hiện điều đó.

Nếu bạn chỉ cần một vật tế thần, sau đó lặng lẽ huých người khác để giao trách nhiệm cho sự nghiệp của bất kỳ ai mà bạn muốn phá hủy hoặc làm suy yếu. Ít nhất hãy thành thật về nó.

Quay trở lại với công việc của một kiến ​​trúc sư hiệu quả, họ có thể nghĩ công việc của họ là một vị trí quản lý, thay vì chỉ là một vị trí ra quyết định. Nếu họ không ủy thác ít nhất các quyết định thường lệ nhất cho các đội, thì họ sẽ trở thành nút cổ chai và làm chậm toàn bộ tổ chức . Thêm nhiều kiến ​​trúc sư ở đầu không làm cho nó đi nhanh hơn. Tu luyện các quyết định kiến ​​trúc tốt hơn từ nền tảng sẽ. Các ban đoàn kỹ thuật sẽ giúp kiến trúc sư của bạn trở nên thoải mái hơn theo thời gian ủy thác ngày càng có nhiều quyết định để các đội bóng như những đội kiếm được tin tưởng bởi khả năng hiển thị.

Tôi nghĩ về một kiến ​​trúc sư tuyệt vời như một người giúp tôi hiểu cách thiết kế hệ thống của mình tốt hơn, người sẽ khuyên tôi kiên nhẫn khi tôi yêu cầu và đôi khi sẽ ngăn tôi đưa ra quyết định rất kém. Một kiến ​​trúc sư như vậy hoạt động như một nhà lãnh đạo theo nghĩa chân thực nhất của từ này: một người mà người khác tự nguyện làm theo .

Tôi biết đó là rất nhiều.

Tài liệu tham khảo

Miller, Bán hàng chiến lược mới . Cuốn sách này bao gồm một mô hình để hiểu lý do tại sao bạn không đóng được một giao dịch cụ thể. Tôi thấy điều này là vô giá trong việc hiểu tại sao đồng nghiệp sẽ không làm điều rõ ràng tuyệt vời mà tôi đề xuất.

Weinberg, Trở thành một nhà lãnh đạo kỹ thuật . Cuốn sách này đã giúp tôi học cách làm phần không phải kiến ​​trúc sư trong công việc của kiến ​​trúc sư hiệu quả.

Appelo, Ban đại biểu và Poker đoàn . Đừng đánh giá thấp mức độ khó của phái đoàn và mức độ chúng ta hút vào nó. Học làm điều đó hiệu quả hơn và thoải mái hơn.


1
Là 'h' chìa khóa của bạn tinh ranh? ;)
Dave Hillier

3
Không, Dave. Tôi đã sử dụng đại từ Spivak (trung tính về giới tính).
JB Rainsberger

Vì những câu hỏi như @DaveHillier đặt ra, tôi có xu hướng sử dụng "s / he" ... (Cảm ơn vì câu trả lời tuyệt vời này, đưa thực tế trở lại vào "nhóm đang / không / có / sở hữu ..." sáo rỗng)
Marjan Venema 7/11/14

1
@ jdl134679 Kiểm soát phiên bản để giải cứu: softwareengineering.stackexchange.com/posts/260541/revutions
JB Rainsberger

1
@Walfrat Sau khi suy nghĩ nhiều hơn, tôi quyết định làm rõ điểm này hơn một chút. Một người quan tâm sẽ cố gắng học những gì họ cần học, nhưng có khả năng cần hỗ trợ, chẳng hạn như một người cố vấn.
JB Rainsberger

10

Các kiến trúc , yêu cầu và thiết kế tốt nhất xuất hiện từ các nhóm tự tổ chức

- Tuyên ngôn nhanh nhẹn

Vì vậy, nhóm tự tổ chức để đưa ra quyết định kiến ​​trúc theo bất kỳ cách nào nó thấy phù hợp. Không có quy tắc cứng và nhanh, nó có thể bao gồm từ sự đồng thuận đến một "hội đồng" gồm các thành viên cao cấp nhất, để chỉ định một thành viên cụ thể là cơ quan kiến ​​trúc, để cho phép kiến ​​trúc sư chọn nếu có một thành viên có chức danh như vậy .. .


9
Tôi thích Agile, nhưng đây là một điểm yếu lớn - kiến ​​trúc thường bị bỏ quên hoặc bị trộn lẫn với nhau.
dùng949300

1
@ user949300 "Agile" như trong bản tuyên ngôn nói rất ít về kiến ​​trúc. Những phương pháp chính xác mà bạn đang rút ra kết luận này? XP sẽ khuyến khích bạn tái cấu trúc không thương tiếc. Bạn có ủng hộ BUFD không?
Dave Hillier

"XP sẽ khuyến khích bạn tái cấu trúc không thương tiếc": Cho đến khi bạn dành nhiều thời gian để tái cấu trúc hơn là viết mã mới. Tôi nghĩ giải pháp tốt nhất là tìm sự cân bằng giữa các quyết định kiến ​​trúc cơ bản mà bạn đưa ra trước khi phân tích cẩn thận và các quyết định thiết kế nhỏ hơn mà bạn thực hiện trong suốt quá trình tái cấu trúc.
Giorgio

@ user949300 đó là vì nhóm không tự tổ chức, nếu họ sẽ liên lạc thường xuyên với các thành viên khác trong nhóm bất cứ khi nào cần đưa ra quyết định kiến ​​trúc và lập tài liệu / tranh luận / thảo luận chính xác về những ý tưởng đó.
Rudolf Olah

3

Tôi cảm thấy rằng câu trả lời cho "" ai chịu trách nhiệm đưa ra các quyết định thiết kế và kiến ​​trúc cấp cao? "Phụ thuộc vào quy mô và số lượng đội.

Đối với một hoặc hai đội có 3-7 trên mỗi đội thì đội tự tổ chức có thể làm với sự dẫn dắt từ các thành viên cấp cao.

Đối với 3 nhóm trở lên, độ phức tạp tăng lên dẫn đến nhu cầu về một nhóm kiến ​​trúc có thể xem liệu các nhóm phụ khác nhau có đang làm việc sẽ giao tiếp với các nhóm khác không. Theo kinh nghiệm của tôi, điểm đó đạt được khi có khoảng 8 đội hoặc khoảng 50 người.


1

Có một số tài nguyên tuyệt vời từ nhóm Khung quy mô nhanh (SAFe) trên trang web của họ.

Về cơ bản, nó giúp bạn mở rộng quy mô nhanh trong toàn tổ chức của mình, vượt lên trên một bản phát hành duy nhất và lập kế hoạch danh mục và chương trình. Tài liệu của họ cho thấy các đề xuất về cách liên quan đến Kiến trúc sư doanh nghiệp và hệ thống của bạn trong quá trình giới thiệu sử thi kiến ​​trúc vào tàu phát hành.

Chỉnh sửa cho rõ ràng để giải quyết câu hỏi trực tiếp hơn:

Trong một môi trường nhanh nhẹn có nhiều tầng sở hữu trên kiến ​​trúc. Nhóm triển khai nhanh sẽ sở hữu kiến ​​trúc mới nổi ở mức độ thấp bằng cách tái cấu trúc khi cần thiết để tiếp tục thực hiện các hồ sơ tồn đọng của họ. Các quyết định kiến ​​trúc cấp cao hơn (hệ điều hành, trình duyệt, nền tảng, thư viện được hỗ trợ) thuộc trách nhiệm của các kiến ​​trúc sư hệ thống và doanh nghiệp của bạn. Họ sẽ làm cho các trường hợp kinh doanh khi những thay đổi này cần phải xảy ra và sẽ khuyến nghị cho những thay đổi kiến ​​trúc này được thêm vào tàu phát hành cho các nhóm thực hiện.

Vì vậy, liên quan đến các quyết định kiến ​​trúc cấp cao vượt ra ngoài nước rút, bạn thường sẽ có những quyết định này được đưa ra ở cấp độ cao hơn nhóm. Theo truyền thống, các chuyên gia này đã có vai trò 'kiến trúc sư' trong doanh nghiệp.


2
Làm thế nào để trả lời câu hỏi này, "ai chịu trách nhiệm đưa ra các quyết định thiết kế và kiến ​​trúc cấp cao"?
gnat

1
Cảm ơn bạn gnat, tôi đã cố gắng chỉnh sửa nó để làm cho nó rõ ràng hơn về ý định của tôi đã được trả lời cho câu hỏi. Tôi đã thực hiện một vài bước nhảy vọt trong đầu, nhưng quên viết chúng xuống :)
Jay S

1

Tôi nghĩ rằng hầu hết các câu trả lời khác đang nghĩ về điều này từ quan điểm của một dự án.

Nếu đó là cấp độ kiến ​​trúc duy nhất trong một tổ chức thì kết quả sẽ thực sự là hỗn loạn. Tôi đã chứng kiến ​​tận mắt sự hỗn loạn này, thật đáng buồn nó xảy ra.

Theo TOGAF, Phòng Kiến trúc Doanh nghiệp lập các kế hoạch cấp cao cho và với doanh nghiệp để tạo và thay thế môi trường CNTT. Kiến trúc sư doanh nghiệp sẽ xác định các nguyên tắc kiến ​​trúc và ký kết chúng ở các cấp cao nhất của tổ chức và sẽ giúp tạo ra các yêu cầu và kiến ​​trúc cấp cao cho từng dự án. Mỗi dự án được bắt đầu để cung cấp một khối kiến ​​trúc trong kiến ​​trúc cấp cao đó.

Vì vậy, ở cấp độ dự án, Solution Architect sẽ tạo kiến ​​trúc dự án (có thể lặp lại) và sẽ đăng xuất từ ​​Enterprise Architect.

Bây giờ, để tập trung vào một dự án nhanh. Một dự án nhanh có yêu cầu. Chúng không ở dạng một "Tài liệu yêu cầu" đồ sộ mà thay vào đó là những bản anh hùng ca và những câu chuyện. Những sử thi này vẫn cần lập kế hoạch. Bạn không gửi một nhóm các nhà phát triển trong một vài lần chạy nước rút vào nơi chưa biết. Bạn biết ở mức độ cao hệ thống cần làm gì, hệ thống nào khác cần tương tác và phần cứng / Hệ điều hành / Ngôn ngữ nào mà tổ chức có và hướng dẫn và ràng buộc các lựa chọn kiến ​​trúc mở cho Solution Architect. Ví dụ: nếu bạn đã cam kết với máy chủ .NET và SQL, bạn sẽ phải thực hiện một cách cực kỳtrường hợp hấp dẫn để triển khai trang web thương mại điện tử dựa trên Magento bằng PHP và MySQL vì chi phí liên quan đến việc hỗ trợ hai DB, hai ngôn ngữ, hai máy chủ web, v.v. Ngoài ra, một dự án có thể chọn sử dụng thư viện hoàn toàn khác hoặc giao diện khác và cảm thấy và điều này có thể có tác động đến tất cả các dự án trên chuyến bay khác. Điều cần thiết là phải có sự giám sát của Kiến trúc sư doanh nghiệp để ngăn chặn loại "Nợ kiến ​​trúc" này xảy ra.


0

Phụ thuộc vào thiết kế tổ chức của tổ chức và nếu sản phẩm nằm trong danh mục đầu tư. Các tổ chức lớn hơn, định hướng vai trò có thể chỉ định các kiến ​​trúc sư cao cấp để lãnh đạo các loại hoạt động này.

Nói chung, một kiến ​​trúc sư cao cấp sẽ tạo điều kiện và hướng dẫn các quyết định thiết kế vì chúng không chỉ ảnh hưởng đến tồn đọng sản phẩm, chúng có thể ảnh hưởng đến một số sản phẩm trong danh mục sản phẩm.

Các công ty nhỏ hơn, nhanh nhẹn có thể dựa vào các nhà phát triển là chuyên gia hệ thống để dẫn dắt nhóm phát triển sắp xếp thiết kế kiến ​​trúc.

Cuối cùng, các quyết định kiến ​​trúc cần được sự đồng ý của nhóm giao hàng làm việc trên sản phẩm. Kiến trúc sư giàu kinh nghiệm và lãnh đạo công nghệ sẽ tập trung hơn vào việc tạo điều kiện cho các cuộc thảo luận xung quanh thiết kế nên trông như thế nào, thay vì chỉ đạo thiết kế.


0

Tôi nghĩ rằng hầu hết các câu trả lời đã nhấn mạnh rằng nhóm không phải là một người nên đưa ra các quyết định này.

Những gì họ không chạm vào là một nguyên tắc Agile khác:

Đơn giản - nghệ thuật tối đa hóa số lượng công việc không được thực hiện - là điều cần thiết.

Suy nghĩ về kiến ​​trúc cấp cao và các quyết định thiết kế thường không được thực hiện một cách đơn giản, có thể dẫn đến lãng phí rất nhiều nỗ lực và thêm sự phức tạp không cần thiết có thể khiến mọi thứ khó mở rộng hơn.

Hãy suy nghĩ 'làm vườn' hơn 'kiến trúc' 'Tạo ra văn hóa sống, thiết kế phát triển

Trong quá trình lặp hiện tại của bạn, bạn nên đưa ra quyết định về kiến ​​trúc & thiết kế cho nhu cầu hiện tại của mình. Thay vì nhìn về tương lai có thể không bao giờ trở thành, hãy tập trung vào những gì bạn cần bây giờ. Có lẽ bây giờ YAGNI là một kiến ​​trúc được cân nhắc kỹ lưỡng, hãy để nhóm xử lý từng chút một.

Đọc khác:

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.