Giống như nhiều người cùng tuổi với tôi trong ngành này (phát triển phần mềm) nếu điều đó không rõ ràng, tôi vẫn nhớ cách mà mọi thứ hoạt động trước khi có internet và phương pháp phát triển phần mềm linh hoạt .Lập trình trong những ngày đó là sử dụng các công cụ đắt tiền đi kèm với chồng sách đặt trên bàn của bạn. Google and Stackoverflow( trang web dành cho lập trình viên ) không tồn tại. Thậm chí ở chỗ làm vẫn chưa có internet..Tôi đã học lập trình bằng cách sử dụng hướng dẫn cơ bản đi kèm với phó đề đốc của tôi 64. Agile( tập hợp các nguyên lý dành cho phát triển phần mềm) không phải là một vật.
Mọi thứ đã thay đổi kể từ đó và chủ yếu là tốt hơn.Lập trình Extreme của Kent Beck là một cuốn sách và lý tưởng mà tôi đã rất chờ đợi nó ra mắt.Trong khoảng thời gian đó, tôi đã làm Ph. D( tiến sĩ khoa học). trong lĩnh vực kỹ thuật phần mềm.
Tôi thậm chí đã đề cập nó trong luận án của tôi vào năm 2003 . Phong trào Agile (Kent Beck tất nhiên là một trong những người ký Tuyên ngôn Agile), đã cách mạng hóa sự phát triển đã được cách mạng hóa theo nhiều cách.
Sai lầm khi thực hiện phương pháp Agile
Ngày nay, mọi người đang tuyên bố / giả vờ nhanh nhẹn. Từ này đã trở nên hơi vô nghĩa. Mọi ngân hàng, công ty bảo hiểm và cửa hàng phần mềm nhỏ đang làm theo phương pháp. Capital A Agile tất nhiên vì họ đang làm những việc "theo sách".Bất cứ ai biết bất cứ điều gì về Agile đều biết đây chính xác là điều sai trái. Tôi đã ở cùng phòng với một số người ký tuyên ngôn tại các hội nghị, bài giảng, hội thảo, v.v. và tôi đã nghe họ giải thích rõ ràng về điều này. Phương pháp Agile là một bộ công cụ và cách làm việc mà bạn sử dụng và thích ứng với nhu cầu của bạn. Sử dụng sách làm điểm bắt đầu, chứ không phải là trạng thái kết thúc. Nếu bạn không biết gì, bạn cũng có thể bắt đầu bằng cách làm điều này.
Tôi đã hơi mệt mỏi với việc các phe phái chỉ trích “ bạn đang làm sai “ dập tắt mọi thứ như phương pháp Scrum, mà tôi cho rằng đã trở nên hơi có hại trong ngành công nghiệp của chúng tôi.Mọi người hoặc ghét scrum hoặc yêu nó và chủ yếu là vì những lý do sai lầm (một trong hai cách).Nói rộng ra, mọi người không thích sự thiếu logic của ứng dụng bị lan truyền, các cuộc tranh cãi thường xuyên trong các cuộc họp vô nghĩa , và sự cạn kiệt cảm xúc và lãng phí năng lượng cho những tranh luận về cách làm "đúng", bất kể điều đó có nghĩa là gì. Cá nhân tôi, đây là điều mà tôi đã chứng kiến trong hầu hết các dự án mà tôi đã tham gia trong 15 năm qua. Bằng chứng cho thấy tôi không đơn độc.
Dù tốt hơn hay tệ hơn, phương pháp Scrum đã thay thế mô hình “thác nước” thành thứ dễ nắm bắt để các tổ chức tự sắp xếp lại thành phương pháp Agile mà không thực sự phải thay đổi nhiều. Điều đó không có nghĩa là Scrum hoặc Agile là xấu nhưng đặc biệt Scrum dường như đã trở thành công cụ được lựa chọn để triển khai nhanh. Scrum thậm chí còn có thuật ngữ riêng cho việc này: scrumbutt.
Có rất nhiều điều không “linh hoạt” đang diễn ra trong ngành công nghiệp của chúng tôi. Hầu hết các công ty phát triển phần mềm đều nhàm chán, ngớ ngẩn và không hiệu quả như 20 năm trước. Các dự án công nghệ thông tin của chính phủ vẫn tiến hành sai một cách ngoạn mục. Các ngân hàng vẫn mất hàng tấn tiền trong các dự án sai lầm. Các công ty như Lidl vẫn cho phép bản thân bị gạt bởi các công ty như SAP (đến mức 0,5 tỷ ). Xin lưu ý, tôi đổ lỗi cho cả hai công ty điều này.
Ngày nay ,mọi người đến nhà thờ Agile cầu nguyện và có rất nhiều Agilists tự phong / huấn luyện viên Agile / vv để giúp bạn tìm ra cách làm đúng. Rất nhiều công ty sử dụng một số người đi trước để đảm bảo họ làm những việc "theo sách", điều này tất nhiên “đánh bại” mục đích.
Dù quan điểm của bạn về vấn đề này là gì, một xu hướng trong ngành của chúng tôi là mọi thứ đang thay đổi một lần nữa và mọi người đang nhìn xa hơn về những cách thức tổ chức phát triển phần mềm khác nhau và tương đối mới. Nếu chỉ để phân biệt với tất cả những người làm theo phương pháp Agile một cách sai trái.
Agile đã xuất hiện gần 20 năm rồi. Bạn sẽ không thể cải thiện mọi thứ bằng cách không thay đổi mọi thứ và làm mọi thứ rung chuyển một chút. Một số người đã bắt đầu coi đây là bài viết nói về phương pháp Agile. Dù đó là gì, scrum chắc chắn không phải là một phần của nó.
Lịch sử và sự phát triển của Agile
Khi bản tuyên ngôn về Agile được ký, hầu hết mọi người trên thực tế không làm theo phương pháp Agile hoặc bất cứ thứ gì liên quan đến nó. Agile là một điều mới mẻ và có phần gây tranh cãi. Mọi người đang làm đủ thứ và nói chung là khó hiểu và xung đột giữa các quy trình , kỹ thuật mô hình hóa , yêu cầu phương pháp kỹ thuật và công cụ.Sau đó ,các trường đại học chủ yếu dạy mô hình thác nước.
Vào cuối những năm 1990 và đầu những năm 2000, mọi người đã cố gắng chuẩn hóa các ngôn ngữ mô hình hóa. Kết quả, UML( ngôn ngữ mô hình hóa thống nhất), đã được phổ biến rộng rãi trong một thời gian và các công ty như Rational (sau này được IBM mua lại) đã cố gắng biến nó thành trung tâm của quá trình phát triển. Kết quả,Quy trình phát triển phần mềm hợp nhất RUP đã được coi là hiện đại sau đó và đưa ra thời gian ngắn chống lại Agile. Rational và RUP đã kết thúc trong tay IBM; được cho là một trong những công ty linh hoạt nhất tồn tại vào thời điểm đó (và ngày nay). Bộ đồ màu xanh / áo sơ mi trắng vẫn còn tồn tại ở IBM. Các tiêu chuẩn, chứng nhận, đào tạo và kinh doanh tư vấn liên quan đang bùng nổ.
UML và RUP đã duy trì các giáo điều của mô hình thác nước, trước tiên là thực hiện các thiết kế chi tiết (tất nhiên là sử dụng UML) sau khi thực hiện các yêu cầu kỹ thuật (cũng sử dụng UML, như thế nào cho thuận tiện) và trước khi thực hiện công việc và trước khi thử nghiệm sẽ bắt đầu. Tóm lại, điều đó cũng được cho là được thực hiện bằng cách sử dụng UML với một thứ gọi là phát triển theo mô hình. Rất may, MDA(đại lý tuyên truyền thông điệp) và phạm vi liên quan của phần mềm miễn phí không còn xuất hiện nhiều trong các cuộc thảo luận nghiêm túc về phát triển phần mềm ngày nay.
Nhưng RUP cũng là một bước đệm hướng tới phương pháp Agile. Tiến trình hợp nhất đã cố gắng để được lặp đi lặp lại là tốt. Điều này thực sự có nghĩa là bạn phải thực hiện mô hình thác nước nhiều lần trong một dự án; mỗi quý một lần hoặc hơn. Tiền đề của Rational là công cụ cần thiết này, rất nhiều công cụ. Các công cụ rất phức tạp đòi hỏi rất nhiều tư vấn. Đây là lý do tại sao IBM đã mua chúng và họ đã kiếm được rất nhiều tiền khi các tổ chức thực hiện RUP, đào tạo kiến trúc sư phần mềm và bán giấy phép với giá cao cho phần mềm. Quay trở lại những ngày đó, bất kỳ kiến trúc sư phần mềm tự trọng nào cũng có một số hộp và sách có logo Rational( lý trí ) nổi bật trong tầm nhìn. Họ đang sử dụng các sơ đồ nhìn ấn tượng và thông thường sẽ có rất nhiều tài liệu kiến trúc và thiết kế với nhiều sơ đồ hơn.
Phương phá Agile đã dán tiếp làm thất vọng vì con người thực hiện, chủ yếu theo nghĩa là nó đã nổ bong bóng đó. Xin lỗi về sự chơi chữ xấu. Nó chỉ tan đi trong không gian khoảng 5 năm. Từ năm 2000 đến 2005, UML dần biến mất khỏi cuộc sống của chúng ta. Tôi đã không sử dụng các công cụ UML từ lâu và không thể nói rằng tôi nhớ chúng.
Phát triển lặp đi lặp lại dĩ nhiên là cũ như mô hình thác nước. Bài báo gốc của Royce về mô hình thác nước Quản lý sự phát triển của các hệ thống phần mềm lớn từ năm 1970 thực sự vẫn là một bài đọc khá tốt và sớm được bổ sung bằng các bài báo về phát triển xoắn ốc và lặp lại.
Vòng phản hồi là một điều tốt; mọi kỹ sư đều biết điều này. Trong thực tế, Royce đã đưa ra các bước lặp trong bài báo đó! Trích dẫn từ bài báo: "Cố gắng thực hiện công việc hai lần - kết quả đầu tiên sớm sẽ cung cấp một mô phỏng cho sản phẩm cuối cùng". Royce đã cố gắng trở thành phương pháp Agile vào năm 1970.Tất nhiên công việc của anh ta bị câm lặng: trước tiên hãy thực hiện các yêu cầu; đặt những thứ đó vào đá và biến chúng thành thiết kế và thực hiện và có thể thực hiện kiểm tra / sửa lỗi một chút trước khi chúng ta ném nó lên tường và bỏ đi. Thật thú vị, mô hình thác nước không xuất hiện trong bài báo của Royce! Bài báo gốc về mô hình thác nước hoàn toàn không đề cập đến mô hình thác nước. Đừng đổ lỗi cho Royce hay cho mô hình thác nước. Từ ngày đầu tiên mô hình thác nước chưa bao giờ là một thứ gì đó.
Điều mà tuyên ngôn agile và sự chuyển động đạt được là bong bóng thác nước đã vỡ và sự phát triển lặp lại trở thành chuẩn mực. Có rất nhiều tài liệu thiết kế trong UML cản trở bạn khi lặp lại và làm cho khó thực hiện điều đó. Nếu lặp đi lặp lại mục tiêu của bạn, bạn không thể mất thời gian làm điều đó. Mọi người nhận ra rằng giá trị gia tăng của tài liệu này thường không đầy đủ và hết hạn là điều đáng nghi ngờ.
Kết quả là UML đã trở thành một thứ vô ích và từ đó mà ngày nay đó không phải là một chủ đề xuất hiện trong kế hoạch phần mềm. Tương tự với các tài liệu yêu cầu. Đây là một chút ma thuật để bắt đầu. Với những người nhanh nhẹn đã nhận ra rằng việc xác định các vùng nhỏ của những gì bạn muốn thay đổi so với những gì bạn có ngay bây giờ dễ dàng hơn nhiều thay vì chỉ định toàn bộ điều đó từ trước. Mà bạn chắc chắn sẽ sai bất luận thế nào.
Loại bỏ sự quan liêu của dự án như thế cho phép các chu kỳ ngắn hơn và lặp lại nhanh hơn và phát triển tập trung xung quanh các nguyên mẫu làm việc ban đầu. Lập trình cực đoan là về việc đưa nó đến mức cao nhất (vào thời điểm đó) để thực hiện những lần chạy nước rút chỉ trong vài tuần. Điều này là chưa từng thấy trong một ngành công nghiệp nơi các dự án có thể mất nhiều tháng hoặc nhiều năm mà không tạo ra mã làm việc.
Agile đã mang đến một cuộc cách mạng về công cụ
Các công cụ như trình theo dõi vấn đề ủy quyền này. Bugzilla là người nổi tiếng đầu tiên có nhiều sự thu hút. Điều này xảy ra khoảng thời gian Agile trở thành một thứ được nhận diện bởi người dùng. Trình theo dõi vấn đề đã biến các yêu cầu thành một cách làm việc mới. Thay vì viết thông số kỹ thuật, thay vào đó bạn chỉ định các yêu cầu thay đổi dưới dạng các vấn đề được theo dõi. Ban đầu, nó được sử dụng cho các lỗi nhưng rất nhanh nó đã được mở rộng để theo dõi tất cả các loại thay đổi. Tương tự, wiki đã thay thế tài liệu thiết kế và sản phẩm.
Phương pháp Agile sinh ra việc áp dụng và phát triển rất nhiều công cụ mới; nhiều trong số đó có nguồn gốc từ các cộng đồng nguồn mở. Ngày nay, bất kỳ dự án nào cũng có trình theo dõi vấn đề, một số loại hệ thống kiểm soát phiên bản phi tập trung (thường là Git), công cụ CI, wiki, công cụ truyền thông như irc hoặc slack, v.v. Những công cụ này rất cần thiết và chúng tiếp tục thay đổi cách mọi người làm việc. Một số công cụ này được chạy trong đám mây bởi các công ty như Atlassian, Gitlab và Github. Việc Microsoft mua lại sau này cho thấy tầm quan trọng của những công cụ này.
Thế giới nguồn mở luôn được phân phối và không bao giờ có thể dựa vào các cuộc họp. Do đó, họ đã áp dụng các công cụ và quy trình hỗ trợ cách làm việc của họ. Các dự án ban đầu đã sử dụng những thứ như danh sách gửi thư và các nhóm tin tức; và các hệ thống kiểm soát phiên bản như CVS, RCS và những thứ sau này như Subversion và Git. Tương tự như vậy, Irc trước Slack vài thập kỷ và tiếp tục là cách giao tiếp ưa thích trong một số dự án. Việc thực hành các yêu cầu kéo trên Github / Gitlab hiện đang phổ biến trong các dự án doanh nghiệp xuất hiện từ thực tiễn trao đổi các bản vá thông qua danh sách gửi thư và các nhóm tin tức. Cuối cùng, Git đã được tạo để làm cho quá trình này dễ dàng hơn và Github đã tạo giao diện người dùng cho nó.
Nhiều trong số các công cụ này không phổ biến (hoặc thậm chí xung quanh) khi bản tuyên ngôn Agile được ký. Tuy nhiên, người linh hoạt chấp nhận các công cụ này và cũng sinh ra phong trào Devops tích hợp kinh nghiệm hoạt động và trách nhiệm vào các nhóm. Devops thậm chí còn mang nhiều công cụ hơn để bàn. Những thứ như tự động triển khai, docker, kubernetes, PAAS, SAAS, chatops, v.v.
Tất cả các công cụ này và thực tiễn liên quan của chúng đang dần dẫn đến một thế giới nhanh nhẹn.
Các cuộc họp là tình trạng bế tắc sự đồng bộ hoá.
Agile thay thế mô hình thác nước bằng các quy trình có cấu trúc để tổ chức phát triển theo cách lặp lại. Các công cụ được đề cập ở trên chủ yếu đến sau. Một tác dụng phụ ngoài ý muốn của agile là rất nhiều cuộc họp mới. Nói chuyện với bất kỳ kỹ sư nào về những thứ như Scrum và về cơ bản bạn sẽ đánh dấu vào những cuộc họp họ phải làm: chạy nước rút quy hoạch, ước tính, hồi tưởng, đánh giá, và tất nhiên là họp hàng ngày. Các triển khai sách giáo khoa của Scrum về cơ bản là chu kỳ vô tận của các cuộc họp như vậy. Hầu hết các kỹ sư mà tôi biết ghét các cuộc họp và / hoặc xem chúng là một điều nghiêm khắc cần thiết nhất.
Với những người nhanh nhẹn đang phát hiện ra rằng giá trị gia tăng của các cuộc họp là đáng nghi ngờ và các công cụ tồn tại tạo điều kiện cho việc loại bỏ chúng. Một trong những công ty tồn tại trong thời đại .com yêu thích của tôi, des Pair.com, vẫn bán một poster tuyệt vời với khẩu hiệu sau: Cuộc họp. Không ai trong chúng ta ngu ngốc như tất cả chúng ta. . Tôi đã đến nhiều cuộc họp liên quan đến scrum khiến tôi nhớ đến poster đó.
Các cuộc họp vốn đã đồng bộ trong cả thời gian và (thường cả) không gian. Họ yêu cầu người đứng đầu trong một căn phòng tại một thời điểm cụ thể. Điều này rất gây rối bởi vì mọi người phải dừng những gì họ đang làm, đi đến cuộc họp, thảo luận và quyết định mọi thứ cùng nhau, và đi đến quyết định cuối cùng. Các công cụ hội nghị truyền hình hấp dẫn cho điều này và những người tham dự từ xa thường gặp bất lợi rất lớn trong các cuộc họp như vậy.
Đi không đồng bộ
Với phương pháp phát triển phần mềm linh hoạt, mọi người đang giữ các công cụ họ đã áp dụng từ các nhóm OSS(hệ thống hỗ trợ hoạt động) và một số thực tiễn của Agile. Tuy nhiên, họ đang từ bỏ các cuộc họp và thường loại bỏ các tắc nghẽn đồng bộ hóa trong quy trình của họ. Điều này cũng tương tự như việc nói lời tạm biệt với các sơ đồ UML lỗi thời, các thông số kỹ thuật yêu cầu vô nghĩa và tốc độ phát triển của phong cách mô hình thác nước. Tôi có nhiều bạn bè và đồng nghiệp đang làm việc trong các nhóm phân phối trên toàn cầu.
Có một vài thực hành là chìa khóa để phát triển phần mềm linh hoạt. Công cụ hỗ trợ chính là triển khai liên tục hoặc phát hành liên tục. Nói một cách đơn giản: nếu công cụ đã sẵn sàng, bạn hãy cung cấp ngay lập tức để giữ cho các vòng phản hồi càng ngắn càng tốt. Cộng đồng OSS đã tìm ra điều này trước tiên. Các bản dựng hàng đêm của Mozilla đã là một thứ khá lâu miễn là các sản phẩm nguồn mở của họ đã xuất hiện. Phát hành thường xuyên là rất cần thiết để thu thập thông tin phản hồi thông qua một trình theo dõi vấn đề. Bạn không đợi cho đến sau lần hồi cứu tiếp theo sau hai tuần hoặc bất kỳ cột mốc tùy ý nào bạn có để nhận phản hồi đó. Và bạn sử dụng các công cụ và quy trình tự động để đảm bảo điều này xảy ra theo cách được kiểm soát và dự đoán.
Triển khai liên tục đòi hỏi một mức độ cao của tự động hóa. Nó đòi hỏi tích hợp liên tục: aka. tự động đánh giá xem bạn có phù hợp để giao hàng ngay bây giờ không. Mỗi thay đổi kích hoạt một bản dựng CI(kỹ thuật phần mềm tích hợp). CD ( đĩa quang) loại bỏ việc quản lý phát hành với vai trò và CI giúp các nhà quản lý sản phẩm không phải kiểm tra thủ công và phê duyệt các bản phát hành.
Lần lượt tích hợp liên tục đòi hỏi phải có các bài kiểm tra có thể chạy tự động bao phủ đủ sản phẩm mà mọi người cảm thấy tự tin rằng mọi thứ hoạt động như họ dự tính. Mục tiêu của kiểm tra tự động là ngăn chặn việc kiểm tra thủ công trên con đường quan trọng là phát hành bất kỳ phần mềm nào.
Một điều nữa mà việc triển khai liên tục đòi hỏi là khả năng phân nhánh và hợp nhất các thay đổi. Để giữ cho chi nhánh sản xuất ổn định và đáng tin cậy, điều cần thiết là phải tiếp tục công việc trên các chi nhánh cho đến khi nó đủ tốt.
Git(phần mềm quản lý mã nguồn) là chìa khóa hỗ trợ chính cho việc này và một công cụ khác xuất hiện trong thế giới OSS. Trước Git, các hệ thống kiểm soát phiên bản là những bế tắc tổ chức khổng lồ. Sự phân nhánh là một nỗi lo lắng và đủ phức tạp mà việc sáp nhập sau đó đòi hỏi rất nhiều kế hoạch. Các tổ chức thường xuyên bị bế tắc khi sáp nhập. Điều này đã được giảm nhẹ với đóng băng cam kết và thực hành tương tự. Linus Torvalds đã điều hành dự án OSS lớn nhất thế giới (Linux) trong gần 25 năm và tất cả các kế hoạch và phối hợp này xung quanh các chi nhánh và sáp nhập đã làm ông khó chịu đến mức ông phát minh ra Git. Git mã hóa và cải thiện quản lý thay đổi không đồng bộ mà cộng đồng phát triển Linux đã và đang thực hành.
Tất nhiên Linux vẫn tiếp tục dựa vào danh sách gửi thư để sử dụng git. Các nhà phát triển Linux trao đổi các bản vá git (tức là xuất khẩu văn bản các cam kết, không chỉ khác biệt) qua email. Tuy nhiên, một công ty có tên Github đã xuất hiện khiến Git trở nên thân thiện hơn với số đông người dùng và giới thiệu cho chúng tôi một công cụ quan trọng để đăng bài nhanh: Pull Request. Về cơ bản, đó là điều tương tự nhưng luồng đánh giá và hợp nhất được hỗ trợ với giao diện Web người dùng đẹp.
Pull requests là một cách không đồng bộ để quản lý các thay đổi trong phần mềm. Quay lại khi agile bắt đầu kiểm soát phiên bản đã được thực hiện khi thực hiện CVS (lật đổ vẫn đang trong giai đoạn thử nghiệm) và phân nhánh được coi là một nghi thức rất nguy hiểm tốt nhất nên tránh . Toàn bộ các công ty đã nhận được mà không có hệ thống kiểm soát phiên bản hoặc chi nhánh.
Pull requests,CI và CD là những công cụ mạnh mẽ có thể loại bỏ rất nhiều bế tắc của đồng bộ hóa trong phát triển phần mềm. Bạn bắt đầu làm việc về một chủ đề thông qua trình theo dõi vấn đề, sau khi thảo luận về công cụ đó, trên danh sách gửi thư, hoặc slack / skype / irc / bất cứ điều gì, sau đó bạn tạo một nhánh và bắt đầu công việc. Khi hoàn thành, bạn tạo một yêu cầu Pull requests (PR). Các bên liên quan cung cấp phản hồi (sau khi được chỉ định hoặc @tagged). Trong khi đó CI xác nhận mọi thứ đã sẵn sàng để hợp nhất. Khi PR được phê duyệt, nó được hợp nhất. Điều này lần lượt kích hoạt một triển khai tự động. Bắt đầu để kết thúc vòng đời của một thay đổi phần mềm có thể hoàn toàn không đồng bộ. Mọi người đồng bộ hóa trên thẻ trong trình theo dõi vấn đề và Pull requests và leo thang thông qua các công cụ truyền thông không đồng bộ. Khi công cụ bị lỗi, PR có liên quan được xác định, lịch sử git và trình theo dõi vấn đề được sử dụng để tìm hiểu điều gì đã xảy ra và nếu cần PR mới được tạo để hoàn nguyên hoặc khắc phục sự cố. Các công cụ tạo điều kiện cho việc ra quyết định, lập kế hoạch, kiểm toán, tự động hóa và ảnh hưởng đến tất cả các vòng đời của mô hình thác nước truyền thống.
Không đồng bộ cho phép các nhóm phân phối
Tiến hành không đồng bộ có thể cắt giảm các cuộc họp và loại bỏ Sprint là một điều cần thiết hoặc một đơn vị công việc có ý nghĩa và cho phép bạn lặp lại hàng giờ thay vì hàng tuần. Không đồng bộ cũng cho phép bạn phân phối công việc theo địa lý. Các cuộc họp là một trở ngại cho điều này bởi vì chúng yêu cầu mọi người phải ở cùng một nơi và múi giờ. Không thực tế nếu bạn có người ở tất cả các châu lục. Bằng cách không đồng bộ, mọi người có thể điều phối công việc và đồng bộ hóa thông qua các vấn đề, yêu cầu có ảnh hưởngvà hờ hững trong khi việc ra quyết định xung quanh các bản phát hành, triển khai, v.v. được tự động hóa.
Điều này cho phép bạn thoát khỏi tất cả các cuộc họp liên quan đến Agile. Tất cả bọn họ. Đây là lý do tại sao tôi tin rằng việc đi không đồng bộ và phân phối có hiệu quả sẽ đưa chúng ta đến một thế giới Agile .. Họp hàng ngày không thực tế trong một nhóm phân phối, vì vậy có những người đi. Có các kế hoạch chạy nước rút dài và các phiên ước tính qua các cuộc gọi video cũng không thực tế. Sprints( khoảng thời gian mà các nhóm trong Scrum cần để sản xuất và hoạt động) không còn cần thiết. Và như vậy.
Bạn có nên đăng bài Agile?
Bây giờ mọi người có nên nhảy vào bandwagon( hiệu ứng tâm lý) và bắt đầu thực hiện phương pháp phát triển phần mềm linh hoạt không? Tôi cho rằng, không, bạn chỉ nên làm những việc phù hợp với bối cảnh của mình. Giống như bạn phải làm với Agile. Điều gì hữu ích mặc dù phản ánh về việc bạn đang ở đâu với tổ chức của mình về những gì bạn đang làm, những gì bạn đang cố gắng thực hiện, những công cụ và quy trình bạn có, những gì bế tắc của bạn và cách bạn đang phát triển các quy trình và công cụ của bạn thời gian. Bạn có thể đã sử dụng rất nhiều các công cụ và thực hành được đề cập ở trên.
Tôi thấy các đội và công ty phân phối là những người điều khiển chính của thế giới linh hoạt. Các công cụ và thực tiễn không đồng bộ là một yếu tố quyết định chính cho điều đó. Có rất nhiều lợi thế kinh tế để phân phối có thể khiến mọi người quan tâm đến việc trở nên phân tán hơn và ít bị bế tắc hơn trong các cuộc họp. Ví dụ, tuyển dụng dễ dàng hơn khi mọi người không phải chuyển đến văn phòng trung tâm của bạn. Bạn có quyền truy cập vào một nhóm tài năng toàn cầu. Không phải có văn phòng đắt tiền ở những nơi đắt đỏ như San Francisco hay London cũng là một điểm cộng rất lớn. Không lãng phí tỷ lệ ngân sách R & D( nghiên cứu và phát triển) hai chữ số cho các cuộc họp và đi du lịch liên quan cũng là một lợi ích lớn. Gắn bó tất cả mọi người trong phòng họp cả hai tuần một lần để lập kế hoạch và buổi lễ liên quan đến scrum là 10% ngân sách phát triển của bạn.
Nếu bạn muốn khai thác những lợi ích này, bạn cần suy nghĩ về cách bạn có thể tích hợp không đồng bộ trong các quy trình hiện tại của mình. Hoàn toàn ổn khi tiếp tục thực hiện Scrum và thực hiện phương pháp phát triển phần mềm linh hoạt cùng một lúc. Nhiều công ty làm điều này. Đó không phải là về việc nhảy việc mà là về việc phản ánh những gì bạn đang làm và tại sao và làm thế nào nó hoạt động. Cá nhân tôi , từ lâu tôi đã ưa thích các quy trình kiểu Kanban vì chúng dễ dàng phù hợp hơn với việc thực hiện mọi thứ không đồng bộ. Dù bạn làm gì, xin đừng giáo điều về nó.