完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita
これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある本稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ
Apache Log4jの脆弱性とともに浮かび上がったオープンソースのメンテナの責任範囲の問題 - YAMDAS現更新履歴
www.jpcert.or.jp piyolog.hatenadiary.jp 先週は Apache Log4j の脆弱性問題が大きな話題となった……と過去形で書いてはいけないのかもしれない。危機はまだ続いている。 今回、脆弱性の破壊力のヤバさとともにクローズアップされたのは、今日、多くのビジネスの生命線となっているオープンソースソフトウェアのメンテナンスが、無報酬であり感謝されない仕事になっており、「オープンソースは壊れている」んじゃないの？ という問題である。 20年以上みんなずっと同じ話してるなと思ってしまうが、オープンソースが壊れている、壊れていないの話がやたらに流れている。この文脈ならフリーソフトウェアの時代からずっと壊れてるんだよ。それでも動いているのは自由だからだよ。— Shuji Sado (佐渡 秀治) (@shujisado) December 14, 2021 dev
リスクの洗い出しと判断のコツ - やしお
会社で係長的なポジションになって3年近くが経った。先日、副係長というか職長的なポジションが新たに設けられ、30歳前後のメンバーが就いた。折を見て彼らに伝える機会があるかもしれないし、3年やってみた知見を自分の中で一度整理しておきたいと思った。（大手メーカーの製造側に近い部門で働いている、という前提がある。） 自分が苦しくならないようにする 究極的には本人が自分でスタイルを確立するしかない。 「こうした方がより良い」と思って行動変容しても、それで自分が苦しくなるなら続けられない。 どうせ正解の型が一意に決まるわけではないし、仮に正解の型があっても自分を完全にはめ込むこともできない。 「自分がやれるようにやるだけ」くらいに思っている方が精神衛生に良い。それで不適格ならしょうがない。 一方で「より良い方法」に寄せる努力も必要で、その間のバランスが必要になる。 例えば自分自身は、人付き合いがすごく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
