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.)
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 11 years ago.
What is a good tool to design the implementation of websites? I typically use UMl to design applications, but I feel that does not apply well to websites, specifically the heavy emphasis on UI that websites require.
What would be a good tool to use to plan a webpage?
What kind of model do you need?
Are you capturing some information about the visual aspects? In which case wire-frames or other story-boarding techniques are good.
You also need may to capture navigation information, which can be done via story-boarding but sometimes a UML state diagram is more succint and easy to reason about.
Then you may also wish to capture the data model associated with each state, and in which case a simple UML class diagram works well.
In an AJAX-based app you also need to document the "invisible" ajax activities, and again UML state diagrams along with classes for the invoked REST services can be helpful.
For the UI, I'd certainly not use UML but a wireframing tool like MockingBird or Pencil. The first one has my preference, it's awesome. Just try it.
Well, I use PowerPoint to create web page mockups. It's fast, and allows you to create "storyboards" that simulate actual use of the website and its various pages.
PowerPoint is great for presenting conceptual ideas, or modeling the UI for a real person to see if they understand it (kind of like a high-resolution paper prototype).
The PowerPoint Prototyping Toolkit provides a collection of shapes, such as textboxes and dropdowns, that assist in creating form mockups. This template is also useful.
You can take a look at ForeUI. You can design not only the UI but also the behavior of the website. Here is an example: Blog Mockup Created with ForeUI
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 11 years ago.
Are there any statistics for this? I realize it must vary from person to person, but it seems like there should be a general average.
The reason I ask is that the company I contract for has multiple software products, totaling ~75,000 lines of code - and they seemed disappointed and shocked when they ask me a question about a specific portion that I don't immediately know the answer to (I am the only programmer they have, and did not author the majority of the systems) They think I should just know it all from memory. So I wanted something like a statistic to show them that an average programmer couldn't possibly have all that in his head at one time. Or should I?
You should remember where to find the needed stuff not remember it itself.
You should also be familiar with code structure and architecture enough to make an educated guess where a problem might originate and where you could possibly find the stuff you know exist but not sure where exactly.
You brain works like cache. The stuff you used recently is kept there, more older entries are erased. But there will never be enough memory to remember the code all at once. Because then you will want to remember all API functions, then all specs, then something else. This all is not feasible.
And being surprised with you that you don't remember all the code is probably one more instance of those perversed notions of how programmers do things. Ignore them.
It depends not only on your memorization skills, but also a lot on the code. Obviously, clean, idiomatic code is much easier to memorize than a badly written inconsistent mess.
Probably because clean code can be broken down into much larger "abstract tokens".
Indeed interesting question but I am in doubt if there is adequate answer at all. Here are only obvious factors I see right from the start:
Overall design quality. Even if you are new in well designed code you can very quickly identify where you should look to get answers.
Project documentation quality. For poor documented projects even developers that are in project from the start can't say anything about some parts.
Implementation quality. OK. You have good general architecture, good documentation for interfaces but even one really bad programmer could break all of this. This is because many companies are very strict about code reviews and I think it is the only one technique to prevent such situation.
Programmer experience. As you move ahead you see number of 'already known' code "bricks" in software new to you and experience is great help in this so contractors are often very experienced specialists familiar with various approaches and this gives average contractor ability to move much faster then full time programmer which is brilliant but worked 10 years in only 1 project context.
General person smartness. My opinion this is really not so important as most of others factors but it is really important.
... but the common problem is often companies hire contractors for some existing software improvement and they simply think this is only about to hang picture on the wall. You should perform some negotiation to force them to understand part of work is to understand what really should be done to meet their requirements at all. And such "learning" requires resources and is part of work itself. But I think it is slightly off-topic for StackOverflow (despite I voted up ;) ). Is it more for Startups discussion?
Even if you have written all that code you might forget portions of it. But you'll be able to recall it once you review it.
I think its natural for a programmer to forget some portions of his/her code after a long time.
Ask them how they want you to spend your time: surveying vast amounts of code you didn't write and perhaps writing up internal documentation, or whatever currently keeps you occupied It's not a facetious question. If they want quicker response to new issues, they need to invest in research.
I don't think there's a meaningful answer to this measured in LOC. As a manager, what I want to know is that someone in your situation can answer a question in a reasonable amount of time -- and unless I know you're in the middle of something, I wouldn't expect that 'reasonable amount of time' to be 'instantaneously'.
You should be able to understand all the components within the system and how they interact so that when there is a problem you can isolate one or two likely components and drill down.
I find it helpful to draw a few diagrams and keep them handy so I can use them to communicate with my boss\customer as well as jog my memory.
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.
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.
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.
Does anyone know of a decent UML standards guide?
My company currently relies on UML 2.0 (rightly or wrongly) to do the majority (read all) of their design work. I have been asked to come up with a draft 'best practice' guide to help other developers develop better models. The main problem I face is that Im slightly biased against UML... I feel that: if a diagram takes more than 5 mins to draw then its too complicated! Im looking for advice predominantly on what sort of standards I should be looking at. Also Im looking for an external source of information that can be used to balence out my irrational loathing of UML-heavy design and act as a 'sanitizer' for my suggestions.
Most of all Im looking to write a useful document rather than one that will sit moulding away in some obscure network directory.
Any ideas?
UML Distilled by Martin Fowler
Like Paul C, I recommend UML Distilled. It is primarily about UML, but it contains a lot of insight about design in general (although it insists a bit too much on index cards IMO), it is short, pleasant to read, and to the point.
I strongly recommend against UML in a Nutshell. It is the worst O'Reilly book I have: insanely dense, hard to read and meandering. Not worth the paper it is printed on.
We are not talking about a book that says how to use UML, but rather a style or standards guide of some sort. Enter, UML profiles... This can get you both the standardization and reduced complexity you are looking for. You can limit the relationships and elements which can be used. You can also require certain things. A large company may choose to focus on the assets and data movement and limit it's standardized diagrams to this view. However, a company making real-time software for tanks might focus on action or flow.
The whole point of UML is that it is not specific and useful for every kind of situation. Martin Fowler and Elements of style books will not reduce diagramming time and increase comprehension. You need standardized profiles or patterns for than. I have seen it work, to the point that the business can read them. Many tools allow you to create a profile which eases learning curve for the designers and reduces drawing time.
MDA Distilled (OMG Press) is a good book if you want to understand the concepts, but it is not needed.
Really, UML Profiles. You don't want a standard because your company or your need is different. A standard for Web Services does not work for real-time or financial services.
Buy everyone a copy of The Elements of UML 2.0 Style. Job done.
For a quick reference on how to compose individual UML diagrams, I heartily recommend The Elements of UML Style 2.0 and I put my money where my recommendation lies by purchasing the 2nd edition to replace my 1st ed.
Apart from this recommendation, I think the most important thing in a company when introducing any style guide is to have a local feedback mechanism where people can post comments on which aspects of the style guide work for them, especially when you're using an official printed guide. A wiki or similar casual repository should suffice for this.
I also suggest highlighting diagrams which were particularly good examples (or bad ones, if the team humor could take it). Consider a framed Diagram of the Week like the Employee of the Week you see in so many stores. That gives a gentle reminder that diagram readability is taken seriously but hopefully with enough fun to get more buy-in to the concept.
I know you probably want an easy to read book for this but from what you are describing I would suggest going with the specs found on OMG itself. They are a bit much to read but would be as complete as you could hope for. They also have lonks to articles and tutorials that may be helpful.
As far as books go I have found that Using UML is quite good since it tackles the software development process as well as the UML tools and methods.