※転載済み　スクラムでやりつづけた大事なこと（具体性　中）

転載済み
https://zenn.dev/thiem/articles/9cdedec94be25a


# 注意：
抽象度中、具体度中の記事です。
全てのプロジェクトに適切なものかはプロジェクトに応じますのであくまで参考程度に。

非機能要件↓
<img width="150px" alt="ロリ" src="https://1.bp.blogspot.com/-KXJrCb1niqs/X5OclON7brI/AAAAAAABcA8/tz4BfmewslQC6RV3XSnPEn1L0J01ryIcgCNcBGAsYHQ/s400/youkai_backbeard.png">

# 大事なこと
大事だったなのは、プロジェクトごとに当たり前と当たり前じゃないが分かれるギリギリのところをお客さんに怒られない程度に継続して対応したこと。
あとプロジェクトとお客さんでは、より優先してプロジェクトの健全性をとるという信念。
※あくまで冷静に
<img width="150px" src="http://2.bp.blogspot.com/-pH_D9fHMXm8/UZM5GJe-ZKI/AAAAAAAASTQ/TpNSUnZUdTo/s180-c/ojizousan.png">

※ここでいう怒られない程度とは、webサイト作成など目に見えるわかりやすい開発に対して、目に見えない非機能要件がプロジェクトの成功率を左右することはよくあり、そういった地味なものへの目に見えづらい対応を、
目に見える制作物の開発速度を8割以下にはしない程度で対応するということ
※結局は3ヶ月〜半年などのスパンで見たら、バグの発生率、対応工数などを下げるので確実にペイできるとお客さんとコミュニケーションをとり納得してもらうことが大事。

# 具体例（抽象度中くらい）：
・適切なコードレビュー体制
<img width="150px" src="https://3.bp.blogspot.com/-WZZLYymIBV0/WUdYbsq5S4I/AAAAAAABE70/pCSwPzrM-OAAvBRRBvkgnmrEXk6cOZJCACLcBGAs/s180-c/gourmet_writer_woman.png">
・コーディング規約の設定
<img width="150px" src="https://4.bp.blogspot.com/-GBuNMwxiQBc/WFJWTF_ITlI/AAAAAAABAaQ/lJ23YZGCfL8RKimp5EbEKpJ9QebiJ8nFwCLcB/s180-c/school_gakkyu_houkai.png">
・ペアプロの有効な活用（全てではなく、毎スプリント要所での実施計画）
<img width="150px" src="http://1.bp.blogspot.com/-KZ7ZKFesLf4/UqmPwdAXeJI/AAAAAAAAblg/kEzK4vq_97o/s180-c/skate_figure_pair.png">
・コード品質、スクラム単語、マイナー技術などに関してチームメンバーからチームメンバーに対する勉強会
<img width="150px" src="https://3.bp.blogspot.com/-J0gNrW4zjoA/Wtxrz686UfI/AAAAAAABLqY/VsjQAOBHCrga9gtO0ilzNdztjRdOpLegQCLcBGAs/s180-c/benkyoukai_kunrenkou_international.png">
・コーディング上でのアーキテクチャの継続的な再設計
<img width="150px" src="https://4.bp.blogspot.com/-pwDZYTq8zsw/W-0hIVxhSFI/AAAAAAABQPg/-HG25dorDbkQb2WVot1yZFq4MTtRagpbACLcBGAs/s180-c/syourai_sekkei_man.png">
・デプロイ作業の自動化（全てではないが、頻繁な更新があったり、手作業リスク、複雑性などに応じてマストとするべき箇所はある）
　※cloudfrontのbehaviorが70個とかあったので、cloudformationにしたり、ブランチマージ時に開発環境のアプリケーションを自動デプロイしたり
<img width="150px" src="http://3.bp.blogspot.com/-aQv7kvOqIgc/U-8Fp7EjiWI/AAAAAAAAkvo/yVSK8sGL4VI/s180-c/kaden_syokusenki.png">
・マルチベンダーでの責任範囲の明確化（マルチベンダーの場合に限り）
<img width="150px" src="https://1.bp.blogspot.com/-ejibkKYoypM/WGYjdp4H2wI/AAAAAAABAys/E45Kov9QLCE_DDQYbL2uXxjny6R8rITggCLcB/s180-c/rakugo_bunshichimottoi.png">
・インフラパラメータ(awsなど)のwiki管理（インフラも対応している場合に限り）
<img width="150px" src="https://1.bp.blogspot.com/-I4BHL3BnPAo/XiOmSRZKWeI/AAAAAAABXHM/V8nAGfrCwqQn_OJ9bvlUWBhGvMxnh4y8gCNcBGAsYHQ/s180-c/trpg_character_sheet.png">
・リファクタリングを週1-2時間
<img width="150px" src="https://3.bp.blogspot.com/-Hy_N_4HUrO0/VocuX3gf1qI/AAAAAAAA2Z4/2ylJOCp1GOs/s180-c/souji_ofuro.png">
・知識共有を週2-3時間
<img width="150px" src="https://2.bp.blogspot.com/-w661BkZiogY/WFCPzTTyP5I/AAAAAAABAYA/HMd5ZzxzUu0JlvkH50I8YrPQ_G1rlOBjACLcB/s180-c/car_sharing.png">
・1タスク切りを最大1時間の単位まで分解する
<img width="150px" src="http://3.bp.blogspot.com/-GTFTcrywC5o/VJ6XrfyQH0I/AAAAAAAAqOc/JXc3E53vTgk/s180-c/puzzle_boy.png">
・開発ルールの蓄積
<img width="150px" src="https://1.bp.blogspot.com/-_HNFmvzrfhw/WerK8iVefvI/AAAAAAABHr0/DqwztqZ1B-MDvjMn-wC5hbrBLe94MR8MwCLcBGAs/s180-c/money_chokin_seikou_woman.png">
・開発上の細かい問題をgit hub issueの活用し、継続的に潰すこと
<img width="150px" src="https://3.bp.blogspot.com/-CwusFDqJhQ8/WGnPa_47IyI/AAAAAAABA6Y/Hu6osqdFNvEVYEAn3jxekC1t122sjpAKQCLcB/s180-c/room_office_dirty.png">
・品質指標の定義と見える化（コードカバレッジ、コード重複、コードスメルなど）
<img width="150px" src="https://4.bp.blogspot.com/-fXNoZRDBT38/WlGpXrgdYII/AAAAAAABJmo/78F0oIO8rakumr-sFPWiOhmQj-oYFOwigCLcBGAs/s180-c/job_dakenshi_kandume.png">

・非機能要件の前もったストーリー化
<img width="150px" src="http://1.bp.blogspot.com/-3UlFgnIe5qM/U2LukKMpb9I/AAAAAAAAfsk/Zeyx6RwvWbo/s180-c/time_machine.png">
・使用開発環境の前もった需要予測と実装（実例でいうとstaging環境）
<img width="150px" src="http://1.bp.blogspot.com/-mEG6sBd3lb8/Vf-Zon8LWLI/AAAAAAAAyBs/Mb8qvit5Kx8/s180-c/clone_man.png">

・要求要件、条件を明文化しwiki化(wikiだったり、チケット自体にだったり、チケットからwikiへのリンクだったり)
<img width="150px" src="https://1.bp.blogspot.com/--ZLNoD9ra1o/X4aVs2DIumI/AAAAAAABby8/dNvRJUk49Z0yG8FLXge4hQogLx5k74FxgCNcBGAsYHQ/s180-c/pop_kids_shoes_slipper_soroetene.png">
・チーム及び個人の開発速度の見える化と最適化のための仕組みづくり（ここだけでかなり話が長くなるので抽象度高いところで割愛）
<img width="150px" src="http://2.bp.blogspot.com/-n82hWJW0YwU/UT10KBkHUFI/AAAAAAAAOsY/pdwEX8AuSnc/s180-c/fantasy_toumeiningen.png">
<img width="150px" src="https://blogger.googleusercontent.com/img/a/AVvXsEiZ3rtXinzv6pp4KsemTWSW9TaEY5wfa9WYCc19Fi1xJdU0YSycyea0XN5iLwKFExn7DNCQpOu_KzIKS-dhqjpWv-p06fIi15z54qxX4KDmW-NsjRc7orKT7VW0_9DjxuKdCfN-0lZjAC3hh5tvOZBweZVjLRkfyLtd7zJqIDlYnLo0AJQGsJjXItOEjg=s180-c">
・「ざっくり見積もり」による4半期ごとのマイルストーンの作成と予算どり（優先度はやや低）
<img width="150px" src="https://1.bp.blogspot.com/-oy89vgiKoDs/X9GYaKhEduI/AAAAAAABcw0/7Cv9bU_UIcg_4bJS8foeKgOc8Vz3sKbwwCNcBGAsYHQ/s180-c/thumbnail_calender.jpg.">

・unitテスト実装
・e2eテスト実装（優先度はやや低）
<img width="150px" src="https://3.bp.blogspot.com/-1w_U96Q3yGc/WeAFe0HfspI/AAAAAAABHjs/v3mAi6n2K2AXt8O-RQ5O07v4-teSXRvLwCLcBGAs/s180-c/kodomo_shiryoku_kensa2.png">
・スクラムのフレームワークの定期的な復習（優先度はやや低）
<img width="150px" src="https://1.bp.blogspot.com/-RLKIRQEi_uU/XxU0ptF1vJI/AAAAAAABaOc/eeu-VfvE3S4rK9K-TyqE7CwQYjhgxsHoACNcBGAsYHQ/s180-c/sports_takkyu_volley.png">
→ここにヒントや答えがあることがよくある
e.g.それぞれのイベントのタイムボックスの制限時間など