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
Does anyone have any good documents talking about agile eligibility criterias of a project ? maybe a checklist to identify opportunities and risks before the beginning of the project.
Thanks :)
The short answer is this: If your project is all of the following:
Short (no longer than a month, as a rule of thumb)
Simple (everything there will be to know about the project is presently known)
Straight Forward (After delivery, there will be no future development / maintenance)
Then you may consider not doing agile!
In all other cases, you will be well served by developing your project in an agile manner.
From small start ups to large multinational companies (Microsoft, for example) more and more companies are implementing agile mindsets and methodologies.
From small clients to middle-sized financial institutes to gigantic ones (United States Department of Defense, for example), more and more are accepting, encouraging or even demanding a flexible and incremental delivery and an open visible development project.
The important thing to understand, though is that perceptions of what agile is and isn't are often wrong. not planning, for example, or not documenting are, despite popular belief not agile.
What I would suggest, is to first make sure you understand what agile really is. Here are a few good resources:
The agile manifesto (Important note: while the things on the left are more important, we still value the things on the right).
Scrum.org's Scrum Guide
Lyssa Adkins' Blog
If you pardon my own shameless plug, you can read my blog, too.
Here are they:
http://pm.versionone.com/AgileChecklist.html
http://standard-data-systems.net/Project_Checklist/Agile%20Audit.pdf
Also, you can google it for: agile project checklists.
Good luck.
Related
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
The last time I wrote a specification was years ago, using a waterfall method.
I am now about to gather the requirements for my first Laravel project, I am working as a lone developer.
How is everyone else doing this?
I was thinking of getting an overview of the requirements, writing a spec, then communicating with the customer iteratively to refine the document to something I can start working with.
Then I was going to do a prototype and gets some feedback.
Then I would work on "chunks" of the project and present to the customer for feedback and refining after every stage.
How does that sound? Any recommended reading?
Mick
The Scrum approach is to put requirements in the format of 'user stories' in to a backlog (effectively a prioritised list).
Rather than gathering all the detailed requirements up front we aim to gather just enough requirements to start development (perhaps sufficient to keep the team busy for 2-4 weeks). In Scrum we work in what we call 'sprints' that are regular sized iterations of work (much like the "chunks" you describe).
Then, the requirements are continuously refined and added to as the team progresses. The team does the highest priority requirements first and then demonstrates progress to the customer (the 'Product Owner' in Scrum terminology) and stakeholders (other interested parties). Based on the feedback the team gets they either carry on as before or they may adapt. For example they may take the feedback and add it as new user stories to the backlog and prioritise them against the existing stories. This differs from the prototype approach in that we try to have production-ready working software at the end of each iteration.
If you are interested in using this agile approach I would highly recommend reading 'Agile Estimating and Planning' by Mike Cohn.
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 10 years ago.
Improve this question
When using an agile methodology on a team programming project, what should be done when several people needs to work in something that is to be used by everyone. For example, There is a User entity, and two people have to do requirements that need to use that entity. So, first an skeleton is created and then the activities are assigned? or what is the procedure in these cases.
And second, Is it possible to find information that addresses this kind of issues that can occur when applying such methodologies?
Thanks
The best thing about Scrum, is that it is an amazing tool for identifying bad practices. This is one of the cases. An agile team should be working with as many hands as possible, on the same requirement (requirement, feature, user story - same thing). The division of work between members should be based on the tasks needed to complete the requirement, no the requirements themselves.
Each task would be defined based on the modifications that need to be made to a certain component. Doing that will not only make the problem go away (nobody's working on the same code), but will unite the team members' efforts, and make them function as a real team, rather than a disparate group of individuals that happen to share a room and a manager.
As for official information on the subject, I can suggest reading any book about Scrum, but you might want to focus on the following sites:
Introduction to Scrum
Mike Cohn's Blog
Scrum.org
A few great books:
Succeeding with Scrum - Mike Cohn
Free ebook - Scrum & XP from the Trenches - Henrik Kniberg
And finally, if you pardon the shameless plug, you can check out my blog - I have a few posts on this subject (such as this one) and others from my experience about implementing agile methods in software teams.
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 was surfing the web, and I came across the term "Boeing Agile Software Process," but I was unable to find a definition or any details. Presumably, this is the software process used at Boeing and it's Agile, but could anyone explain what the Boeing Agile Software process is/was?
You can read the first several pages of the paper:
"A Tail of Two Projects: How 'Agile'
Methods Succeeded After 'Traditional'
Methods Had Failed in a Critical
System-Development Project"
that Robert Bedoll wrote about agile methods at Boeing and published for XP/Agile Universe 2003 here, on Google Books. Here's a summary:
We adopted the following principles:
Rapid prototyping of designs, with immediate customer feedback
Continuous involvement of the customer Weekly production releases:
Follow our standard development cycle
(requirements - design – code – test -
release) but compress it from formal
releases every three months to formal
releases every week.
Start simple and keep it simple
Evolve the tool to follow the evolving business process
Provide a one to three week cycle time for new feature introduction
Maintain a small development team
Produce abbreviated versions of our standard design documents.Let the
prototyping drive the design
documentation.
Retain our SEI (Software Engineering Institute) Level 2 rating.
It looks like there's a draft "not yet been formally approved by Boeing for publication" in .doc format here, that explains the principles in more detail. I'm not not a lawyer and don't know if there are legal implications if one were to read that draft. You can buy the whole published paper as a .pdf here and probably other places.
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 4 years ago.
Improve this question
The site I work with on a day-to-day basis has its share of shortcomings and we often make design decisions to "get us by right now" with the intention of fixing those up later.
I've found that making the time to actually go back and fix them, let alone remembering what the full list of to-do items is can be challenging at best.
Can you recommend any tools, resources or tricks that help you effectively manage your technical debt?
You could use any bug/task tracking software, eg see this stack overflow question: https://stackoverflow.com/questions/101774/what-is-your-bug-task-tracking-tool.
Of course, a simple solution is just to have a text file called TODO or similar. It's low maintenance, and particularly appropriate if it's a WORN file (write once, read never).
Unit testing
Refactoring
Continuous Integration
Planning (XP, Kanban, etc.) to avoid adding more technical debt
Standards
Code reviews
Project retrospectives
Static analysis tools (like FxCop) integrated with the CI build or check in process
I'd say TODO comments in the code, but my experience has been that developers generally ignore these.
I would suggest you add an item in your product backlog whenever you deliberately incur technical debt. This way, it is possible to consciously spend time during each iteration.
There is a plug-in for Sonar that you can use to find potential problems in your code base.
/Roger
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
Peter Stevens has a great summary of different agile contract models on his blog. I've decided that I like one of them the best (Time and Materials with Variable Scope and Cost Ceiling) for a project I'm initiating, but I can't find a sample contract or template for such a contract. Anyone know where I could find something like that?
Jeff Sutherland (http://en.wikipedia.org/wiki/Jeff_Sutherland) spoke at Agile 2008 on this topic: http://jeffsutherland.com/scrum/2008/08/agile-2008-money-for-nothing.html (slides: http://jeffsutherland.com/scrum/Agile2008MoneyforNothing.pdf)
It spawned an "Agile Contracts" discussion over here: http://www.coactivate.org/projects/agile-contracts/summary, and that discussion includes a wiki page that's the beginnings of a contract template: http://www.coactivate.org/projects/agile-contracts/money-for-nothing-change-for-free
Not a template, but some additional tips that might help with this - from Mike Cohn:
http://www.mountaingoatsoftware.com/articles/5-writing-contracts-for-agile-development
[rewritten in response to comment on original post]
It's not so difficult to write, examples can be found in your native tongue all over the Internet (plain time-material contract to start from). Just make sure you keep it clear and simple.
The 2 things to remember are:
Write in your native language, to prevent confusion (if client is abroad English is best). E.g. our contracts are stated in Dutch.
Have your attorney check whatever you come up with, for a decent template