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
Working on a large and complex application, I wonder where and whether we should be storing scenarios to document how the software works.
When we discuss problems with an existing feature, it's hard to see what we have already done and it would be hard to look back with a scrum tool such as TFS. We have some tests but these are not visible to the product owner. Should we be looking to pull out some vast story / scenario list, amending / updating as we go or is this not agile.
We have no record of how the software works other than the code, some unit tests,some test cases and a few out of date user guides.
We tend to use our automated acceptance tests to document this. As we work on a user story we also develop automated tests and this is part of our Definition of Done.
We use SpecFlow for the tests and these are written as Given, When, Then scenarios that are easy to read and understand and can be shared with the product owners.
These tests add a lot of value as they are our automated regression suite so regression testing is quicker and easier, but as they are constantly kept up to date as we develop new stories they also act as documentation of how the system works.
You might find it useful to have a look at a few blogs around Specification by Example which is essentially what we are trying to do.
A few links I found useful in the past are:
http://www.thoughtworks.com/insights/blog/specification-example
http://martinfowler.com/bliki/SpecificationByExample.html
Apart from the tests we used also a Wiki for documentation. Especially the REST API was documented with request/response examples but also other software behaviour (results from long discussions, difficult to remember stuff).
Since you want to be able to match a description of what you've done to the running software, then it sounds like you should put that in version control along with the software. Start with a docs/ directory, then add detail as you need it. I do this frequently, and it just works. If you want to make this web-servable, then set up a web server somewhere to check out the docs every so often and point the document root at the working copy docs/ directory.
Related
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
My team is building a product that has a lot of components that rely on each other. For example, whenever we add a new type of data to the system, we also have to add logging code to track the changes that use that data type. Or, when we add a new UI screen, we have to make sure that its strings are externalized so they can be translated. These things slow down almost every task we do, and sometimes one of the the steps gets forgotten.
The traditional way to handle this problem is to add required checklists and documentation and things like that. How do Agile methodologies handle it?
The design you describe sounds like it might be a little too tightly-coupled. A renewed focus on enterprise patterns (such as Inversion of Control, programming to interfaces, etc) could help a lot.
If you are doing pair programming, you should be checking each other's work, making sure all of the i's are dotted and the t's are crossed.
If you are doing Test Driven Development, your tests should not be passing until all requirements for that particular portion of the development effort are satisfied.
If you are developing a large, complex system, you need experienced developers who understand the design and development process. You may also need a hands-on (read:coding) architect who can oversee the whole process.
Oh, and checklists (despite their traditional nature) are good too.
I'd suggest reading Alistair Cockburn's "”Agile Software Development: The Cooperative Game" - he takes quite an intelligent approach to Agile that's largely "do what gets the job done". That might help you work out how to get some kind of checklist / documentation into what you're doing without making everything horribly top-heavy.
Could some of your problems be solved by better tests? When you talked about not doing things that need to be done, my first thought was "why hasn't a test failed?" Maybe you need to look at tools for testing user interfaces? (edit: or even some small script on commit that greps code for whatever indicates the need for translation strings and checks against the files with the translations in?)
Also, can you change your design so that it's both less coupled and "forces" you to do the right thing. Perhaps making those data types implement a logging interface that the logger delegates to, or similar...?
Depending on your IDE there are various tools to help identify strings that need to be externalized, but if you are in a habit of just not putting in static strings this can be avoided.
If you need to add logging I would suggest AOP, as, at some point you will want to remove the logging code and you risk breaking the application.
But, a long-term, complex system is ideal for agile development, as, while you are developing, the needs of the client/customer may change, and you can adapt to it.
You need to ensure that the customer has feedback on a regular basis (ideally daily, and in a perfect system the customer has a rep sitting by for questions).
When I have many steps that must be done, esp for something like datatypes, I will resort to using a spreadsheet, so, you add a datatype, you add a row to the spreadsheet. Then you can track everything that needs to be done before that datatype is completely added to the application.
Have cross-component teams. That way when you add some functionality, the member(s) from the logging component will update their part and the translator(s) will update the strings.
I think it is important to understand that Agile methodology is only a process framework, not a process in itself. For example it says to follow test driven development and do pair programming but it does not say how to write the tests, or suggest a review checklist or suggest a coding guideline or say what documents to write. Those parts are entirely upto you or your organization to define and follow.
When planning a feature, you can add a engineering task called "review" and allot time for it. You could do the review task in whatever way works best for you and your organization. If pair programming doesn't work as well as a formal inspection for you, you should do formal inspections.
Do what needs to be done, but not more:
better definition of done (the definition of done is a kind of checklist to me),
better testing,
"just enough" documentation (Agile != no documentation),
etc.
Well, where I work we have QA that can catch some of the bugs if there are missing requirements or something slips through. I'm not saying the development team is intentionally putting in bugs, but as a codebase grows, it becomes harder and harder to remain nimble and thorough in checking everything.
Wikis can be useful for capturing methods used to try to get the clearest requirements. By clear I mean that the story card isn't likely to list all the requirements and that there may be discussions with an end-user or business analyst to get their understanding of what is desired. Part of our sign-offs involve getting an end-user to see the functionality and approve it before moving from the development environment.
Once every handful of sprints, we may have most of a sprint devoted to bug fixing/refactoring so that things can be cleaned up that would otherwise not get done as they aren't likely to be important. This can be cosmetic bugs or broken windows that while they have little business value initially can be useful in the long run.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
We do distributed agile development and could really us a solution like story cards on a wall/board, only on a webpage where you could easily drag and drop them. Any suggestions? Thanks.
Trello is perfect for something like this. It's very simple, yet flexible. It's like a simpler version of PivotalTracker, mentioned above.
Its been a while since this was asked, but the best option out there in my opinion is http://www.Sprint.ly
Really powerful. Really beautiful. Really User Story focused!
I've used Eidos. I think it's the best if you want to use in Agile project (I've used it for real 3-4 projects for the real customer). Eidos team keep developing to serve human's need in Agile project. I think they invite beta users to test now. If you have problems about co-located team, this tool is quite useful (I prefer physical thing anyway if my team is co-located)
Me using Eidos, it's easier than Jira and focus more in Agile than Trello.
Not drag and drop, but I find basecamp very nice for agile development.
http://basecamphq.com
See if scrumy suits.
It's a tool roughly based on scrum. You create stories from them assign tasks to a story board assign them to people. In fact it is exactly what you've asked for! :)
You can set up a free project and play around with it.
Screenshot here
For User Stories, I find Pivotal Tracker to be awesome. It automatically fits user stories into each iteration based on computed velocity. Implements just enough workflow so everyone understands what they're responsible for. And is one of the cleanest, nicest implementations I've seen. (Although AgileZen is up there too... that app is gorgeous - but I just didn't gel with it in the same way)
However the drag-drop in PivotalTracker is limited to User Story-level objects. You don't move tasks around. For a more this-sprint/iteration task board, Scrumy is probably the one to go for.
Mingle may be something to explore and see if it'll work for your situation.
maybe a Bit oversized for your purposes, but targetprocess is a nice full blown project Management Software. It has a nice Kanban Board which fulfills your stroyboard requirement including Drag&Drop. It is free for up to 5Users.
I have used xPlanner before successfully.
http://www.xplanner.org/
Also, I have seen peole use Google Sites for similar effect. Either is drag and drop though
You could try using http://www.cardmeeting.com/
Take a look at Assembla tickets and its agile planner, it is a way to go.
Drag & Drop for:
to make tickets and user-stories
to sort tickets inside a milestone
to sort user stories
to move stories/tickets between milestones
sorting will be available on Monday(26 Oct) with next release as they promised.
Finally distributed agile development is a way that Assembla is doing their client jobs.
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
I'm interested in evaluating bug trackers, but I wanted to back up and figure out what sorts of criteria were most important in bug software. So far things I've thought of include:
integration with source control
usability
basic features (email notifications, rss, case states)
customization
advanced features (reporting, visualizations)
stability
cost
IDE integration
Any ideas?
Ease of use
This should, in my opinion, be on the top of your list of features to evaluate against. You want inhouse developers and testers to take any and all things they notice in the software and plug it into the tool, even if they're currently working on something else. For this to happen, the tool must be so easy to use that it stays out of the way and just takes your data. The worst bugs are those you don't know about.
A tool that has 15+ fields on the screen, where 10+ are required in order to just be able to submit the issue, is not such a system. With such a system, you'll get postit notes from testers to developers about the little things.
When evaluating BugTracker X, which bugtracker do the developers of BugTracker X use?
customizable workflows (from "open" to "in work" to "resolved" to "closed")
fine granular access control
There was a recent thread on Hacker News about this exact question. Lots of good stuff in there!
An API. Mandatory.
You MUST be able to catch and automatically submit bugs into your bug tracker from applications running in the field.
(Copy/Pasted from "Lasse V. Karlsen"'s answer)
You want inhouse developers and testers to take any and all things they notice in the software and plug it into the tool, even if they're currently working on something else. For this to happen, the tool must be so easy to use that it stays out of the way and just takes your data. The worst bugs are those you don't know about.
Even good, conscientious testers, if they are focused on testing component A but happened to stumble on a bug in component B, might not actually enter that bug if there is a lot of friction in the bug tracker. Friction means, required fields. It's not that the testers are bad or lazy - it's just how the human mind works. We focus. We don't see the guy in the gorilla suit.
The Joel/FogBugz philosophy of NO required fields is the right one (Also the philosophy of my own BugTracker.NET). You almost always can gather the details later - what os, what version, what browser, etc.
Also, take a look at "Bug Shooting", if your app has a GUI. You want to make it as easy as possible for the testers to take a screenshot and get it into the bug tracker, and that's a great tool for it. Pick a tracker that works with Bug Shooting or has its own dedicated screen shot tool.
Distribution. My version control system is distributed, why shouldn't my bugtracker? If I fix a bug on the train, why should I be able to make the fix but not record it?
Probably everything mentioned by others, plus some from me.
If you have long term big project, separate testing team that will do functional tests, you should take few additional things into consideration:
- can bugs be linked to test cases (and more precisely to given run)?
- can defect tracking system exchange data with test management system?
- can it produce (useful) reports?
- can bugs be grouped by release?
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
I found a lot of questions asking for the best tool, but none asking for the features, you really need? And what features you never really needed?
(I caught myself to be comparing tools on feature matrices. Something I hate, because in the end I will be using only the 3-4 most important features and leave the rest untouched.)
It need to:
collect bugs
order bugs on priority/severity/due date etc
assign bugs to developers
track a bug history
link similar bugs together
link bugs to customers
link solved bugs to releases
provide enough information or a reference to get the information to reproduce the bug
usable by more than one developer
bug status need to be accessible by the client that reported the bug.
And there are more.
Simple end user data entry. Without this you won't have bugs entered, which equals worthless bug tool.
I can't answer this question for you, because I can't predict what is important for you, or what your situation is:
Are you on a large or small development team, or are you a one-man shop?
Would it be useful to have a system in place where you could have your application automatically send in trouble reports that create incidents in your bug tracking software?
Is being able to predict a release schedule important, or is this just something for a side project you're doing in your spare time?
Is integration with source control important?
In reality, you're the only one who can answer what features are required for you.
Those are the 3 must-have features I find most important:
Web interface so people can follow-up
Source control integration, otherwise it's really hard to track who did what and deploy patches
Configurable workflow with email notifications
Things I would really like to see:
1) Voting - i.e. how many customers/users does this bug hurt?
2) Severity/priority/whatever - the distinction between these terms is subtle and normally (IMHO) insignificant, but you have to have some idea of how important the bug is. Most tools have this, but overcomplicate it.
3) Dependencies - both internal (on other bugs in the same system) and external (external libraries, software, etc). Most bugs have this in reality, but it's not normally expressible in the database, leading to long, pointless debates at triage time.
Things I think are largely pointless:
1) Any extensive questionnaires - any bug-tracker that asks too many questions will just get bad data. That's worse than none.
2) Controversial, but compulsory daily/weekly/whatever email notifications. They just get filed as spam/ignored/filtered out. If developers should be fixing bugs, and aren't, that's a management problem. Software cannot fix this.
Need:
Email notification.
Status
Group notify
Group rights
Web interface
Easy / fast interface
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
We are an all Unix shop (Solaris, Linux). This last product cycle I returned to a project lead capacity, and needed to produce a schedule. I asked what tools my managers would accept, and was surprised to hear "text files". My teammate and I gamely tried this, and probably worse, HTML tables, to track the tasks we wanted to size. It was pretty painful.
We then tried a few tools. MrProject is buggy, limited and crashes too frequently. My manager swears that Microsoft Project is inflexible. Whenever they needed to change a task, reassign a resource or rebalance, it generally hosed their plan. So I started looking around on the Internet for a Linux-capable project planning tool. One that sounded interesting is TaskJuggler. It's neat in that the inputs are declarative files. I feel like I'm building a makefile for a project.
However. I have a limited amount of time to devote to evaluating this tool and it seems pretty complex. Before diving into the next product cycle, I'd like to know if TaskJuggler is robust enough, flexible and capable of handling multi-month, multiple resource projects with frequent changes. So I'm calling on all engineers who have had experience with this tool to share their insights. Thanks!
There is nothing free in project management, and managing a complex project with software is inevitably complex. The real question is, does the chosen tool help with this?
Task Juggler has a learning curve, and in the end is suitable for someone who doesn't mind reading the manual (an absolute necessity for this tool) and isn't tied to graphical input. Task Juggler requires that you think about your project and structure it in a meaningful way. It is helpful if you do a diagram in advance (many TJ users make mind maps and there is a tool out there somewhere to generate TJ input statements from a FreeMind mind map). It is also very helpful if you organize your input file in some meaningful way, making things easy to find.
That said, once you get going, creating a project with TJ is super fast. You don't need to bother with a million dialog boxes, you just tell TJ what you want in TJ's text language.
But all of that aside, what I like about TJ (and hated at first, coming from a legacy of other more traditional tools) is that it ensures that your schedule makes sense. OpenProj happily schedules resources at 300% and more. TJ will give you an error and make you fix it. Yes, it's annoying. But the end result is that you have a project schedule that makes sense and can actually be executed. Imagine that!
As I started out by saying, nothing's free. TJ requires study and some effort. The reward is rich and copious reporting, all the information you need to manage your project to cost and schedule, and the enforcement of a logical, reliable approach to scheduling and resource allocation. And it doesn't cost $499 or whatever MSP goes for --- it's free.
I have been using taskjuggler for the past 4/5 years now (4 projects with an average duration of a year or more). I find it very useful to create my initial estimates of
how long the project will take
When will each resource group be freed.
What if we added more resources with varying level of experience and efficiency to different domains of the project.
Typically the kind of stuff that upper management will ask you about your schedule can be generated much faster and at a more accurate granularity compared to doing something similar using MS Project or other GUI based tools.
Till recently I was using taskjuggler to get my initial schedule and using ms excel to track the project.
This is the first time I am using task juggler to actually track the project on a weekly basis. and so far the results look good.
TaskJuggler's syntax is rather easy, but do take your time to read the documentation.
My experience with TJ:
very powerful and expressive syntax
useful for detailed calculation of large projects
However in reality a manual planning takes into account many implicit constraints, which TJ requires to be made explicit in order to obtain realistic scenario's. This is of course true for every planning tool, but I found it rather cumbersome to add and edit manual constraints in large projects in TJ... Therefore I found it less suited for project tracking and rescheduling afterwards.
I now use OmniPlanner, which is a far simpler tool than TJ and MSProject but turns out to suit my needs (especially in tracking, analysis and reporting).
I am using Taskjuggler to develop a very detailed task manager for big movie productions. It's brilliant cause of it's syntax and csv outputs.
I have been using it for 1w and love it.
The acceptance test, so to speak, is if you find text/coding more expressive than UI based input.
If you do feel comfortable expressing your thinking in a structured language but prefer/expect UI then do not spend time with TaskJuggler.
See http://www.pegasoft.ca/coder/coder_july_2008.html for these remarks like
"Don't expect a nice user interface with an "Add Task" button here."
"Even reports must be designed in it's awkward, C-like language"
If that is how you think then do not spend time with TaskJuggler.
TaskJuggler is (almost) a DSL for planning.
If you do not know what a DSL is then do not spend time with TaskJuggler.
Or learn about DSLs. :-)
For the rest, try it because it might just put planning in your own hands and take it away from the hands of people who demand it from you only to ask for status.