AgileBox アジャイルチーム支援

AgileBoxとは AgileBox for Jiraは、アジャイルチームのJira使用体験を向上させるために設計されたアドオンです。ビジュアルボード、スプリント計画、レトロスペクティブ、デイリースタンドアップミーティングツールなど、チームがアジャイルプロジェクトを計画・管理するのに役立つツール群を提供します。AgileBox for Jiraは、チームが進捗を追跡し、ブロッカーを特定し、ワークフローを最適化するのに役立ちます。 プランニングポーカーによるスプリント計画 プランニングポーカーは、スクラムポーカーとも呼ばれ、ソフトウェア開発タスクの工数を見積もるためのコンセンサスベースのゲーミフィケーション手法です。また、ワイドバンド・デルファイ法の一種でもあります。プランニングポーカーは、アジャイルソフトウェア開発、特にスクラムとエクストリームプログラミングで最もよく使われます。ここでは、グループのメンバーが声を出す代わりに、数字の書かれたカードを表向きにテーブルに出して見積もりを行います。そして、そのカードが公開され、見積もりが議論されます。このように数字を隠すことで、最初に声に出した数字がその後の見積もりの前例となるアンカリングという認知バイアスを回避することが可能となります。 AgileBoxのプランニングポーカー機能は、リモートチームに対してバーチャルなプランニングポーカーを提供します。チームは実際に同じ場所にいなくても、プランニングポーカー・セッションに参加することができます。各チームメンバーは自分のコンピュータや モバイルデバイスからセッションに参加し、ファシリテーターは中央拠点からセッションをリードすることができます。セッション中、チームメンバーは仮想の山札を使ってタスクの大きさを見積もります。ファシリテーターは、その見積もりを確認し、適切なメンバーにタスクを割り当てることができます。 Agile Scrum Planning Poker for Jira アジャイルレトロスペクティブ レトロスペクティブとは、アジャイルソフトウェア開発のスプリントやプロジェクトの終わりに開催されるミーティングで、チームがうまくいったこと、改善できたことを振り返る場を指します。また、チームメンバーが自分たちのプロセスを振り返り、より効率的かつ効果的に仕事を進めるための改善点をまとめて特定する機会でもあります。振り返りの目的は、問題をより迅速に特定し対処することと、成功を認識し喜びを分かち合うことです。ミーティングでは、チームメンバーが協力して潜在的なソリューションを洗い出し、アクションアイテムに同意し、次のスプリントまたはプロジェクトの目標を設定します。レトロスペクティブは、可能な限り最高の製品を提供するために、継続的な学習と改善を促すものであり、アジャイル手法の重要な部分だと言えます。 AgileBox Retrospectivesは、チームが自分たちの仕事について生産的で有意義な会話をするために設計されたオンラインツールです。これにより、チームは成功を振り返り、改善すべき点を特定し、将来のためのアクションプランを策定することができます。AgileBox…

重要なポイント DevSecOpsは、DevOpsの拡張として、ソフトウェア開発プロセス全体にセキュリティを統合するものです。 ソフトウェアサプライチェーンへの攻撃は年々増加しており、オープンソースコンポーネントのリスクを積極的に管理することが不可欠になっています。 開発プロセスにセキュリティを組み込むことで、チーム間の摩擦を増やし開発を遅らせる可能性のある「scan and scold」アプローチから、アプリケーションセキュリティに組織を移行させることができます。 ソフトウェア開発ライフサイクルを通じてセキュリティの問題に対処することは、時間と費用の節約につながり、顧客の信頼を維持することにもつながります。 はじめに DevSecOpsトラックの最初の技術記事「DevSecOpsとは何か？」では、DevSecOpsはDevOpsの拡張であり、品質を作り込むことで、ソフトウェア開発者によるオープンソースソフトウェア（OSS）コンポーネントの選択を含むソフトウェア開発ライフサイクル（SDLC）全体に、アプリケーションセキュリティ対策を統合することを主張するものである、と説明しました。 DevSecOps戦略の一環として、OSSコンポーネント管理を優先させるべき説得力のある理由がたくさんあるので、今回の記事ではそれについて説明します。   ソフトウェアサプライチェーンの現状 (オープンソース）ソフトウェアが世界を食べようとしている 「ソフトウェアが世界を席巻する」と言われる昨今、開発者はより複雑な機能を持つソフトウェアを、これまで以上に早くリリースする必要に迫られています。 この任務を果たすために、OSSのコンポーネントに依存するケースが増えています。結局のところ、アプリケーションに必要な同じ機能を提供する、自由に利用できて広く使われているコンポーネントがあるのに、なぜ独自のコードを書いて「車輪の再発明」をしなければならないのでしょうか？ 実際、Sonatype社の「State of the Software Supply…