Hướng dẫn dành cho lập trình viên để bẻ khóa mã 'Làm việc hai lần, giảm một nửa thời gian'

Quản lý lý thuyết là đầy đủ các ông ngoại. Tôi đã đọc các tác phẩm của Deming, Goldratt, Ohno và Drucker. Tôi đã nghe nói về Ackoff và Juran. Tôi rất thích thái độ nhân văn và cẩn thận trong mỗi cuốn sách tôi đã đọc. Không bao giờ có chuyện: “Bóc lột người ta đến kiệt quệ”. Peter Drucker, trong cuốn "Management Rev Ed", thậm chí còn hướng dẫn chúng ta, những nhà quản lý của thế kỷ 21, những điều chúng ta nên làm:

Đóng góp quan trọng nhất và thật sự độc đáo của quản lý trong thế kỷ XX là năng suất của người lao động thủ công trong sản xuất đã tăng gấp 50 lần. Tương tự như vậy, đóng góp quan trọng nhất mà ban quản lý cần thực hiện trong thế kỷ 21 là tăng năng suất của công việc tri thức và người lao động tri thức.

Hai mươi năm nữa của thế kỷ 21, chúng ta đã tiến gần đến mức nào để hoàn thành mục tiêu đầy tham vọng này trong thế giới phát triển phần mềm? Tôi thấy rằng chúng ta còn cách xa nó. Hãy khám phá xem chúng ta đang ở đâu, chúng ta gặp phải những vấn đề gì và chúng ta có thể làm gì với chúng.

Khám phá cách tiếp cận rộng rãi để phát triển phần mềm hiệu quả

"Nghệ thuật làm hai lần công việc trong một nửa thời gian" là phụ đề của cuốn sách " Scrum " của Jeff Sutherland, đồng tác giả của khuôn khổ này. Tôi thích phụ đề này, vì nó phản ánh mạnh mẽ mức độ hiệu quả mà chúng ta có thể đạt được trong nỗ lực lập trình của mình. Tuy nhiên, không phải tất cả đều không có mây. Vấn đề đầu tiên mà chúng ta gặp phải ở đây là thật khó để hiểu thế nào là hiệu quả trong công việc của chúng ta. Vấn đề phức tạp sau đây là hiểu liệu chúng ta có trở nên hiệu quả hơn theo thời gian hay không.

Nhưng tại sao cuối cùng chúng ta lại muốn hiệu quả? Chà, đó là làm điều tương tự với ít nỗ lực hơn và trong nhiều lĩnh vực của cuộc sống, thật tuyệt khi có được kết quả tương tự hoặc tốt hơn nhanh hơn hoặc với mức giá thấp hơn.

Hãy trở lại câu hỏi của chúng ta. Những người thực hành Scrum đề xuất các điểm câu chuyện như một thước đo của một nhiệm vụ. Có một định nghĩa từ trang web scrum.org :

Story Point là một đơn vị đo lường tương đối, được các nhóm Scrum riêng lẻ quyết định và sử dụng, để cung cấp các ước tính tương đối về nỗ lực hoàn thành các yêu cầu.

Điểm câu chuyện là mức độ phức tạp liên quan đến nhiệm vụ tham chiếu. Bạn và tôi có cảm nhận được chúng ta đã phải nỗ lực như thế nào để thực hiện nhiệm vụ không mấy khó khăn đó. Nếu tôi nói với bạn rằng công việc mới sẽ tốn ba điểm câu chuyện, tôi nói rằng nó sẽ khó gấp ba lần công việc trước đó. Đó là dự đoán của tôi, và ai biết được nó sẽ khó đến mức nào.

Hãy tập trung lại vào hiệu quả. Nếu chúng tôi giao các nhiệm vụ ước tính trong 25 điểm câu chuyện trong lần chạy nước rút này, liệu chúng tôi có tốt hơn so với lần chạy nước rút trước khi chúng tôi chỉ có 15 điểm không? Hoặc có thể chúng tôi đã cẩn thận hơn và đưa ra ước tính cao hơn cho cùng một nỗ lực? Nhưng làm thế nào chúng ta thậm chí có thể so sánh? Chúng tôi không làm công việc lặp đi lặp lại trong công nghệ phần mềm ở quy mô nhà máy. Chúng tôi thiết kế và triển khai các nhà máy thông tin cung cấp dịch vụ. Có chỗ cho các cuộc đàm phán về hiệu quả trong ngành của chúng ta không?

Có một nơi cho những cuộc nói chuyện này. Ít nhất, chúng ta có thể cố tình làm mọi thứ chậm lại. Ví dụ, chúng ta có thể trì hoãn hoặc nhảy từ nhiệm vụ này sang nhiệm vụ khác. Nếu chúng ta có thể làm điều gì đó kém hiệu quả hơn, thì sẽ có hy vọng cho điều ngược lại. Tuy nhiên, tôi không coi điểm câu chuyện là một công cụ đo lường hữu ích ở đây. Họ có thể dễ dàng bị lạm dụng một cách cố ý hoặc vô ý. Chúng ta cần tìm kiếm thứ gì đó tốt hơn.

Xác định đối tượng đo lường

Trước khi xác định cách tăng tốc độ nỗ lực lập trình của mình, chúng ta cần xác định nỗ lực này mà chúng ta muốn đo lường là gì. Tôi không thấy bất cứ điều gì chúng ta có thể sử dụng trong toàn ngành, nhưng mặt tích cực là chúng ta không cần sự rộng rãi như vậy để cải thiện hiệu quả. Nhu cầu là một cái gì đó mô tả một bước công việc có ý nghĩa trong việc phát triển sản phẩm lập trình của bạn. Chúng ta có thể sử dụng sử thi, nhiệm vụ, tính năng hoặc bất kỳ thứ gì khác đại diện cho sự điều chỉnh tích cực của hệ thống đang được phát triển.

Ở nơi hiện tại của tôi, chúng tôi sử dụng ba cấp độ khác nhau:

 User-valuable feature: ⎿ Its slice for the engineering team's convenience: ⎿ The specific task inside a slice (eg, back-end task).

Chúng ta cần điều chỉnh để có các đặc điểm sau:

1. Có thời gian bắt đầu và thời gian hoàn thành;
2. Xảy ra thường xuyên.

Vì vậy, những gì chúng tôi định nghĩa ở đây là "tác phẩm lớn này". Hãy đặt tên cho nó là hành động trong phần tiếp theo của bài báo. Không phải tất cả các hành động đều giống nhau. Tôi đã chứng minh ba loại trong ví dụ trên.

Chúng ta cần hành động xảy ra thường xuyên.

Yêu cầu này xuất phát từ thực tế là bạn không thể hiệu quả ngay từ đầu nhưng có thể trở nên hiệu quả hơn theo thời gian. Nó không phải là nhược điểm của phương pháp được mô tả. Scrum hoạt động theo cách này, Hệ thống Sản xuất Toyota hoạt động theo cách này và khoa học cũng hoạt động theo cách này. Chúng tôi yêu cầu khả năng lặp lại để khám phá trạng thái hiện tại và cải thiện nó một cách nhất quán.

Bạn có thể làm bất cứ điều gì mới với hiệu quả được tối ưu hóa cuối cùng chỉ một cách tình cờ. Và hành động càng phức tạp thì càng ít khả năng xảy ra. Chuẩn bị trước có thể giúp đỡ. Tuy nhiên, khả năng chuẩn bị trước có nghĩa là hành động hoặc các hoạt động phụ của nó đã xảy ra trong quá khứ và có kiến thức về chúng. Không có gì để chuẩn bị cho một cái gì đó hoàn toàn mới. Mặt khác, chúng ta hầu như không gặp một điều hoàn toàn mới lạ nào trong cuộc sống của mình. Một phần nhỏ của trải nghiệm trước đó luôn phù hợp với những tình huống chưa từng trải qua.

Tóm lại, chúng ta có một loại hành động như một bản chất để đo lường.

Làm thế nào để đo lường một hành động của một loại?

Thoạt nhìn, phần trước không thêm bất cứ điều gì. Chúng tôi làm một số hành động của một loại. Làm thế nào nó tốt hơn so với các nhiệm vụ được đo bằng điểm câu chuyện, kích cỡ áo phông hoặc động vật? Một cái tên không phải là một lợi ích duy nhất. Hành động của một loại có hai dấu thời gian và chúng ta có thể đo thời lượng của nó bằng cách trừ thời điểm bắt đầu khỏi thời điểm hoàn thành. Thời lượng là một lợi ích tuyệt vời ở đây vì nó là chìa khóa của chúng tôi đối với ngôn ngữ thực tế hàng ngày.

• Mất bao nhiêu thời gian để hoàn thành một sử thi?
• Chúng tôi mất 39 ngày từ khi bắt đầu đến khi hoàn thành.

Tuyệt vời.

Có bất cứ điều gì khác mà chúng tôi đạt được?

Yêu cầu thứ hai đối với hành động của chúng ta, sự xuất hiện thường xuyên, mang đến cho chúng ta nhiều điều khó tin. Trước hết, chúng ta có được một dòng hành động của một loại. Dưới đây là định nghĩa về quy trình từ cuốn sách "Actionable Agile Metrics for Predictability " của Daniel Vacanti:

Nói một cách đơn giản, dòng chảy là sự di chuyển và phân phối giá trị của khách hàng thông qua một quy trình.

Yêu cầu của chúng tôi về hai dấu thời gian, thời điểm bắt đầu và thời điểm kết thúc một hành động, cung cấp cho chúng tôi một tập hợp các chỉ số mới tốt. Đây là từ cùng một cuốn sách:

Công việc đang tiến hành (số lượng mục mà chúng tôi đang làm việc tại bất kỳ thời điểm nào), Thời gian chu kỳ (mất bao lâu để mỗi mục đó đi qua quy trình của chúng tôi) và Thông lượng (có bao nhiêu mục trong số đó hoàn thành trên mỗi đơn vị thời gian ).

Tôi có thể gây tò mò cho bạn nếu bạn nghĩ rằng đó là tất cả những gì chúng ta có ở đây. Chúng tôi đang ở giai đoạn đầu. Một kho báu khác mà dòng chảy mang lại cho chúng ta là dấu vết mà nó để lại khi thời gian trôi qua. Dấu vết này cho phép chúng tôi hiểu hệ thống tốt hơn. Chúng ta có thể chụp nó bằng một số sơ đồ. Một trong số đó là Biểu đồ phân tán thời gian theo chu kỳ.

Niềm vui của nó đến từ việc nó nắm bắt được "cách chúng tôi làm mọi việc ở đây". Nó không yêu cầu bất cứ điều gì từ quá trình của bạn, không có phương pháp cụ thể. Bạn có muốn ghi lại quy trình đánh răng bằng biểu đồ phân tán thời gian chu kỳ không? Cứ làm đi. Bạn có muốn điều tương tự cho những ngôi nhà được xây dựng trong khu vực của bạn không? Hoàn toàn tốt. Bạn có muốn theo dõi vòng đời phát triển, bao gồm các thử nghiệm A/B được thực hiện sau khi phát triển các tính năng mới không? Hãy bắt đầu và làm.

Trong hình, bạn cũng có thể thấy các dòng phân vị được ký với 50%, 70%, 85% và 95% ở bên phải. Có ý nghĩa gì? Ở phía bên trái, có những ngày. Bạn có thể đọc 85% và 16 ngày theo cách sau:

Đối với 85% mặt hàng đã vào hệ thống của chúng tôi trong khoảng thời gian được xem xét, phải mất 16 ngày hoặc ít hơn để rời khỏi mặt hàng đó.

Đây là lần thứ hai tôi sử dụng từ "hệ thống" trong phần này. Nó có nghĩa là gì? Hãy định nghĩa nó theo cách sau cho câu chuyện này:

Hệ thống là một cái gì đó thực hiện các hành động của một loại.

Một hành động của một loại trong ví dụ về hệ thống xây dựng nhà ở trên cao là xây dựng một ngôi nhà. Làm một km đường không được tính là một hành động ở đây. Đó là một loại hành động khác và một hệ thống khác. Tuy nhiên, không có sự phân chia cụ thể, nhưng chúng tôi muốn ngôi nhà của mình giống nhau, cũng như việc đánh răng và phát triển phần mềm bằng thử nghiệm A/B. Đối với một cái gì đó đủ khác biệt, chúng ta có thể đưa ra một hệ thống khác.

Thêm một lợi ích quan trọng

Đã đến lúc thảo luận thêm về một hiệu ứng sẽ giúp chúng tôi đảm bảo tính chính xác của các nỗ lực nâng cao của chúng tôi. Hãy tưởng tượng bạn có một nhóm và cần tạo phần mềm mới. Bạn lấy câu chuyện của người dùng làm thước đo tiến độ, như một hành động. Sau khi hoàn thành câu chuyện đầu tiên của bạn, đã đến lúc nhìn lại để xem chúng ta có thể làm tốt hơn ở đâu trong lần tới.

Có điều gì đó trong logic này dẫn chúng ta đến một cái bẫy? Chúng ta hãy có một cái nhìn gần hơn.

Trong quá trình triển khai câu chuyện người dùng đầu tiên, trở ngại chính là thỏa thuận về các thư viện cần thiết và cài đặt phần mềm cần thiết. Phải mất một thời gian, và đó là một nỗi đau thực sự. Trong quá trình hồi tưởng, nhóm đã thảo luận về mức độ đau đớn của nó và cách chúng ta có thể làm tốt hơn vào lần tới. Một sai sót khá rõ ràng là lần sau, bạn sẽ cần phải đồng ý với các thư viện và cài đặt phần mềm. Thư viện thường tồn tại trong một thời gian dài. Cài đặt phần mềm sẽ là một phần của quá trình giới thiệu thành viên mới, nhưng nó sẽ không làm phiền nhóm đã thành lập trong câu chuyện người dùng thứ hai của họ. Nó đủ khác biệt và giờ đây có thể trở thành một phần của hệ thống giới thiệu.

Chúng ta hãy xem phần trí tuệ lập trình sau đây của Donald Knuth ( hoặc Tony Hoare ):

Tối ưu hóa sớm là gốc rễ của mọi điều ác.

Tôi đoán bạn đã gặp trường hợp này, nó bảo bạn đừng nghĩ đến hiệu năng trong giai đoạn đầu của quá trình phát triển phần mềm. Bạn có thể đã thấy sự khôn ngoan này trong hình thức sau:

Làm cho nó hoạt động, Làm cho nó đúng, Làm cho nó nhanh.

Ví dụ về việc cài đặt các thư viện cho thấy câu ngạn ngữ này có liên quan đến mã và cả nhóm viết mã! Thật là một bí ẩn mà chúng ta gặp ở đây! Nó không phải là một bí ẩn mà là thuộc tính của một hệ thống. Có ít nhất hai lý do chúng ta nên tránh nhảy ngay vào các cải tiến sau lần thử đầu tiên.

Lý do thống kê để không nhảy ngay vào phần nâng cao

Mọi hành động hoàn chỉnh của một loại đều có thời hạn của nó. Thời lượng bao gồm hai phần: một phần do những lý do thông thường và một phần do những lý do đặc biệt gây ra.

Hãy xem lại ví dụ đánh răng một lần nữa. Thông thường, việc phủ kem đánh răng lên bàn chải đánh răng mất vài giây. Trong trường hợp đặc biệt, bạn cần lấy kem đánh răng ra khỏi tủ, mở ra và sử dụng. Ở đây toàn bộ hành động mất vài phút. Nếu vì bất kỳ lý do gì, chúng ta cần nghĩ đến hiệu quả của lớp phủ bàn chải đánh răng trong quá trình đánh răng, thì việc làm như vậy sau bước đầu tiên sẽ gây hiểu nhầm. Hành động ban đầu chứa một phần bổ sung và khác với hành động điển hình mà chúng tôi muốn tăng tốc.

Bản chất của việc đặc biệt dẫn đến sự xuất hiện không nhất quán của các lý do về thời lượng đặc biệt. Những gì thể hiện luôn là cốt lõi trong hành động của chúng tôi, mục tiêu hiệu quả cho các cải tiến của chúng tôi.

Lý thuyết về các ràng buộc Lý do không nhảy ngay vào cải tiến

Lý thuyết ràng buộc cho chúng ta biết điều gì? Nó cho chúng ta biết rằng toàn bộ việc sản xuất ra thứ gì đó sẽ hiệu quả như bộ phận kém hiệu quả nhất của nó. Hãy tưởng tượng chúng ta có một công ty đang xây dựng những ngôi nhà nhỏ một tầng. Năng lực hàng năm của chúng tôi như sau:

• 6 tầng hầm,
• 24 bộ tường,
• 52 nóc nhà.

Chúng ta có thể xây dựng bao nhiêu ngôi nhà mỗi năm? Bạn có thể trả lời sáu, nhưng tôi khuyên bạn không nên nói nhiều hơn sáu. Quá trình xây dựng của chúng tôi là một quá trình mang tính hệ quả: tầng hầm → tường → mái nhà. Hoàn thành cuối cùng, ngôi nhà thứ sáu có thể tụt hậu vào cuối năm.

Nếu chúng tôi tăng số lượng bức tường mà chúng tôi nâng lên hoặc mái nhà mà chúng tôi xây dựng, liệu điều này có làm thay đổi năng lực của toàn công ty chúng tôi không? Chúng tôi sẽ sản xuất nhiều hơn "không quá sáu" đã đề cập? Không, tầng hầm vẫn giới hạn chúng ta.

Những con số năng lực trên đây được rút ra từ kinh nghiệm của công ty bề ngoài này. Chúng tôi không có trải nghiệm này sau khi triển khai câu chuyện của người dùng đầu tiên. Chúng tôi vẫn chưa xác định được giới hạn của hệ thống xây dựng câu chuyện người dùng của mình vì chúng tôi không biết mỗi lượt đăng ký phụ kéo dài bao lâu. Hãy coi việc đảm bảo chất lượng của chúng tôi là một phần trong quy trình phát triển câu chuyện người dùng của chúng tôi. Thử nghiệm một câu chuyện của người dùng kéo dài bốn giờ. Quá trình phát triển một câu chuyện của người dùng nói chung kéo dài năm ngày làm việc. Giả sử có 250 ngày làm việc trong một năm. Bạn có muốn hoàn thành 50 câu chuyện của người dùng khi kết thúc hay 730 câu chuyện không? Như với những ngôi nhà và tầng hầm, nhiều nhất là 50 mỗi năm. Chúng ta cần thu thập số liệu thống kê để hiểu hình dạng hành động của mình và phần kém hiệu quả nhất của nó.

Bao nhiêu hành động hoàn chỉnh là đủ để bắt đầu các cải tiến?

Để hoàn toàn chắc chắn, tôi khuyên bạn nên có ∞ số hành động hoàn thành vào thời điểm này. Sau khi có con số chính xác này, bạn có thể chắc chắn 100% nên cường hóa cái gì trước.🥁

Đối với những người bên ngoài thế giới của toán học thuần túy, chúng ta hãy xem xét những suy nghĩ sau đây. Dưới đây là tài liệu tham khảo từ cuốn sách "Actionable Agile Metrics for Predictability " tham khảo cuốn sách " How to Measure Anything ":

Ví dụ: Douglas Hubbard (có cuốn sách "Cách đo lường mọi thứ" được liệt kê trong Thư mục tham khảo) tư vấn cho khách hàng của mình về " Quy tắc năm ": Quy tắc năm – Có 93,75% khả năng trung bình của một dân số nằm giữa các giá trị nhỏ nhất và lớn nhất trong bất kỳ mẫu ngẫu nhiên nào gồm năm từ tổng thể đó.

Xin đừng coi đây là điều cấm kỵ để thay đổi điều gì đó trong năm hành động đầu tiên. Cũng xem xét các khía cạnh khác: an toàn sức khỏe, sự gắn kết của nhóm, v.v.

Bắt đầu nâng cấp từ đâu?

Nếu chúng ta thực hiện một hành động cơ bản, chẳng hạn như bật TV bằng cách nhấn một nút trên đó, thì chúng ta có thể nghĩ về nó một cách tổng thể. Để giảm số lượng chuyển động và tổng thời gian, hãy mua cho mình một cái bấm và giữ nó ở một nơi gần ghế sofa của bạn. Trong ví dụ này, hành động đầu tiên có thể mất khoảng 20 giây và hành động thứ hai... một giây. Chúc mừng tôi! Bạn đã giảm được 95% thời gian yêu cầu trước đây và vẫn nhận được giá trị như cũ. Thật là một loại bỏ chất thải tuyệt vời!

Không phải tất cả các hành động đều đơn giản như vậy. Quá trình phát triển câu chuyện của người dùng đã được đề cập rất phức tạp. Thật khó để xử lý sự cải tiến ở đó trong một lần nhảy. Chúng ta cần chia nhỏ mọi thứ thành các phần phụ, như trong ví dụ xây nhà. Chúng ta có thể bắt đầu với vòng đời sau:

1. Phân tích,
2. Phát triển,
3. thử nghiệm,
4. Xong.

Bắt đầu từ đâu?

Trong sản xuất tinh gọn, quá trình sáng tạo, hoặc hành động như được đặt tên trong bài viết này, bao gồm ba loại phụ:

• Hoạt động gia tăng giá trị;
• Các hoạt động không tạo ra giá trị gia tăng cần thiết;
• Rác thải.

Xây dựng câu chuyện của người dùng, thiết kế giải pháp và mã hóa giải pháp đó đều là các hoạt động tạo ra giá trị gia tăng. Sử dụng phân nhánh git trong quá trình phát triển có thể được coi là hoạt động phi giá trị gia tăng cần thiết. Nó không thêm bất cứ thứ gì vào sự thay đổi này mà tổ chức toàn bộ quá trình. Lãng phí ngăn cản sự tích lũy giá trị trong một thời gian mà không có lý do chính đáng. Chờ đợi cơ sở dữ liệu không hoạt động là một sự lãng phí.

Trong sản xuất tinh gọn, lãng phí (hoặc muda ) được biết đến và định nghĩa bởi người tạo ra Hệ thống sản xuất Toyota, Taiichi Ohno. Ít nhất chúng được xác định cho công ty Toyota, nhà sản xuất ô tô. Các ngành công nghiệp khác có các biến thể của họ. Đây là của chúng tôi, do Mary và Tom Poppendiecks tạo ra trong cuốn sách " Lean Software Development ":

1. Công việc được thực hiện một phần,
2. quy trình bổ sung,
3. Các tính năng bổ sung,
4. Chuyển đổi nhiệm vụ,
5. Chờ,
6. Cử động,
7. Khiếm khuyết.

Hay những cái này? Từ cuốn sách " Triển khai phát triển phần mềm tinh gọn " của cùng tác giả:

1. Công việc được thực hiện một phần,
2. Các tính năng bổ sung,
3. học lại,
4. Bàn giao không cần thiết,
5. Chuyển đổi nhiệm vụ,
6. Sự chậm trễ,
7. Khiếm khuyết.

Ít nhất các kỹ sư phần mềm có thể di chuyển ngay bây giờ!😅

Làm thế nào những trụ cột này có thể thay đổi nhiều như vậy chỉ trong vài năm trong ngành của chúng ta? Tôi thấy câu trả lời là không thể có đủ danh sách lãng phí cho mọi thời đại sắp tới. Ngay cả Toyota, tại một số thời điểm, đã đưa ra sự lãng phí thứ tám.

Thật tuyệt khi danh sách ngành của chúng ta đã thay đổi hoàn toàn. Sự thay đổi này mở rộng tâm trí của chúng ta để xem xét lại những suy nghĩ của chúng ta về những gì là lãng phí một cách liên tục. Dưới đây là một cách nhìn khác về những gì có thể là một phần lãng phí trong quá trình phát triển phần mềm:

Một trong những hiểu lầm lớn nhất trong thế giới phần mềm là giá trị của mã. Nhưng mã là một trách nhiệm pháp lý, như chúng tôi sẽ nhắc đi nhắc lại trong cuốn sách này. Càng viết nhiều mã, chúng ta càng tạo ra nhiều rủi ro và phức tạp hơn cho chính mình.

Đó là một câu trích dẫn từ " The Value Flywheel Effect " của David Anderson với Mark McCann & Michael O'Reilly. Chà, thật là một chuyến đi!

Vì vậy, làm thế nào để chúng ta bắt đầu? Bằng cách nhìn vào subaction ít năng suất nhất. Chúng ta tìm kiếm điều gì? Subactions mà không thêm giá trị.

Xem xét lại quy trình phát triển câu chuyện của người dùng

Hãy để tôi nhắc bạn về quy trình làm việc mà chúng tôi đã có:

1. Phân tích,
2. Phát triển,
3. thử nghiệm,
4. Xong.

Thông thường, đây là những phần được thực hiện bởi những người khác nhau và luôn có một khoảng thời gian để chờ bàn giao. Hãy ghi lại nó:

1. Hoạt động phân tích,
2. Phân tích xong,
3. Đang phát triển,
4. Phát triển xong,
5. thử nghiệm,
6. Xong.

Tôi đã không nghĩ ra các bước này. Tôi đã lấy chúng từ bản giới thiệu sản phẩm ActionableAgile Analytics . Chúng ta có thể tin tưởng họ? Tôi sẽ đồng ý, vì tôi đã xem các ví dụ khác nhau về dữ liệu thực và ví dụ này có vẻ gần giống. Hãy điều tra các số liệu thống kê của các giai đoạn sau đây. Nó thể hiện mức trung bình.

Thời gian chu kỳ hệ thống là 9,37 ngày. Tuyên bố này có nghĩa là một nhiệm vụ đến giai đoạn Hoạt động phân tích , di chuyển qua tất cả các nhiệm vụ tiếp theo và rời khỏi Kiểm tra để hoàn thành và trung bình, đường dẫn này mất 9,37 ngày. Các giai đoạn có tên "Hoạt động" dường như mang lại sự hữu ích cho kết quả cũng như Thử nghiệm . Các giai đoạn kết thúc bằng "Hoàn thành" là hàng đợi, chờ đợi và không có gì hữu ích. Nếu chúng ta đánh dấu chúng tương ứng bằng cách sử dụng biểu đồ Hiệu quả dòng chảy, chúng ta sẽ thấy rằng, trung bình, chỉ 40% thời gian dành cho một câu chuyện của người dùng là có giá trị.

Trong sơ đồ này, chúng tôi cũng bao gồm thời gian bị chặn được theo dõi và các nhiệm vụ kỳ lạ, những nhiệm vụ này dành toàn bộ thời gian ở giai đoạn "Hoàn thành". Nếu chúng tôi loại trừ chúng, hiệu suất luồng cho ví dụ demo này sẽ vào khoảng 50%.

Giải quyết sự lãng phí thời gian được phát hiện

Vì chúng tôi có quá ít thông tin về bộ dữ liệu trình diễn nên sẽ không có những khuyến nghị cụ thể như: "Hãy tặng cho Đội E những chiếc máy tính tốt hơn". Tuy nhiên, sẽ có đủ suy nghĩ để truyền cảm hứng cho chính bạn trong trường hợp của bạn. Phần kém hiệu quả nhất trong quy trình của chúng tôi là giai đoạn Phân tích xong . Chúng tôi thậm chí không thể gọi nó như vậy vì nó mô tả sự chờ đợi. Tuy nhiên, phải mất gần 29% của mọi nhiệm vụ. Điều gì có thể là lý do ở đây?

Giai đoạn phát triển tích cực không có vẻ chậm, cần ít thời gian hơn để hoàn thành so với phần phân tích tích cực. Nhìn vào WIP trung bình, chúng tôi sẽ nhấn mạnh vấn đề: bộ phận phân tích có thể xử lý đồng thời nhiều câu chuyện của người dùng hơn.

Cân bằng điều này, ví dụ, bằng cách đưa nhiều nhà phát triển hơn vào nhóm, có thể là một giải pháp khả thi. Tuy nhiên, đừng quá vội vàng ở đây. Lý do có thể khá khác nhau. Giai đoạn Phân tích Xong có thể chứa công việc bí mật. Có thể các nhà phát triển không hài lòng với chất lượng yêu cầu nhưng không thể giải quyết vấn đề này một cách có hệ thống và dành thời gian trong giai đoạn này để nâng cao chúng. Để khám phá các điều kiện biên, đề xuất giao diện người dùng xử lý các yêu cầu không đồng bộ, v.v.

Trước khi đề xuất giải pháp, hãy áp dụng phân tích nguyên nhân gốc rễ: sử dụng năm câu hỏi tại sao , xương cá hoặc thứ gì khác.

Xác minh sự thành công của thay đổi được áp dụng

Giả sử rằng chúng ta đã giải quyết vấn đề từ phần trước. Làm thế nào chúng ta có thể chắc chắn rằng thay đổi được đề xuất có hiệu quả? Chúng ta cần tích lũy dữ liệu một lần nữa. Bạn có nhớ Quy tắc Năm ở trên không? Chúng ta cũng có thể sử dụng nó ở đây. Hệ thống của chúng tôi hiện đã được điều chỉnh. Hãy đo nó một lần nữa.

Trong công việc của mình, tôi sử dụng hai công cụ để đo lường kết quả của thí nghiệm:

1. Sơ đồ dòng tích lũy,
2. Đường xu hướng trên biểu đồ Phân tán Thời gian Chu kỳ.

Bạn có thấy khu vực màu lục lam của Phân tích Xong không? Mong đợi nó ít nhất sẽ trở nên mỏng hơn khi thời gian trôi qua và nhiều nhất là biến mất.

Nhìn vào đường đứt nét màu xanh lá cây xuất hiện trên sơ đồ vốn đã quen thuộc này. Nó cho thấy xu hướng thời gian chu kỳ 85% trong N ngày qua. Tôi sử dụng 30 thay vì N, vì nó đủ ổn định để thể hiện những thay đổi. Nếu giải pháp được phát hiện xử lý nguyên nhân gốc rễ đủ sâu, thì đường này sẽ giảm ≈30% xuống còn 11 ngày.

Nếu không có thay đổi đáng kể về dữ liệu, đã đến lúc tìm kiếm các giải pháp khác.

Các bước tiếp theo

Điểm rõ ràng tiếp theo để cải thiện là giai đoạn Phát triển Hoàn thành . Hãy tưởng tượng rằng chúng ta cũng đã đương đầu với nó. Chúng tôi đã cắt giảm 50% thời gian cần thiết ban đầu để hoàn thành câu chuyện của người dùng. Tuy nhiên, tiêu đề của câu chuyện hứa hẹn năng suất tăng gấp bốn lần. Trong trường hợp này, chúng ta có thể bắt đầu nghĩ đến giai đoạn Hoạt động Phân tích . Sau đó, cố gắng song song hóa Thử nghiệm với nó và Phát triển Hoạt động .

Tuy nhiên, tôi không chắc rằng nó là cần thiết ở đây. Hãy tưởng tượng bạn đang sử dụng phần mềm có các tính năng mới hai ngày một lần. Thị trường có thể chưa sẵn sàng cho nó. Thị trường trở thành một hạn chế cho hệ thống của chúng tôi. Khám phá này không có nghĩa là chúng tôi luôn bị hạn chế với những cải tiến của mình. Thông thường, chúng tôi có một số hệ thống phát triển tạo ra giá trị và các tính năng của chúng tôi mất nhiều thời gian hơn chín ngày. Theo kinh nghiệm của tôi, quan điểm của con chim về các mặt hàng tồn tại trong sáu tháng chỉ phát hiện ra 30% thời gian gia tăng giá trị. Bức tranh chi tiết hơn về các nhiệm vụ bên trong 30% một lần nữa chứng minh chính xác 30% thời gian giá trị gia tăng. Hóa ra trong cả 180 ngày, chỉ có 16 ngày hoạt động giá trị gia tăng. Tiềm năng cải thiện gấp 11 lần có thể nhìn thấy được.

Cách tiếp cận tóm tắt

câu hỏi hợp lệ

Tôi cảm thấy rằng phương pháp được mô tả có tiềm năng cao trong việc quản lý đóng góp của thế kỷ 20 đã qua với chúng ta. Khi tôi nói với ai đó về phương pháp này, tôi thường phải đối mặt với một số câu hỏi:

1. Điều này sẽ không phá hủy niềm vui của lập trình?

2. Phát triển phần mềm là rất khó đoán và rất sáng tạo. Làm sao chúng ta có thể nói về việc làm việc dựa trên hiệu quả của nó?!

   
   

Đề xuất sẽ không phá hủy niềm vui của chương trình. Bạn có thể nhận thấy rằng chúng tôi đã làm việc để loại bỏ các lỗ hổng trong quy trình mà không có gì xảy ra. Có thể thực hiện nhiệm vụ vừa tạo cũng vui như thực hiện nó hai ngày sau. Một niềm vui khác đến từ việc xem mã của bạn khi hệ thống đang thay đổi và nhóm của bạn cũng vậy. Bạn có một vùng đất mới của các công cụ lập trình và các cách tiếp cận được mở ra.

Tại sao trước đây bạn cần các công cụ lập trình mob trực tuyến? Để trở nên nhanh hơn? Nhưng những gì đã được nhanh hơn sau đó? Tại sao bạn cần giai đoạn thiết kế phần mềm rõ ràng? A ha! Nhóm phát triển của chúng tôi có rất nhiều lỗi, đó là lý do tại sao các câu chuyện của người dùng phải đợi tới 30% vòng đời của họ để các nhà phát triển sửa lỗi. Tại sao chúng ta không ngăn chặn chúng?

Điều giết chết niềm vui của việc lập trình là nhu cầu thường xuyên cắt bỏ thịt của bạn để hoàn thành nhiệm vụ. Được trao quyền với các phương pháp, công cụ và kiến thức tốt hơn không giết chết niềm vui.

Vâng, việc tạo ra phần mềm thực sự là không thể đoán trước và không thường xuyên. Tuy nhiên, nó là vô hạn không thể đoán trước? Liệu một năm có đủ để hoàn thành bất kỳ nhiệm vụ nào mà bạn đang xem xét từ công việc tồn đọng của mình không? Mười năm thì sao? Có phải bản chất của sự biến đổi của chúng khó nắm bắt đến mức chúng ta không thể làm gì với nó? Sự tồn tại của sơ đồ Cycle Time Scatterplot cho chúng ta thấy rằng có giới hạn đối với sự thay đổi trong phát triển phần mềm. Bạn có thể chỉ ra rằng một số tác vụ yêu cầu sửa lỗi liên tục bằng văn bản nhanh chóng, trong khi những tác vụ khác yêu cầu vài ngày điều tra. Tôi đồng ý với điều này, nhưng tôi cũng muốn hỏi bạn: "Sự tồn tại của những tác vụ này là kết quả của bản chất phần mềm không thể tránh khỏi hay nó là kết quả của kiến trúc phần mềm mà bạn sử dụng? Không phải cục bùn lớn trong các quy trình là lý do cho một mớ hỗn độn như vậy?"

Không phải nhu cầu về một quy trình phát triển mượt mà hơn cuối cùng cũng là lý do chính đáng để giải quyết các khoản nợ kỹ thuật, kiến trúc và quy trình của bạn sao?

Đúng vậy, ngay cả trong kiến trúc thân thiện với sự thay đổi nhất, sẽ xuất hiện những câu hỏi hóc búa đòi hỏi nhiều thời gian hơn chúng ta mong muốn. Và chúng tôi đã có vị trí trên biểu đồ Phân tán Thời gian Chu kỳ phía trên đường phân vị thứ 95 để xử lý chúng. Nhưng chúng là những ngoại lệ, và chúng ta không muốn mọi thứ trở thành ngoại lệ.

Chúng tôi, những người quản lý, không nên chữa cháy mà nên làm việc trên thiết kế hệ thống của chúng tôi và sự thay đổi của chúng.

Tránh các bước rõ ràng và sai lầm

Tôi không phải là người đầu tiên tìm kiếm hiệu quả trong ngành công nghiệp của chúng tôi. Một số người tìm kiếm nghĩ rằng họ đã quen thuộc với chủ đề này. Cách tiếp cận của họ là cài đặt phần mềm theo dõi trên máy tính của người sử dụng lao động và trừng phạt những người làm một số việc bị coi là không có việc làm. Phương pháp này cho thấy hoàn toàn không nhận thức được nguồn gốc của hiệu quả phát triển phần mềm. Ý tưởng về thành công lớn do căng thẳng lớn không chỉ là nghèo nàn. Đó là cái chết. Nó giới hạn cái nhìn của chúng ta về hệ thống của mình chỉ ở một khía cạnh: làm việc đủ chăm chỉ hay không đủ. Kinh nghiệm cá nhân của bạn cung cấp đủ ví dụ về những người kiệt sức. Lịch sử cho chúng ta thấy rằng các quốc gia đã rơi vào cái bẫy này với nhiều thương vong đi kèm. Không, làm việc chăm chỉ không phải là cách để cải tiến liên tục. Nhưng nó là gì?

Khám phá nơi bắt đầu

Hơn một thế kỷ trước, Frederick Taylor đã bắt đầu nghiên cứu về cái mà ngày nay chúng ta gọi là quản lý khoa học. Anh ấy nhìn các đồng nghiệp của mình và tìm kiếm những phương pháp hiệu quả hơn để họ thực hiện công việc của mình:

Taylor quyết tâm khám phá, bằng các phương pháp khoa học, những người đàn ông sẽ mất bao lâu để thực hiện từng phần công việc nhất định; và chính vào mùa thu năm 1882, ông bắt đầu đưa những đặc điểm đầu tiên của quản lý khoa học vào hoạt động.

Tôi không biết cấu trúc của công việc kinh doanh mà Taylor đang làm lúc đó. Đó có thể là trường hợp bước sản xuất của anh ấy nằm trong số những bước khác, điều đó cũng có thể có nghĩa là Taylor đã bị mắc bẫy tối ưu hóa dưới mức cục bộ. Đó là vấn đề về việc tăng số lượng mái nhà mà công ty xây dựng nhà tưởng tượng của chúng tôi có thể xử lý. Ảnh hưởng khám phá của Taylor không giảm đi, ngay cả khi đây là trường hợp. Bây giờ chúng tôi biết sự nguy hiểm của cái bẫy này và có thể hành động thông minh hơn.

Bạn có nhớ ví dụ của tôi với các mục kéo dài sáu tháng hoặc 180 ngày không? Nếu tôi loại bỏ thành công thời gian lãng phí cho các hạng mục bên trong nơi các kỹ sư làm việc, tôi sẽ tiết kiệm được 38 ngày và còn lại 142 ngày cho một hạng mục lớn. Nếu tôi làm tương tự cho bên ngoài nơi cả nhóm làm việc, tôi sẽ tiết kiệm được 126 ngày và có 54 ngày cho cùng một mặt hàng lớn. Tra tấn các nhà phát triển bằng thời gian làm thêm giờ và giường trong văn phòng chẳng có ý nghĩa gì nếu bạn muốn thắng lớn. Nhìn vào quá trình cung cấp giá trị từ quan điểm của con chim và chỉ đi sâu hơn khi bạn ra khỏi phòng để cải thiện ở cấp độ này.