bliki: Flaccid Scrum
There's a mess I've heard about with quite a few projects recently. It works out like this: They want to use an agile process, and pick Scrum They adopt the Scrum practices, and maybe even the principles After a while progress is slow because the code base is a mess What's happened is that they haven't paid enough attention to the internal quality of their software. If you make that mistake you'll
bliki: Technical Debt Quadrant
There's been a few posts over the last couple of months about TechnicalDebt that's raised the question of what kinds of design flaws should or shouldn't be classified as Technical Debt. A good example of this is Uncle Bob's post saying a mess is not a debt. His argument is that messy code, produced by people who are ignorant of good design practices, shouldn't be a debt. Technical Debt should be r
bliki: Design Stamina Hypothesis
Is it worth the effort to design software well? From time to time I have indirect conversations about whether good software design is a worthwhile activity. I say these conversations are indirect because I don't think I've ever come across someone saying that software design is pointless. Usually it's expressed in a form like “we really need to move fast to make our target next year so we are redu
The Practical Test Pyramid
The “Test Pyramid” is a metaphor that tells us to group software tests into buckets of different granularity. It also gives an idea of how many tests we should have in each of these groups. Although the concept of the Test Pyramid has been around for a while, teams still struggle to put it into practice properly. This article revisits the original concept of the Test Pyramid and shows how you can
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
