組織にテストを書く文化を根付かせる戦略と戦術（2019夏版） / Strategy and Tactics of Building Automated Testing Culture into Organization 2019 Summer Editionデブサミ夏 【B-4】 2019/07/02 13:15 ～ 14:00 https://event.shoeisha.jp/devsumi/20190702/session/2077/
技術的負債を抱えた状態で技術者がすべきこと - sandbox
この Qiita のエントリに触発され、元文章の目的はさておき、技術的負債についての自分の考えを書いてみようと思う。 技術的負債の定義や、問題は下記エントリを参照して頂くとして、なかでも最後の「技術者がすべきこと」について、「自分だったらこの様にアプローチするか」ということを書く。 技術者がすべきこと 大前提 開発前にステークホルダー(ここではプロジェクトの責任者とする)に、プロジェクトの性質として何を重視するかを認識、選択してもらう。 短期的な価値実現を最優先とし、初速を重視、ソフトウェアの健全さ、プロダクトの成長速度を犠牲にする 長期的な価値実現を最優先とし、ソフトウェアの健全さ、プロダクトの成長速度を重視し、初速を犠牲にする 1 を選択するという事について、健全でない状態や、成長速度が犠牲になった状態がどの様なものかを、プロジェクトが走り出す前に十分に認識してもらう必要がある。 …と
技術的負債 - Qiita
この文章の目的 開発者とステークホルダーが「技術的負債」という言葉で正しくコミュニケーションをとれるようになることをゴールとする。技術的負債については色々な所で語られるが、実際の現場では技術的負債が管理されてない事が多いのでは無いだろうか。この場で技術的負債という言葉についての知見をまとめ、たたき台とする事で、ゴールに到達する第一歩としたい。 対象読者 開発者 責任者/見積もりに対して決定権を持つ人 技術的負債とは何か 技術的負債とは、コード・設計の状態を表す見積もりのための言葉である。継続的に開発を行う上で理想状態から離れたものを負債という比喩で表していている。 たとえば、省略可能なプロセスを飛ばす事で開発の高速化を行う事があり、初期開発を高速に行う開発者の中には意識的・無意識的問わずこれを行っている事例が多々存在する。このようにして抱えられた技術的負債は長期的に見た場合に問題を引き起こ
「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
システム開発には、技術的負債、文書的負債、情報的負債の３つの負債がある - 室長のひとりごち
技術的負債はアジャイル開発の本を読んで知ったので、多分、ウォーターフォール開発関連の書籍ではなかったのだろうと思うのだけれど、誰が詳しい人いたら教えてください。 その技術的負債に関するブログとかを読むと人それぞれに負債として取り上げて書いているようなので、これといった決まりはないように見受けられるのだけれど。だから技術的負債ががが、なんて言うつもりはないのです。 技術的負債という言葉が出て来る前まで、いや確かな時期はわからないけれど、それより以前にこんなことを経験から感じていたものです。 ウォーターフォールでの開発プロジェクトは一般的に設計＜開発＞テストの比率で人員が増減するのはご存知のとおりです。もう少し正確に言えば、設計工程でも後半に向かって増加します。開発からテスト工程に移り、テスト工程も進捗するに従って人員はキーパーソンや維持管理を継続するなら、維持管理にアサイン予定のメンバを中心
技術的負債を管理する
日付2013-5-18(Sat) 書いた人おかざわ (id:yujiorama) 書いた理由技術的負債はいつ読んでも面白いんだけどそろそろ普通に向き合いたくなったので。 技術的負債を管理する 技術的負債は悪いものとみなされている。避けるべきものであり、できるだけ早く支払うべきものなのだ。 あなたもそう思うだろうか？私たちはそうは思わない。最初に技術的負債と財政的負債を比較して、戦略の設計とステークホルダーにおける類似点について驚くべき点があることを説明する。それからコード中の技術的負債を識別するための様々な可能性について一覧にする。それらはきっとあなたが対処しなければならないものだ。 最後にプロジェクトが技術的負債を返済するために取りうるいろんなやり方について述べる。あなたが返済したほうがよいのか、負債を変換するほうがよいのか、ただ注意を払うだけでよいのかを考える時にきっと役に立つだろう。
技術的負債と戦わずにマネジメントする - Qiita
技術的負債とどうやって戦うか - Qiita こちらを読んで、思ったことを書いてみようと思いました。 記事についての感想 ほとんど同意です！ 凄くまとまっていて読みやすかったです。 ここに書くのは引用記事の別視点での自分の解釈になります。 技術的負債はいつ生まれるか？ 残念ながらアプリケーションのコードを書いた瞬間に技術的負債は生まれます。 どんなに綺麗に書いても、レビューをしても消えることはない闇です。 つまり技術的負債は生み出さないようにするものではなく、コントロールするべきものなのです。 そして、引用元タイトルでは戦う！となっていましたが、 僕は戦い続けて疲れてしまったため、マネジメントすることにしました。 (やることは変わりません) 技術的負債を許容する 技術的負債を細かく返すことは賛成。 ただ、開発者はスケジュールと戦っているため、スケジュール内に必要な機能を提供することが最低限
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
