Tag Info

Hot answers tagged

8

Testers don't want to re-test is kind of like saying "coders don't want to refactor." Its part of the job. The process can be restated as something like this: Tasks are created. Code is generated. Code is tested. Code is reviewed. Imperfections are found in the code. New Tasks are created to address these imperfections (e.g. the code is refactored). ...


7

Technical stories are allowed, but I would advise you to try to avoid them as much as you can. For example, your story for saving and retrieving images can easily be written as two regular user-stories As a reviewer, I want my uploaded photos to be stored persistently, so that other users can view them at any time. (Note that this assumes that in your ...


6

If you are going to review the code at some point, it's no more expensive to do the review early. And it seems you have an expensive testing process, so you don't want to test twice. Therefore it is cheaper to review the code before testing. Reviewing the code after testing doesn't make the work go faster. It makes it go slower and tempts you to deliver ...


6

As with all things software, It depends on the complexity and context of a given project. The more tied you are to the risks of the project's success the better served you are by clear declarations of need/intent and deliverable results. Are you an employee of the people/company that want's the project done? If so, having an iterative approach without a ...


5

If you are finding it hard to get code reviews to happen in the time you currently have before QA, you should consider making code reviews more lightweight, as Code Review in Agile Teams, Part II that @Dukeling posted discusses. I found that even the simplest thing that could possibly be called a code review gave benefits: before committing code (or pushing ...


5

Something estimated to take that long can be shared, something that was estimated at more than a month of work for one person has not been properly broken down and tasked out. You've mentioned that there are a couple different pages involved, at the most naive level this could be broken down by page if you define the expected data passed between the pages if ...


4

The question, given your particular example, would be why does a developer want to develop a mechanism to store and retrieve images so that users can add/view images wherever required, unless a user wants to add or view images? That is, while your question is a good one, the example isn't. This is a user feature and should have a user story. And if the user ...


4

As @Tracker1 already mentioned it depends. The most important thing is managing expectations. Let me explain... In a standard software project you follow some kind of a software life-cycle process. The main steps or phases are: requirements gathering, planning, development, maintenance and obsoleting. In all of these steps there are stake-holders involved ...


4

Contract matters This is a big mistake because the time that I will spend [...] will not be paid Actually, the big mistake is that your contract makes it possible that you spend your time working for free. It doesn't matter if you are solving a bug or learning a technology required for a new project: the customer has to pay for the time you spend. You ...


3

You include every line of code and configuration that took you time to write. It is doubtful that the 1 kSLOC of JSON and XML appeared out of thin air. If you fail to do this, you will underestimate the amount of effort to create the product. On the other hand, it is likely the case that writing 1 kSLOC of JSON will take a different amount of time than ...


2

If it's that mission critical don't break the task, but have someone review what you write. The PM will be happy to have devoted more resources to one of the most important parts of the project and the code will be more robust.


1

From the sounds of it testers don't want to retest because testing is a painful/expensive process. Test automation both by devs and testers is a huge bonus for teams trying to work in an agile way. The cheaper, easier, and more reproduceable your tests are then the more you can execute them - and the less resistance you'll get to changing something. Done a ...


1

One solution for this problem is to do do a quick review of the code by another peer once a user story is finished, so that there won't be any basic / obvious mistakes in the code. But this has to happen before the test cycle. Then there would be less code changes after the test, when you do a larger reviews with all team together.


1

This is a good question. I don't have an official answer but where I work we add technical user stories and call them technical debt. If they weren't permitted, I would find some other way to get them added for the mere purpose of having my work recorded and communicated to the business. Likewise, having this documentation reminds us of what is needed for ...


1

This post reads like you really are feeling the frustration - I can empathise. There are a few things that could help you through this; A good book on code construction etc. Code complete 2 is often cited in this regard More or better familiarity with you tools Using their features well Making peace with their short comings, no tool is perfect Time, it ...



Only top voted, non community-wiki answers of a minimum length are eligible