kelatebaru

There are some problems with Scrum that mainly occur when dealing with third party components or legacy systems: wrong estimations (time, impact, risk, complexity) bad requirements (inconsistent, incomplete, testable, conflicting, faulty) development involved in operations (bug analysis, data correction, deployment, hot-fixes) delays in development (bugs in legacy system, missing documentation) testing (quality/quantity of test cases, un-mockable interfaces, long running offline processes, performance issues, live and test system differ) General problems with Scrum: development (gold plating, rework, misunderstandings and bugs from collective code ownership) estimations (missing experience, excessive estimations for unpleasant stories) technical debt vs. velocity (architecture violations save deadlines) performance (stories are functional requirements, performance is normally no acceptance criteria, often only specified as "system should be fast and responsive") testing (t...

A professor once told me: Remember, a string goes into the server, a string goes out. Not more, not less. So let's ask the following questions: do you need a seven tier architecture? do you need to write a servlet container in PHP? do you need to derive a class more than twice? where do you need OOP? do you need design patterns? how to choose the right technology? And here are the development principles: keep it simple and stupid! (kiss principle) don't write your architecture on more than one slide write less code, you must maintain it! test your code, you're responsible for it! don't import much code from libraries, you might need to fix or upgrade it don't trust user input, don't trust foreign code, trust your own code don't use design patterns you don't understand no backup, no future don't use technologies you haven't evaluated for the current task if you're not sure how to decide, make more tests don't follow general recommendation...