Có ngày giao hàng cố định cho các yếu tố cách thức làm việc của Agile không?


47

Chúng tôi tiếp tục được thông báo rằng chúng tôi sẽ làm việc một cách nhanh nhẹn trong một dự án mới của quản lý cấp cao. Họ đã thiết lập các bản dựng, lập kế hoạch chạy nước rút, hồi tưởng, v.v. một. Kế hoạch này đi ra đến quý 2 năm 2017.

Đối với tôi điều này có vẻ giống như Thác nước theo nghĩa tồi tệ nhất, một kế hoạch không có đầu vào từ đội kỹ thuật đã được lập ra trong đó những câu chuyện nhất định trong kế hoạch rất không rõ ràng và không ai được nhóm dev phát hiện.

Tuy nhiên, tôi biết lập luận của họ sẽ là "các bên liên quan cao cấp phải có ngày và phải có kế hoạch, chúng tôi không thể làm việc từ một hồ sơ tồn đọng." Đối với tôi điều này có vẻ như các bên liên quan cao cấp đã không mua vào Agile và do đó chúng tôi cam chịu thất bại khi thực hiện nó ở cấp độ thấp hơn.

Đây có phải là một bản án công bằng hay tôi phản ứng thái quá với kế hoạch này!?


28
Những gì quản lý của bạn đưa ra hoàn toàn không liên quan gì đến Agile.
Euphoric

13
"Điều này có vẻ giống như Thác nước theo nghĩa xấu nhất" - bằng mọi cách có nghĩa là không thích Thác nước, nhưng nó không tuân theo mọi thứ bạn gặp phải mà bạn không thích là Thác nước. Ví dụ: nếu quy trình của bạn dẫn đến việc bạn có một "đột biến" sớm, nghĩa là thực hiện một phần hoạt động của hệ thống trước khi thiết kế các phần khác, thì có lẽ bạn không thực hiện Waterfall ngay cả khi bạn không làm Agile (đúng cách ) hoặc. Nếu bạn không viết nhiều tài liệu thiết kế để đáp ứng với nhiều tài liệu yêu cầu, bạn chắc chắn sẽ không thực hiện Waterfall ngay cả khi bạn không làm Agile.
Steve Jessop

3
Ngay khi điều gì đó xảy ra có nghĩa là kế hoạch lớn là không thực tế (và nó có thể sẽ xảy ra), hãy ném toàn bộ ra. Khi quản lý phàn nàn, hãy nhắc nhở họ rằng bản tuyên ngôn Agile coi trọng giá trị "đáp ứng thay đổi theo kế hoạch". Họ sẽ bảo bạn bám sát kế hoạch và bạn sẽ có thể tự tin nói rằng bạn không làm việc theo kiểu Agile, hoặc họ sẽ đồng ý và để bạn thích nghi, và hy vọng rằng kế hoạch đó vô ích phía trước hơn bạn có thể tự tin dự đoán và lần sau, họ sẽ không lãng phí thời gian của mình vào một lịch trình chi tiết (và cam chịu) như vậy.
anaximander

3
@Kyralessa Ít nhất từ ​​kinh nghiệm của tôi, Scrum hầu như luôn được bán như một phương pháp nhanh nhẹn.
T. Sar - Phục hồi Monica

3
@kyralessa từ nghiên cứu nhanh Tôi có thể làm có vẻ như bạn là người duy nhất nói SCRUM không nhanh nhẹn. Nếu bạn có một số tài liệu tham khảo để sao lưu này, tôi rất muốn đọc chúng.
Newtopian

Câu trả lời:


60

Có một sự khác biệt giữa việc đáp ứng thời hạn và hoàn thành tất cả các yêu cầu. Nó giống như câu ngạn ngữ cũ "nhanh, tốt hay rẻ, chọn hai".

Vì vậy, ở đây bạn có ngày giao hàng cố định - điều đó thật tốt, điều đó có nghĩa là bạn được sắp xếp thời gian trong đó những gì bạn giao vào cuối nước rút cuối cùng sẽ là sản phẩm cuối cùng. Bạn nhớ rằng bạn luôn phải phát hành phần mềm làm việc vào cuối mỗi lần chạy nước rút phải không.

Điều có thể xảy ra là phần mềm cuối cùng sẽ thiếu một số tính năng. Vâng, điều này xảy ra với tất cả các phương pháp phát triển, bao gồm thác nước. Tất cả những gì sẽ xảy ra là bạn sẽ được giao nhiệm vụ sản xuất một bản phát hành bản vá sau đó hoặc phiên bản 2. Điều đó giả định rằng việc giao hàng cuối cùng của bạn là đủ tốt!

Vì vậy, ngày cố định không phải là một cách làm việc không nhanh nhẹn. Agile không có nghĩa là có ngân sách không giới hạn để bạn chơi với các công cụ lập kế hoạch mới của mình. Điều đó có nghĩa là bạn sẽ phải tập trung vào việc giao hàng, đó không bao giờ là điều xấu.


5
Điều này là đúng, nhưng nếu sau đó ban quản lý quyết định rằng họ muốn hoàn thành tính năng vào ngày giao hàng thì các nhà phát triển sẽ giữ túi. Bạn có được phiếu bầu tán thành của tôi bởi vì khi bạn chỉ ra, những gì các OP mô tả không phải là vốn trái ngược với Agile làm việc.
Cronax

3
@Cronax Mỗi người quản lý có tên sẽ hiểu thời gian và các tính năng là lực lượng đối lập. Bạn chọn cái nào là quan trọng nhất. Nếu họ quyết định rằng họ phải có tính năng đầy đủ và đúng thời gian, thì đó là lỗi của họ vì đã không điều khiển đội một cách thích hợp. (Tôi biết, tôi biết ...)
gbjbaanb

3
@Cronax đừng quá khó khăn với những người quản lý kém, doanh số thường khiến họ bỏ rơi họ.
gbjbaanb

5
Đọc điều này như đã nêu "tất cả các công việc họ muốn chúng tôi phân phối với ngày đối với từng yếu tố và giới thiệu lại ngày với những gì sẽ được trình diễn trong mỗi người", có vẻ như kế hoạch không linh hoạt với những gì được giao trong những ngày nhất định.
JimmyJames

14
Câu trả lời này làm cho một điểm tốt, nhưng nó dường như chỉ được áp dụng cho một tình huống khác. Từ câu hỏi, có vẻ như những gì sẽ được giao và khi nào nó sẽ được gửi đều được quản lý.
Ben Aaronson

37

Không. Đây là loại chính xác mà những công ty không phải phần mềm có xu hướng làm. Có kế hoạch, thời hạn và ngân sách. Và nó chắc chắn sẽ thất bại, vì con người không dự đoán được tương lai.

Chúng ta hãy đi qua các điểm khác nhau ở đây:

Chúng tôi tiếp tục được thông báo rằng chúng tôi sẽ làm việc một cách nhanh nhẹn trong một dự án mới của quản lý cấp cao.

Nếu bạn là Agile, thì bạn sẽ có các nhóm tự tổ chức, không được quản lý hướng dẫn cách làm việc.

Tuy nhiên, giờ đây họ đã đưa ra một kế hoạch chi tiết tất cả các công việc họ muốn chúng tôi phân phối với ngày đối với từng yếu tố và giới thiệu lại ngày với những gì sẽ được demo trong mỗi một.

Không. Đó là khá nhiều các phản đề của sự phát triển lặp đi lặp lại. Một cái gì đó sẽ xảy ra (ai đó bị bệnh, ai đó rời đi, một số yêu cầu đã bị lãng quên, máy chủ của bạn chết, bất cứ điều gì) và sau đó bạn bỏ lỡ một trong những mục tiêu này. Bây giờ quản lý hoặc phải tính toán lại toàn bộ kế hoạch, hoặc phá vỡ đòn roi khi phát triển.

không ai được ước tính bởi nhóm dev.

Vì vậy, như thế nào quản lý biết rằng kế hoạch này là khả thi ở tất cả ? Trong Agile, công việc là một cuộc đàm phán. Kinh doanh nói: chúng tôi muốn điều này. Kỹ thuật nói: được thôi, giả sử XYZ, sẽ mất 3 tuần. Không có sự hợp tác của khách hàng trong những gì bạn mô tả. Không có cá nhân và tương tác.

Đối với tôi điều này có vẻ như các bên liên quan cao cấp đã không mua vào Agile và do đó chúng tôi cam chịu thất bại khi thực hiện nó ở cấp độ thấp hơn.

Bạn không nhất thiết phải cam chịu, nhưng nếu không, đó chỉ là sự trùng hợp. Khi tất cả các công việc xuất hiện vì quản lý không thể nhìn thấy tương lai, bạn sẽ bỏ lỡ ngày của bạn (hoặc sản xuất mã kém chất lượng hoặc yêu cầu nhiều tài nguyên hơn dự kiến). Đó sẽ là lỗi của bạn . Quản lý có thể sẽ gây áp lực cho bạn làm việc nhiều giờ hơn để hẹn hò, hoặc có thể ném mọi người vào vấn đề.

Trường hợp tốt nhất , quản lý thực sự nhanh nhẹn và đủ thông minh để giảm phạm vi. Có nghĩa là họ chỉ dành tất cả thời gian này để xây dựng một kế hoạch chi tiết lớn mà không có giá trị.


6
Bi quan @Wildcard? Hay là chủ nghĩa hiện thực ?
RubberDuck

7
@Wildcard Và trớ trêu thay, rất tự giới thiệu, đưa ra dự đoán về tương lai ;-)
Cort Ammon

1
Wildcard đã đúng, tôi khá chắc chắn rằng chúng ta đã đóng đinh ngày mà mặt trời sẽ nổ tung hoặc thiên tai sẽ trở nên thảm khốc hơn bao nhiêu do biến đổi khí hậu, hòa bình thế giới sẽ vẫn là một trò đùa cho tương lai gần, v.v. Telastyn, chúng tôi rất giỏi trong việc dự đoán tương lai, vì vậy hãy cắt giảm những tuyên bố quá bi quan của bạn!
null

8
@wildcard - No plan survives contact with the enemy. Và bạn không thể cho tôi biết ai là người chiến thắng lớn nhất sẽ tham dự NYSE tháng 1 năm 2020. Đó là sự thật. Chúng tôi có nhiều thiên niên kỷ dữ liệu để chứng minh rằng đó là sự thật. Và biết những gì bạn không / không thể biết là hữu ích quan trọng khi lập kế hoạch xây dựng phần mềm. Hãy nhìn vào tình hình của OP - phần lớn áp đảo trong kế hoạch của họ được xây dựng dựa trên những dự đoán không tốt hơn cơ hội . Tôi nghĩ đó là một cách khủng khiếp để lên kế hoạch. Ngay cả khi bạn nghĩ rằng nó ngây thơ và gây tử vong cho tôi, thì nó vẫn không hề kém cạnh.
Telastyn

2
Hoàn toàn đồng ý rằng nó không phải là Agile, những gì được mô tả trong câu hỏi. Nhưng các mục tiêu có thể và thực hiện được mỗi ngày. Đúng là các mục tiêu chiến thuật thường yêu cầu điều chỉnh trong việc hoàn thành mục tiêu chiến lược rộng hơn , nhưng điều đó không làm cho nó không thể đáp ứng được thời hạn hoặc thực hiện trong ngân sách. Nhân tiện, tôi nghĩ rằng chúng ta thực sự có thể thỏa thuận chặt chẽ hơn dường như: Tôi đồng ý mọi người không tuyệt vời trong việc dự đoán tương lai. Tôi không đồng ý rằng điều đó ngăn cản việc hoàn thành một mục tiêu dự định.
tự đại diện

18

Nếu có một kỳ vọng rằng các bộ tính năng cụ thể sẽ được phân phối vào các ngày cụ thể, thì không, đây không phải là quản lý dự án nhanh. Quản lý dự án Agile có bản chất thực nghiệm. Dự đoán không được thực hiện dựa trên mong muốn của giám đốc điều hành mà là phân tích hiệu suất trước đó.

Mô tả của bạn phù hợp với những gì tôi coi là nhanh nhẹn tôn sùng hàng hóa. Trọng tâm là các quy trình và nghi lễ cụ thể chứ không phải các khái niệm cốt lõi của quản lý dự án dựa trên bằng chứng. Bạn có thể có một số may mắn để người kinh doanh hiểu nếu bạn liên quan điều này với Lean hoặc TPS . Vấn đề thực sự bạn cần giải quyết ở đây là khiến quản lý vượt qua nỗi sợ về những điều chưa biết. Câu trả lời đúng cho các giám đốc điều hành là "chúng tôi không thể cho bạn biết khi nào mọi việc sẽ được thực hiện nhưng một khi chúng tôi bắt đầu cung cấp giá trị, chúng tôi có thể xây dựng các dự đoán dựa trên kinh nghiệm của mình." Các nhà phát triển có xu hướng nói những điều như "nó đã hoàn thành khi nó hoàn thành" và "Tôi không biết khi nào nó sẽ được thực hiện." Các nhà quản lý sẽ không nói những điều như vậy với các giám đốc điều hành, nó làm cho chúng nghe giống như nincompoops.

Nhiều khả năng, kế hoạch sẽ thất bại và cần được sửa đổi. Rủi ro lớn nhất đối với đội là sẽ có một cú hích lớn để đạt đến thời hạn và chất lượng sẽ bị ảnh hưởng. Tại một số điểm bạn sẽ không đạt được mục tiêu (rất có thể, đó sẽ là hạn chót đầu tiên) và sẽ có một cú hích để đạt được ngày đó. Làm thêm giờ sẽ được dự kiến ​​và sẽ có áp lực để cắt góc (bỏ qua kiểm tra đơn vị, đánh giá mã, v.v.) Đây là một con dốc trơn trượt và một khi bạn bắt đầu đi xuống con đường này, đó là một chút xoắn ốc xuống và mọi thứ sẽ trở nên xấu xí. Năng suất sẽ trở nên tồi tệ hơn khi dự án tiếp tục theo cách này.

Nếu bạn có thể khiến nhóm phát triển trình bày một mặt trận thống nhất, bạn thực sự nên đẩy lùi và giữ dòng về chất lượng. Kinh nghiệm của tôi là các nhà quản lý dự án có xu hướng nghĩ đầu ra phần mềm là tuyến tính. Nghĩa là, mỗi giai đoạn X sẽ tạo ra Y 'tiền hoàn thành'. Đó là, nếu bạn không "hoàn thành 50%" trong nửa thời gian cho phép, các klaxon bắt đầu rạo rực. Trong thực tế, nếu bạn làm đúng, tính năng đầu tiên có xu hướng mất nhiều thời gian hơn tính năng thứ 50 (có kích thước tương tự.) Nếu bạn có thể vượt qua giai đoạn khủng hoảng nguy hiểm ban đầu ("chuyện gì đang xảy ra?", "Tôi không ' Không thấy bất cứ điều gì được thực hiện! ") bạn có thể sẽ ổn.


9

Chào mừng đến với kinh doanh thực sự.

Có một phong cách kinh doanh cũ hơn, mà tôi có xu hướng gọi là "phát triển truyền thống" và sau đó có một phong cách mới, "phát triển nhanh". Nếu tôi cố gắng coi những điều này là những lý tưởng đối nghịch, chúng ta sẽ thấy một sự phân chia đơn giản ở giữa: các kế hoạch và yêu cầu đi trên cột truyền thống, khám phá và tiến hóa đi vào cột nhanh nhẹn. Đó là gọn gàng, ngăn nắp, và sai.

Trong thực tế, kinh doanh là một tìm kiếm cho phương tiện hạnh phúc giữa hai. Thật dễ dàng để chỉ ra rằng một trong hai cực đoan thực sự rơi xuống trên mặt của nó. Chúng tôi, những người yêu thích Agile háo hức chứng minh tất cả các vấn đề về lý tưởng thuần túy của sự phát triển truyền thống, và có rất nhiều người có thể chỉ ra nhiều cách mà Agile thuần túy sụp đổ. Các công ty nhanh nhẹn thành công là những người tìm thấy sự cân bằng đặc biệt giữa hai. Các công ty truyền thống thành công là những người tìm thấy sự cân bằng đặc biệt giữa hai. Bạn không thể có cái này mà không có cái kia.

Ngay cả quá trình SCRUM may mắn của chúng tôi cho thấy sự cân bằng giữa hai. Mặc dù có một nỗ lực rõ ràng để tối đa hóa sự nhanh nhẹn, có một vài sự đánh đổi quan trọng được thực hiện. Chẳng hạn, Chủ sở hữu sản phẩm có công việc hùng mạnh là vận động cho tất cả các khách hàng. SCRUM cố ý không chỉ định cách thức tương tác đó hoạt động. Nó cố tình trao trả thực tế rằng mọi người cần được trả tiền vào cuối ngày. Đó là công việc của Chủ sở hữu sản phẩm để tạo ra ảo tưởng rằng điều đó không quan trọng.

(Thật thú vị khi lưu ý rằng agile thuần hoạt động rất tốt, miễn là bạn không được trả tiền cho đến khi bạn sản xuất sản phẩm và bạn không có quyền truy cập vào thông tin độc quyền cho đến khi bạn được giao. với thương mại này là các doanh nhân)

Vì vậy, ban quản lý đã ra lệnh những tính năng nào sẽ có trong đó và khi nào chúng cần ở đó. Tốt rồi. Một cụm từ tôi đã nghe là "khách hàng chọn cái gì và khi nào, nhà sản xuất chọn ai và làm thế nào." Bạn đã được đăng ký cho "cái gì" và "khi nào". Họ đã không nói bất cứ điều gì về ai hoặc làm thế nào, ngoài việc cung cấp cho bạn cơ hội sử dụng "Agile" như cách bạn làm. Tất cả những gì còn lại là để giúp quản lý hiểu có bao nhiêu người họ sẽ cần thuê để đáp ứng nhu cầu của họ.

Trong một thế giới hoàn hảo, công ty của bạn nhanh nhẹn từ bên ngoài. Nó tương tác với khách hàng của mình một cách nhanh nhẹn, cho phép các nhà phát triển phát triển nhanh chóng cho họ. Tuy nhiên, rất thường xuyên công ty phải tương tác với bên ngoài trong khi phát triển nhanh bên trong. Ở giữa luôn là một tập hợp các sự đánh đổi phức tạp, duy nhất cho mỗi công ty.

Cá nhân, tôi coi tình huống này là một trường hợp thử nghiệm cho bất cứ ai nghĩ rằng họ hiểu sự phát triển nhanh. Tại một thời điểm nào đó trong tương lai, bạn sẽ phải phát triển một sản phẩm cho thời hạn và cặp sản phẩm / thời hạn đó sẽ tương đối cố định. Nếu một sản phẩm / thời hạn cố định phá vỡ quy trình của bạn, bạn có thể thực sự nói rằng bạn là Agile ngay từ đầu không?

Lời khuyên của tôi: đừng nghĩ đây là thác nước. Bạn vẫn kiểm soát "làm thế nào." Bạn vẫn có thể thực hiện tất cả các thao tác chạy nước rút nhanh và tạo mẫu linh hoạt mà Agile rất nổi tiếng. Bạn chỉ cần lưu ý rằng cao su gặp đường và bạn phải giao hàng. Đây là thế giới thực, không phải thế giới lý tưởng. Nó sẽ tốt hơn cho họ để hỏi bạn ở nơi đầu tiên? Chắc chắn rồi. Nó có thể không phải là cuộc gọi của bạn. Có thể có hàng ngàn lý do liên quan đến kinh doanh để làm theo cách của họ mà bạn chỉ đơn giản là không hiểu đầy đủ. Hãy thoải mái đẩy lùi họ, nhưng hiểu rằng họ có thể có một lý do rất tốt cho những gì họ đã làm.


4

Agile không ngăn bạn lập kế hoạch cho các mốc quan trọng (Ví dụ: chúng tôi sẽ phát hành V 1.0 sau 3 tháng), nhưng những gì đi vào từng cột mốc không thể được sửa.

Tôi nghĩ bạn nên phản ứng như thế nào tùy thuộc vào bản chất của dự án. Nếu dự án sẽ đưa một người lên mặt trăng vào quý 2 năm 2017 thì mọi người sẽ đồng ý rằng nó sẽ thất bại. Nếu bạn nghĩ rằng bạn có thể phân phối MVP vào cuối quý 2 năm 2017, bạn nên làm việc trên nó bằng cách chạy nước rút.

Nếu quản lý nghĩ rằng nhóm của bạn đang cố gắng hết sức và bạn có thể cho thấy sự tiến bộ với mỗi lần chạy nước rút, bạn sẽ có thể đàm phán thêm thời gian.


4

MỌI dự án liên quan đến kinh doanh có những hạn chế:

  • Thời gian
  • Tài nguyên
  • Một bộ tính năng tối thiểu dự kiến

Điều này không có gì khác. Phát triển nhanh không có nghĩa là "mọi người trả tiền cho chúng tôi, vì vậy chúng tôi có thể phát triển bất cứ điều gì chúng tôi muốn bất cứ khi nào nó có thể sẵn sàng" - bạn sẽ luôn có một khung thời gian. Sẽ luôn có một số ngày với một số yêu cầu tối thiểu và nếu chúng không được đáp ứng, dự án sẽ bị hủy và được gọi là thất bại. Đôi khi chúng có thể ẩn - vì vậy người quản lý biết "Nếu tôi không có UI hoạt động với các tính năng này sau 4 tuần, dự án này chắc chắn sẽ thất bại" - hoặc có thể có các cổ đông đặt mục tiêu.

Có nhiều dự án kết quả từ pháp luật. - Nếu chính phủ quyết định bạn phải triển khai Tính năng X cho đến năm 2017 để tôn trọng luật mới, bạn sẽ có thời hạn không thể thương lượng và một bộ tính năng cần sẵn sàng. Biến duy nhất là lượng tài nguyên mà quản lý có thể phân bổ cho nhiệm vụ. - Và trong các dự án này, trong đó thời hạn là quyết định bên ngoài, họ sẽ cần theo dõi tiến trình của bạn, nghe bạn tiên lượng và nhân viên lên các nhóm hoặc thuê ngoài một phần công việc để đáp ứng mục tiêu của họ.

Tất cả điều này không phản đối sự phát triển nhanh. Bạn vẫn sẽ chạy nước rút, phát triển các tính năng của mình trong khung thời gian của riêng bạn. Bạn sẽ luôn nhận được các ưu tiên tính năng của mình từ một khách hàng - và bạn sẽ làm việc để cung cấp càng nhiều các tính năng này càng tốt cho đến thời hạn.

Nếu thời hạn thực sự sẽ được đáp ứng với các tài nguyên có sẵn là một vấn đề quản lý. Bạn có thể đưa ra tiên lượng và cập nhật trạng thái hàng tuần / hàng ngày và họ có thể quyết định xem họ có cần thêm tài nguyên không. Nếu không, bạn sẽ tiếp tục làm việc trong các lần chạy nước rút và cung cấp runnables - giống như bất kỳ dự án nào.


3

Như ai đó đã chỉ ra trước khi bản tuyên ngôn nói:

Cá nhân và tương tác qua quá trình

Tôi sẽ đề nghị bạn xem xét kế hoạch đưa ra và đề nghị thay đổi kế hoạch đó. Hãy nhớ Tuyên ngôn nói rằng tồn đọng không bao giờ là cuối cùng, nó tiếp tục phát triển.

Vì vậy, bạn có thể đưa đề xuất của bạn cho nhóm. Nếu bạn có một lý do hợp lệ và nhóm đồng ý với nó, bất kỳ chủ sở hữu sản phẩm nào xứng đáng với muối của họ sẽ xem xét chúng và evlove các hồ sơ tồn đọng để phản ánh ý kiến ​​của toàn bộ nhóm.

Đây là điểm mà nó có thể đi hai chiều.

  1. Chủ sở hữu sản phẩm và doanh nghiệp đồng ý với lý do của bạn và có thể tăng tài nguyên để đáp ứng thời hạn nếu đó là tùy chọn HOẶC họ có thể chọn bỏ một số tính năng để đáp ứng thời hạn.

  2. Họ có thể vẫn muốn bám sát phiên bản của chính họ chống lại ý kiến ​​tập thể của đội.

Nếu kết quả là # 2 thì đây không phải là Agile.

Nếu bạn kết thúc với vị trí số 1 thì tôi sẽ nói rằng nhóm đang đi đúng hướng, bởi vì Agile không chỉ là về các Dev "Phản ứng để thay đổi" mà còn về việc doanh nghiệp có thể phản ứng với thay đổi.


2

Hãy tưởng tượng bạn yêu cầu ai đó vẽ một bức tường, một ngôi nhà và sau đó là cả một con đường cho bạn, bạn sẽ dành cho người đó bao nhiêu thời gian để làm điều đó?

Dù câu trả lời của bạn là gì, bạn sẽ sai. Đó là nó.

Không có cách nào họ có thể đúng về ngày nếu họ không hỏi những người cần thực hiện công việc họ nghĩ gì.

Nhân tiện, nếu bạn (với tư cách là một nhóm) chấp nhận những ngày này, bạn đã sai ở đó.

Bạn nên yêu cầu một chút thời gian để lập kế hoạch này cùng với các bên liên quan, để bạn có thể đặt mức độ ưu tiên tùy thuộc vào mức độ dễ dàng và nhanh chóng để hoàn thành công việc.

Ví dụ, có thể tác phẩm cuối cùng sẽ mất gấp đôi thời gian họ nghĩ, nhưng họ có thể sử dụng bản beta sớm hơn nhiều so với họ mong đợi.

Nói chung, bạn không thể để mọi người nghĩ rằng bạn sẽ có thể thực hiện X trong thời gian Y nếu bạn không thể hoặc có thể nhanh hơn, đó là trách nhiệm của bạn để làm rõ về những gì bạn cần về chi tiết và thời gian.


1
Đây không thực sự là về việc chấp nhận một thời hạn. Bạn sẽ làm gì, nếu chính phủ quyết định công ty của bạn phải tuân thủ một luật nhất định cho đến năm 2017? Bạn không thể nói "Tôi không chấp nhận điều này" - bạn sẽ phải làm việc trong các lần chạy nước rút, ưu tiên và cố gắng thực hiện các tính năng cần thiết. Bạn báo cáo tiến trình của mình trong mỗi lần chạy nước rút và quản lý có thể quyết định mua thêm tài nguyên nếu số lượng tính năng bạn trình bày không đáp ứng mong đợi của họ.
Falco

-2

Nó không có kế hoạch aglie không.

Nhưng nếu bạn cho rằng bạn không biết kế hoạch và chỉ chạy nước rút bằng cách chạy nước rút. Nó có thể là aglie làm việc.

Luôn luôn có ngày và ngân sách. Luôn có nguy cơ họ sẽ bị bỏ lỡ hoặc vượt qua và khi điều đó xảy ra, bạn sẽ luôn phải quay lại kế hoạch B.

Nếu bạn đã làm việc một cách nhanh nhẹn thì kế hoạch B hy vọng là bản demo của lần chạy nước rút cuối cùng

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.