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.
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
I am a long time agile advocated but one of the things that bothers me about Agile is that a lot of agile practitioners, especially the younger ones, have thrown out or are missing a whole lot of good (non Scrum, non XP) practices. Alistair Cockburn's style of writing Use Cases springs to mind; orthogonal arrays (pairwise testing) is another.
I read mostly Agile related books and articles and work with mostly Agile folk ... is there anything I'm missing?
It might be interesting in 5-10 years time to see how maintainable these systems are when nobody wrote down why a particular decision was made and all the people involved have left.
is there anything I'm missing?
Yes, I think a lot, but only if you are interested in Softawre Development Processes.
I like this paraphrase:
Each project should be as agile as possible but not more agile.
Not every project can be agile... but I think 80%+ can.
I see Agile as "car of the year". It is very well suited for most of the people, but if you need/want something special, for example car able to speed 300KM/H or car able to carry 20 tons of goods you need something else.
There is also so many cases when one may want something else than "car of the year" that requires a book to write them down :-) I recommend you Agility and Discipline Made Easy: Practices from OpenUP and RUP. In this book you'll find many "missing parts" very well illustrated. The key to understanding is that Agility is only a (requested) property of software development process which sometimes cannot be achieved. The book describes several Key Development Principles (which are basis for RUP) and explains which level of "ceremony" and "iterativeness" follows from using them on different levels of adoption.
An example
Practice: Automate change management and change propagation
In your project you may require very advanced and strict change management and decide to "Automate change management and change propagation" by implementing custom or re-configuring existing tools and by using Change and Control Board.
Effect: This most probably increase level of "ceremony" in your project.
(...) have thrown out or are missing a whole lot of good (non Scrum, non XP) practices.
Scrum is not prescriptive, it's up to you to choose how to do things. In other words, nothing forces you to use User Stories for example (even if User Stories work for lots of teams, there is no consensus) so feel free to use (light) use-cases if you think they are more appropriate in your context. To illustrate this, Jeff Sutherland reported he would never use User Stories again for PDA device projects (they use some kind of "light specifications" in his current company). And the same applies for testing, use whatever works for you. To summarize, if you find XP not flexible enough, use something else... and inspect and adapt.
Iterative development.
In practice, agile teams may do iterations (or anything for that matter, agile is a kind of "true scotsman"), but agile processes don't require or define iterative development sufficiently.
Take RUP, for example - clumsy and bloated, it does compile a few good methods for long-term development that agile misses.
On a general note, agile is a way to steer clear of problems: how to avoid long term planning, how to keep teams small, tasks short, customers involved, etc. It works more often than not, but sometimes you have to face and solve problems: how to reach strict deadline, make big team work, achieve distant and complex goals, make customer refine requirements. That's when one needs to look beyond agile.
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 5 years ago.
Improve this question
I want to start Agile practices in a team. I'm assuming the information is available for free online about how to specifically carry it out.
Online I can locate the manifesto, the alliances and corporations involved but where is the actual central guide or root instruction set about how to do it? (Maybe the practices themselves are more ethereal or subjective than I expect and it's found in multiple places?)
Edit to summarize solutions:
Agile is a concept so that's what's to be found online about it. However specific processes or methods of Agile development have been created like Scrum and Extreme programming to provide concrete solutions to teams who want to adopt Agile and reap its proposed benefits. Find the shoe (or method) that fits best. Maybe create it.
If looking for solutions online to implement Agile development in your organization or for your project, seek out the specific methods too and decide among them.
There are numerous Agile methods.
Not one. And nothing definitive on something like "Agile". That's like a definitive guide to "Honesty".
Read this for one Agile method that some folks like: http://www.controlchaos.com/old-site/Scrumo.htm
Alos, there are numerous non-Agile methods. They'll all have a form similar to this: http://en.wikipedia.org/wiki/Waterfall_model
I agree with S.Lott. There are lots of Agile methods, not the one Agile method per se. Likewise I wouldn't know any central guide which covers All You Ever Wanted to Know About Agile.
I would actually recommend a book here. The one I found gave a pretty good introduction into how to go agile was O'Reilly's "The Art of Agile Development". Mind you, yeah, it is a book and therefore costs money, but not so much that it wouldn't be worth it if you really want to learn something.
There's nothing like specifically carrying out Agile. It's a bunch of methods and ways that you can adapt (or choose not to adapt). Some of them are more important than others, specific methods (like Scrum) define a couple of must-follow rules, whereas you can just as well pick what you think works best for you and see how it turns out.
I would actually recommend starting at one point with a good definition of Agile (the one at Wikipedia seems fine, along with a list of Agile methods and practices) and reading up on all the methods and practices from there. There will be googling involved.
Here is a good resource to learn about Extreme Programming which is another agile methodology.
Here's a downloadable book by Henrik Kniberg on Scrum and XP from the Trenches which describes in detail how his team did Scrum. When we implemented Scrum it was useful to have an in-depth look at what another team had found effective.
There is no definitive resource for all agile methods - as there is so much diversity in the methods.
The people that came up with the word "agile" didn't actually have that much in common - so it's not as though there's an "international headquarters of agile"... ;-)
It depends which one you want to know about: Scrum or XP or Crystal or one of the other methods... some of them are quite different from each other...
For Extreme Programming - the original XP material (and many of the experts) wrote it up at http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
Scrum: The Scrum Alliance is pretty much the definitive place for Scrum http://www.scrumalliance.org/
Crystal is by Alistair Cockburn so look for stuff by him. I don't know much about how to do crystal, but Google likes this: http://alistair.cockburn.us/Crystal+methodologies+main+foyer
Don't start out by reading a bunch of different methods you haven't tried out and mixing together the bits you like - a mistake that's far too common. That results in random chaos.
Best way to start:
Look at some agile methods
Pick the one you think is most practical to adopt in your circumstances.
Try doing it by the book for a while - say for at least a month.
After you've been doing it for a while, you can get the team together to run a retrospective to decide what to improve - or what to try instead.
Recommendation (assuming you don't have experienced help on hand)
Scrum is pretty easy to get going. You can set it up in about 2 days if you're familiar with the basics.
Maybe after you've done scrum for a while you can start phasing in more of the XP practices. In any case, scrum doesn't have anything to say about technical things like the code, testing or refactoring - so once you've got the scrum basics down, you could start rolling in some XP practices. I think Test-Driven Development is the first one to start with.
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
When you have sprint task in Scrum, where do you put how you want to program something? For example, say I am making a tetris game and I want to build the part of the game that tracks the current score and a high score table. I have my feature, my user story and my task, but now I want to talk about how to design it.
Is that design something that is recorded on the sprint somewhere as to how to do that or is that just somethign the programmer figures out. Do you put do task x use database such and such, create these columns, etc.? If not, do you record that at all? Is that what trac is for? I don't mean too high level design.
I touched on it here: Where in the scrum process is programming architecture discussed?
but my current question is later in the project after the infrastructure. I'm speaking more about the middle now. The actual typing in the code. Some said they decide along the way, some team-leads. Is this is even documented anywhere except in the code itself with docs and comments?
edit: does your boss just say, okay, you do this part, I don't care how?
Thank you.
There can be architectural requirements in addition to user-specified requirements that can muddy this a bit. Thus, one could have a, "You will use MVP on this," that does limit the design a bit.
In my current project, aside from requirements from outside the team, the programmer just figures it out is our standard operating procedure. This can mean crazy things can be done and re-worked later on as not everyone will code something so that the rest of the team can easily use it and change it.
Code, comments and docs cover 99% of where coding details would be found. What's left, if one assumes that wikis are part of docs?
Scrum says absolutely nothing about programming tasks. Up to you to work that out...
Scrum doesn't necessarily have anything explicitly to do with programming - you can use it to organise magazine publication, church administration, museum exhibitions... it's a management technique not explicitly a way of managing software development.
If you do extreme programming inside scrum, you just break your user stories for the iteration down into task cards, pair up and do them.
When I submit tasks to my programming team, the description usually takes the shape of a demo, a description on how the feature is shown in order to be reviewed.
How the task will be implemented is decided when we evaluate the task. The team members split the task in smaller items. If a design is necessary, the team will have to discuss it before being able to split it. If the design is too complex to be done inside this meeting, we will simply create a design task, agile/scrum doesn't force how this should be done (in a wiki, in a doc, in your mind, on a napkin, your choice) aside for saying as little documentation as possible. In most case the design is decided on a spot, after a bit of debate, and the resulting smaller tasks are the description of how things will be done.
Also, sometimes the person doing it will make discoveries along the way that change the design and so, the way to work on it. We may then thrash some cards, make new ones. The key is to be flexible.
You do what you need to do. Avoid designing everything up front, but if there are things you already know will not change, then just capture them. However, corollary to YAGNI is that you don't try to capture too much too soon as the understanding of what is needed will likely change before someone gets to do it.
I think your question sounds more like you should be asking who, not when or where. The reason Agile projects succeed is that they understand that people are part of the process. Agile projects that fail seem to tend to favor doing things according to someone's idea of "the book" and not understanding the people and project they have. If you have one senior team lead and a bunch of junior developers, then maybe the senior should spend more of their time on such details (emphasis on maybe). If you have a bunch of seniors, then leaving these to the individual may be a better idea. I assume you don't have any cross-team considerations. If you do, then hashing out some of the details like DB schema might need to come early if multiple teams depend on it.
If you (as team member) feels the need to talk about design, to so some design brainstorming with other team members, then just do it. About the how, many teams will just use a whiteboard and brain juice for this and keep things lightweight which is a good practice IMHO.
Personally, I don't see much value in writing down every decision and detail in a formalized document, at least not in early project phases. Written documents are very hard to maintain and get deprecated pretty fast. So I tend to prefer face to face communication. Actually, written documents should only be created if they're really going to be used, and in a very short term. This can sound obvious but I've seen several projects very proud of their (obsolete) documentation but without any line of code. That's just ridiculous. In other words, write extensive documentation as late as possible, and only if someone value it (e.g. the product owner).
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
Let's say that a developer is interested in learning Scrum, but nobody else on the team is interested. I realize that Scrum is made for teams, and the process would have to be modified to fit a single person.
Is there any benefit to be gained by the developer trying Scrum, even if the team doesn't? If so, how would the process be modified to suit the situation?
I think there's benefit to be gained by any method that helps you develop goals, tasks, keep on top of work and deliver something often.
Your individual work-products would gain the same advantages that teams gain with scrum:
You'd get something done every {Sprint Iteration Period Here}, something you can hand off and say "This is now ready".
Your estimation technique will start to improve with reflection and retrospectives
You'll start to plan your day and make commitments to yourself about getting things done, so again your estimation of your capacity will increase
Retrospectives will formalize improvement of your personal work process. You'll start actively improving, removing and adapting to suit you and your individual needs.
You wouldn't be able to rely on other team members to help out, which is a bit annoying, and you wouldn't have a product owner, Scrum master or a backlog to pick tasks from. You may not even be in a position to make decisions on what to work on next. But I think the formal discipline and reflection is helpful for all craft practitioners, at all levels, alone or in groups.
And who knows, you might even inspire your team to Scrum it up once they see what great results you're getting.
I would suggest that you use Extreme Programming instead, as that works better for one programming than a decidely team-based process.
Then you can get the benefits of being more agile, but if your team is not agile then you will have some issues due to the use of a different paradigm.
For me, the biggest key was getting buy-in from my supervisor. It can be tough to try and have some sort of Sprint only to have it interupted multiple times (Supposedly XP teams handle this better, but I don't think any developer does.). Also, don't forget to include either power users (they could be testers) or members of other departments that could be used as Product Owners. I like to sit with other users and do a type of paired programming (OK they don't code) where I can ask questions while coding and do quick demos to get feedback. This helps when I'm struggling to create specs because those requesting the app are having a hard time telling me what they want.
Even if it's just you in the daily stand-up, it can be scrum.
If you compare yesterday's planned with actual and define today's plans -- without talking to other people -- that's still a kind of daily stand-up.
I'd say that what you're doing probably is scrum if you're following the daily-sprint-release cycles; even if there aren't a any other people to talk to each morning.
G'day,
For the best thing to come out of learning Scrum is the concept of involving the customer early and often. That way there are no nasty "that's actually not what we wanted" moments when you deliver to the customer after six months hard work.
HTH
cheers,
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
There's not a lot to add to the subject really.
I am after a free task board/ burndown reporting tool for Windows.
If you're willing to host your tool,
TargetProcess
(http://www.targetprocess.com/)
XPlanner(http://xplanner.codehaus.org/)
If not,
Pivotal Tracker (http://www.pivotaltracker.com/)
ScrumWorks (http://danube.com/scrumworks/basic)
All are either free or have a free version.
Depending on your real needs, solutions range from :
hand-written cards complemented with a manually drawn burndown chart as big visible chart as recommend by Ilja
spreadsheet-based list with automatic burndown graph generation (example)
online tools such as scrumy, scrumpad and skinnyboard
local application with web access
free ScrumWorks basic, Icescrum2
or commercial ScrumWorks Pro ProjectCards, or, as Eliza recommended, TargetProcess
Remember however the Agile manifesto is recommending to favor "Individuals and interactions over processes and tools".
I'd recommend starting small, perhaps with a spreadsheet if you insist on automatic burndown charting.
Check out SeeNowDo at www.seenowdo.com
It's a free online taskboard for distributed Agile teams. It's pretty cool and provides convenient features like 'always-on' and 'instant-sync' capability. It also has some cool ways of managing the taskboard layout once you have alot of tasks on it. Best of all, it's completely free.
Apparently I got to disclose I built this product
You might want to try: http://www.burndown-charts.com
It's a free webapp for managing burndown charts. You create a team and a sprint and you are ready to go. Enter your tasks once they are done. Perfect for when you still want to keep a board and/or post-its. You can add teammates to your team if you need.
You're not going to spend an hour figuring out how to use it.
That is exactly what Scrumy.com is. It is a whiteboard with sticky notes. The pro version has a burndown.
Try Mingle. It is free for upto 5 users.
Open Source app: http://taskboard.cognifide.com/
Fast, tidy tool :)
EDIT
Ok, we are working on something that does just what you asked and way more:
Actionable metrics
Powerful analytics
All this on a slick Dashboard
It's meant to eliminate the use of excel sheets to build your own reports by hand.
It's a far better solution and it is in beta right now.
Sign up and participate in the beta to make sure your features are well covered!
http://www.in-sight.io
Well, without knowing more about your situation, I have to highly recommend a wall of index cards and a handdrawn chart on flip chart paper. Works much better than any software in the standard situation.
If you really have to use software, there is none that I could recommend unreservedly, let alone a free one. You might want to keep in mind that some of the commercial ones are free for open source or academic projects, too. Which one's right for you will depend, besides other things, on how much you want it to define your process.
You might consider creating your own solution using a spreadsheet.
That way you get low overhead on data entry and as much reporting capabilities as you want, without having an external tool define your process.
Especially on single-person projects (as this appears to be from the comment on Ilja Preuß's answer), I find that a simple spreadsheet actually works better for me.
I keep all my tasks in one workbook, and the formulas that pull out interesting data and calculations in a separate workbook.
I made a basic plugin that can be inserted in google wave and be used as a taskboard. More details in http://agilebooknote.blogspot.com/2009/11/taskboardy-available.html.
Cheers,
-fede
I'm a fan of google docs because of the simplicity and also because I can give access to my team so that they can update their tasks on a daily basis. The template I use and a tutorial on how to use it is available at
Burn Down Chart Tutorial: Simple Agile Project Tracking
I know this is old thread, but I came across this question looking for something similar. I signed up for AgileZen (http://www.agilezen.com/) and it's actually quite good.
I wanted something free that my wife and I could use for personal/home stuff. It's free if you're willing to have only one project (I call it "Home") and one other collaborator (my wife). It's a pretty good solution for us.
I promise I have no affiliation with them! Except that I now use their product.
If your project is open source, non-profit or a classroom you can get free access to Atlassians' JIRA + Greenhopper (and other tools) for agile project management. Otherwise small teams can get access for a nominal fee.
see http://www.atlassian.com/software/greenhopper/overview and http://www.atlassian.com/software/jira/overview.
See http://www.atlassian.com/software/views/open-source-license-request if your an open source project.
http://www.atlassian.com/software/views/community-license-request if you are a non-profit
and
http://www.atlassian.com/survey/classroom-license-request if your a classroom.