Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am in a team which we are delivering a product right now. We are preparing for regression sprint it will be the next sprint. In this sprint testers will have to test the whole application to ensure that the application in a stable state.
The problem is in development team actually we finished the queue of tasks that is needed for the current release, and we have a large queue of tasks but in another release.
I can think of two options to solve this issue
Doing a regression with some of testing team and let the other testing team join the development team to work in the next release
Dedicate a sprint to regression & bug fixing.
Hint: we have limited resources in testing so we can't offer a team for testing the regression
There is no such thing as a 'regression testing sprint'. It is a contradiction in terms, as a sprint includes everything that is necessary to deliver a potentially shippable increment of software.
In Scrum we do development, testing (including regression testing) within a time box that we call a sprint. We do this because:
We want to deliver working software every sprint
We want to give a true reflection of progress
When you save up the regression testing you are giving a false impression of progress. It may appear that certain functionality has been completed, but really until it has been regression tested there is no way to know how much work remains (e.g. there may be regression bugs to fix).
It is interesting that you say you have limited testing resources. I suspect what you mean by this is that you have limited people who have the label of 'tester'. A developer can do regression testing. They may even write automated regression tests, a particularly powerful approach when doing agile development.
In your current situation I would suggest you have sprint dedicated to finishing off the outstanding work. That means regression testing and bug fixing. If the developers don't have bugs to fix they should help out with the regression testing (either manually or by writing automated regression tests).
For the future try not to let testing get out of synch with development. Aim to finish every sprint with each story in a state of 'done' that includes regression testing and any other work that is necessary for it to be ready for a production release.
you might want to revisit your dev process so in the future
through automation of various tests (done by developers)
and/or by adding some time in sprint x+1 to fix the bugs found in sprint x
and/or by making smaller stories that can be implemented and validated in a single sprint (see the size of the sprint)
and/or a shift in culture if dev and qa are seen as different teams
you gradually come to avoid a scenario like your current one.
Assumption: you are not maintaining a huge legacy system (cobol) where a hardening sprint , or more, might make sense.
for the moment option 2 looks like the best compromise, assuming your devs will help the testing and testers will not find so many bugs that you will need a new sprint for bug fixing a new regression, etc :).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What happens in Scrum when the development team is the support team as well? How can this be improved using Jira?
We can't have a fire fighter because not all developers can solve both front-end and back-end issues.
But the support issues make team velocity difficult to obtain.
Mike Cohn wrote a good article on sprint planning for teams with a lot of interruptions.
He suggests having a rolling estimate of the average time spent on interruptions. Then allow for that when you do sprint planning.
For example, say the team averages 30% of their time spent on fixing issues. When you do the planning you plan for a capacity of 70% for development work.
As you mention in your question, nominating a person to handle issue fixes is a common approach. This is beneficial as it allows the other members of the team to focus on new development work without unexpected interruptions. In your situation where developers are specialists this is more difficult to achieve. You may want to consider doing some cross-skilling so that developers can handle a broader range of issues. They may not fix some issues as well as a specialist, but the loss in efficiency is gained back by the rest of the team avoiding interruptions.
Other things worth considering:
Triage bugs and only do the critical ones immediately. Schedule the other bug fixes as a part of your next sprint planning session. This may be easier to achieve if you have short sprints (say 1 week long) as the users will have less time to wait for a fix.
Analyse the bugs and see if some development work could potentially prevent future issues. For example, you may find that a lot of bugs occur due to bad data. Spending time making the code more tolerant to bad data can help.
Consider investing more time in automating your regression tests. This up-front investment of time can reduce the number of future bugs. It may seem like a lot of time and effort to do this, but making your workload more predictable can be valuable enough to offset this cost.
Production bugs have a bigger impact than the time spent fixing them due to the unpredictable way in which the work arises. That is why focusing on quality makes sense, even if it does seem like a lot of extra effort.
So the SCRUM is really for planned work, and if there is a lot of interruptions it may not be the best approach, maybe you should look at kanban or combination of both?
#Banarby Golden's answer very much answers the core question already, but since you've also asked about how to implement this in your JIRA project management:
I'd suggest using different projects or different epics for development and support tasks. Using a default Scrum project for development and a dedicated Kanban project for support issues seem's like a reasonable aproach to me (we are using this technique as well).
You can also create boards which span multiple projects, if you want to visualize the whole workload.
You could adapt the process based on the type of work coming in to sprints. It doesn't have to be set in stone as things can change over time.
Kanban gives teams just enough work so that they are consistently working at capacity.
Scrum divides work into sprints (fix-length iterations) allowing teams to work on top priority stories.
Scrumban is a hybrid of Kanban and Scrum. It's based on having a continuous flow of work and follows a pull-system. Stories exist in a backlog and teams still operate in sprints but WIP (Work in progress) is limited through each stage of the workflow and productivity measurements are in place using Cycle and Lead time metrics.
Note: Cycle time is the time a story takes from start to finish in the teams workflow. Lead Time is the total time the story appears on the Scrumban board.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
could someone explain to me the iterative development methodology and the benefits/limitations for using it in developing a web application?
Also, I've been researching it but I am confused, is it part of Agile or not? Some sources say that it is and some don't?
Thanks all.
Iterative is opposed to waterfall development. As you know, you should go through a couple of different phases for delivering a software product.
Requirements Engineering/Elicitation
Analysis & Design
Implementation
Testing & Verification
Deployment & Maintenance
At the end of each phase, you will have some Artifacts or deliverable results. In waterfall strategies, once you finish a phase, everything is done, and you will not come back to that phase again.
In iterative approaches, you will go through these phases repeatedly. In each cycle you repeat all of or part of these phases and at the end of each cycle you will deliver a working product.
Iterative approaches let you to develop your software incrementally and you will be able to establish and then further extend your product step by step. You may deliver just a skeleton of your web application at the end of first cycles and thenafter in each cycle, you will revisit your requirements, design, implementation, and your testing plans. You will find bugs and fix them. At the same time, you will receive feedback from your end-customers and change your product accordingly.
Agile methodologies like scrum, are mainly about how to eliminate unnecessary extensive processes like heavy documentation, formal meetings, etc. So, you can focus on your product and code instead and iterate through your cycles much faster. Agile neither enforce waterfall nor iterative approaches, but the fact is that waterfall is now outdated and it is not going be used any more in industry.
Iterative development has been around quite a while. It certainly predates agile, though you could argue it is ancestor of the agile development approach.
There are some non-agile development approaches that include iterations, such as RUP, so it is not exclusively an agile practice.
There are also a lot of ways to use the iterative approach. You could, for example, do up-front gathering of requirements and design and then use iteration during the development phase only.
Agile frameworks like XP and Scrum take iterations a bit further and look to have a 'releasable' product at the end of each iteration.
Benefits of the agile iterative approach:
The product is releasable at an earlier stage in development
Progress is often easier to measure (released code is a great measure of progress)
The iterative approach allows teams to more easily respond to change
Limitations of the agile iterative approach:
It can be a challenge to fit things like UAT and regulatory compliance in to iterations
There can be an overhead associated with frequent releases and frequent re-planning
You could think of having a releasable product at the end of each iteration as a pure form of iterative development. Not every team uses this approach. For example, some may leave the user testing until after several iterations. The downside with this is that you are never really sure the work is 'done', because potentially user feedback could change things.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What are the difference between Agile and iterative and incremental development? Is Agile considered as iterative and incremental? Some info shown the Agile is the latest of iterative and incremental. I need a clear clarification on this.
Iterative - you don't finish a feature in one go. You are in a code >> get feedback >> code >> ... cycle. You keep iterating till done.
Incremental - you build as much as you need right now. You don't over-engineer or add flexibility unless the need is proven. When the need arises, you build on top of whatever already exists. (Note: differs from iterative in that you're adding new things.. vs refining something).
Agile - you are agile if you value the same things as listed in the agile manifesto. It also means that there is no standard template or checklist or procedure to "do agile". It doesn't overspecify.. it just states that you can use whatever practices you need to "be agile". Scrum, XP, Kanban are some of the more prescriptive 'agile' methodologies because they share the same set of values. Continuous and early feedback, frequent releases/demos, evolve design, etc.. hence they can be iterative and incremental.
Incremental development means that different parts of a software project are continuously integrated into the whole, instead of a monolithic approach where all the different parts are assembled in one or a few milestones of the project.
Iterative means that once a first version of a component is complete it is tested, reviewed and the results are almost immediately transformed into a new version (iteration) of this component.
So as a first result: iterative development doesn't need to be incremental and vice versa, but these methods are a good fit.
Agile development aims to reduce massive planing overhead in software projects to allow fast reactions to change e.g. in customer wishes. Incremental and iterative development are almost always part of an agile development strategy. There are several approaches to Agile development (e.g. scrum).
Iterative development implies revisiting usual waterfall model steps over the course of product lifetime. The stages can even overlap, i.e. while doing end-to-end testing you could already start preparing new requirements.
Incremental development means you roadmap your features and implement them incrementally.
Agile aims at creating "potentially shippable product" after every sprint. How you achieve it is a different story. Agile tries to employ "best" techniques from various fields (e.g. extreme programming). Agile does not exclude running neither incremental nor iterative development.
Some important and successfully executed software projects like Google Chrome and Mozilla Firefox are fine examples of both iterative and incremental software development.
I will quote fine ars technica article which describes this approach: http://arstechnica.com/information-technology/2010/07/chrome-team-sets-six-week-cadence-for-new-major-versions/
According to Chrome program manager Anthony Laforge, the increased pace is designed to address three main goals. One is to get new features out to users faster. The second is make the release schedule predictable and therefore easier to plan which features will be included and which features will be targeted for later releases. Third, and most counterintuitive, is to cut the level of stress for Chrome developers.
Laforge explains that the shorter, predictable time periods between releases are more like "trains leaving Grand Central Station." New features that are ready don't have to wait for others that are taking longer to complete—they can just hop on the current release "train." This can in turn take the pressure off developers to rush to get other features done, since another release train will be coming in six weeks. And they can rest easy knowing their work isn't holding the train from leaving the station.<<
Agile is mostly used technique in project development.In agile technology peoples are switches from one technology to other ..Main purpose is to remove dependancy.
Like Peoples shifted from production to development,and development to testing.
Thats why dependancy will remove on a single team or person..
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
What are the agile testing methods? And what are the traditional testing methods?
What are the agile testing methods? And what are the traditional testing methods?
There are no "Agile Testing Methods" by itself as such but only testing done in an Agile Environment. Even if they exist, you cannot use "Agile Testing Methods" successfully in a waterfall organisation - so you have your concepts a little wrong there.
Anyway to give you some constructive feedback, the testing functions may very well be the same like waterfall, but the following may be different in an Agile Environment:
atmosphere and culture would be more collaborative (more face to face interaction),
tester involvement would be early,
the Team would code to a test, rather than code first and then create a test plan,
you would be cross functional so you may have to write code or do requirements gathering, and you will work closely with the customer,
you would work in 2 - 4 week iterations,
you would continually improve your testing procedures
you will not have a QA/Testing department
your role will be a "Team member who has most Testing experience" rather than "Tester"
Traditional methods are mostly the exact opposites of the check list above, seriously.
In traditional testing, assuming waterfall process, testing happens after the development phase. Testers create their tests from the requirements gathered at the beginning of the project. In the stereotypical sense, large organizations have a QA department completely separated from development departments where they are handed the final application and documentation to write test cases from.
In an agile environment testing occur asynchronously with development so that when a developer finishes a task it is tested so that at the end of the iteration the stakeholders know the task is a fully functional and tested. If bugs are revealed, they can be fixed earlier in the cycle, not in the final stretch.
This does not assume that every team writes using TDD or even pair/extreme programming.
One of the goals of agile is to improve communication between team members. Testers are included in the iteration planning and review meetings giving them more insight into what a given task is to accomplish. This will help them write tests beyond the sometimes vague black and white requirements.
I disagree with the notion that agile does not scale to larger projects that incorporate a QA department. Yes, in many cases and in some author recommendations agile teams are made of less than 10 but testing is integral in delivering a quality project. The challenge is how to proceed when corporate walls limit progress. How can I get a tester in my meetings or on my team? How can we get the QA more involved so that the customers are happy? etc.
I am not shure if there are any "testmethods" that are special to agile.
Of course there is "testdriven" (tdd) and "behaviordriven" (bdd) development but i donot see these as "testing methods".
Unittests are not special to agile or traditional.
As #khachik mentioned it: there is offen a huge difference when (in the develpment process) the tests are desigend and applied.
Traditional = Waterfall or V-Modell: Test are done in the end (if at all)
Agile : Test should be written before the code is written.
Your question is a bit unclear, but if I rephrase it as "How do testing methods differ in Agile environments versus waterfall type environments" you may get answers along the lines of:
In an Agile environment testing is, at a minimum, done at regular iterations (sprints). In waterfall style environments, testing tends to be performed after development is complete.
In an Agile environment testing is often included within development in the form of Test Driven Development (TDD). In a waterfall environment, testing is a separate stage of implementation.
In practice, this is a deep topic with complex perceptions on how development and testing should be done. TDD is an up front thinking process and in theory removes the need for end testers. Some argue that people skilled in Exploratory Testing are still needed regardless of the number of defined acceptance criteria and test cases.
The challenge in your question and even my rephrasing is that Software Testing isn't a simple thing that fits in one place nor has one shape. As for how it is actually done or should be done, there are thousands of articles on the topic with many opinions.
I'd suggest that you look up Bret Pettichord's presentation on the different schools of software testing, as a start. There aren't just two schools - agile vs traditional, but at least five. It's a great summary that will give you a quick overview.
The link posted above for Agile Testing, by Lisa Crispin and Janet Gregory is good, but I'd also strongly recommend:
Elizabeth Hendrickson - last year's Pask award winner. Agile tester. Why haven't you clicked on that link yet?
Also worth reading: the Context-driven Testing principles
In traditional methods first the entire development will takes place then testing will start,whatever bugs are occur are fixed by developers.
In agile methodology testing is a continuous process and it done concurrently with the development of the software components.
For regression perspective this type of testing will work more efficiently.
Agile testing is a fast process as compare to the traditional techniques.
(A practice that follows the principles of agile software development is called Agile Testing.)
In a lay man’s term, testing can be referred to as revealing a person's or an organization’s capabilities by putting them under strain; challenging. It can also be referred to as making a plan first, realizing the goals, estimating and planning all the procedures and the risks involved and then testing- whether one is proceeding towards the decided goal or not. In case not, then agile helps to change and formulate the plan and fix the hindrances in order to meet the goal finally. With agile testing it has become easy now to check the workings in between the procedure unlike the waterfall method. Agile is an iterative development methodology, where requirements evolve through collaboration between the customer and self-organizing teams and agile aligns development with customer needs.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
In my workplace, we "follow" the agile methodology. However, all we do is standups. How else do I have to change my way of working as a developer, to follow agile?
Thanks
Agile is really a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. It's hard to do by yourself.
That said, there are things you can do that will make you more agile, and that your teammates may choose to emulate once they see the advantages:
Work in small pieces. You want to break your tasks down into pieces that can be completed in a reasonable amount of time. (The teams I've worked on usually measured things in half-day units. Thus you could complete 2 units of work a day, and 10 units in a week.)
Commit functioning code. When you're working, you want to commit your code frequently, but only when the code compiles, and works without breaking your unit tests. You do not want to be the person who commits code that breaks a build.
Write Unit Tests. Your team IS writing unit tests for its code, right? If not, then start now. Writing unit tests will force you to structure your code to be testable, which will also force you to improve your implementation and design. It will also detect regression errors, by checking everything that used to work when someone makes a change.
Unit Tests for all bugs. Any time you need to fix a bug, first write a unit test that causes your code to fail in the same manner as the bug. Then fix your code. If the fix is good, your unit test should now pass -- and all of the rest of your unit tests should continue to pass.
Unit Tests for all new code. When you're building new code, you should be building to a spec. One of the best ways to ensure that the spec is good, is to use the spec to write unit tests for your code. Once you've got enough tests to validate the code you intend to write, go to work, testing your code against your tests. Once your code passes the tests, you can commit to the team repository.
Use Continuous Integration. This is something that the team itself should be doing, but if you can get the use of an extra PC (it doesn't have to be fast, just have enough memory and disk space to build your tools and build your software). Load CruiseControl.net or Hudson on it, point it at your repository, and configure it to wait for new commits, checkout your workspace, build your software, and run your unit tests. Why? Because it will catch when someone has neglected to commit all of the pieces of their change, before the change propagates to the whole team.
Automate your builds. Before you can use Continuous Integration you need to be able to build your software repeatedly without human intervention. If you're using Visual Studio, learn how to build using MSBuild or Nant. If you're doing Java, learn how to build with Ant or Maven. By building automatically, you avoid build and release problems associated with manual steps. (I once reduced the build process for a project from a notebook that took 2 professionals a week to complete, to a set of scripts that would take about an hour to run -- you better believe that improved the quality of releases.)
That sounds like waterfall with daily meetings. Implementing agile is quite a vast difference and you can't just change from waterfall to agile yourself, you need others to follow suit for it to work.
I think the largest change will be to stop thinking in "project" scope, and start thinking in very small increments of work. For example, when the project "Create website X" comes up, you'll need to break that down on a page by page basis. Determine what needs to be done, how exactly are we fetching, storing, updating, displaying the data. How long will it take to write the different pieces of code required to do that? Once that is laid out (there is much more planning involved in agile, from my experience) then you can start saying "By Wednesday, I'll be able to show you guys that I can save on page X and I'll display the data on page Y".
Usually there is a "planning" meeting. This can take an hour or it can take 6, this depends on how well your criteria is conveyed, how many members are on the team, and how long of a sprint you're working with. Everyone selects work that they will do, and puts estimates on it. After your sprint (which most people recommend to be one or two weeks) there is another meeting. Ideally in this meeting everyone will demo what they have been doing the past week(s), and it will work perfectly. Afterward there is some reflection, what worked well? Did we mis-estimate something terribly?
That is one "cycle", do that ~50 times and website X is complete! :)
To start with, there is no such thing like "the agile methodology", agile is an umbrella term that describes several agile methodologies and if all your workplace is doing is standups, I can already tell you that this doesn't make a workplace agile.
Second, while you can adopt some "agile practices" (especially engineering practices) at an individual level, this will never be enough to make you agile: 1. agile is in my opinion more about the way to drive product development than engineering practices 2. agile is a collective team game.
So, my recommendation would be to dive into for example Scrum and XP from the Trenches and to grab some copies for your coworkers, your boss or potential sponsors.
Congratulations on doing stand-ups. It's a good first change.
That you're asking suggests that you or the team would like to be better at this. In that case, you can go one of two ways:
Huge change, or
Incremental improvement
If you decide you'd like a huge change, you'll probably need some books, training and maybe a coach or experienced practitioner around. This is often successful if people higher up in the organisation are invested in the change too.
If you decide you'd like to improve incrementally, it's worth reading around Agile just to get some ideas. I recommend "XP Explained". There are a lot of blogs out there, too, as well as posts here. The two things you'll need to do are:
Try to deliver some software, or at least get feedback from the stakeholders
Work out why that was hard and what you can do to make it easier.
We normally do the first with showcases and the second with retrospectives. I recommend having retrospectives at least every two weeks, even if it's really hard to showcase working code.
Things I often see flagged up quickly as problems include:
Team not co-located ("Team" includes BAs and QAs)
Environment not suited
Lack of visibility of work in progress or overall goals
Too much work in progress - things started but not finished
Projects in progress that nobody really cares about
Project progress makes it obvious that it's not worth doing
Codebase is really hard to change
Blame culture discourages collaboration.
Whatever you find out, you won't be the first.
Note that Agile is a transparent methodology, whichever version you use. A lot of people get scared by transparency. This is normal. Sometimes managers higher up have a vested interest in not allowing things to be transparent. This is also common, and at that point you might need external help. Delivering working software can be very persuasive, though.
Good luck!
If you want do to this from the ground up, then all you need is the agile manifesto and recurring retrospectives each week. But I guess that is not enough, so here is my start-up-list:
Convert your existing project tasks/points/todos into User Stories
Pair program on everything. Switch pairs often!
Use Test Driven Development. Strive for 100% coverage!
Use one week iterations. Repetition is learning!
Deliver valuable software to the customer in each iteration.
Even if entire team doesn't work in an agile way there are few practices that you can adopt as Developer. You can begin with CI, TDD, automated deploy. As a team you can try out retrospective session.