t_wの輪郭

Feedlyでフォローするボタン
開発者あれdeveloperかいはつしゃ
開発者のエゴしゅいろ経験豊富な開発者開発者の生産性開発とドキュメンテーションの分離あれソフトウェア開発者アプリ開発者開発者が多くの経験をできると、開発者の生産性が上がる開発者が多くの経験をすると、経験豊富な開発者が増える開発者が多くの経験をできるテスターが開発者になる開発者がテスターをする開発者が容易にテストできる開発者不足開発者が不足する開発者が増える開発者コンソール会える開発者大橋悦夫開発者の作業あれ

あれ

2024/8/26 22:22:00

弊チームのデベロッパー増やしたい。N+1の冗長性しか無いので、N+2の冗長性がほしい。

「他チームから暇そうな開発者ぶっこ抜いたろｗｗｗ」とか思ってたら、他チームが忙しく成る雰囲気がでて頓挫した。

他チームが忙しくなるべく火を付けたのは私なので、なんやこいつである。
可燃性ガスが溜まってきてる臭いがしたので……。

あれ

2020/9/15 23:06:00

一般的な受注型の柔品開発を例にとると、
　要求分析→設計→開発→試験→納品→検収
の工程を経る
　
これを一気通貫にできる作業者がいれば、各工程をまたぐ際に必要な言語化・文書化の作業が省くことができる
　
その代わりに柔品の属人化を招く
水すましのような、文書化専属の作業者がいれば属人化を回避できるかもしれない（開発とドキュメンテーションの分離）
口述筆記の形をとるかもしれないし、成果物からの文書化の形をとるかもしれない
　
また、開発できる柔品の規模は1人分に制限される
残念ながら、例外を除いて文書化を省くことはできない

ドキュメンテーションを引き受ける作業者がいれば、開発者は開発に集中できる

技術的なドキュメント化はあらゆるプロジェクトに求められる汚れ仕事である。 適切なドキュメントを書いて、保守することは、プロジェクトチームが後で使ううえで重要だ。しかし、こうしたドキュメントは誰が書くというのだろう？ 開発者が自分でドキュメントを書いたら、「実際の」作業の妨げになってしまう。

それゆえ:
必要なドメインをよく知っていて、設計自体には利害関係のないテクニカルライターを雇おう。 適切な記法を用いて設計を表現してもらおう。整えたうえで公開し、レビューしたり、組織で使えるようにしてもらおう。

from 『組織パターン』