@Nekonecode 良いプログラムを書くために心がけたい、たった１つの事「FOF」
「まず１ファイル」
記事拝見しました。そう。これなんです。個人でも、複数人でも。
班活動(group work)
班活動(group work)をする前に、個人作業した結果を持ち寄るようにしています。
FOFの原則のGroup版です。
当方では班活動はGitlabにあげたソースコードか、Wiki、Issueの記事を使っています。
設計審査(Code Review)にしろ、週報にしろ、全員がGitlabに上げてから始めます。
量の少ないものから議論(little thing first)
量の少ないものから議論すれば、すべてを議論できたり、みんなが主人公になれたりします。
量の多いものから議論すると、時間ぎれになったり、他の内容をそこに含んでいて、議論しないものができてしまう。
すべての人を主人公にした議論ができることが班活動では大事です。
具体例(example)
私は、主に試験担当です。
ソースコードをあげる時は試験プログラム
試験結果から直すとよい変更提案
分析結果
を上げます。
対象の設計が決まっていなくても、最終顧客を想定した、受け入れ試験案を書きます。
過去のいやな思いで(Past bad cases)
過去の否定的なことを書くのは、今日はやめておきます。
とにかく、自分で書いたものを持ち寄るのが基本。
自分の手を動かさないで、人の批判や足をひっぱる人はいらない。
それぞれが書いたものを持ち寄れば、他人を批判する時間が無駄だとわかる。
参考資料
@kazuo_reve 私が効果を確認した「小川メソッド」
@kazuo_reve 新人の方によく展開している有益な情報
@kazuo_reve ワークショップ「ソフトウェア開発におけるHAZOP入門」の結果
自己参照
効率的なHAZOPの進め方。仮説（187）
「@kazuo_reve ワークショップ「ソフトウェア開発におけるHAZOP入門」の結果」の分類
公開算譜は機敏だ(An Open Source Project is Agile)GitHub with Docker。仮説（51）
「会議は30分未満」小耳にはさんだ話。臨機応変。
文書履歴(document history)
ver. 0.01 初稿 20190506
ver. 0.02 かきかけの文を書き終わる。 20190507
ver. 0.03 参考資料追記 20220307
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.