アジャイル・スクラムに関するチップス
海洋ロボコンをやってた人です。
ここではアジャイル・スクラムに関するチップスとしてインプットした内容を備忘録として記載しておきます。
チームでソフトウェア開発する際に、どのような体制・運用にするかというときの知識として調べたのが背景になります。
本記事に記載の情報は全て"公開情報"から記載しています。
ソフトウェア開発を着手する方に向けて、少しでも参考にしていただけれと思い記載しますので、この記事が読者の方に役に立てば幸いです。
追加したい内容があり次第、不定期アップデートを心がけます。
アジャイル方法論
全般をインプットしておくと良い。
コストドライバーの話も面白い
スクラム開発
Scrumガイドという、Scrumフレームワークの公式な定義書が公開されており、フレームワークの要素やルール、それらが果たす目的が明確に示されたガイドがあります。
Scrumは、複雑な作業環境で価値を最大化するための軽量フレームワークで、ガイドではその本質的な設計とアイデアを守る重要性が強調されています。
ガイドは、ソフトウェア開発だけでなく、研究、分析、科学など多様な分野で活用されるScrumの適用を支援し、適切な実践を促進する効果もあります。
詳しくは下記の記事がとても勉強になります。
デイリースクラム
スクラム開発における重要なタスクの一つです。
週によって議題を決めるや、参加者のメリデリを明示的にする目的ですが、会議は増やせばよいというものではないので頻度はチーム状況に応じて実施する方針かと。
ノウハウ/ナレッジ管理
特に事務処理系とかは、タスク修了後にまとめておくと再利用可能なので使いまわしができます。
内部・外部どちらにも共有できるのがベスト。
今ではNotionでWiki管理もできるようです。
Technical Writing
技術文章系を書くときに気をつけたいこと。
RACI
それぞれのタスクに対しての業務範囲と責務分担を事前に決めることを目的としています。
WBS
タスク、PJ管理として導入することで、PJ全体の流れを把握します。
企画検討
企画検討の進め方。
Q: PoC はなぜやるべきなのか？
A: PoC を行うことで、新しい技術やアイデアの実現可能性を早期に確認し、リスクを最小限に抑えることができます。また、投資前に効果や課題を明確にするため、投資家やステークホルダーにとっても重要です。
Response
レスポンスに対しても、基本返信スタイルを合わせる。
基本は👆と同意見。
緊急度や重要度を強調させる、状況に応じてメンション@するとかも必要ですね。
返信テンプレート
自分の発言は後で引用されて突っ込まれても、抜けもれなくディフェンスできるようにしておくのが大切です。
- 現状報告系、どうなってる？
8/10件着手完了しています。80%完了しています。
現在はXXを着手中です。
課題があれば、打ち上げ。
課題に対して次作業の遅れがあれば打ち上げ
遅れがある場合はどこで挽回するのか記述
見通し提示 （遅れがある場合はそれも追記）
エビデンス提示
このあたりは、PREP法という形で伝えると分かりやすい文章になると思います。
- 確認依頼の回答側
ベースは下記で、シンプルかつ端的にが大切と考えています。
「Yes / No」、 「はい/いいえ」、「合っている/違う」など、まずはQ&Aの回答を端的に答える。
その次に補足説明が必要なら記載する。
リアクションで返すでもOKかと。
- 確認依頼を要求する側
Yes / Noやはい、いいえ で答えやすいQ＆Aをまず初めに記載する。PREP法と同じ。
詳細不要で、回答のみ要求する場合はYes / Noで返答してほしい旨を記載する。
または、Yesの場合は👍、Noの場合はコメントなど相手にしてほしいアクションを明示する。
確認依頼は手間ですが、確認取らずに進めて手戻りしないために初めのうちは確認しておいた方がスムーズです。Noの場合の手段はレベルに応じて使分けてください。
以上です。
Likeいただけると大変励みになりますので、よろしくお願いいたします。
Discussion