As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
It seems Scrum and Agile tests/assertions are becoming popular this year. For example, Nokia test for Scrum. I don't think it is a good idea to have such tests at all. What do you think?
On the one hand, there are more and more people that claim they are agile, so such a test allows to sort out those in the line of "we're doing XP, we do not comment our code".
But how can we be sure people will understand the question the right way and not answer "well, we have iterations. We often have to extend them a bit to meet our committements, but we do have four weeks long iterations." ?
On the other hand, the link you provided in interesting as it's not the initial version, and it's backed by Jeff Sutherland.
The point is : you cannot sumarize a development methodology with eight questions. Therefore, IMHO, the test alone is interesting, if answered with a correct understanding of the question. It can be helpful for teams that wants to improve. I won't say the same thing for the results that are collected with this test.
This infoQ article says it in a better way: Simple checklists can provide a useful quick-and-dirty assessment. They won't tell you if the practices are actually delivering results.
I just quickly took the test and found that the questions were good questions to ask anyone who claims to be doing Scrum. I'd also ask questions such as:
Do you have an automated build process?
How often does it run?
What happens when the build breaks?
OTOH, a test like this is useful as a self assessment, but I would not 'rate' a team based on a test.
I see Nokia test usable for quick overview.
For further investigation I suggest to use more detailed Scrum Checklist by Henrik Kniberg which is helpfull for coaches and scrum masters to quickly identify gaps in most areas agile team does. Even there are 70 questions, team memebers answer yes/no. We were able to complete this survey in 20 minutes. Especially if you repeat it after few months, you probably will be surprised by answers of your team.
If you need to do deep analyses of agile implementation I suggest to use C*omparative Agilit*y assesment created by Mike Cohn. It helps in relative comparision of your company to the industry. We use it in an enterprise organization with immediate impact on the adaption process quality. Thanks to this is adaption process in this enterprise company much better
See more about Scrum Checklist and Comparative Agility here.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am looking to introduce an agile method to my boss so that we could hopefully implement it at our work place. I've been doing a lot of research yet I can't find what makes it standout from other agile methods. I am thinking maybe it is the consistent meetings or is it the heavy reliance on artifacts? Please let me know. Thanks!
Look on wikipedia. The scrum agile method is at http://en.wikipedia.org/wiki/Scrum_%28development%29
Here is another stackoverflow question that tells the difference between scrum and extreme programming (XP). Mountain Goat Software also goes into this.
I'd try not to get bogged down in the little differences in the different approaches. It's perfectly legitimate to pick and choose the practices that you think will fit best into your workplace or environment, or the ones that will be easiest to convince your boss (and team) to adopt. You don't have to be dogmatic about just doing SCRUM or XP or whatever.
The key things I would try to implement (but YMMV)
group planning
daily stand ups
time boxed iterations
end of iteration reviews
If I was trying to convince my reluctant boss or team, I'd probably start with daily stand ups. They are low-cost/low-effort, and if done well should help the team gel a little more with understanding what everyone else is doing and what the roadblocks are.
Scrum is focused on how to manage a project, particularly with respect to planning and estimation.
XP (Extreme Programming) is focused on technical excellence and quality within the project, and keeping the cost of change low.
Think of each of them as a toolbox, where one toolbox doesn't build a house. Scrum relies on a low cost of change in order for its measurements of velocity and its estimation off the back of them to be accurate - but it doesn't actually provide the methods for this to work. XP has most of Scrum contained within its practices, though some Scrum techniques like breaking stories into tasks can be useful for teams who are learning.
Even together, you may find that they don't provide quite enough tools for adaptive planning, large-scale organisational change, cultural change, good recruitment practices, and the many other inputs to an Agile team which often get left out of methodologies.
I'd aim for a combination of Scrum with XP, and you might like to look into Lean, Kanban, BDD and Feature Injection while you're at it - there are some useful tools there too.
As for starting, here are my two core practices:
Try to deliver some software (showcase or release every couple of weeks)
Work out why that was hard and what to do about it (retrospectives).
Good luck!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm trying to find a good, simple introduction to domain driven design, but that is proving to be difficult.
The books I have looked at all share the same problems.
They are massive 300+ pages. I really wish this practice would change with computer books.
They shine in chapter 1, explaining the introductory and basic concepts. Then when it comes down to getting into the material they blaze through the advanced concepts with poor examples and little explanation, then jump to the next concept.
Am I asking too much when I ask is there a book for domain driven design under 300 pages that progresses at a constant pace?
I hate it when books spend so much time on the introductory concepts, yet don't bother explaining the more advanced stuff.
Update
The reason I want a sub 300 page book is because those 500+ page monsters have a lot of fluff in them and can't seem to get to the point (or skip it altogether).
Try this one - available online at InfoQ. On the plus side, it's free. On the downside, it might be too basic for you. If you want an introduction though, surely it's the basic concepts that you want to get to grips with first before delving into the advanced topics?
Domain Driven Design Quickly - 104 pages.
There's also another free download, DDD Step by Step - a really short introduction to DDD, only 34 pages.
(and the corresponding webpage Think DDD)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
My company uses Jira for storing requirements, which are written in the form of User Stories ("As a ... I want ... So that...") with details in the subtasks ("Given ... when ... then...").
I write requirements, usually an iteration ahead of the developers.
I tend to draft my requirements in a word processor before putting them in Jira. I like the flexibility as I'm working out the best way to organize the information, jumping around from one story to another, using search & replace as I figure out the clearest wording, etc.
While a word processor outline is helpful for much of this, it's not so good at tracking issue links: dependencies & related requirements.
So, can anybody recommend a good tool for writing stories & tasks which allows me to diagram relationships as I write?
I've been thinking in terms of something which handles concept mapping (though not mind mapping, which is generally limited to 1 central concept). This is just for my personal authoring; I don't need a project management system.
Thanks in advance.
Update: After posting this, I started wondering about TiddlyWiki. That's not quite the right tool, given its linking methods, but seems the right direction... Does that vein spark any ideas?
What about a simple spreadsheet (like this one)? A spreadsheet is extremely powerful (to re/organize, filter, etc) and has always worked well for me (use indentation if required or a additional column for IDs of related stories).
We use a combination of spreadsheets and an internal Wiki for user stories. The spreadsheet holds the basic information, like ID, title, user role, priority and so on as well as a link to the Wiki page for this story.
The Wiki page then has all the information about the user story, a full description, acceptance criteria, design notes and so on.
If there are dependencies between stories these are included as links within the user story usually with a short note about what this dependency means (e.g. "This story assumes that story x has been completed" or "Y & Z are not part of this story, but of story X").
This is a pretty low-tech solution, and doesn't really support visual diagrams of relations. However, it has worked for us so far.
Perhaps this is overkill, but does Mingle by Thoughtworks do what you need?
(I am not actually a Mingle user, but this sounds like the sort of thing it would do.)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
For my area, I get the updates from
ww.asp.net
code.google.com
www.webmasterworld.com
What others do you highly recommend?
For anything .NET you cant go past Scott Gu's blog.
DZone is pretty good if you want to know what's happening in programmer blogosphere, especially for Java programmers, but not limited to Java. The thing I like the most about them is monthly e-mail newsletter with top links for the month, which makes me return, especially if I didn't have much time to procrastrinate that month.
If you're into anything with Linux:
http://www.linux.com/feature
A List Apart has some excellent web articles
If you want keep up with browsers, Web Browsers News and Reviews might help.
Finally, PPK, a javascript expert, often has some interesting links and blog posts.
Here is a list of the recommended blogs if you're into .NET development:
http://haacked.com
http://weblogs.asp.net/scottgu/
http://weblogs.asp.net/fredriknormen/
http://www.nikhilk.net
For PHP-related stuff PHP Planet and for PostgreSQL Planet PostgreSQL. If you're intrested in PostgreSQL depesz has a very nice blog with a lot of information about upcoming versions, performance tweaks, etc.
Ayende's (creator of Rhino Mocks) blog is a great read.
Forgot to mention www.codeproject.com is good one to get latest news too.
Check also: http://www.infoq.com/
I find a lot of helpfull info at https://web.archive.org/web/20211020202742/https://www.4guysfromrolla.com/
http://www.dotnetkicks.com (dnk)
dnk is a .net focussed community site, a kick being a .net digg is you wish, and in some part may well have inspired some ideas on the admirable stackoverflow.
Some of the blogs above are excellent and I subscribe to many of them, but for what is latest updates, it is hard to beat dnk for it aggregation and collective ranking. You will find all of the above there but also some very interesting one blog wonders as well.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The project is poorly defined: we are to write educational software for CS 111 Computer Programming I students focusing on functions. We have 6 student developers with various backgrounds working in Flex. The project has a duration of about 7 weeks. We have very limited face time (30 min per week) and very limited work time (<8 hours per developer per week). We have limited access to the customers (professor of our course, professor of CS 111, students in CS 111).
Our toolset includes Flex Builder, Subversion, and TRAC.
What methodology is best for this project and why? Alternately, what features should be gathered from various methodologies to better suit this situation?
What makes you think any methodology would be successful under these circumstances -- little communication, more requirements than time, and lack of access to customers?
That being said, I would focus on incremental delivery (each iteration should have some few working features), unit testing (all tests pass before check in), tagging of incremental releases (the ability to go back to a working release), and pairing of strong team members with weaker team members to boost the overall productivity of the team. Consider devoting one strong member of the team to integration testing.
Incremental delivery is most important. Showing a working demo of less than what was asked for is always better than showing a non-working prototype.
You could use Agile methodology here but obviously you'll have to adopt it to suit your needs.
For example if you don't have enough access to the real customers that someone with the best understanding of your goals will have to act as a customer proxy. I would also suggest trying to get more access to the customers - almost everyone try to appear more busy then they are and there is usually a way to resolve that obstacle.
Make sure that the limited work time your team have they have at the same time. There could be no Agile approach when you could not work together.
You could definitely use story-based estimations, iterative development process etc.
What is really important is too give every team member a clear and unambiguous understanding of how the Agile process works and what is each person's role in the project. It's very easy to say that you will use SCRUM but unfortunately without real understanding and experience that will not really mean much.
Some advice:
Educate your team members
Get a list of what you would like to deliver if you would not be limited by the time/resources.
Find out what is realistic to deliver given your constraints. That will probably be not much. Don't try to be overly optimistic. Focus on what you could really achieve.
Make sure that your real customers are on board for that.
Use short iterations (1 week or less). Make sure you could deliver fully tested product by the end of each iteration.
Show your work early.