スターバン 柔軟な開発方法論、ゲーミフィケーション、その他多くの流行語

投稿は短く、不適切な写真でも読みやすくなることはありませんので、まず対象読者を指定しましょう。

• あなたは、ソフトウェア開発者、開発チームリーダー、プロジェクトマネージャー、またはその同等者です。
• 1人以上、できれば3人以上のプログラマがプロジェクトに取り組んでいます。
• これらのスクラムとエッジブックをすべて試してみて、それらの魅力を感じましたが、方法論の独断的なフォローについて特定の不満があります。 おそらく、プロセスの定式化に関与している人は誰もいないので、タスクは単純に「急襲」します。
• チームは（プロジェクトから、ストレスなどから）疲れており、すぐに誰もがニンジンとスティックを持つことになります。

まあ、「自分自身のために」プログラマーのチームによって発明された方法論がありますが、私たちの意見では、他の人のために試みることは興味深いでしょう。 チーム内では、市場関係の小さな経済モデルが再作成され、チーム通貨の為替レートを使用して優先順位が調整されます。 。

前文

ITの世界は、ソフトウェア開発プロセスを構築するための多くのアプローチを発明し、産業化以前の同僚から最高のアイデアを借りてきました。 専門能力開発の特定の段階で、チームと顧客の動機付け、品質管理、作業の視覚化の問題に遭遇しました。 私たちが受けたすべての最高のすべてを取り込んで、スターバンの形で中規模のプロジェクトの作業を組織しました。

歴史的背景

商用ソフトウェア開発の世界の長い旅は、多くのプロジェクト管理アプローチに直面しました。 滝を見たり、 RUPに取り組んだり、 MSFの基本的な概念を適用しようとしたりしましたが、一番の思い出は柔軟な方法論によって残されました。 2年間続いた1つのプロジェクトの枠組みの中で、スクラムからカンバンに切り替え、チームを分割して統合し、 ゴールドラットとトヨタをニーズに合わせて曲げました。

スクラムから、チームのコミュニケーションと無次元（条件付き）単位でのタスクの評価方法を採用しました。 プロセスの反復性も同様に重要ですが、規制することができます。 また、スクラムでは、現在の作業の視覚化（戦術的計画）は完全に詳細です。 かんばんは、制約の理論、チーム内の変更に合わせて設定する柔軟性、および戦略マップ上の現在の作業を視覚化するのに適しています。 これらの2つの方法論は、標準的な実施形態ではまれであるため、完全に分離することは困難です。 たとえば、多くのプログラマーはストーリーポイントでタスクを評価するのが難しいため、人の時間をストーリーポイントに変換するためのテーブルが作成されるか、評価がすぐにクロックに入れられます。 代わりに、プロジェクトの現在の値に従ってタスクを評価することにし、この値を星と呼びました。 そのため、スターバンという名前が登場しました。

STARbanはいつ必要ですか？

1. 必ずしも準備が整っていない、または明確なTKを備えたプロジェクトがあり、具体的で評価された形式で提示する必要があります。
2. プロジェクトのサイズは十分であるため、チームは他の参加者によるプロジェクトの変更やプロジェクトの現在のステータスを監視する時間がありません。
3. 集団的責任の問題（なぜこれを行う必要がありますか？私はzakomichですので、テスターがそれを見つけられない可能性がありますか？もう一度、誰かがビルドをダンプしました。昼食を食べながら行きます。
4. プロジェクトのサポートステータスへの移行または資格超過のため、やる気の低下。 （働くにはあまりにも良い、売春に従事するにはあまりにもい）。

OK、5〜15人が参加するプロジェクトがあり、戦略的な計画を厳しくする必要があり、タスクを日常業務として認識している疲れたプログラマーが何人かいます。 残りはタスクを負担と見なし、タスクの正式な閉鎖と努力の最小化を目標として設定します。 彼らが言うように、必要なことは強調します。



まず、スターバンは完全なソフトウェア開発方法論ではなく、生産性を高め、プロジェクトが危機に陥るのを防ぐための一連の拡張機能であることに注意してください。 疲れた開発者は、プロジェクトを離れて、文書化されていない独自の知識を持ち帰ることができます。 マネージャーは申し出によりうまくマージできますが、プロジェクトの現在のステータスを理解することは非常に困難です。 テスト部門はタスクを閉じて受け入れテストを構築し、製品のすべてのユーザーが指示を完全に読み、猫の墓に決して違反しないことを誓います。 開発部門はテスト部門に誓い、責任をアナリストに移し、大規模な会議を収集します。2時間聴き、1時間の会議議事録を作成し、その結果、再び彼に伝えるために利害関係者との次の会議をスケジュールします。



各チームメンバーがこれらのコンポーネントの個々の組み合わせを必要とするため、ニンジンとスティックのバランスはめったにありません。 ですから、順守して順守することで心の安らぎがもたらされ、プロジェクトが消えることのない利益をもたらすように、順を追って検討していきます。

STARban開発の王子様

チームへの分割

チームに4〜5人の開発者しかいなくても、3人以上が1つの機能（ユーザーストーリー）を同時に開発できる可能性は低いため、開発者を2つのチームに分ける理由があります。 ほとんどの場合、1〜2人が機能で忙しく、3番目の人は現時点で次の機能の開発の準備に従事できます。

平均すると、何らかの理由で、理想的なチームは常に3人で構成されていることが常に経験からわかりました。 これは主観的な意味かもしれませんが、同僚もしばしば同じ結論に達しました。 普遍的な自律ユニットであることは、意思決定の外部制御の欠如のために困難であり、悪いことであり、より大きなチームは自分自身をブロックすることができます。 さらに、チームの各メンバーは、他のメンバーが何をしているかを知っている必要があります。

ホワイトボードを使用してプロジェクトの進行状況とチームを視覚化する

ボードは次の機能を実行する必要があります。

1. 最も完全なRoadMapプロジェクトを表示します。 チームは、製品の目的を確認し、最も戦略的なソリューションを適用するために開発で使用します。 製品の所有者は、同じスキームで優先順位を調整すると同時に、追加の緊急タスクが他の締切に影響することを理解できます。
2. 開発のための即時タスクのスタックを示します。 これは、現在のタスクを完了するためのインセンティブを提供します。 開発の課題はSPで評価する必要があります。
3. チームによるタスクの現在の実行のステータスを表示します。 これにより、チームメンバはアクションを調整し、他のチームメンバに問題について通知し、インスタントステータスを確認できます。 マネージャは、このデータのダイナミクスに基づいて、問題を確認し、ソリューションに介入できます。
4. 既製のタスクは、次のリリースがリリースされるときにバージョンに分割できます。これにより、特定の製品リリースの機能をナビゲートできます。

取締役会は、プロセスを最適化する上で重要な部分であり、可能な限り有益なものでなければなりません。

左端の列は、プロジェクトのロードマップであり、タスクの優先度でソートされています。 また、開発インフラストラクチャのサービスと近代化のグローバルな技術タスクを含める必要があります。 機能を修正するための緊急のリクエストも含まれている場合がありますが、他のカードと同じルールに従う必要があります。 私たちは2つのルールを採用しました。この列のカードは色で分けられ、各カードには数値の優先度が表示されます。これはプロジェクト管理システムでのソートに役立ちます。 すべての参加者が予想される開発結果を確認し、現在のタスクを実行する際の将来のニーズを考慮できるように、この列は可能な限り埋める必要があります。 利害関係者（顧客、彼の代理人、開発されたソフトウェアの所有者）は、タスクの優先度を変更できます。 優先度を変更すると、彼はすぐに損失を評価できます。変更により、どの機能のリリースが変更されます。



次の列の製品バックログには、ユーザーストーリーとして形式化された機能変更タスク、バグ、および技術タスクが含まれています。 ここでの詳細は、タスクのタイプと同様に異なる場合があります。 たとえば、バージョン管理システムでブランチをマージすることは、特定のユーザーストーリーに関連する場合がありますが、コンテキストに応じて、別個の評価済みカードになる場合もあります。 この列の優先度は役割を果たさなくなり、タスクの抽出順序は「星評価」を使用してマネージャーによって調整される必要があります。 スターについては後で説明しますが、現時点では、チームがより多くのスターカードを開発に使用する方が収益性が高いことを知っておくだけです。 この列では、投機を避けるために同時にカードの数に制限を入力できます。 カードの数が開発に関与するミニチームの数よりも1多い必要がある場合、猫トレイルールを試しました（複数の猫を家に置いている場合、トレイの数もユニットあたりの数を超える必要があります）。







タスクが不足しているため、この列で事前計画を実行する必要があります。 各チームの代表者、マネージャー、および必要に応じて顧客代表者が事前計画に参加します。 開発者はタスクの複雑さの見積もりを共有し、顧客またはマネージャーはプロジェクトとの関連性を評価します。 同時に、星の最終評価は、マネージャーが現在の優先順位とプロジェクトの状況に基づいて設定します。 タスクはマネージャーだけで追加および評価することもできますが、これは重大なバグを処理する価値があるだけです。 この列の色分けも忘れないでください。これにより、近い将来に新しい機能を探すか、製品を安定させるか、またはチームが開発インフラストラクチャで忙しいかを理解できます。 OK、タスクを分解および評価する方法を誰もが知っていると仮定し、カラーブラインドに適した色が選択されると仮定します。



次の4列は水平に分割されます。 各チームはボードの一部を所有し、その上に記録を保持します。 チームが製品バックログから別のカードを開発に取り込む必要がある場合、計画を実行します。タスクをタスクに分解し、実装の詳細を見つけ、実装時間を見積もります。 タスクは「動作する」ようになります-そして、ここにすべてのカードが配置されます。 分解は、ルールに準拠するのに十分な詳細である必要があります：タスクごとに1人。 階層的な番号付け<機能番号>。<タスク番号>または機能による色分けは依然として有効です。



チームがフリーハンドのない不要なタスクをキャプチャしないようにする方法は？ これを行う必要はありますか？ カードの数に制限を設けるべきですか？ むしろ、これについては後述するスターマーケット方式で規制する必要がありますが、問題が発生した場合は、ゴールドラットの制限を問題なく導入できます。 「作業中」列のタスクには、アイコンを使用できます。これらは、遠くから目立つカードに関する追加のメモです。 太字のステッカーが適しています。 例：「！」 -タスクは、最初の推定よりも長く作業中です。 「？」 -タスクには、他のチームとの会議を必要とする質問があります。 ボードのこの部分をできるだけ頻繁に更新し、タスクのバッジに従ってください。



タスクのアクティビティが完了すると、「検証」列に移動します。 テストチームは、すべての同じ色の機能タスクがテストに合格し、テストを開始したことを確認します。 ボード上のバグは、カード上のステッカーで表示したり、アイコンを追加したりできます。



テストが完了し、バグがなくなると、タスクは「完了」列に転送されます。 ここでは、通常はカードをはしごで接着するだけで、フィーチャにグループ化することができます。 期限切れのバッジなどの一部のバッジは、ここで役立つ場合があります。 承認手続きの一環として、チームは定期的に、製品所有者または担当アナリスト向けにこの列に到達したタスクのデモを準備します。 製品のバックログ列の詳細で受け入れられたタスクは、受け入れられた列に移動します。







「受け入れられた」列。 システムに多くのバグがあり（長期にわたるプロジェクトについて話しているため、トラッカーに適切なバグがある場合）、それぞれを評価する意味がない場合、この列にはすべてのチームに共通の星のバグ評価の現在の割合が含まれます。 たとえば、1つのバグに4分の1スター、または各バグに1つのスター。 1つのリリースのフレームワーク内でこの数値を変更しないことをお勧めします。したがって、事前に新しい機能と製品の安定化のバランスを選択してください。 このコラムでは、バックログに由来するバグのみが言及されていますが、チームによって実装された機能によるテスト中に作成されたバグは言及されていません。 しかし、どこにも例外があります。



次の製品リリースのリリース時に、「accepted」のすべてのカードがすべてのチームに共通の「accepted」列に転送され、次のバージョン番号がマークされます。 これを視覚化する最も簡単な方法は、バージョン番号による並べ替え、バージョン番号による色分け、または列内のグループ化です。



最後に一つ。 待合室とそれらのないコンベアがあります。 制限のために新しいタスクをテストに変換できない場合がありますが、それらは準備ができています。 この状況はさまざまな理由で発生します。 チームがテストの機能に従ってバグを修正したくない場合、これらはチームの問題であり、古いタスクを終了する前にテストに新しいタスクを転送する機会を与えるべきではありません。 テスト部門がタスクの流れに対応していないか、優先順位が低い場合は、テスト機能に星印で追加の価格を割り当てることができます。そして、チームの1人がこの機能をテストに使用できます。 このアプローチは、チーム間で知識を共有するのにも役立ちます。

指数ボードのタイムライン

また、「すべてのための1つのボード」として再定式化することもできます。 ロードマップ製品を搭載したボードはスクラムボードと共有され、リリースごとの機能の分布さえも視覚化されないことがあります。 これには利点があります。たとえば、ロードマップを実際のマップの形で示すことができ、必ずしも明らかな数値の優先順位やフラットリストではなく、要素の依存関係を示します。 わかりました、誰もあなたを空間で制限しません（より正確には-誰もあなたを時空で制限しません）！







面積2〜3平方メートルの磁気ホワイトボードは、必要な柱をすべて備えた大規模プロジェクトの2次元モデルを作成するのに十分であり、まだ装飾の余地があります。 電子バージョンをスケーリングとともに使用する場合、必要な制限までタスクを詳細化することを妨げるものは何もありません。 タイムラインの観点では、ボードは「月->週->日->月」のようになります。

星のタスクを評価する

タスクを評価する方法-時間またはストーリーポイントで？ ストーリーポイントと評価方法を無次元の量（象、オウム）で決定しようとする多くの試みがあります。 ほとんどは複雑さの概念につながり、その結果、通信テーブルSP->時間の内部（および公式に承認された）構築につながります。 プロジェクト間を歩き回ると、最初にチームの1 SP == 8時間の割合で見積もりを満たし、次に次のオフィスで1人の20 SP == 8時間の仕事を見ることができます。 依存関係は非線形である場合があります。 そして、このストーリーのポイントが何であるかを最初に理解することはありません。 本が言うように、すべてが比較対象です。 比較するものです。



「スターポイント」または単に「スター」は、プロジェクトの現在の重要性に基づいてプロジェクトのタスクを評価するための無次元の値です。 お金との類推ができます。 スターの契約率で継続的に作業する開発者のチームがあります。 マネージャーは新しいタスクを提供します-ビルドサーバーでビルドする場合、製品にバージョン管理を追加し、バージョンの割り当てを半自動にする必要があります。 10つ星の価格を提供します。 プログラマーはタスクを評価し、10個のバグを修正する方が簡単であることを理解しています。10個のバグは、それぞれ1つ星と評価されています。 バージョンを指定するには、エラーを修正するためのサポートサービスが緊急に必要になるため、この機能は製品の安定化よりも優先されるため、マネージャーが20スターの価格を設定し、最初に解放された開発者が急いでこのタスクを自分またはチームが一度に20スターを獲得できるようにします。



しばらくして、プロジェクトマネージャーは、開発者が大きなタスクを攻撃し、アプリケーションの操作中に発生した軽微なエラーについて多くの苦情がサポートサービスに寄せられることに気付きました。 これは、タイプミス、リスト形式でのソートの欠如、およびそのようなマイナーではあるが不快な欠点の多くである可能性があります。 個々のエラーの交渉は高すぎるため、リーダーは決定を下し、チームに発表します。火曜日から週の終わりまで、すべてのクローズドバグはトリプル係数で評価されます。 直接指示を与える必要はありません。また、追加のスターを獲得する機会を逃さないように、開発チーム自体が開発ベクトルを変更します。





プログラマには重要なタスクや複雑なタスクを取得する動機がないように見えるかもしれませんが、そうではありません。

市場

ヘッドが次のカードを受け入れると、星印の値は実装に関与した開発者またはチームのアカウントに転送されます。 星の美しさは、星を救うだけでなく使うこともできるということです。 経済と呼ばれるいくつかの問題があり、それにはインフレ、市場、投機といったいくつかの他の問題が続きます。

これは、同時に良い面と悪い面があります。 そして、残念なことに、または幸いなことに、人の最大の友人がまさにこの点に埋もれています。 プロジェクトマネージャーは、プロジェクトに関与する従業員間で市場関係を開始し、権威主義的な指示ではなく、目に見えない手でシステムを規制する必要があります。



星を何に使うことができますか？ それはすべてプロジェクトと会社に依存し、無形の動機は異なります。 休日、Xbox One、500スターごとにジムやボート旅行を考慮することはできません。これは、従業員に無条件で提供する会社だからです。 プロジェクト内には、商品になることができる他の多くのルーチンがあります。 すべてのタスクが興味深いわけではありませんが、興味深いことはそれほど適切ではない可能性があり、これが優先度が低い理由です。 2つのチームが1つのタスクを監視できます。 このタスクのために入札を手配することができ、より多くの星を与える人はそれを実行に移す権利があります。 チームは機能のバグをブロックしていますが、コラムの制限に収まらない何らかのタスクを取りたいですか？ ある機能のバグを別のチームに販売させてください！ そして、彼らは価格に同意します。 または、列の追加のスロットを1週間購入させます。 しかし、遅刻した場合は、恒星相当の罰金が科せられるため、翌月には最も不快なタスクのみが得られます（他のチームは報酬を受け取ります）。 誰かがマージを好まない、そして誰かがテストを書く。 新しい機能のテストがないため、罰金が課されますが、罰金の半分の費用でこれらのテストを書く人を見つけることができます。 忙しいテストチームと自己テストタスクの例も適しています。



リーダーの仕事は、星の価値を下げたり、優先順位を透過的に示したり、市場を操作したりすることなく、星のバランスを維持することです。 星のバグの交換レートなどの特定のルールを設定する必要がありますが、同時に一定の柔軟性を示し、チームのイニシアチブをサポートします。 誰かがコーヒーマシンを洗うためにターンを売ることを決めた場合-どうして！ 星の運用委員会？ できます。 しかし、より多くの星を獲得したいという願望を維持することをお勧めします。そうしないと何も機能しません。



それでもこのアイテムで問題が発生する場合は、MosigraとHabrahabrのボードゲーム「 Startup 」が考えの土台となり、xbox oneとボート旅行に疲れている同僚を再び喜ばせます。

技術的な課題は重要です

はい これを覚えておく必要があります。 使用済みライブラリのバージョンの更新、リビジョン、 CIおよびCDのセットアップ、 VCSのセットアップ、チームWikiのサポート、タスクトラッカーの変更。 これらのタスクは、総作業量で考慮される必要があり、星で優先順位と価値を持っている必要があります。 チームはDevOpsスキルを獲得し、プロジェクトは少し節約されます。

イスタンブール

そして、スクラムを試しましたが、好きではありませんでした。

そして、すべてが私たちと連携しています。

チームリーダーは何も変えたくない

マネージャーは、おもちゃの遊びを終えてコードを書くと言いました

プログラマが少なすぎます。なぜこれが必要なのでしょうか？

そして、ここでは、どうすればいいのか書かれていません...

...プログラマーは星を獲得したくない

...私たちは常に本番環境で緊急のバグ修正を行っています

...私たちはタスクを誤って判断します。それに時間をかける価値はありますか？

...すべてが燃えますが、制限により何も修正できません

...ボードはありません

...ミガルキンはすべての星をハムスターにし、それらを与えたくない

そうそう ソフトウェア開発は、スペシャリストとプロジェクトの両方が生き残るために懐疑心が必要な品質である領域です。 まあ、スターバンは標準的なアジャイルの失望の苦味を学んだ人にとってより可能性が高いですが、同じプロジェクトをさらに4つ持っているマネージャーと一緒に、プロジェクトのプログラマーとして働き続ける特別な場所があることも知っています そして、おそらくもう1つあります。 または、1つのプロジェクトには1つのチームがあり、もう1つのプロジェクトには完全に異なるチームがあり、部分的に顧客が配置されています。 一言で言えば、この人生であなたがきちんと振る舞う方が良いでしょう。



特定の問題を解決するために柔軟な開発方法論が作成されました-開発者を顧客から保護し、タスクのパイプライン処理を提供し、変化する要件に適応します。 特定の方法論に関係なく、常に使用するのに有利な便利なプラクティスがあります。 スターバンは、プロジェクトの開発をプロセスのすべての参加者にとって快適で興味深いものにするために、それらをまとめようとしました。 同時に、さまざまな条件に適応できます。 プロジェクトには数人の開発者しかいませんが、チームイベントを個人的なイベントに置き換えることにより、優れた競争を組織することもできます。 委員会は、目標の設定の現実とプロジェクトの形式化の可能性に適応できます。 誰も特定のプロジェクトにスターバンを結び付けさえしません-単一のバックログ（多くの場合、製造会社のIT部門で発生する）内のタスクを想像して1つのボードに収まる場合、そのプロジェクトは条件付きの仕切りにすぎません。



そして最終的には、誰もが彼らにふさわしいソフトウェア開発プロセスを手に入れるでしょう。