Tôi đang thành lập một công ty phần mềm tài chính và trong quá trình tôi đang nghiên cứu các nguyên tắc và phương pháp Agile và một khía cạnh của sự phát triển mà tôi chưa thấy được giải quyết là nơi phù hợp với nhu cầu liên tục của các nhà phát triển để học các kỹ năng và công nghệ mới trong quá trình phát triển quá trình.

Trước khi làm việc với phần mềm tài chính trong vài năm gần đây, tôi đã dành phần lớn sự nghiệp của mình là một lập trình viên đồ họa 3d làm việc về các trò chơi video và phần mềm GIS và sinh trắc học và tôi luôn đơn giản phải lao vào một vách đá và tìm ra cách bay. Mặc dù tôi luôn thành công, tôi chắc chắn rằng tôi sẽ không sống lâu như tôi sẽ có nếu tôi đã không tự giết mình khi làm việc quá 100 tuần và nhiều tháng một lần.

Bây giờ tôi đang bắt đầu một công ty phần mềm không có nhu cầu sáng tạo mạnh mẽ về đồ họa 3d, tôi muốn thiết lập một cách tiếp cận toàn diện hơn để phát triển.

Có thể nhanh nhẹn không giải quyết vấn đề này, nhưng nếu có, tôi đã không tìm thấy ở đâu và tôi sẽ đánh giá cao bất kỳ kiến ​​thức hoặc chuyên môn hoặc kinh nghiệm bất cứ ai có với điều này.

Điều này thực sự không liên quan nhiều đến Agile, hoặc thậm chí với Kỹ thuật phần mềm. Điều này chỉ đơn giản đúng với bất kỳ công ty nào trong bất kỳ doanh nghiệp nào: bạn cần dành thời gian cho việc đào tạo. Giai đoạn.

Agile có ý tưởng về "tốc độ bền vững", điều đó có nghĩa là, không có lúc nào, nhóm nên làm việc chăm chỉ hơn những gì nó có thể duy trì trong một khoảng thời gian không xác định. Tức là không có "thời gian khủng hoảng". Điều này cần phải được tôn vinh bằng cách đào tạo là tốt. Vì vậy, đây là một tốc độ bền vững cho nhóm của bạn là "không quá 5 giờ liên tục mà không nghỉ, không quá 9 giờ mỗi ngày, không quá 40 giờ mỗi tuần" và bạn muốn cung cấp 10% thời gian cho việc đào tạo, sau đó bạn cần lập kế hoạch cho các dự án của bạn trong 36 tuần.

Nhưng một lần nữa, điều này không liên quan gì đến Agile, đó chỉ là lẽ thường và toán tiểu học.

Cá nhân, tôi sẽ nghĩ rằng một cái gì đó như cho phép nửa giờ mỗi ngày, một nửa ngày mỗi tuần và một tuần đầy đủ mỗi quý sẽ cho phép nhóm có được kiến ​​thức có kích thước khác nhau một cách nhanh chóng và với tốc độ ổn định.

Ngoài ra còn có một số thực hành Agile giúp chuyển giao kiến ​​thức, nghĩa là làm giảm bớt sự khác biệt về mức độ kiến ​​thức giữa các nhóm:

• hồi tưởng hàng ngày
• hồi tưởng trên mỗi lần chạy nước rút
• hồi tưởng trên mỗi dự án
• lập trình cặp
• ghép nối bóng bàn (hoán đổi trình điều khiển và điều hướng sau mỗi bước của chu trình tái cấu trúc màu đỏ-xanh lá cây)
• ghép nối bừa bãi (không có cặp cố định, cặp được chỉ định ngẫu nhiên và thay đổi mỗi sáng và trưa)
• số lượng thành viên nhóm lẻ (nếu bạn lập trình cặp, để một thành viên trong nhóm tự do tìm hiểu)
• lập trình mob (một biến thể của lập trình cặp trong đó toàn bộ nhóm sử dụng một máy tính và màn hình duy nhất, một thành viên trong nhóm được chỉ định chỉ đơn giản là một "người đánh máy" và những người khác nói cho anh ta biết phải viết gì)
• các nhóm lăng nhăng (nhà phát triển được phân ngẫu nhiên vào các nhóm mỗi ngày / mỗi lần chạy nước rút)

Lập trình cặp và lập trình mob không chỉ cung cấp đánh giá mã liên tục mà còn chia sẻ kiến ​​thức liên tục. Ghép nối Ping-pong ngăn không cho một người "ăn cắp bàn phím". Ghép nối bừa bãi truyền bá kiến ​​thức trong toàn bộ nhóm, các nhóm bừa bãi truyền bá kiến ​​thức trong toàn công ty và đảm bảo rằng mọi nhà phát triển đều biết mọi dự án và mọi cơ sở mã hóa; nó cũng sẽ dẫn đến một mức độ tiêu chuẩn hóa cao trong cơ sở mã. Mặc dù trọng tâm chính của các quá trình hồi cứu là cung cấp phản hồi về quá trình phát triển và điều chỉnh cho phù hợp, nó cũng có thể được sử dụng để truyền đạt một vấn đề không phổ biến và cách giải quyết nó.

Không cần phải nói rằng nhà tuyển dụng nên cung cấp một thư viện rộng lớn, đăng ký trả phí cho ACM, Springer, IEEE, v.v., cũng như các phòng yên tĩnh để học và các phòng lớn hơn để giảng dạy. Rất nhiều bảng trắng và bảng lật, cũng như Máy chiếu ở khắp mọi nơi tất nhiên là hợp lý nói chung, không chỉ để đào tạo.

Tôi sẽ đồng ý với hầu hết những gì Jörg W Mittag nói , nhưng không phải với tuyên bố rằng "điều này thực sự không liên quan nhiều đến Agile". Một số kỹ thuật Agile hỗ trợ học tập và phát triển các cá nhân và nhóm.

Các phương thức Agile có xu hướng dựa trên gia số hoặc lưu lượng liên tục. Trong cả hai trường hợp, công việc được sắp xếp dựa trên việc xem xét các yếu tố như ưu tiên, giá trị và phụ thuộc. Vì trọng tâm là công việc ngắn hạn, nhóm có thể xác định kiến ​​thức cần thiết để cung cấp và, nếu thiếu kiến ​​thức là vấn đề, hãy lập kế hoạch để có được kiến ​​thức đó ngay lập tức. Khả năng hiển thị và minh bạch cũng có xu hướng là các khía cạnh chính của các phương pháp Agile khác nhau, vì vậy các bên liên quan có thể thấy nhóm đang làm việc và cách họ đang làm việc để cải thiện khả năng cung cấp giá trị. Khi học tập mở rộng là cần thiết, nó có thể được lên kế hoạch trong tương lai gần hoặc lặp lại hiện tại.

Một khi các cá nhân trong một nhóm đã có được kiến ​​thức, có các kỹ thuật xung quanh ghép nối và di động. Lập trình cặp là một thực hành chính trong Lập trình cực đoan cũng đã được áp dụng cho các phương pháp khác và được thiết kế để, trong số những thứ khác, tạo điều kiện học tập. Mobbing đang áp dụng điều này cho nhiều hơn chỉ hai người. Sự hợp tác chặt chẽ và chức năng chéo của các đội có nghĩa là không có silo và thông tin này được phổ biến.

Ngay cả với khả năng lập kế hoạch và thực hiện việc học những gì cần thiết cho công việc trước mắt, việc có các thành viên trong nhóm có kiến ​​thức là rất quan trọng. Có những người có một số mức độ kiến ​​thức hiện có về các công cụ, công nghệ và miền sẽ cho phép họ được thông báo nhiều hơn khi nhận nhiệm vụ học tập và hiệu quả hơn khi phổ biến kiến ​​thức cho các thành viên khác trong nhóm.

Lập kế hoạch bằng chứng về nhiệm vụ khái niệm cho lần chạy nước rút mà bạn muốn dành ngân sách thời gian để học một kỹ năng. Giữ cho nó tập trung vào một cái gì đó rất cụ thể, như học cách tạo một bảng HTML có thể truy cập. Tiếp tục lên lịch bằng chứng về các nhiệm vụ khái niệm cho đến khi bạn đã học được các kỹ năng cần thiết cho câu chuyện. Cung cấp cho mỗi tác vụ POC một số điểm câu chuyện và ngày đáo hạn để bạn có thể đặt đúng thời gian cho nó và hiển thị tiến trình ở cuối giai đoạn nước rút.

Vậy điều gì sẽ xảy ra nếu một câu chuyện chỉ nên có 5 điểm cho một nhà phát triển có kinh nghiệm? Có thể mất 3-4 nhiệm vụ tại 8 điểm mỗi. Sau những nhiệm vụ POC đó, câu chuyện vẫn có thể chỉ còn 5 điểm, nhưng ít nhất bạn dành thời gian để học các kỹ năng mới để câu chuyện 5 điểm không phải là 40 điểm - ngay cả khi câu chuyện và nhiệm vụ POC có tới 40 điểm.

Scrum có ý tưởng về một 'cành'. Nếu nhóm đang đảm nhận một công nghệ hoặc khả năng mới, một đột biến là một câu chuyện để gói gọn công việc đó. Vì vậy, trong khi một câu chuyện nhanh nhẹn là một chức năng tập trung vào người dùng, thì đầu ra của một đột biến là tài liệu về những gì đã học được và một sự cố công việc để đưa nó vào thực tế trong ứng dụng thực tế.

Trong thực tế, tôi đã thấy rằng đó là một cách tốt để quản lý ít nhất là đào tạo quy mô nhỏ - đủ để giúp các nhà phát triển tăng tốc với một hệ thống hoặc khung mới trong khi vẫn đưa ra trách nhiệm cho lịch trình.

Tôi đã không thấy điều này trong các câu trả lời khác, vì vậy tôi muốn thêm rằng nhiều tổ chức bắt đầu bang hội, hoặc chương hoặc Trung tâm Xuất sắc xung quanh các khu vực kỹ năng. Đây có thể là những chủ đề rộng như công nghệ hoặc những chủ đề cụ thể như React Native Development. Tất cả phụ thuộc vào việc lợi ích tham gia có tồn tại trong công ty của bạn hay không.

Bất kể, các nhóm này thường sở hữu nhiệm vụ giúp mọi người trong nhóm phát triển chuyên nghiệp. Điều này tạo ra một không gian riêng biệt bên ngoài công việc để tái tạo và mở rộng các kỹ năng cho cả những người sử dụng các kỹ năng đó mỗi ngày và ngay cả những người ngoài ngành học đó quan tâm đến đào tạo chéo. Đây không phải là giải pháp duy nhất cho vấn đề này, nhưng dường như nó đang trở nên ngày càng phổ biến.

Một số người khác đã đề cập đến các khía cạnh, nhưng tôi chỉ muốn chia sẻ cách tôi phù hợp với sự phát triển cá nhân trong một môi trường nhanh nhẹn.

1. Đang phát triển

Đây là cách dễ nhất, giảm năng lực của bạn trong mỗi lần chạy nước rút cho đến khi bạn có đủ thời gian để thực hiện phát triển liên tục. Phần khó thường bám sát kế hoạch của bạn và cũng thực hiện phát triển nếu có nhiều nhiệm vụ khác được chọn. Nếu bạn gặp trường hợp khẩn cấp, bạn có thể hy sinh ngay lúc này và sau đó, nhưng nếu không thì không.

Vì bạn giảm năng lực, nên bất cứ điều gì bạn làm trong danh mục này đều nằm ngoài mối quan tâm trực tiếp của các thành viên khác trong nhóm và họ có thể không có nhiều lý do để lo lắng về điều đó hoặc cập nhật kế hoạch cụ thể trong từng lần chạy nước rút.

2. Những nỗ lực lớn hơn trong một lần chạy nước rút

Những gì tôi đã tìm thấy là nếu bạn đã lên kế hoạch cho một cái gì đó có tác động lớn hơn (ví dụ đào tạo 2 ngày trong một lần chạy nước rút), bạn nên cập nhật nước rút để phản ánh điều này. Tôi không chắc giải pháp lý thuyết cho việc này là gì, nhưng tôi thường thấy rằng mọi người chỉ cần đặt nhiệm vụ huấn luyện lên bảng để đảm bảo rằng ai đó đang bận rộn với điều này.

Thay phiên, bạn có thể sửa khả năng chạy nước rút của lần chạy nước rút cụ thể, nhưng trừ khi mọi người nhìn rất kỹ vào hiệu suất / hiệu quả đo được của bạn, tôi sẽ tránh xa điều này. Đặc biệt trong một đội ngũ mới, sự ổn định có lẽ có giá trị hơn độ chính xác.

Agile là một tập hợp các triết lý, hãy xem bản tuyên ngôn, đó là TẤT CẢ Agile, vì vậy khi bạn nói Agile có thể giải quyết vấn đề của tôi như thế nào, tôi khuyên bạn nên tìm hiểu thêm về Agile. Hãy thực hiện cụ thể Agile: SCRUM. Trong SCRUM, chúng tôi có các khái niệm về một Sprint và gai. Thông qua hai hiện vật này, có thể hoàn thành việc tạo ngân sách cho việc học.

Nếu bạn xem một cuộc chạy nước rút như một biểu đồ hình tròn, bạn có thể phân chia các ưu tiên dựa trên chủ đề, một chủ đề như vậy có thể là ... học các kỹ năng mới!

Spike là một nhiệm vụ nghiên cứu trên một cuộc chạy nước rút liên quan đến việc đánh giá tính khả thi của một cái gì đó thường thông qua học tập.

Cuối cùng, việc bạn đang làm vẫn còn trên bàn và bạn có thể học KHI làm bất cứ điều gì bạn đang làm, tại thời điểm đó bạn có thể thử tăng điểm / năng lực để đối phó với thách thức kỹ thuật.

Để trích dẫn từ Tuyên ngôn Agile :

Các cá nhân và tương tác qua các quy trình và công cụ
Phần mềm làm việc trên tài liệu toàn diện
Hợp tác của khách hàng trong đàm phán hợp đồng
Đáp ứng thay đổi theo kế hoạch

Nhấn mạnh là của tôi, làm nổi bật những phần có lẽ phù hợp nhất với bạn.

Về cơ bản, các nhà phát triển nhanh nhẹn được đào tạo tốt có thể đáp ứng với môi trường thay đổi tốt hơn nhiều so với những người để kỹ năng của họ hóa đá.

Nếu tôi có thể thêm định nghĩa nhanh của riêng mình, chúng tôi cũng có thể đưa "cộng tác khách hàng" vào hỗn hợp. Tôi thấy định nghĩa tốt nhất về sự nhanh nhẹn là dựa trên ý tưởng về sự nhanh nhẹn - nếu khách hàng (hoặc môi trường) thay đổi hoàn toàn, bạn sẽ đối phó tốt như thế nào? Nếu bạn đang thúc đẩy một môi trường hợp tác của khách hàng, họ sẽ có quyền lợi trong nhóm của bạn biết họ đang làm gì.