Phương pháp lập trình nào sẽ phù hợp với chúng ta?


11

Thật không may, ai đó đã dạy quản lý cấp trên của chúng tôi từ "Agile" và bây giờ họ muốn chúng tôi tiến tới nó. Tôi có một sự hiểu biết ngoại vi về nhanh nhẹn (về nguyên tắc) nhưng chưa bao giờ sử dụng nó trong thực tế. Từ những gì tôi biết, nó sẽ không phù hợp với tổ chức của chúng tôi. Ngay bây giờ, mọi thứ khá grungey. Đây là cách nó diễn ra;

Chúng tôi là một nhóm rất nhỏ - hai nhà phát triển, một DBA, một nhà thiết kế. Công ty tôi làm việc kiếm được một số tiền lớn không tương xứng so với quy mô của nó và gần 95% trong số đó là bán hàng trực tuyến thuần túy.

Từ góc độ phát triển, chúng tôi phải chịu nhiều cuộc xâm lược bàn trong một ngày thông thường (chúng tôi hỗ trợ công nghệ cũng như nhà phát triển), công việc có thể thường xuyên rơi khỏi bầu trời trong một khoảnh khắc thông báo nếu một thành viên trong nhóm bán hàng hứa hẹn điều gì đó với ai đó . Chúng tôi cũng thực hiện các dự án lớn hơn và chúng là một cơn ác mộng với sự gián đoạn liên tục. Một số người trong chúng ta đang bắt đầu xé tóc ra! Các kế hoạch dự án được soạn thảo bởi các nhà quản lý không có kỹ thuật trong bảng tính excel, nơi họ cố gắng chia nhỏ nhiệm vụ thành các câu có kích thước vừa phải để họ có thể hiểu và đặt một ngày bên cạnh mỗi người. Những cuộc hẹn hò này luôn vô cùng phi thực tế và thường bị bỏ lỡ, và các cuộc họp của chúng tôi (mà chúng tôi có hàng tuần) thường đầy những khoảnh khắc khó xử với những người hỏi "tại sao điều này chưa được thực hiện".

Tôi khá chắc chắn Agile không phải là người dành cho chúng tôi. Bây giờ, cho rằng (và tôi đã cố gắng) công ty này sẽ không thay đổi cách thức của mình và chỉ có nhóm phát triển sẵn sàng thay đổi, có phương pháp phát triển nào mà chúng tôi có thể áp dụng, phù hợp với việc giúp chúng tôi tiết kiệm không?


Bạn đang mô tả chính xác một nơi làm việc cũ của tôi đến mức không thoải mái.
John N

2
Câu đầu tiên mang đến một dải Dilbert trong tâm trí. :)
MetalMikester

@MetalMikester - Tôi nghĩ mauve có nhiều RAM nhất. Đó là suy nghĩ của tôi khi đọc dòng đó là tốt.
jfrankcarr

1
Thật không may, tôi quen thuộc với một số "tính năng" của công ty nhỏ này. Tôi nghĩ rằng họ đã nhầm "Agile" là "nhanh hơn".
Smith

1
@jfrankcarr Tôi có nghĩa là hai: dilbert.com/strips/comic/2007-11-26dilbert.com/strips/comic/2005-11-16 (. nghĩ điều màu hoa cà là một người chiến thắng là tốt :))
MetalMikester

Câu trả lời:


10

Agile thực sự được thiết kế để giải quyết nhiều vấn đề chính xác mà bạn đang gặp phải. Nếu ban quản lý đã thực sự mua và không làm hỏng quá trình, bạn có thể thấy một sự cải thiện lớn. Hãy để tôi giải quyết vấn đề của bạn từng điểm một. Kinh nghiệm của tôi là với scrum, vì vậy tôi sẽ nói từ quan điểm đó, nhưng tôi chắc rằng các triển khai khác có lợi ích tương tự.

  • công việc rơi khỏi bầu trời Những câu chuyện này được đặt ở dưới cùng của hồ sơ tồn đọng cho đến khi chủ sở hữu sản phẩm và nhóm có thể gặp nhau để đồng ý di chuyển nó lên. Ưu tiên của nó được xác định liên quan đến tất cả các cam kết khác của nhóm của bạn và ưu tiên đó được hiển thị cho mọi bên liên quan muốn xem xét. Sẽ cực kỳ hiếm khi thêm một tính năng mới ở giữa giai đoạn nước rút và chỉ những lỗi ưu tiên cao nhất mới được phép làm gián đoạn một lần chạy nước rút. Thật đáng ngạc nhiên khi có nhiều "trường hợp khẩn cấp" có thể đợi đến cuối tuần sau khi điều đó được mong đợi thường xuyên.
  • thực hiện các dự án lớn hơn Bạn sẽ có tầm nhìn để cho thấy mức độ ưu tiên ngắn hạn ảnh hưởng đến các dự án dài hạn của bạn. Nếu mọi người liên tục chuyển câu chuyện của người dùng trước các dự án dài hạn của bạn thì không sao, nhưng để đưa ra quyết định đó, mọi người sẽ biết tác động của nó đối với lịch trình của dự án dài hạn.
  • kế hoạch dự án được soạn thảo bởi các nhà quản lý phi kỹ thuật Câu chuyện của người dùng được cho là được viết từ quan điểm phi kỹ thuật, nhưng nhóm scrum của bạn nên được trao quyền để ước tính và xác định chi tiết thực hiện.
  • ngày tháng thật phi thực tế Nhóm của bạn xử lý tất cả các ước tính, bởi vì bạn là người biết bạn đang làm gì. Nếu những ước tính đó không được doanh nghiệp chấp nhận, họ phải quyết định cách ưu tiên các tính năng. Nếu họ cần nhiều công việc hơn bạn có thể xử lý, nhu cầu thuê thêm người sẽ được nhìn thấy rõ ràng.
  • ngày thường bị bỏ lỡ Đầu tiên, ước tính của bạn sẽ thực tế hơn, điều này sẽ giúp ích. Ngoài ra, bạn đang cắn những miếng nhỏ hơn và thực sự hoàn thiện chúng, điều này giúp doanh nghiệp cảm thấy như bạn đã tạo ra thứ gì đó hữu ích ngay cả khi không hoàn thành tính năng.
  • các cuộc họp chứa đầy những khoảnh khắc khó xử Agile có nhiều khả năng hiển thị hơn và chu kỳ phản hồi nhanh hơn nhiều, với một chủ sở hữu sản phẩm tham gia rất nhiều. Các vấn đề chặn và lý do trì hoãn của bạn không phải là một bất ngờ.
  • cũng làm hỗ trợ công nghệ Trái ngược với niềm tin phổ biến, nhanh nhẹn không tương thích với lịch trình phân chia. Các yếu tố Scrum trong sự gián đoạn của bạn vào vận tốc nhóm của bạn. Nếu bạn thường dành một nửa thời gian của mình để làm hỗ trợ kỹ thuật, bạn sẽ chỉ có một nửa vận tốc.

Điều mang lại và bán hàng phải nhận ra là nhanh nhẹn không phải là cách để kiểm soát chặt chẽ hơn nhóm phát triển, nó giúp nhóm tự chủ hơn để làm những gì họ giỏi trong khi giúp doanh nghiệp xem xét thực tế tất cả các ưu tiên của mình mỗi khi giao việc đội.


1
"Nếu quản lý đã thực sự mua vào và sẽ không làm hỏng quá trình" <- là điểm mấu chốt cho bất kỳ thành công cuối cùng nào. Tôi ước có một phép thuật nào đó để biến điều đó thành hiện thực. Nó bốc mùi khi thấy một cái gì đó bắt đầu tốt trở nên xoắn khủng khiếp.
anon

Tôi nghĩ rằng điều này phù hợp với câu trả lời của bạn ... joelonsoftware.com/articles/DevelopmentAdstraction.html
Joe Internet

Lập luận của bạn có sức thuyết phục, nhưng thật đáng buồn tôi nghĩ rằng quản lý tại công ty bưu chính ban đầu đang tìm kiếm một viên đạn bạc. Tôi không chắc họ sẽ hỗ trợ nhanh nhẹn khi nhận ra rằng họ có thể mất một số quyền kiểm soát đối với các khía cạnh của quy trình phát triển. Điều có thể sẽ xảy ra là có rất nhiều dịch vụ môi được trả cho nhanh nhẹn, một vài thứ được sắp xếp lại, và cuối cùng mọi thứ tiếp tục khá nhiều như trước đây.
Antonio2011a

10

Tôi sẽ nói rằng hãy tận dụng lợi thế của quản lý ý tưởng của bạn! Âm thanh như họ đang làm cho bạn một lợi ích và cung cấp cho bạn một số đòn bẩy để cải thiện phương pháp làm việc của bạn.

Nói với họ OK chúng ta sẽ đi nhanh nhẹn, nó đòi hỏi trong số những thứ khác: -

  • một sự tách biệt của sự phát triển và hỗ trợ
  • một quy trình thu thập yêu cầu chính thức - dưới sự kiểm soát của nhóm CNTT. "Câu chuyện" v.v ... nghe có vẻ rất mơ hồ - nhưng thực ra đây là một phương pháp "trang trọng" để ăn mặc trông không chính thức.
  • lập kế hoạch là dưới sự kiểm soát của nhóm CNTT.

Nếu họ không chấp nhận điều này thì hãy nói với họ rằng bạn không thể nhanh nhẹn.


Chúng là những gợi ý tuyệt vời nhưng chúng đòi hỏi phải thay đổi văn hóa và thay đổi văn hóa chỉ đơn giản là không xảy ra khi tiền được chuyển vào và dễ dàng.
maple_shaft

1
Có nhưng vấn đề là ban quản lý đã cho họ mở! HỌ yêu cầu các phương pháp Agile, nhóm nên quay lại với một đề xuất hợp lý, trong đó nhấn mạnh đến bản chất cấu trúc cao của các quy trình nhanh.
James Anderson

8

Agile không phải là một phương pháp lập trình, Agile là một phương pháp quản lý dự án. Nếu quản lý cấp trên thực sự muốn bạn thử dùng từ thông dụng mới mà họ đã tìm thấy, họ cần có thể hiểu rằng phương thức Agile bắt đầu từ đầu và liên quan đến việc quản lý qua từng bước. Nếu bạn cần cung cấp cho họ một liều lượng thực tế lớn, có thể tổ chức một bài thuyết trình Powerpoint 30 phút về Agile để cung cấp cho họ một chút giáo dục. Các nhà quản lý yêu thích Powerpoint.

Tuy nhiên, nếu như bạn nói, nhóm phát triển là những người duy nhất sẵn sàng thay đổi, thì không có phương pháp phát triển nào có thể giúp bạn. Nếu không giảm bớt các nhiệm vụ còn lại, sự gián đoạn sẽ tiếp tục xảy ra và bạn sẽ tiếp tục được yêu cầu đáp ứng thời hạn mà bạn đơn giản không thể đáp ứng.

Lời khuyên của tôi trong kịch bản này là giáo dục, chứ không phải quản lý, quản lý như cách nó thực sự ở trên chiến tuyến.


5
"Agile" thậm chí không phải là một phương pháp quản lý dự án. Đó là một thuật ngữ ô mơ hồ cho một loạt các phương pháp cụ thể và các ý tưởng và thực tiễn mà chúng dựa trên.
Michael Borgwardt

Và một ví dụ về Agile bắt đầu từ đầu sẽ liên quan đến việc chọn chính xác phương thức họ muốn sử dụng!
Snorbuckle

2
Một số phương thức nhanh ở cấp quản lý dự án (Scrum) trong khi các phương thức khác ở cấp nhiệm vụ phát triển (Lập trình cực đoan). Bạn cũng nói rằng các phương thức nhanh bắt đầu từ đầu, tuy nhiên cải tiến quy trình (bất kể phương pháp hay mục tiêu) có xu hướng được chấp nhận nhiều hơn khi đi từ dưới lên và bạn được mua từ mỗi cấp bắt đầu với các nhà phát triển / kỹ sư ở tầng lên thông qua chuỗi quản lý.
Thomas Owens

5

Không có phương pháp phát triển phần mềm và quản lý dự án có thể giúp đỡ trong một tổ chức nơi những người bán hàng ra lệnh theo lịch trình hàng ngày. Làm thế nào bạn có nghĩa vụ để quản lý một dự án giữa một tuần làm việc hỗn loạn và mất tập trung như vậy?

Vì vậy, nhiều nhà quản lý cấp trên nhìn thấy giá trị của Agile và muốn những lợi ích của nó nhưng họ hầu như không bao giờ có thể thực hiện các thay đổi nội bộ cần thiết để đảm bảo di chuyển thành công. Các cửa hàng Agile thành công duy nhất mà tôi biết đã bắt đầu theo cách đó. Tôi không thể nhớ lại một trường hợp duy nhất trong kinh nghiệm chuyên môn của tôi về một cửa hàng phát triển phần mềm quản lý bán hàng hoặc thác nước đang thực hiện vì nó đòi hỏi một sự thay đổi cơ bản trong văn hóa.

Là sự thay đổi trong văn hóa có thể? Có, nhưng trong trường hợp của bạn gần như chắc chắn là không.

Một sự thay đổi trong văn hóa thường là cần thiết bởi một đối thủ cạnh tranh đe dọa sự tồn tại của công ty hoặc một tình huống tạo ra hoặc phá vỡ hoặc một số tình huống liên quan tương tự khác để biện minh cho một lần tái tổ chức. Trong tình huống của bạn, công ty của bạn hoàn toàn ở đầu kia của quang phổ, nơi tiền ngay bây giờ rất dễ dàng và mọi người đều béo lên.

Các công ty KHÔNG BAO GIỜ thay đổi từ bên trong khi tiền dễ dàng. Tại sao họ, họ thành công mặc dù thất bại trong phát triển phần mềm, không phải vì thành công phát triển phần mềm.

Lời khuyên cuối cùng của tôi là nếu tôi là bạn, tôi sẽ tìm kiếm thứ gì đó tốt hơn. Mọi người ở đây có những lời khuyên tuyệt vời nhưng tôi đã thấy bài hát này và nhảy trước đó và nó không hoạt động trong tình huống của bạn.


2
maple_shaft đã đúng: Chạy! Hiện nay!
Landei

lol, tôi sợ anh ấy có thể đúng :)
Mikey Hogarth

1

nhìn vào extremeprogramming.org - XP là một dạng Agile với các khía cạnh dễ hiểu mà bạn có thể chọn và chọn một giỏ hàng; một nơi rất tốt để bắt đầu

cam kết của khách hàng không thay đổi suy nghĩ của họ trong quá trình giao thoa sẽ là nơi khởi đầu tốt cho môi trường của bạn, từ âm thanh của nó ;-)


IMHO tai ương lớn nhất của họ liên quan đến cách xử lý các yêu cầu và các nhiệm vụ được ước tính, tức là quản lý dự án. XP không mạnh về mặt đó và cũng chứa rất nhiều thứ (ví dụ lập trình cặp) có thể khiến việc chấp nhận trở nên khó khăn hơn và không trực tiếp giúp giải quyết vấn đề của họ. Vì vậy, ví dụ Scrum có thể là một lựa chọn tốt hơn cho người mới bắt đầu. Tất nhiên, XP và Scrum kết hợp tốt, nhưng XP chỉ nên được xem xét ở giai đoạn sau.
Péter Török

Tôi không nghĩ rằng đó là một ý tưởng tuyệt vời cho một người mới nhanh nhẹn để chọn và chọn thực hành một giỏ hàng. XP hoạt động vì các thực tiễn cùng nhau khuyến khích và thúc đẩy các hành vi mong muốn. Để có kết quả tốt nhất, việc may đo chỉ nên được thực hiện khi nhóm có thêm một chút kinh nghiệm.
Michael

@Michael: trong một số môi trường, bạn phải luộc ếch từ từ ;-)
Steven A. Lowe

@ StevenA.Lowe: Đó là sự thật - nhưng người mua hãy cẩn thận với việc may sớm. Đó là nơi các thuật ngữ như "Scrum-but" xuất phát từ, như trong "Vâng, chúng tôi đang làm Scrum, nhưng chúng tôi không thực hiện [chèn thực hành ở đây]" dẫn đến các vấn đề nghiêm trọng nếu bạn không biết bạn là gì đang làm
Michael

1

Nếu người ta xem xét cảnh quan của các phương pháp, cả truyền thống và đương đại, người ta sẽ nhận ra rằng "Agile" là một "phương pháp chống đối" hơn là một phương pháp. Các mẫu nhằm mục đích mô tả giải pháp "trường hợp tốt nhất" cho một vấn đề nhất định trong một bối cảnh cụ thể. Nỗ lực vi phạm trực tiếp một giải pháp hoặc mô hình như vậy, thường được gọi là "chống mẫu" hoặc thực tiễn trong trường hợp xấu hơn. Tương tự như vậy, trong khi các phương pháp phát triển phần mềm thực sự cố gắng quy định các thực tiễn trong trường hợp tốt nhất trong việc phát triển các giải pháp, thì "Agile" (Scrum, XP, v.v.) cố gắng vi phạm trực tiếp bất kỳ và tất cả các cấu trúc trong quy trình phát triển phần mềm, có lợi cho sự hỗn loạn, hỗn loạn Cách tiếp cận - mà (cuối), dường như cũng đòi hỏi những tràng pháo tay từ người xem (ngây thơ).

Như đã nói, thật phù hợp để ghi nhớ bối cảnh mà triết lý Agile nảy sinh. Mặc dù phương pháp lặp tinh vi (ví dụ Quy trình hợp nhất) tồn tại vào thời điểm đó, phương pháp chính vẫn là phương pháp thác nước cũ, quy định "thực hành tốt nhất" về phân tích yêu cầu hoàn chỉnh, sau đó hoàn thành thiết kế, sau đó phát triển / mã hóa giải pháp, sau đó thực hiện giải pháp. Rõ ràng, cách tiếp cận kỹ thuật để phát triển phần mềm này không được khuyến khích - và dẫn đến hàng đống giấy tờ trước đó (và đôi khi không bao giờ) nhìn thấy một giải pháp thực thi.

Tuy nhiên, nó vẫn không đảm bảo việc vứt bỏ em bé bằng nước tắm, như trường hợp của những người biểu tình của Agile. Cách tiếp cận Agile gần như thực thi phủ định trực tiếp bất cứ thứ gì được sử dụng trước nó - ngoại trừ có thể là mã hóa thực tế của giải pháp. Rõ ràng, đây là một dấu hiệu của cái nhìn sâu sắc hạn chế về phía người sáng lập ra nó, hoặc có thể nó chỉ đơn giản là một trường hợp "không có gì là mù, như những người không muốn nhìn thấy".

Tuy nhiên, ưu điểm của agile là nó khuyến khích các quy trình được sắp xếp hợp lý và tập trung vào mã thực thi - điều chắc chắn là khả năng cung cấp cuối cùng của bạn.

NGAY BÂY GIỜ, để trả lời câu hỏi của bạn trực tiếp hơn:

Đưa ra cái nhìn tổng quan về môi trường của bạn, trước tiên tôi khuyên bạn nên chọn triển khai Agile (ví dụ Scrum, XP, v.v.). Sau đó, tùy chỉnh cách tiếp cận để phù hợp với môi trường của bạn, phác họa một quy trình rõ ràng về cách nhóm của bạn sẽ làm việc, ví dụ:

  • Nhận yêu cầu từ người dùng;

  • Ưu tiên người dùng yêu cầu;

  • Gage tác động của việc tăng cường trên hệ thống hiện tại (có thể trong các cuộc họp độc lập hàng ngày / hàng tuần của bạn);

  • Ước tính thời gian phát triển của mỗi cải tiến - và truyền đạt lại cho những người dùng yêu cầu khác nhau;

  • Thực hiện (các) cải tiến thực tế trên hệ thống hiện có (tức là mã hóa).

  • Tiến hành kiểm tra người dùng - và nhận cam kết từ người dùng (ví dụ qua email) rằng các thay đổi được yêu cầu đã được thực hiện thành công.

Điều này sẽ cung cấp một số cấu trúc (và trật tự), đồng thời duy trì một số giá trị của phương pháp Agile.

Với những điều đã nói ở trên, hãy nhớ rằng bài diễn văn tiếng Anh cũ, "Agile as a khỉ khỉ, không bị gò bó mà không có lý do!


0

Tôi muốn nói rằng bạn cần một phương pháp như Agile là điều cần thiết cho nhóm của bạn. Vì công ty của bạn rất vô tổ chức, bạn cần phải có tổ chức hơn trong nhóm nhà phát triển của riêng bạn. Tôi không nghĩ tuy nhiên các nhà quản lý kỹ thuật phi kỹ thuật của bạn nên có bất cứ điều gì để làm với nó.

Nếu bạn sẽ đẩy lùi nhân viên bán hàng của mình và yêu cầu thời hạn thực tế, bạn cần chứng minh điều đó bằng các kế hoạch có tổ chức.

Ngoài ra trên một lưu ý tách biệt nếu họ đến với bạn với các ước tính mà không cần tư vấn kỹ thuật sau đó chỉ cần từ chối họ điểm trống.


1
Tôi đồng ý rằng Agile là giải pháp tiềm năng cho tai ương của họ, tuy nhiên, a) nó chắc chắn cần sự hiểu biết, cam kết và hỗ trợ mạnh mẽ từ ban quản lý, b) đẩy và từ chối chỉ tạo ra các phản ứng bất lợi làm giảm cơ hội của giải pháp (và có thể làm tăng tình cờ cơ hội bị đuổi việc :-().
Péter Török

0

Có lẽ tập trung vào các khía cạnh gia tăng / lặp đi lặp lại là những gì cả nhóm của bạn và các bên liên quan ngoài trời cần có thể cung cấp thường xuyên và nhất quán. Theo thời gian, đội ngũ bán hàng và quản lý sẽ có được niềm tin rằng khi họ đưa ra yêu cầu tính năng mới, họ có thể chắc chắn rằng nhóm của bạn sẽ cung cấp trong một khung thời gian phù hợp.

Tất nhiên, bạn cần đầu tư vào thử nghiệm đơn vị / hệ thống / hồi quy, xây dựng tự động, dogfooding, v.v., để đến đó nếu bạn chưa ở đó.


0

Đầu tiên tôi đề nghị thu thập một số dữ liệu. Ngồi xuống tại một thời điểm yên tĩnh và tìm hiểu hiện trạng thực sự là gì - cách mọi thứ được thực hiện. Nếu ban quản lý rất muốn thực hiện một cái gì đó mà họ có thể gọi là nhanh nhẹn, thì hãy tìm ra thứ gì đó có hiệu quả với nhóm của bạn, vẽ một tài liệu, tát "Agile" vào tên và bạn sẽ ổn. Hãy nhớ rằng điều duy nhất họ thực sự biết về nhanh nhẹn là từ này, và một số liên kết mơ hồ với sự nhanh chóng cho định nghĩa thông thường của nó trong tiếng Anh. Vì vậy, những gì tôi ủng hộ là nhóm của bạn đứng trước vấn đề, tìm ra hương vị phù hợp với bạn, và sau đó trình bày điều đó cho quản lý của bạn theo cách Agile (tm). Nếu không, một số PHB sẽ chọn một cuốn sách và cố gắng lắp chốt vuông vào lỗ tròn và sẽ không có ai hạnh phúc.

Nếu bạn đi với một hình thức nhanh nhẹn "thuần túy", có thể khó khăn với nhóm của bạn cũng phải hoàn thành vai trò hỗ trợ. Hãy đối mặt với điều đó, sếp của bạn có thể gặp khó khăn khi chấp nhận các thành viên trong nhóm của bạn trả lời các yêu cầu của bộ phận trợ giúp bằng cách nói "hãy để tôi tạo một mục tồn đọng, tôi sẽ nhận được điều đó trong (thời gian kết thúc nước rút) trong vài tuần."

Rào cản lớn nhất là tiền. Nếu tất cả mọi thứ là nước thịt xanh, sẽ khó hơn nhiều để nói có gì đó không ổn và cần phải thay đổi.

May mắn nhất.


0

Ngược lại, đối với tôi có vẻ như một phương pháp Agile chính xác là những gì bạn cần để đối phó với thời hạn bị bỏ lỡ, kỳ vọng không thực tế và các dự án có kế hoạch kém.

Quản lý của bạn đã chỉ ra rằng họ quan tâm đến từ Buzz mới này. Nhiều khả năng họ sẽ muốn sử dụng nó để thổi phồng việc tiếp thị sản phẩm của bạn. đây không hẳn là một điều xấu, nhưng nó sẽ cần phải được quản lý rất cẩn thận nếu bạn muốn làm cho một phương thức Agile hoạt động cho bạn.

Một nửa trận chiến đang nhận được sự mua lại từ ban quản lý. Để họ tiếp thu ý tưởng về Agile là hầu hết các trận chiến. Phần còn lại là đảm bảo rằng những kỳ vọng của họ được quản lý để họ tiếp tục muốn bạn nhanh nhẹn và tránh để họ trở nên bất mãn khi và nếu người quản lý của bạn cảm thấy như thể sự kiểm soát của họ đối với việc quản lý dự án chủ yếu là trượt qua ngón tay của họ.

Trước khi công ty của bạn quyết định bất cứ điều gì, tôi khuyên bạn nên tham gia một huấn luyện viên Agile để thực hiện một cuộc hội thảo và hội thảo nửa ngày. Làm cho bạn suy nghĩ như một nhóm - các nhà quản lý và nhà phát triển giống nhau - về những gì về Agile mà bạn cảm thấy sẽ làm việc cho bạn và những gì bạn cảm thấy sẽ không. Mặt khác, ban quản lý tin tưởng vào phán đoán của bạn, thì bạn sẽ cần phải làm quen với một số Phương thức và Phương thức Agile, và tạo một hội thảo hoặc của riêng bạn. Cá nhân, tôi hướng đến việc đưa một huấn luyện viên giàu kinh nghiệm vào, để bạn không lãng phí nhiều thời gian và để duy trì động lực. Trong lúc này, hãy lấy một bản sao của một vài cuốn sách Agile tốt làm tài liệu tham khảo, đọc kỹ, nhưng cũng để chúng treo xung quanh bàn của bạn, nơi quản lý có thể nhìn thấy chúng. Tâm lý học thăng hoa có thể làm việc kỳ diệu trong một tình huống như tình huống bạn đã mô tả.

Tôi muốn giới thiệu ít nhất là đọc những điều sau đây:

và để có thêm tín dụng (vì tôi nghĩ đó là người bạn đồng hành tuyệt vời cho những cuốn sách khác mà tôi đã đề cập):

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.