Tag Info

New answers tagged

2

For a good definition of Test Driven Development, I suggest you read Doc Brown's post. Here is how I would answer a similar question: All three practices are not mutually exclusive and can be combined into the larger software development process. Developing based on User Stories in iterative development cycles (Agile) does not exclude the engineering ...


0

TDD means writing unit tests, before writing the code. Your unit tests are the documentation, and they dictate the design. Integration tests is testing how group of modules integrate together. It comes after unit testing. Agile methodology is the way you organize your process, in order to faster respond to requirements changes. That usually means ...


-2

Whilst there is a clear issue when a member of a dev team ends up working away from the rest of a team, hot desking within a dev team could provide way of knowledge sharing effictively and facilitating pair programming


-1

In my experience (from working as a software consultant 10+ years) is that it's really really difficult. Either your team will be disturbed by the others or you will disturb them. I would say that a company adopting hot-desk policy for developers don't understand the requirements and the CIO/CTO should fight the policy.


-1

Put your build, status, project whatevers in the cloud. Either using third-party services or your own software on cloud servers. Then it does not matter where you work from as long as you can reach the internet.


0

In my opinion the velocity during the first sprints is meaningless, because the team is normally busy with other things in the so called Forming and Storming phase. Dealing with velocity from the beginning may frustrate the team members even more. The best time is to bring in velocity during the Norming Phase. See: Tuckman's Stages of Group Development


2

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 ...


0

Agile doesn't necessitate an absence of high level design. Before a story can be worked on by a developer, is a single user story going to completely capture everything needed to be defined before one can start sprinting? As a user, I need to enter first name into a text input field on the X form, so that I can submit my first name as part of my profile ...


3

To use your .NET analogy, the flow for an agile development of those controls would be: TextBox: This text box is pretty awesome! CheckBox: Hey, another one, wait a minute... Label: Yeah, I'm seeing a trend here BaseControl: That helps! Essentially, instead of up front trying to look for your abstractions and designs, allow the design to emerge as you ...


1

There is some room for debate, but I think most people agree on the gist of it. simplest path that is consistent with their goals Simple is relative to the goals. A prototype for the .NET concept may have been built the way you described, but at some point, the goal involves a major framework that needs to be built with a lot of rigor and room for ...


-1

Here's a quote from "Agile Principles, Patterns, and Practices in C#" By Micah Martin, Robert C. Martin Simplicity the art of maximizing the amount of work not done is essential. Agile teams do not try to build the grand system in the sky. Rather, they always take the simplest path that is consistent with their goals. They don’t put a lot of ...


2

The concept of agile is that things change. So if you spend a very long time working on a super-engine, by the time you've finished and its ready to use, the requirements or technology may have changed and you'll have to start over. In reality that's not likely to happen, but the requirements do change. So agile methodology works on the principle of getting ...


5

The key thing to consider here is whether your stories are manageable chunks of work. To be manageable they need to be: Unambiguously defined Fairly easy to estimate Completable within a sprint So, if you find that merging two stories somehow compromises any of the above points, then don't do it. Personally, I prefer working with many small stories as ...


0

I think it really depends on the stories themselves, are you going to differentiate the process or administration of the two tasks? I could envision a scenario where there really is no difference beyond whether or not you are creating a new record. This could be done as a single story. I could also envision a scenario when only certain admins can create ...


2

TL;DR They ought to be two separate, but related requirements. The risk in running them as separate requirements is that you'll have duplicated code for the associated UI and underlying services. But the risk in combining them as a single requirement is that the edit path has a slightly different setup to it. A create path would look something like ...


2

I think that Option A, with separate user stories, would be preferred. User stories are requirements. There are a set of characteristics of a good requirement that tend to be well accepted. Option A ensures that your user stories are cohesive (addresses one and only one thing), atomic (does not contain conjunctions), and more easily verifiable than Option ...


0

I don't know what a default velocity is. But... You got to start somewhere. New team on a new project. Everyone estimates to the best of their knowledge, and with short iterations (say 1-week sprints) by 3rd week you should have a vastly improved understanding of your velocity. First 2 weeks will be a mess.


2

Yes there is a reason - because a default velocity is meaningless. The velocity is the speed at which your team can progress tasks, but that measure is created by using the sped at which your team has completed tasks. That's the only way of calculating a velocity. So by using a default one, you might as well stick your finger in the air and say "finished ...


1

Scrum Master do not give their status update, but they are there to facilitate the stand up meeting. Their role is to make sure meeting starts on time, everyone in the meeting gives their status updates within their time frame, take action when any team-member has roadblocks in completing their task. FYI, we are using our daily stand up meeting online at ...


1

My preferred method which I have been using for at least a few years now is to bump up the number after each story is completed. This means that the versions released at the end of the sprint will not be continuous, e.g. after 1.2.3 you might find 1.5.2 rather than 1.4.0. In the changelog you may either list the intermediate versions with their ...


2

If the classic semantic versioning scheme "MAJOR.MINOR.PATCH" makes sense, depends on to whom you deploy, and especially when and how often you deploy to the end user. The scheme is most useful if you work with stable release "4.5", where you start with as 4.5.0. The versions 4.5.1, 4.5.2, and so on contain only bug fixes, whilst you internally already work ...


4

For typical release management, you will want a build number being generated by your build system so that the DLLs are versioned every time they are deployed. This will ensure you can later check which version is deployed on a given server. Your 'marketing' version, which is usually put in release notes or published to your site should not be updated each ...


2

I would use build numbers. Usually a build number would correspond to the highest version of the version control system. If mondays build number was 1745 and there has been checked 5 changes in during tuesday, tuesday evenings build number would be 1750. Then make a short summary for what has changed between 1745 and 1750. Then every time you update the ...


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.


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 ...


2

It depends. Different agile teams have different processes because they have different needs. If you have a few dozen bugs coming in every day, an informal cube meeting is probably not going to cut it. If the majority of the bugs are user inputted, you need someone who just looks for dupes and can judge usability issues. If you're a small group, then ...


0

The first thing to say is that almost everything a Scrum team works on should be discussed in Sprint Planning meetings in the usual way. Whether a Story is a bug fix our new feature development, it is at this point that the Product Owner should put it in its place in a prioritised Sprint. Secondly, disruptions to Sprints do occur - it's just a question of ...


2

Triaging is not typically done as a meeting. Teams do it differently, depending on the product, but on our team, the product owner triages the customer issues, and we rotate another team member as "triager of the day" for issues that testing finds. The triager's job is not supposed to be debugging, but answering the following questions as efficiently as ...


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.


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 ...


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 ...


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). ...


6

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 ...


9

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 ...



Top 50 recent answers are included