Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Our team is transitioning from waterfall model to Agile model. We are using Rally for sprint planning and user stories.
The current project that we are working on required 4-5 weeks of lab setup, installation of servers and other general administration tasks. Originally, the plan was to finish these tasks and then start official sprints in Rally.
However, now the official direction is to include these tasks which we have already done in Rally as well. So, I've got the following questions:
Is it possible to include sprints from past dates and add those to Rally?
Is the above an allowed practice in Rally?
What could be alternative way to document what we have accomplished so far in Rally if #1 above is not allowed?
Thanks in advance.
You can certainly create Sprints whose start and end dates are in the past. You can then associate Rally artifacts to those sprints. This will at least get your data into Rally.
However, what you won't be able to do is obtain reporting or burndown charts for those sprints. Per your question about post-dating object - you cannot modify CreationDate or InProgressDate or AcceptedDate for Rally artifacts, after the fact, even using the API. These values are calculated by Rally internally and cannot be modified, for purposes of trace-ability and accountability.
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 3 years ago.
Improve this question
How to decide which type of testing(Manual or automation) required for a project or application to test?
What are the parameters we have to consider to select which type of testing(Manual or automation) to test very new application?
It depends on :-
Size of the project- If the project is large and consist of so many functionalities then automation testing is suggested
How many times you want to test a particular feature- If the requirement is to test regularly then automation test is best
Font size and image- This can not be tested through any automation tool so to test this, one should need to do manual testing
To find bugs- If one needs to find a lot of bugs, Manual testing is suggested.
You shouldn't have to choose between automation testing and manual testing the way you're asking. The way you're asking it gives me the feeling that the product is already waiting to be tested. In this case you would need to resort to manual testing.
Ideally you would want to have both and even more of automation. Some of the questions that you need to ask are:
Is this a new project or an existing one? If it's a new project then it's easier to plan for automation from the start. You could start implementing automation tests from the start. If it's an existing project then you'll need time to set up automation + write scripts etc. Then you have to resort to manual testing initially.
Is there any existing team? If yes, then what are they doing. You need to continue the process instead of suddenly disrupting it for anyone.
How much resources (money+people) do you have? Do you have manual testing resources? Are they busy or do they have bandwidth? How many automation test resources do you have?
What kind of project is it? Who does it go to? Does it have human lives depending upon it? Does it need a legal certificate of some kind for being tested?
There's just too many questions based on how your question is currently stated. I hope that this answers your question when we consider it generally. But if you're looking for a particular answer then please consider adding more context.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Hi I am currently in a Scrum Team where the Scrum Master and Product Owner exclusively decide which stories a team will work on for a sprint.
They are also exclusively responsible for analysing the accuracy of estimations and measuring velocity.
I am in favour of giving this responsibility to the team but I would like some unbiased opinions on the approach, pros/cons etc.
I recommend a review of the scrum guide for a truly unbiased view. It's available from here : http://scrumguides.org/ The scrum guide is very clear on the separation of roles in the areas you've mentioned.
The product owner is responsible for the product backlog, including it's ordering.
The estimation of the items in the product backlog is the responsibility of the people doing the work (ie: the development team).
The selection for work to be taken in to a sprint is a collaboration between the product owner and the development team.
Velocity is a measure of the work completed in prior sprints. It doesn't need to be measured. It simply 'is'.
You sholud do it togehter as a Scrum Team. It's true that PO set business priorities but also there can be some technical blockers and dev team can support PO in that field. SM shouldn't make dacisions - his role is to support both, developers and PO to find best solution.
About velocity and estimations, that's is also part of SM work to help you identyfy your problems, ex with estimations and in general planing and analysing data helps here a lot to check if your estimations are ex too optymistic
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Gathering requirements is an essential stage creating software or web applications.
I have searched the web extensively without finding any directions on how to elicit requirements for personal projects. All information i found - including books i read - is focussing on different stakeholders.
So i´m wondering, what would be the best way to 'gather' the requirements for personal projects?
I can't imagine i'm the only one with this question. I have plenty of ideas for webapplications. Since i am the only stakeholder at this time - no users are identified yet, i need to develop a couple of applications for personal use - i find it hard to interview my self to elicit those requirements.
As English is not my native language, apologies for possible textual errors.
You can have a document with all the information you have in your head of the project in a bullet list format called "Project Memoir". Just list all the information & business rules you need to put in the project. You can after that start developing a kind of informal Software
requirements document (as it's for a personal project) containing some essential information for you in the development phase, like a feature list with their description, use cases & scenarios that will help you in testing in later phase, mock up screens for defining the UI look & elements, data elements lists for defining screen contents. Just keep it simple & easy as it's for only your personal use.
Hope that would help :)
The questions are supposed to be a trigger of a thought process.
What makes it any different in case you are the developer next to the stakeholder? Your thoughts are those of a stakeholder and you will have to try to identify your own requirements by this process.
Identifying your own requirements with a structured approach will help you identifying requirements that you would otherwise have encountered during development.
If the sole purpose is not only personal, I doubt whether it is a good idea to start developing. Then you will need to find prospects to interview. Investigate the possible markets.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
It sounds strange, but that's what I need. An effective way to document a Scrum project.
I agree that it's a waste of time to produce User Stories and a Requirements Documents.
But sometimes we need to have the vision of how the software currently works.
How do you do that? Do you know some best practices or case scenarios on this?
Thanks
The short answer is this: you can write anything you want or need to about any project, Scrum or otherwise. Scrum doesn't tell you how to document, but it doesn't tell you not to. The way you document is in itself irrelevant to Scrum.
That said, if you need to understand how the software currently works, a document will not help you. Documentation often lies. If you're trying to understand how the system works, a document will only tell you what people think or want to believe is the truth.
What you should consider, is to use executable specifications and Test Driven Development to prove that what you believe the software does is actually true. automated tests combine documentation, examples and regression tests all into one offer.
There are several kinds of documentation that can help you. It depends on your context which ones you need, and at what detail level. You could also use a tool such as MOOSE to create project specific visualizations of your software at all levels. Some simple documents are:
A story map
Gherkin style high-level features and scenarios
If you've tracked your product backlog items through completion, including acceptance criteria for each you should be able to point to the list of completed product backlog items as documentation. Everything you've programmed should be associated with a PBI, so the completed PBI's document your project.
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
I work for a insurance company. We have our own development department made-up of almost 150 people plus some providers (outsourcing and custom made apps pretty much). In our company my team have made what we call non-functional logic libraries. That is, software libraries to handle things that are horizontal to all the development teams in our department, e.g. Security, Webservices, Logging, Messaging and so on. Most or these tools are either made from scratch or adaptation of a de-facto standard. For example our logger is an appender based on Log4J that also saves the logging messages into a DB. We also define what libraries to use in the application, for example which framework for webservices to use. We use pretty much JavaEE and Oracle AS in all our organization (with some Websphere Application servers).
Much of these projects have their architecture documented (use cases, UML diagrams, etc) and generally the generated documentation are available.
Now what we have seen is that for users sometimes is difficult to use the the libraries we provide and the are constantly asking question or they simply don't use them.
So we are planning to generate a more friendly documentation for them, so my question is:
What are the best practices or the checklist that software documentation should have?
Something comes to my mind:
API Reference guide
Quick start Tutorial
API Generated Documentation.
Must be searchable
Web Access
What else should it have? Also, based in your experience what is the best way to maintain (keep it up-to-date) and publish this type of documentation?
Keep your documentation in version control too.
Make sure on every page it has a version number so you know where your user has been reading from.
Get a CI server going and push documentation to a LIVE documentation site upon updates.
Do documentation reviews like you would code reviews.
Dog-food it :)
Kindness,
Dan