Phát triển dự án Agile tại Intel

Phát triển dự án Agile tại Intel: Một cuộc phiêu lưu Scrum của Pat Elwer, những người đóng góp trong tập đoàn Intel bao gồm Tim Gallagher, tập đoàn Intel; Katie Playfair; Dan Rawsthorne và Michael James, tập đoàn công nghệ Danube.

TỔNG QUAN

Trong nền công nghiệp phát triển vi xử lý, nhóm kỹ thuật phát triển sản phẩm (PDE) tồn tại để cung ứng việc kiểm tra có liên quan để hỗ trợ kiểm thử và phân loại thiết bị hiệu quả về mặt chi phí. Thắt chặt giữa các đội thiết kế thực tế và đội sản xuất, PDE thường chịu áp lực ghê gớm mà không giới hạn kiểm soát các hạn nộp, mục tiêu, yêu cầu hay giao hàng của nhóm. Để hợp lực của các nhóm nhỏ trong PDE, 7 nhóm bao gồm xấp xỉ 50 người tình nguyện dẫn dắt thể thống nhất hơn đạt sự phát triển sản phẩm. Để tổ chức thể thống nhất đó, những người tạo ra đã quyết định Scrum là khung quản lý dự án tốt nhất để sử dụng cùng với kỹ thuật Agile. Bài viết miêu tả chặng đường của việc tổ chức, bài học rút ra và kết quả của sự đầu tư trong Scrum.

GIỚI THIỆU

Trong việc thực hiện Scrum và Agile với thế giới kỹ thuật phần mềm, có rất nhiều practice tốt nhất. Nhiều cái liên quan đến tổ chức nhỏ và vừa sử dụng đội nhỏ, phát triển phần mềm trong các ngôn ngữ hướng đối tượng. Nhóm phát triển sản phẩm Oregon và thái bình dương (OAP) là một tổ chức lớn cần áp dung Scrum va Agile cho đa dạng nhóm, vị trí, văn hóa và môi trường. Sản phẩm công việc của chúng tôi là chương trình kiểm tra được chạy trên công cụ kiểm tra tự động (ATE). ATE có một hệ thống tổ chức độc quyền và ngôn ngữ chung giúp chúng tôi tránh khỏi sử dụng tiêu chuẩn công nghiệp, các giải pháp phần mềm sẵn có có hiệu lực. Trong thực tế, chúng tôi làm việc trong môi trường ngôn ngữ độc quyền không có khung kiểm tra sẵn có và nguồn lực kiểm tra độc lập. Thêm nữa, chúng tôi có lịch sử dài đánh bại yêu cầu, vượt quá cam kết, lỡ kế hoạch, nhiều tuần làm việc điên rồ, thiếu tình thần, và tỷ lệ luân chuyển cao.

Một lịch sử dài trong chế tạo và sản xuất có kết quả là một văn hoá waterfall mạnh mẽ trong Intel, bao quát rộng rãi như là con đường tốt nhất đến thành công. Các đội được tổ chức trong chức năng 'Silos” với lịch trình thường xuyên đưa đến các đội chức năng silo khác. Kết quả là một vài đội đảm trách những gánh nặng không bình thường trong giai đoạn cuối của vòng đời và có doanh thu cao ở cuối dự án. Cuối cùng, các đội được so sánh bởi những chuyên gia chủ yếu mà những kỹ năng hiếm khi bao phủ kỹ năng của các thành viên khác của nhóm. Do đó khó có thể không so sánh nghĩa vụ và chia sẻ trách nhiệm trong đội. Dù tất cả các thử thách, chúng tôi muốn tiến lên trước với nhiều dự án quản lý và tổ chức khác nhau với các đơn vị nhóm kiểm tra tốt hơn và trơn tru trong việc phân phối sản phẩm công việc của chúng tôi. Chúng tôi lựa chọn giới thiệu scrum cho các tổ chức từ bắt đầu của một dự án, khi hầu hết công việc là phát triển cơ sở hạ tầng tiền silicon và công việc sẵn sàng. Nếu chúng tôi có thể đưa scrum vào công việc trong suốt giai đoạn đầu này thì chúng tôi cảm thấy các practice tốt nhất được học trong giai đoạn tương đối yên bình này của quá trình có thể tìm được con đường đến với giai đoạn áp lực hơn nhiều - khi mà công việc hàng ngày phụ thuộc vào chất lượng của silicon thật sự, các điều kiện nghiệp vụ linh động bên ngoài và các yêu cầu của khách hàng chế tạo, thiết kế và sản xuất.

GIAI ĐOẠN 1: CHUẨN BỊ CHO SILICON

Nhóm chuyển tiếp ban đầu bao gồm 6 đội và một cơ số thành viên cấp dưới. Đầu tiên, chúng tôi vẫn giữ tập đoàn công nghệ Danube như là người bán khóa đào tạo và giáo dục Scrum. Xấp xỉ 20 lãnh đạo nhóm và chỉ dẫn công nghệ tham gia khóa học đào tạo chứng chỉ master Scrum trong 2 ngày như là một sự giới thiệu nồng nhiệt cho sự thực hiện và ủy nhiệm Scrum. Không may là 3 quản lý đã lỡ cuộc đào tạo và kết quả dẫn đến những trở ngại về sau qua quá trình chuyển tiếp. Thực hiện trách nhiệm đỡ đầu đã bị chê bai trong thành công của chúng tôi. Có 3 lãnh đạo vắng mặt từ cuộc đào tạo ban đầu dẫn đến có khoảng cách trong kiến thức của họ với các sự thay đổi mà chúng tôi có gắng tạo ra.

Sau khi đào tạo, các thành viên tham gia cuộc họp nhìn lại và thảo luận mà không có đại diện Danube xuất hiện, suy nghĩ, sự hạn chế và cam kết của họ đến một sự tiếp cận Scrum của quản lý dự án. Lãnh đạo các nhóm đồng ý cam kết 3 tháng của nguyên tắc công cụ Scrum và thực hiện theo sách vở trước khi đặt câu hỏi sự hiểu quả của tiến trình mới hay cố gắng thử thay đổi nó cho nhu cầu của Intel. Một đội hành động quá trình (PAT) được thành lập để giám sát sự phát triển của Scrum trong những đội chỉ dẫn và đưa ra sự hỗ trợ cho các câu hỏi quá trình. Thậm chí sự đồng thuận đã ở đó, tôi có thể trực giác thấy sự chia cách tổ chức thành “lợn” và “gà” trong những đội hỗ trợ Scrum.

Lãnh đạo nhóm và đội chức năng như Product Owner cho tất cả 7 đội, trong đó tôi làm việc như là Scrum Master. Tôi cảm thấy mãnh liệt rằng Scrum là một khung công việc quan trọng để thực hiện trong các đội và tôi đang quyết tâm nhận lấy sự mạo hiểm để thành vô địch. Mặc dù kết quả của việc chấp nhận mạo hiểm là tích cực, tôi gần như không tồn tại đủ ¼ của 7 đội Scrum mastering.

Làm việc với tư vấn Danube là Michael James và Dan Rawsthorne, chúng tôi xác định rằng có tình nguyện viên Scrum Master là điều quan trọng cho sự thành công của mỗi đội và sự lành mạnh vốn có của họ. Đầu tiên chúng tôi làm việc với quản lý Intel để đảm bảo rằng vai trò của Scrum master có giá trị trong hệ thống đánh giá sự thể hiện như là công việc kỹ thuật thật sự hơn chỉ là quản lý chung. Thứ hai, người mà bước lên nhận vai trò Scrum master làm trong đội mà họ không có đóng góp kỹ thuật. Điều này giúp tránh bất kỳ xung đột của sự quan tâm giữa dự án kỹ thuật của họ với trách nhiệm cố vấn. Ngân sách không tồn tại cho Scrum master để đưa cho công việc kỹ sư của họ để giúp công việc scrum master. Tuy nhiên, hỗ trợ cho mượn cho sự thay đổi nhẹ nhàng trong vài trò sản phẩm cho những ai bước lên hướng dẫn tiến trình trong vai trò scrum master.

Sau 3 tháng, có thêm 3 scrum master quản lý 7 nhóm. Thêm vào đó, một đội 8 người tình nguyện để bắt đầu sử dụng scrum.

Sau gần 5 tháng, scaling work bắt chéo các đội Scrum trở thành một thử thách lớn nhất. trước khi thêm 5 đội nữa được thành lập qua phần còn lại của năm, tổ chức cần thêm kiến thức trong việc làm thế nào để quản lý các phần phụ thuộc giữa các nhóm đa dạng và thuận tiện hơn cho sự giao tiếp trong nhóm. Danube lần nữa giữ lại để phát triển khóa học scaling scrum làm vừa lòng khách hàng cho các thành viên đầu tiên của khóa chứng chỉ scrum master với những nhà quản lý bị lỡ lớp đầu tiên. Đào tạo dài ngày nhắc lại vấn đề chính như đưa ra kế hoạch, kế hoạch nước rút, và đặc biệt là scaling chéo các nhóm đa dạng. Chúng tôi lần nữa nhận lấy “học, cố gắng, kiểm tra và thích ứng” đạt được scaling này.

Sau khi học một vài practice tốt nhất cho scaling, chúng tôi đưa kết quả trở lại các nhóm để thử một trong những mộ hình scaling từ lớp học và sau đó chắp vá cách tiếp cận đến môi trường thực tế của các nhóm. Sau khi thêm vài vai trò đảm nhiệm phần kỹ thuật phụ thuộc và thêm các tầng trong tổ chức, nhóm có thể giãn ra đến 12 đội scrum, một đội gồm xấp xỉ 5-9 nhà phát triển trong 1 năm.

2 trong số khía cạnh nguyên bản của sự chuyển tiếp tổ chức thành công mà chúng ta thảo luận với tư vấn Danube là tình nguyện và tự tổ chức. Mặc dù các nhóm cam kết thời hạn thử 3 tháng theo đúng sách vở scrum đã được yêu cầu bám sát các bài thực hành và nguyên tắc cốt lõi, sự thích nghi rõ ràng là quan trọng hơn là sự tôn trọng triệt để. Một thái độ thử nó từ sự quản lý kết quả là sự đồng thuận nhóm. Sau 3 tháng thử nghiệm, các đội bản thân tự do tổ chức và kiểm tra, đạt được kết quả mỗi đợt nước rút. Mặc dù các đội cần làm việc cho họ. Sự chệch hướng đã được thảo luận, nhưng không kết tội trong cuộc họp PAT với tất cả PO và scrum master mỗi tuần. Mục tiêu của chúng tôi trong giai đoạn này là tính đồng nhất , không phải đồng dạng. Tính minh bạch cũng là cốt yếu trong dự án. Một wiki nội bộ cho phép các đội soạn thảo văn bản làm việc cho họ, cái không làm việc tốt, và các gợi ý thực hiện tốt nhất cho việc thích nghi Scrum.

Thực hiện đầy đủ Scrum theo đúng sách vở là một phần nguyên của việc dấn thân vào Scrum chéo các đội. Tuy nhiên, ở một tổ chức cỡ như OAP, cần thiết để khuyến khích các cấu trúc doanh nghiệp chắc chắn hay các yêu cầu. Sau giai đoạn 3 tháng chỉ dẫn, một vài sự cải biên được tạo ra để làm Scrum phù hợp trong văn hóa và môi trường của chúng tôi. Đầu tiên, đội phải xác định vai trò nào là thực dụng nhất cho mục tiêu của họ. Chúng tôi đã phát triển các sự mô tả vai trò sau đây:

Business Owners: Các quản lý cấp cao của các kỹ sư chính được giao nhiệm vụ bao quát các đội đa dạng hay uốn các vấn đề kỹ thuật cho tất cả các đội. Bos thiết lập bản đồ các giai đoạn quan trọng (đưa ra kế hoạch) và xác định đặc điểm mong muốn ở mỗi cột mốc. Các đội Scrum vẫn sở hữu kích thước và cam kết đạt tới đặc điểm cột mốc dựa trên tốc độ của họ

Product Owners: Những người quản lý nhóm chức năng điển hình

Technical Owners: kỹ thuật dẫn dắt từ mỗi lĩnh vực chức năng nơi có thể cộng tác trên sự thống nhất, phụ thuộc và kiến trúc đưa ra để đảm bảo thích hợp giữa các đội với sản phẩm phụ thuộc. TOs tổ chức cuộc họp quảng cáo cho sự sụp đổ của thiên anh hùng ca thành những câu chuyển nước rút.

ScrumMasters: Một kỹ sư chéo đội với không có đóng góp tiền đặc biệt nào trong sự án, anh ấy hay cô ấy là một Scrum Master. Điều đó giúp kiểm chế sự thúc đầy Scrum master can thiếp vào các giải pháp kỹ thuật

Teams: Đội được giao đầu ra riêng biệt của hệ kiểm tra, hiếm khi với các thành viên đội chức năng chéo. Hầu hết luôn là đội chức năng silo.

Transient: các thành viên nhóm với kỹ đăng cao đặc biệt cần thiết bới các đội đa dạng không chỉ 1 lần nước rút hay 2 trong 1 thời kỳ. Họ đến và đi tại giới hạn gấp rút.

Conduit: Thành viên đội người đại diện cho hơn 1 người bao gồm các người giám sát đấu thầu hay các thành viên địa phương của đội điều khiển. Các conduit có thể ký nhận nhiều điểm câu chuyện hơn của công việc hơn là thành viên nhóm bình thường

Story owners: Một chuyên gia kỹ thuật với kiến thức đặt biệt làm thế nào để hoàn thành story, là người có thể phát triển nhiệm vụ và yêu cầu đặc biệt của các thành viên trung tâm trong việc hoàn thành nhiệm vụ. Người bạn có thể đến và hỏi “cài gì là tình trạng của vấn đề này” và có được câu trả lời đúng mỗi lần.

Cuối cùng, suốt giai đoạn phát triển sản phẩm, toàn thể nhóm của đội Scrum đã là khách hàng cốt lõi của nó. Chúng tôi chỉ xây cơ sở hạ tầng để hỗ trợ silicon debug và sản xuất. Không có đặc điểm trung tâm yêu cầu bắt buộc suốt giai đoạn đầu hay cả dự án. Điều đó tạo giá trị doanh nghiệp một metric khó cho sự ưu tiên. Do vậy, POs và Bos cố gắng ưu tiên các đặc điểm với sự kết hợp của ước lượng giá trị doanh nghiệp và sự ưu tiên chung, hầu hết như là chiến lược quản lý phụ thuộc .

Đến kết thúc của năm đầu tiên, Scrum đưa cơ bản gốc rễ trong tổ chức và trở thành khung không đầy đủ cho việc lên kế hoạch công việc của chúng tôi và quản lý các yêu cầu của chúng tôi. PAT có dữ liệu giá trị trong sự chắp vá đã và đang không hiệu quả. Silicon lờ mờ ở chân trời. Tiến trình có giữ được dưới áp lực kinh doanh thực sự hay nó bị ném qua cửa sổ vì lợi ích làm việc theo cách cũ?

GIAI ĐOẠN 2: SILICON CÒN LẠI

Silicon đầu tiên là một giai đoạn khó khăn để trở thành kỹ sư phát triển sản phẩm. Nếu bạn đánh dấu nó trên biểu đồ Stacey, nó có thể là pixel đúng nhất trong không gian hỗn độn. Khi silicon đến, tất cả yêu cầu không rõ ràng và nó mất vài tuần để thu thập những dữ liệu cần thiết trên phương thức silicon để xác định con đường mà dự án sẻ trải qua.

Tôi quyết định quay lại và “thanh tra và sửa lại cho hơp cách tiếp cận của tổ chức tôi với Scrum dựa trên cái mà tôi đã thấy xảy ra ở silicon đầu tiên. Điều mà tôi thấy thật sự ngạc nhiên. Tôi có một đôi Scrum đã trở lại thói quen cũ. Một vài scrum khác quyết định họ hoàn thành ở silicon đầu tiên và giải tán một cách thanh nhã. Phần còn lại trung thành với scrum như người đang chìm với cuôc đời bảo quản.

2 tuần nước rút của chúng tôi đã không thể duy trì trong môi trường này và hầu hết đội scrum đã đi đến nước rút 1 tuần thay thế. Họ có thể bắt kịp 1h mỗi ngày để lên kế hoạch 24 h tiếp theo và xem lại, phản ánh trên cái trước. 4 cuộc họp của Scrum sụp đổ dưới trọng lượng của silicon đầu tiên đến cuộc họp đơn lẻ. Tuy nhiên, khi tôi tham dự các cuộc họp đó, tôi đã thấy rằng thói quen cốt lõi của Scrum- như giá trị doanh nghiệp dựa trên sự ưu tiên, kích cỡ nhóm, không làm ngoài backlog, cập nhật tương đương và phát triển dự án công cụ theo số nhiều và xem lại sản phẩm công việc- là tất cả cái xảy ra, chỉ trên cái cân nhỏ hơn và nhanh hơn nhiều như kiến thức của các phương thức đã phát triển.

Trong cuộc họp debug hàng ngày, nơi tất cả người lãnh đạo và quản lý của tổ chức tham dự, tôi có nghe bất kỳ yêu cầu quảng cáo được đưa ra theo Po nói “có một câu chuyện trong backlog” Tôi cũng thấy nhiều ví dụ mà trong đó nhà phát triển đã tước đoạt cổ đông hay PO và lôi kéo họ vào công cụ kiểm tra để chứng kiến rằng nội dung được thêm vào dự án của họ để thỏa mãn tiêu chuẩn chấp nhận được của họ . Giai đoạn của debug mạnh mẽ và phát triển đã diễn ra trong vài tuần. Cuối giai đoạn, Scrum còn lại nổi bật lên nguyên vẹn và mở rộng sự nước rút của họ quay về 2 tuần, như một đàn accordion. Sự thay đổi được thông báo trong cuộc họp debug vào T6, diễn ra qua cuối tuần, 2 tuần nước rút được duy trì trong nỗ lực hôm nay.

GIAI ĐOẠN 3: CHUẨN BỊ CHO SẢN XUẤT

Bởi vì silicon trở nên tốt hơn và chúng tôi đã chuẩn bị bệ sản xuất, tôi thông báo rằng scrums silo chức năng đã bị căng bới chuyển giao trong môi trường tiền silicon. Sự chuyển giao thực hiện bất kỳ khi nào trách nhiệm, kiến thức, hành động và sự phản hồi lại được tách biệt (trong nom):

• Một người quyết định làm gì (trách nhiêm)

• Nguời khác xác định nó được hoàn thành ntn (kiến thức)

• Người thứ 3 thực hiện nó (hành động) và

• Người thứ 4 đánh giá công việc (sự phản hồi lại)

Thêm vào đó, Luật của Conway nói rõ rằng các tổ chức mà thiết kế hệ thống bị ếp buộc cho các thiết kế sản phẩm là bản sao chép của cấu trúc kết nối của tổ chức này (Conway). Tôi đã biết đội chức năng chéo là một phần của Scrum bythe-book và tôi cảm thấy rằng họ đã giải quyết trở ngại đặc trưng, nhưng khong tìm ra giải phát hiệu quả cho thiết lập chúng ngoài tổ chức.

Trong suốt thời gian đó, tôi có thống báo một số nhiệm vụ bắt buộc được thiết lập để giải quyết vấn đề của khái niệm silicon. Ở Intel, một nhiệm vụ bắt buộc là một đôi chức năng được thiết lập để đáp lại sự khủng hoảng. Nếu bạn tham gia một nhiệm vụ bắt buộc đó là bởi vì bạn là một chuyên gia. Bạn ngay lập tức chịu trách nhiệm đến thành công của nhiệm vụ bắt buộc, bạn đánh rơi bất kể điều gì bạn đang làm và bạn không thể nói Không. Tôi không thể thấy làm thế nào để có lợi ích chức năng chéo của nhiệm vụ bắt buộc mà không thay đổi cấu trúc tổ chức.

Tôi đã lên lịch trình một cách trùng khớp một vài khóa đào tạo dựa vào phát triển sản phẩm với Marry và Tom Poppendieck cho nhóm trong khung thời gian và đào tạo Lean đã bộc lộ manh mối quan trọng là làm thế nào để sử dụng Scrum hiệu quả trong giai đoạn này:

Giữa các nhóm chức năng: Cấu trúc tổ chức hiệu quả như kiến thức và chuyên môn kỹ thuật sâu ở đây. Họ cũng cho các thành viên đội Scrum một vị trí để trở về giữa các dự án.

Sáng tạo Scrum đặc điểm chức năng chéo: Đội chức năng cho mượn trách nhiệm chuyên môn cho những nhóm Scrum đặc điểm chức năng chéo. Thành viên đội scrum chức năng chéo 100% cống hiến và không bị ảnh hường bởi quản lý chức năng của họ trong suốt gd nước rút.

Khi tôi nghe vậy, nó thật sự vang dội trong tôi. Scrum chức năng chéo là một nhiệm vụ bắt buộc mà không có sự khủng hoảng.

Chúng tôi đã chạy chỉ dẫn nhanh trên một kiểu khái niệm và các thành viên nhóm thích như vậy. Sự chuyển sao giảm đi đáng kể. các thành viên nhóm có thể tụ lại trong các vấn đề. Giao tiếp và kỹ năng theo trơn tru. Và nếu chức năng thành viên nhóm đặc thù không cần trong sự gấp rút, họ có thể so sánh với các thành viên nhóm khác để đào tạo chéo và giúp đỡ khi có thể.

Một lần nữa,sự tính toán thời gian là tất cả. Dữ liệu dẫn dắt chức năng bắt chéo này cuộn lại đúng thời điểm cho cuộc họp lãnh đạo thường niên. Đây đã là một cơ hội to lớn ảnh hưởng đến sự lãnh đạo tổ chức và tạo ra tiến trình đúng mà nó cho phép Scrum đến chức năng thậm chí còn tốt hơn trước. I đã trình bày sự quan sát của tôi và dữ liệu ban đầu từ chỉ dẫn chức năng chéo đơn lẻ và sự tổ chức đã được bán. Thực tế, tất cả naysayers, cũng như phần không quyết định của tổ chức, đã ký vào quan niệm chức năng chéo scrum. Nó thêm 5 Scrum mới cho quá trình của chúng ta, đem đến tổng ảnh hưởng lên 18 Scrum hơn 2 năm.

NHÌN LẠI

Tôi sử dụng giản đồ đơn giản + và – để diễn tả cái làm tốt và cái chưa.

Định nghĩa mạnh mẽ của sự hoàn thành (+)

Từ khi chúng tôi không có một ngôn ngữ chương trình thật sự, chúng tôi không có một khung kiểm tra đơn vị hay sự thoái lui offline. Trong nền công nghiệp phát triển sản phẩm vi mô, kiểm tra đơn vị nghĩa là kiểm tra đơn vị silicon. Nó dẫn chúng ta tập trung vào việc viết những câu chuyện hay và quan trong hơn cả là viết tiêu chuẩn tốt được chấp nhận. Tiêu chuẩn được chấp nhận (AC) đưa ra một khái niệm mạnh mẽ của sự hoàn thành bởi chi tiết các yêu cầu cho sự thỏa mãn của khách hàng.

Chúng tôi cũng thực hiện quá trình kiểm tra nhẹ nhàng mà chúng tôi gọi là “pair review” . Để hoàn thành câu chuyện, nhà phát triển và PO hay cổ đông phải ngồi lại với nhau và nhất trí rằng AC phải đạt được. Chúng tôi thu thập các metrics đơn giản trong hành động này ở bảng của Cộng thêm, bảo vệ, và trốn thoát.

Cộng thêm là thêm AC rằng SH/PO thêm vào câu chuyện trong suốt quá trình Pair review được chấp nhận bởi nhà phát triển cho nước rút hiện tại và là một chỉ số nhập nhằng câu chuyện AC. Bảo vệ là các lỗi được tạo ra trong qua lúc nước rút và vị bắt trong lúc nước rút. Trốn thoát là lỗi được tạo trong sprint truocs và tim thất trong sprint hiện tại. Bảo vệ chỉ ra quá trình kiểm tra có hiệu quả, trong khi “trốn thoát chỉ ra nó cần phát triển.

Thêm vào đó, chúng tôi phải xác định quá trình phê chuẩn thiết thực. Sự phế chuẩn có thể không khái quát chéo Scrum như kiểm tra,vậy mỗi Scrum chứng minh qui tắc phê chuẩn của nó, một cách thực chất định nghĩa có ý nghĩa được hoàn thành với phê duyệt cho sản phẩm của nó. Sự phê chuẩn phải đảm bảo câu chuyện sẽ làm đúng chức năng trong sản phẩm công việc đưa ra và thường xuyên liên quan việc chạy các phướng thức trong công cụ kiểm tra.

Một câu chuyện chỉ hoàn thành nếu tất cả nhiệm vụ được hoàn thành và nó được kiểm tra và đánh giá.

Không có lòng tin thiên vị (+)

Khi xác định tốc độ có sprint tiếp theo, không lòng tin nào được cho các câu chuyện mà không hoàn thành dựa trên xác định trên của chúng tôi. Đó dường như hà khắc, nhưng cần thiết để dẫn các đội tập trung vào các yêu cầu tốc độ và có giá trị và đảm bảo ước tính của họ bảo gồm các bước đó. Nó có thể dẫn đội tới sự tập trung vào các cam kết. Nếu bạn cam kết 100% hoàn thành và bạn chỉ đưa ra 90%, bạn thất bại.

Sprint 9 ngày (+)

Chúng tôi nước rút 9 ngày và giữ các cuộc họp xem xét lại, hồi tưởng và lên kế hoạch vào ngày t6 khác. Cách đó đội luôn ở ngoài sprint mỗi cuối tuần. Điều đó thật sự giúp tăng chất lượng cuộc sống và động lực của đội scrum. Mỗi cuối tuần là đoạn giữa của sprint và các thành viên đội có thể quyết định trong số bản thân họ nêu ho cần làm việc cuối tuần để đạt mục tiêu. Có thể điều đó hiếm khi xảy ra sau 6 tháng đầu và chúng tôi đạt một nhịp điệu lặp lại và tốc độ chống đỡ được.

Nhịp điệu (+)

Nhịp chín ngày sprint cho phép Pos, Bos và các đội thay đổi trực tiếp như một sự cẩn thiết, khoảng cách thường xuyên. Nhịp điệu đó thực sự giúp giảm các yêu cầu đánh bại mà chúng tôi đã nhìn thấy trong các dự án trước và các nhà quản lý cấp cao bắt đầu thấy rằng đội có thể sản xuất sản phẩm công việc mỗi thứ 6 khác. Dữ liệu chúng tôi thu thập thể hiện 10-20% tốc độ bị mất khi 1 sprint gián đoạn đột ngột. Chúng tôi gọi đó là sprint gián đoạn thuế. 10% của tốc độ bị mất nếu sự gián đoạn đến trong tuần đầu cảu sprint và 20% nếu nó đến vào tuần t2. Các nhà quản lý được đánh thức với sự thông kê này. Họ bắt đầu tôn trọng nhịp điệu của các chu kỳ kế hoạch. Chúng tôi cũng thêm vào một qui luật mà bất kỳ sự thay đổi nào của 1 sprint hành động dẫn tới một sự điều chỉnh lại của nơi phát huy. Một lần nữa, sự quản lý đã đáp lại và khi sự gián đoạn là cần thiết, họ thường đến để chuẩn bị loại bỏ các vật khỏi backlog.

PO ở trong đội (-)

Vì ý nghĩa của sự giao tiếp thuận lợi hơn giữa PO và đội, chúng tôi cho phép PO phục vụ như là các thành viên đóng góp của mỗi đội. Trong một vài trường hợp, nó vận hành khá tốt những một số khác, Pos quản lý vi mô các đội, mệnh lệnh các nhiệm vụ hàng ngày, và giao tiếp thành thật cản trở giữa các thành viên đội. Điều đó dẫn đến các đội giữ các cuộc họp bí mật để thảo luận các sự cản trở tổ chức thật sự mà không có quan sát của PO/quản lý chức năng của họ. Mặc dù các trường hợp xuất hiện để giải quyết quá nhiều, họ làm tất tật khả năng tự tổ chức của đội. Khi chúng tôi xây dựng scrum chức năng chéo chúng tôi không cho phép điều đó.

Công cụ scrum trung tâm (+)

Scrum yêu cầu ghi sổ cho metrics hữu dụng chung, như đốt cháy biểu đồ mỗi ngày. Đó đặt biệt đúng khi chạy đa dạng scrum hay scrum của scrum trong tổ chức của bạn. có một trung tâm, các công cụ mở thêm vào góp phần tạo nên thành công của chuyển đổi. Khi chúng tôi bắt đầu cuộc hành trình, tôi không thể tìm công cụ hỗ trợ Scrum của scrum, do vậy chúng tôi tự tạo ra của riêng. Chúng tôi bắt đầu với Xplanner và đo lường nó chính xác với java va soap cho thứ chúng tôi gọi là Xplanner 2. Dựa vào những thứ đã học được, chúng tôi tạo bảng windows kh. Công cụ trung tâm là chìa khóa giúp có thể quản lý đa dạng nhóm. Trong khi tôi tin tưởng rằng bạn có công cụ để có thể và thuận lợi cho large scale scrum, lời đề nghị bản thân sẵn có cân nhắc điểm mà tôi có thể không đưa sự tiếp cận phát triển quê hương lần nữa.

Backlog đồ sộ (-)

Quản lý một backlog thêm vào cũng là một thử thách. Nếu bất kỳ ai, bất kỳ lúc nào, có thể thêm bất kỳ vào dữ liệu của một đội, có có thể cảm giác như đội bị dội bom với các yêu cầu. một vài Pos muốn khóa dữ liệu của họ ko có phép thêm từ các thành viên khác hay cổ đông. Công cụ của chúng tôi cho scrum đạt những cậu chuyện mới trong đống khác các câu chuyện chấp nhận. PO có thể sau đó xem lạ mỗi câu chuyện mới, thảo luận với cổ đông, và phân tích câu chuyện một cách thích hợp. chúng tôi cũng thực hiện một người đóng băng cho các câu chuyện mà chúng tôi đã biết chúng tôi không thể cho vào một vài sprint. Cổ đông có thể thấy rằng các yêu cầu của họ trong sự đóng băng và dự liệu chính chỉ là 3-5 sprint sau.

Các điểm story (+)

Từ khi hầu hết các đội không có khung chung của sự tham khảo, hầu hết scrum sử dụng ý tưởng các ngày, kích thức cân xứng tốt hơn, nhưng khó hơn để có hầu hết scrum của tôi. Chúng tôi theo dõi các sử dụng từ “các ngày” khi nói chuyện với cấp quản lý các hơn không quen với scrum. Chúng tôi nhanh chóng chuyển sang các điểm khi xem lại dữ liêu với bên ngoài.

Các nhiệm vụ nhận ít hơn 1 ngày(+)

Vứt hết sự ước lượng hàng giờ khỏi cửa sổ là giải phóng đội và người quản lý. Các câu chuyện được chỉ định một mức độ khó trong các điểm câu chuyện và các nhiệm vụ là các thứ đơn giản được làm gấp đôi hay ko làm gì cả, một nhiệm vụ luôn ít hơn 1 ngày, vậy nên một người làm nhiệm vụ nhiều hơn 1 ngày chúng tôi biết họ có thể bị cản trở.

Theo dõi sự đốt cháy trong Scrum hàng ngày (+)

Metrics và sự đại diện có thể thấy được của trạng thái cũng quan trọng để thành công hẹn gặp. Một biểu đồ sprint đốt cháy chứng tỏ hiệu quả trong các đội cảnh báo nếu họ bị bỏ lại sau và có cuộc đối thoại với Pos về trạng thái, trước khi kết thúc một sprint. Scrum master đã đem đến trong biểu đồ đốt cháy mỗi ngày. Kết quả là, không ai đi bộ đến cuộc họp ra soát lại bị sốc bới cái gì đó đã hay chưa hoàn thành.

Sự xem xét lại tăng lên (+)

Chúng tôi không thích chờ đợi cho đến khi cuộc họp xem xét lại để tìm kiếm sự chấp thuận từ PO. Tiến trình kiểm tra xem xét lại song song khuyến khích PO và nhà phát triển ngồi lại cùng nhau khi câu chuyện sớm tưởng rằng sẵn sàng cho việc kiểm tra.Điều đó loại bỏ hầu hết tính bất ngờ trong cuộc họp Review nơi các sản phẩm công việc cuối cùng được xem xét lại. Nó cũng là cuộc họp ngắn hơn.

Tốc độ (+)

Sự rõ ràng của backlog, báo cáo tiến trình, và toàn bộ metrics giúp đánh giá chuyên môn quản lý thường xuyên vây nên họ có thể tạo ra các quyết định kinh doanh dựa trên sự hoàn thành thật sự của các đội. Metrics tốc độ bắt buộc Pos lên lịch trình làm việc theo khả năng. Sau tất cả, bạn không thể có 80 điểm trên 50 point team.

Thực hiện trách nhiệm đỡ đầu (+)

Hỗ trợ là chiến thắng cốt lõi cho cả đội và quản lý. Không có sự hỗ trợ cấp cao từ người quản lý tổ chức, sự chuyển tiếp không thể thành công. Sự quản lý cao hơn đưa ra hỗ trợ cấu trúc, khuyến khích cho những ai nhận vai trò lãnh đạo đọi, và cho họ danh tiếng công việc cho sự đóng góp của họ. Sự lãnh đạo cúng làm nản lòng những ai chọn phá vỡ quá trình. Sự trở ngại của con người là mục đích để đảm bảo thành công, nhưng chúng ta lại mất bất cứ người nào ở sự chuyển tiếp.

Thay đổi thói quen (+)

Cuối cùng, thói quen không được học trừ khi nó được luyện tập. Đội của tôi đã học rằng thực hành Scrum gây ra tốt hơn thói quen và kết quả Scrum. Bằng việc đàm phám phát huy thích hợp, thực hành ưu tiên, đưa ra yêu cầu rõ ràng, bám vào các hộp thời gin, theo dõi metrics và mục tiêu tự tổ chức đội, Scrum tồn tại và lớn manh 2 năm sau khi bắt đầu.

KẾT QUẢ

Scrum sẽ tạo ra một tác động mạnh trong 4 cái chính: thời gian chu trình, kế hoạch thực hiện, động lực, sự thông suốt.

Giảm thời gian chu trình:

• Scrum đóng góp chính làm giảm 66% thời gian chu trình.

Kế hoạch thực hiện:

• Chúng tôi thiết lập và duy trì lên kế hoạch dựa vào năng suất và kết quả 2 tuần cho hơn 1 năm

• Chúng tôi hầu như loại bỏ sơ suất lịch trình và lỡ các cam kết

• Khách hàng và cấp quản lý cao hơn đã thay đổi thói quen để đảm bảo kết thúc trong 2 tuần.

Phát triển động lực:

• Tăng sự giao tiếp và hài lòng trong công việc.

• Đội có động lực thấp nhất giờ là đội thể hiện tốt nhất.

• Tăng sự thông suốt.

Hướng dẫn để đạt được tiêu chuẩn: phong cách CMMI, VER, và tiêu chuẩn VAL.

Scrum không che đậy các lỗi, trở ngại , công cụ yếu và thói quen ít kỹ thuật.

Scrum là đóng góp chính để cân nhắc, nhắc lại, giảm 66% thời gian chu trình để tăng sức sáng tạo trong sản phẩm công việc. Trong khi chúng ta cũng trải qua sự cải tiến công cụ chính, chúng tôi tin rằng Scrum có thể đóng góp cho yêu cầu tăng 50%.

Kết thúc nước rút trong 9 ngày đưa ra lịch trình thiết thực có thể đoán trước được. Sự tiên đoán có chỉ dẫn thực tế làm giảm đánh bại trong yêu cầu đội như quản lý tìm kiếm để tránh trả gián đoạn thuế. Chúng tôi đơn giàn là không lỡ hạn nộp lần nào qua sự quản lý tháo vác của sự ưu tiên và muc tiêu.

Sự thoả mãn công việc đến từ mục tiêu vững chắc được thiết lập với tốc độ dựa trên kế hoạch. Nhóm cảm thấy tự hoà vô cùng về khả năng tạo và đạt được các cam kết. Động lực sẽ cao hơn và những bước đi có thể chứng minh được có giá trị lớn với tổ chức của chúng tôi .

Rất nhiều, rất nhiều các hệ thống và cách thức kỹ thuật truyền thống được đặt câu hỏi là Scrum có thể tạo sự không thích đáng hơn là có thể thấy được. Điều này dẫn chúng ta đầu tư thêm vào cơ sở hạ tầng cho phép chúng ta đạt được nhiều sự thực hiện agile hơn.

TÓM LẠI

Scrum đã phục vụ chúng ta rất tốt trong kỹ thuật phát triển sản phẩm. Yếu cố thành công của chúng tôi là truyền bá toàn công ty và tôi đang truyền bá những ích lợi của Scrum.

Chúng tôi có nhiều thất bại ban đầu và đã học được nhiều bài học đáng giá. Tuy nhiên, chúng tôi đã có một cam kết mạnh mẽ từ người quản lý của chúng tôi và lực lượng nòng cốt của những người tin vào Scrum rằng để chúng tôi quay lại làm nó tốt hơn.

Cuối cùng, tôi nghĩ chúng tôi đã tạo ra bước tiến dài trong việc thay đổi tổ chức của chúng tôi từ tổ chức mệnh lệnh-kiểm soát dựa trên kế hoạch sang tổ chức kiểm tra, thích ứng, tự tổ chức, dựa trên kinh nghiệm lập kế hoạch.

Tôi đã dạy lớp nội bộ giới thiệu Scrum và một vài thành viên từ tổ chức của chúng tôi đã tham dự. Giữa giờ, một trong số họ đến và nói: “ Thật thú vị, nhúng tôi ko biết có những quy tắc. Chỉ là cách tôi làm việc”. Thay đổi thói quen là một chặng đường khó khăn nhưng là nỗ lực đáng giá.