新しいスキルの学習はアジャイルのどこに当てはまりますか?


32

私は金融ソフトウェア会社を立ち上げており、その過程でアジャイルの原則と方法を研究していますが、まだ対処していない開発の1つの側面は、開発者が開発に新しいスキルと技術を習得する絶え間ないニーズを満たす場所ですプロセス。

過去数年間金融ソフトウェアに取り組む前は、3DグラフィックプログラマーとしてのキャリアのほとんどをビデオゲームやGISおよび生体認証ソフトウェアに取り組んでおり、崖から飛び込んで物事を理解する方法を常に簡単に考えていました。飛ぶ。私は常に成功していましたが、一度に100時間の週と月を費やして自分自身を殺さなかったならば、私はそうするまで生き続けるつもりはありません。

3Dグラフィックスの革新的な要求がまったくないソフトウェア会社を立ち上げたので、開発に対するより包括的なアプローチを確立したいと思います。

おそらくアジャイルはこれに対処していないかもしれませんが、もしそうなら、私はどこでこれを見つけたかわからず、誰もがこれについて持っている知識や専門知識や経験に感謝します。



1
学習とR&Dは、暗黙的または明示的にスプリント計画で考慮することができます。また、学習プロセスで簡単に測定可能な結果が得られないことも問題ありません(たとえば、スプリントゴールの一部ではありません)。Incrementalism:pchiusano.github.io/2017-05-17/incrementalism.html「最初は真の進歩は進歩のようには見えません。」をご覧ください。
KolA

1
私の経験から最も簡単な解決策は、休暇中の場合と同様に、トレーニングのために2日間休んでいる場合、それに応じてスプリントのワークロードを調整することです。一部の組織では、トレーニング用の人工的なユーザーストーリーをスプリントに追加していますが、個人的には何も得られません。
サイモン

回答:


43

これは、アジャイルやソフトウェアエンジニアリングとはあまり関係ありません。あらゆるビジネスのあらゆる企業に当てはまります。トレーニングの時間を確保する必要があります。期間。

アジャイルには、「持続可能なペース」という考え方があります。つまり、無期限にチームが持続できる以上の努力をしてはいけません。つまり、「クランチタイム」はありません。これもトレーニングによって尊重される必要があります。したがって、チームの持続的なペースは、「休憩なしで5時間以内、1日あたり9時間以内、1週間あたり40時間以内」であり、トレーニングに10%の時間を提供したい場合は、 36時間のプロジェクトを計画する必要があります。

しかし、これもアジャイルとは何の関係もありません。これは単なる常識であり、小学校の数学です。

個人的には、1日に30分、1週間に1日半、1四半期に1週間を許可するようなことで、チームはさまざまなサイズの知識の塊を迅速かつ安定したペースで取得できると思います。

また、知識の伝達を支援する、つまりチーム全体の知識レベルの違いを滑らかにするアジャイルプラクティスもいくつかあります。

  • 毎日の回顧
  • スプリントごとの回顧
  • プロジェクトごとの回顧
  • ペアプログラミング
  • ピンポンペアリング(赤と緑のリファクタリングサイクルの各ステップの後にドライバーとナビゲーターを交換)
  • 無差別ペアリング(固定ペアなし、ペアはランダムに割り当てられ、毎朝および昼食時に変更されます)
  • 奇数のチームメンバー(ペアプログラミングを行う場合、1人のチームメンバーは自由に学習できます)
  • mobプログラミング
  • 無差別チーム(開発者は毎日/スプリントごとにチームにランダムに割り当てられます)

ペアプログラミングとmobプログラミングは、継続的なコードレビューだけでなく、継続的な知識共有も提供します。ピンポンペアリングは、1人のユーザーが「キーボードを占有する」ことを防ぎます。無差別ペアリングはチーム全体に知識を広め、無差別チームは企業全体に知識を広め、すべての開発者がすべてのプロジェクトとすべてのコードベースを知っていることを確認します。また、コードベースの高度な標準化にもつながります。回顧の主な焦点は開発プロセスに関するフィードバックを提供し、それに応じて適応することですが、一般的でない問題とその解決方法を伝えるためにも使用できます。

言うまでもなく、雇用主は大規模なライブラリ、ACM、Springer、IEEEなどの有料サブスクリプション、学習する静かな部屋、教えるための大きな部屋を提供する必要があります。多くのホワイトボードとフリップボード、もちろん、あらゆる場所のプロジェクターは、トレーニングだけでなく、一般的に賢明です。


5
これはすべて真実だと思います。そして、5時間の日を与えてくれたスクラムマスターもそうでした。Jiraは5時間の日が何であるかを理解していなかったため、計画が悪夢になりました。これらの完全に常識的なアイデアを実施するために使用する前に、アジャイルツールが何を処理できるかを理解してください。
candied_orange

6
「暴徒プログラミング」は本当に耐え難いように聞こえます。
user2818782

4
@ user2818782:真剣に考えすぎず、あまり長く試さないようにすると、3本足のレースを走ることが楽しくなるのと同じように、ちょっと楽しいです。それをばかげたチームビルディング/知識共有の演習として扱うだけで、実際の作業コードの多く(またはいずれか)が生成されることを期待しないでください。
イルマリ・カロネン

1
@IlmariKaronen:私の知る限り、シアトルRuby旅団は10年以上にわたってmobプログラミングを実践しており、驚くほどの速さで、最も便利で、最先端で、最も美しく、最速のRubyコードを一貫して生成しています。それはもちろん逸話的な証拠にすぎず、実際にはせいぜい間接的な逸話にすぎません。しかし、それは実装の成功の少なくとも1つの例です。MobプログラミングのWebサイトには、試してみて、それが自分に適していることがわかった人々の証言がさらにいくつかあります。
イェルクWミッターク

@candied_orange本当に-jiraには文字通り1日の長さを知らせる設定がありますか?
jk。

8

私は、JörgW Mittagが言ったことのほとんどに同意しますが、「これはアジャイルとはあまり関係がない」という声明には同意しません。多数のアジャイル技術が、個人とチームの学習と開発をサポートします。

アジャイル手法は、増分または連続フローに基づいている傾向があります。いずれの場合も、優先度、価値、依存関係などの要因を考慮して作業が順序付けられます。短期的な作業に焦点が当てられているため、チームは提供に必要な知識を特定し、知識の不足が問題である場合は、その知識をジャストインタイムで取得する計画を立てることができます。可視性と透明性もさまざまなアジャイル手法の重要な側面になる傾向があるため、利害関係者はチームが何に取り組んでいるのか、価値を提供する能力を向上させるためにどのように働いているのかを知ることができます。広範な学習が必要な場合、近い将来または現在の反復に計画することができます。

チームの個人が知識を得ると、ペアリングとモブに関するテクニックがあります。ペアプログラミングはエクストリームプログラミングの重要なプラクティスであり、他の方法にも適用されており、とりわけ学習を促進するように設計されています。Mobbingはこれを2人以上に適用しています。チームの緊密なコラボレーションと機能横断性は、サイロがなく、この情報が広まることを意味します。

当面の仕事に必要なことを学習し、計画を立て、実行する能力を備えていても、知識のあるチームメンバーを持つことは非常に重要です。ツール、テクノロジー、およびドメインに関するある程度の既存の知識を持つ人々がいることで、学習タスクを引き受ける際により多くの情報を得ることができ、他のチームメンバーに知識を広める際により効果的になります。


2
空白を埋めてくれてありがとう。実際、短いフィードバックループにより、必要なスキルのターゲット設定が容易になり、透明性により、利害関係者に必要性と利点の両方を簡単に示すことができます。
イェルクWミッターク

5

スキルを習得するための時間を配分するスプリントの概念実証タスクを計画します。アクセシブルなHTMLテーブルを作成する方法を学ぶなど、非常に具体的なものに焦点を合わせてください。ストーリーに必要なスキルを習得するまで、概念実証タスクのスケジューリングを続けます。各POCタスクにストーリーポイントと期日を指定して、適切に時間枠を設定し、スプリントの最後に進行状況を表示できるようにします。

では、経験豊富な開発者にとってストーリーが5ポイントしかない場合はどうでしょうか。たぶん、それぞれ8ポイントで3〜4タスクかかります。これらのPOCタスクの後でも、ストーリーはまだ5ポイントである可能性がありますが、少なくとも5ポイントのストーリーが40ポイントにならないように、ストーリーとPOCタスクが合計40ポイントになる場合でも、新しいスキルを習得する時間を確保します。


4

スクラムには「スパイク」というアイデアがあります。チームが新しいテクノロジーまたは機能を採用している場合、スパイクはその作業をカプセル化するストーリーです。したがって、アジャイルのストーリーはユーザーに焦点を当てた機能の一部ですが、スパイクの出力は、学んだことのドキュメントであり、実際のアプリケーションで実践するための作業の内訳です。

実際には、少なくとも小規模なトレーニングを管理するのに良い方法であることがわかりました。開発者が新しいシステムやフレームワークに慣れるのに十分でありながら、スケジュールに責任を負います。


3

私は他の回答でこれを見ていなかったので、多くの組織がギルド、またはチャプター、またはスキル分野を中心とする優秀なセンターを始めたことを付け加えたかったのです。これらは、テクノロジーのような広範なトピックでも、React Native Developmentのような特定のトピックでもかまいません。参加する関心があなたの会社にあるかどうかにかかっています。

とにかく、これらのグループはしばしば、グループ内の人々が専門的に成長するのを支援するタスクを所有しています。これにより、仕事の外に別のスペースが作成され、毎日スキルを使用する人とクロストレーニングに興味のある専門分野外の人の両方のスキルを強化および拡張できます。これがこの問題の唯一の解決策ではありませんが、ますます一般的になりつつあるようです。


1

他の人たちはすでに側面について言及していましたが、私はアジャイル環境で個人的な開発にどのように適合するかを共有したかっただけです。

1.進行中の開発

これが最も簡単な方法です。進行中の開発を行うのに十分な時間があるまで、各スプリントの容量を減らします。難しい部分は通常、あなたの計画に固執することであり、さらに他のタスクをピックアップする必要がある場合は開発を行うことでもあります。緊急事態が発生した場合、この時間を時々犠牲にすることができますが、そうでない場合はそうしません。

キャパシティを減らしたため、このカテゴリで行うことは、他のチームメンバーの直接の関心の範囲外であり、おそらく、個々のスプリントでそれを心配したり、特に計画を更新したりする理由はあまりありません。

2.スプリント中のより大きな努力

私が見つけたのは、より大きなインパクトのあるものを計画している場合(たとえば、スプリント中に2日間のトレーニング)、スプリントを更新してこれを反映する必要があるということです。これの理論的解決策が何であるかはわかりませんが、人々がトレーニングタスクタスクをボードに置いて、誰かがこれで忙しいことを確認できるようにすることがよくあります。

あるいは、特定のスプリントのスプリントキャパシティを修正することもできますが、測定されたパフォーマンス/効率を非常に注意深く見ない限り、私はこれを避けます。特に新しいチームでは、安定性はおそらく正確性よりも価値があります。


1

アジャイルは哲学のセットです。マニフェストを見てください、それがすべてアジャイルです。アジャイルが私の問題をどのように解決できるかと言うときは、アジャイルについてもっとたくさん学ぶことをお勧めします。アジャイルの具体的な実装、SCRUMを見てみましょう。SCRUMには、スプリントとスパイクの概念があります。これら2つのアーティファクトを使用して、学習のための予算を作成することができます。

スプリントを円グラフとして見ると、トピックに基づいて優先順位を分けることができます。そのようなトピックの1つは...新しいスキルを学ぶことです!

スパイクは、通常は学習を通じて何かの実現可能性を評価することを含む、スプリントに関する研究課題です。

最後に、あなたがやっていることはまだテーブルにあり、あなたが取り組んでいることは何でもやっている間に学ぶことができます。その時点で、技術的な課題に対処するためにストーリーポイント/容量を増やすことができます。


1

アジャイルマニフェスト自体から引用するには:

プロセスとツールを介した個人と対話
包括的なドキュメントを介したソフトウェアの動作
契約交渉を介した顧客のコラボレーション計画に従う
ことによる変化への対応

強調は私のもので、おそらくあなたに最も当てはまる部分を強調しています。

基本的に、十分に訓練されたアジャイル開発者は、スキルセットを石化させるものよりも、変化する環境にはるかによく対応できます。

アジャイルの独自の定義を追加できる場合は、「顧客コラボレーション」を組み合わせることもできます。アジャイルの最良の定義は、アジリティのアイデアに基づいたものであると思います-顧客(または環境)が根本的に変化した場合、どの程度うまく対処できますか?顧客とのコラボレーションの環境を促進している場合、彼らは彼らが何をしているのかを知っているあなたのチームに既得権益を持つでしょう。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.