At work we're having issues with different people wanting/suggesting different names for a new project. It's changed 4 times in the last 2 days.
What processes do people go through when naming internal projects? How do you work as a team to come to a conclusion for a project name?
To make this a little clearer, the question is HOW do you name your projects, not what do you name them. I'm more on about a process so we don't get the 3/4 managers involved spending the next 4 weeks changing the name of the project every 4 hours
Why is the team choosing the name. Don't you have a manager? That's how organizations are supposed to work: if one level can't achieve the goal in a timely manner, escalate it up to the next level.
What a colossal waste of time!
We name them after asimov characters.
The blackjack client was Hari.
Have everyone put their suggestions in a hat, and pull a name at random. Does it really matter?
Have the team make many suggestions.
Have management and Legal weed out the problematic names.
Have the team vote on the remaining names.
Make a list of all potential names, each person only gets to make one name suggestion. Have everyone vote on the names. Each person can vote only once, and not for their own name.
It really depends on how saddled with a name you will be.
For instance if its a .Net project, you will be quite stuck with the name you choose, in which case the projects usually get a really boring naming, even if the site has a nice naming.
In other technologies where there is no "manifest" to the code, named as a project, and moving the code to a new folder name is the "project" then witty names seems to be great fun.
One company I was with named all their projects according to vacation city names. So we had Paris, Athens, etc. I've also used greek gods and constellations. There wasn't much of a process to it, just whatever the development team thought was cool. Though there was an instance where we allowed our beta partner at the time to pick the name of the project - they had a whole contest and everything.
Another project I was on had four phases:
Red, Green, Blue, and 4
Gotta love that.
Use letters to indicate versions of your product, and have team members vote on words that start with the letters.
We've had one project that was named Ambition, Benevolence, Charisma, etc.
I like to use Instant Runoff Voting for this.
I've also found that having new team members suggest names helps them feel ownership for the project.
For my personal projects I name them after Revolutionary War battles (e.g. Lexington, Concord, Saratoga, Ticonderoga). I'm also fond of using names from Greek mythology since I'm a big fan of that :)
Another personal project was named Rushmore (as in Mt. Rushmore). IMO it all depends on what you fancy and whether or not the project name is going to be publicly visible. If it's not, then name it whatever you want (the more mysterious the better if you ask me!) but if it will be public then choose something that doesn't sound ridiculous or will make people go "Huh?". Project Fig Newton or Project Twinkie might sound funny to a group of devs, but how will it sound to customers?
Name your projects in a way that helps developers know what they are when you put the under source control. Outside of your current source control it doesn't matter what people call it.
Try to pick a naming convention that stays the same it will help organize things in your source control and try to stay away from initials and abbreviations because once all the DEVs on that project leave no one will know what the project is.
Try sticking to names like:
customerA Website
customerB WinApp
One place I worked used mountains for the framework, and ski resorts for the client; Another used tube stations. In both cases they were internal names that didn't have a fixed version number (as marketing had a habit of changing that)
I've seen architects choose, CTOs mandate, dev teams rota, and a reward for some arbitrary competition but ultimately it comes down to one man with one vote. You can democratise that any way you want, but whatever you do just make sure it's inoffensive and you stick to it.
Fwiw, my favourite system has been the architect who chose Judge Dredd characters. :D
For personal projects I sometimes use names of big cities, like New York, Berlin, Tokyo etc.
It' both convenient since I feel the project isn't bound to a specific technology or function and can involve into whatever it might be, while at the same time it can be a bit difficult remembering if it was Tokyo or Oslo which was doing "that" cool thing..
At work we have a tradition for more simple and descriptive names. For instance an application that uploads files according to a schedule is called ScheduledFileUploader. And then there's FileOrganizer, MailSender, DiskSpaceMonitor et.c..
you mean a code name? since its gonna stick only in the minds of internal employees, we usually named it the first thing we thought of and we never put it up for discussion, one project we had named "Dough" seriously! :) and it worked like magic, anything works
Female names (everybody likes a nice name, specially if it brings nice memories)
Animals (everybody likes animals)
We usually agree very fast on this one, no problems there. After we have named something, for example, "chipmunk", the jokes and funny pictures start to arrive (everybody likes making up jokes :)
But really, I don't think it makes a difference.
Name your projects after constellations. There are plenty to choose from, most sound cool. Also when you get to the Aries project, you can tell people that you're checking the cell structure and the cell structure has been checked.
With great care and a lot of personal pain. I quite frankly obsess about my personal project names. Even to the point that I will spend hours thinking about the name of a particular type or DLL.
Sadly this is not a joke.
No project names, just version numbers.
Everybody knows that if you released "MyBlaPro 4" you are working on "MyBlaPro 5" and it is going to be out in 1-2 years (your company history can offer a hint on the length of your dev. cycles).
The big secret is not that you are working on the next version, but when it is out.
Code names confuse not only outsiders (think Avalon/WPF, Longhorn/XP/2000/Vista/7) but also insiders. You can sometimes hear discussions like this "no, we added X in Zimfandel, before Cabernet" "no, you are wrong, Cabernet was 5, Zimfandel was 6, but X was added in Merlot"
Add to the mess the half-outsiders. Think localization companies that have to reuse memory translations between versions ("for Rainier we should use the memory from Shasta, or from Whitney?").
My big brother Mikael has been called to some firefighting in very late projects which...he chose some movie titles
Save Willy - a bloated java project
Harry Potter - a architectural disaster java project
Related
Splitting a full name into first and last names is an unsolvable problem because names are really, really complicated. As a result, my model, which represents authors and other contributors to a book, includes both name and filingName fields, where filingName should usually be "Last, First" (for Western names).
However, as a convenience for my users, I'd like to have my app make a reasonable guess at the filing name when the user fills in the regular name. The user can edit the filing name if the guess is wrong, of course, but if I guess right, I'll have saved them some time. Currently I'm simply assuming the last space-separated "word" is the last name and moving it to the front with a comma:
NSMutableArray * parts = [self.name componentsSeparatedByCharactersInSet:NSCharacterSet.whitespaceCharacterSet].mutableCopy;
if(parts.count < 2) {
return self.name;
}
NSString * lastName = parts.lastObject;
[parts removeLastObject];
return [NSString stringWithFormat:#"%#, %#", lastName, [parts componentsJoinedByString:#" "]];
I can immediately think of one case where this will lead me astray: suffixes like "Jr". But I'm sure there are many others. Are there any good resources explaining common naming caveats, or good examples of code tackling this problem, that I can use to improve my heuristic? I'm using Objective-C on the Mac (in case there's some obscure corner of a framework that could help me), but I'm willing to learn from code written in any language.
This sort of question has been asked before, but most answers either focus on the mechanics of splitting apart a string, or devolve into "design your model differently". I am designing my model differently; I'm just looking to let the computer do most of my users' work for them.
As I said earlier, this code is mainly handling the names of authors and other contributors to books. Some of the specific ramifications of that include:
There should only be one name in name, because I support attaching multiple authors to a book.
Most names will not have titles, but professional titles like "Dr." could show up. Ideally these would be discarded, not treated as part of the first name.
The names will usually be of people, but could sometimes be of organizations. I'm perfectly willing to risk mangling organization names to get better person name handling.
I expect I will mostly be handling European names, although detecting the orthography of the name should not be difficult.
The code should not be particularly sensitive to the user's locale.
When you build a software system, there are always serious problems that consume a lot of time. I wouldn't get stucked with this because there is no worldwide naming conventions nor rules. I don't think asking the user to enter his/her filing name will be a bother, for they'll do it just once.
That seems to be the easier solution IMHO.
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
Is Agile/Scrum the answer? How does Scrum handle this?
One Product Owner, One PRoduct Backlog vs Multiple Product Owners and Product Backlogs?
How is it working for you? Please share your success failure stories?
I am trying to put a process together to manage multiple queues of work ranging from
Infrastructure projects, simple feature enhancements and then big projects with a
small development team of 6-7 developers.
One missing bit is whether this is technically one product (like one codebase, even if large) or not.
If those are completely separate products then using Scrum I'd go in very short sprints (1-2 wks) and sequence development work. So two weeks project A, then project B, then C, then again A - maybe for two sprints, then C etc. In such a situation a single backlog makes no sense, separate backlogs should be kept for A, B and C. I know at least one team that works like this.
Whether you need more POs is rather a function of knowledge about products. Maybe you need someone for each project, maybe you have someone who knows well enough A, B and C to be the PO.
If different products then when you try to do it by taking different stories from different backlogs every sprint what you will end up with is split team. Naturally people will specialize in given project, also it will be very hard to have a good definition of done (are we done if we can ship new increments for A and B but not C this sprint?). If you can't sequence projects with short sprints, then I would look towards Kanban for trying to put some organization into this.
If this is one product/one codebase - then things are much easier. Even if the team will have to touch different areas of the codebase because of different projects they will be still working on the same products so all mechanics of Scrum will apply nicely. One backlog, one PO.
One downside of this to be noted is that people on the team will context-switch and there is a penalty from doing this no matter what process you use. Whatever process you pick should try to minimize this as long as possible (as long as business will be able to hold). Nice thing about Scrum is that it has this built in agreement with the PO that context switches can occur only at sprints border - in other words team will get 1-2 wks to concentrate before having to switch to another project.
Also, don't forget about all technical practices of agile. Unit tests. Automatic builds & tests. Code reviews. Clever use of repos. High standards re. quality. All those are a must in such a challenging environment.
I guess you can do two things:
Do one release of one project, when done, do the next
Split up your development team
Or a combination of both :)
Agile/Scrum are nice buzzwords, but don't seem very related to your question.
Since they apply to the scope of a project, not to a bunch of projects.
I have experience with the second option, up to a level where there are more projects then developers, which isn't what you want. But with decent code review sessions it does seem to work.
A little more detail might help.
Is it one big production team, that is sharing lots of projects between them? Is it a small team (5 ish) with lots of projects?
Why do you have lots of projects? Are they working on different time frames, with some being the 'real work' and others being the 'if your not busy do this as a background task'.
I suppose the key here might be the project to developer ratio.
We have a single department of about 15, which runs 3-4 projects at any one time. People generally belong to a project at any one time, but can move between them as projects go through different phases, and as different skills are needed. Test in particular seem to switch projects a lot.
As for a strict process...make the process fit your needs. If we have a better idea of your needs we might be able to make better suggestions.
One critical piece is that the multiple product owners need to be aware of each other and be able to work together outside of the scope of the development. If they're segregated out into their own fiefdoms and each one trying to be louder than the others to get the attention "their product" deserves, then you're going to have problems.
By the time any development work is put before the team, these things should already be straightened out. The developers shouldn't care (or, in some cases, even bother to know) what tasks are for what owners or what projects, etc. They can care and know these things, sure, but it shouldn't be critical.
The product owners and various other high-level roles need to start each sprint with a plan of which stories should be done during that sprint. It doesn't matter how many stories from any given project are included, sorting that out is a scheduling concern for those stakeholders. Working with the architect or senior developer or such, they should simply decide what stories get implemented in the current/next sprint.
(On a side note, I have an Area 51 proposal for just this sort of thing: http://area51.stackexchange.com/proposals/9543/development-methodologies)
IMHO, Scrum is more effective when you have at least 3 to 4 iterations of two weeks with a team of 4 to 6 developers. So for projects of +- 400 man/day
I think it's a bad idea to do multiple projects at a time.
Please also check this previously answered question:
How does Scrum work when you have multiple projects?
It's seems you mix product and project concepts.
I suggest to manage one product development with one team and one product backlog. Don't create separate projects for feature requests of one project. Instead have one team working on different requests from different customers by prioritizing the user stories.
Though, if those are completely separate products you develop, try to split up the team so each teams can concentrate on one product at a time.
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
This thread is a follow up to my previous one. It's in fact 2 questions, so I hope no one minds, as they are dependent on each other.
We are starting a new project at work and we consider it as a great opportunity to try Agile techniques in action. We had a brainstorming about ideas we read in several books and articles, and came up with concept that would suit us the best: 2 weeks iteration, followed by call with clients who would choose what stuff they want to have in next iteration. I just have few more questions, which we couldn't figure out ourselves.
What to do in the first iteration?
What to, generally, do in the first few iterations if we start from the scratch? Just give it a month of development to code core of the application or start with simple wire-frames with limited pre-coded functionality? What usually clients want to see? Shiny stuff that doesn't work or ugly stuff that does work?
How to communicate with clients?
Our initial thought it to set the process to something like this:
alt text http://img690.imageshack.us/img690/2553/communication.png
Is it a good idea to have a Focal Point on client side or is it better to communicate straight with all the clients to prevent miscommunication?
Any thoughts are welcome! Thanks in advance.
In my opinion, a key success factor for agile development is to focus on delivering value for the customer in each iteration. I would definitely pick "ugly stuff that does work" over "shiny stuff that doesn't work". Doing shiny UIs and trying to get the client to understand hat business logic takes a lot of time to implement is always risky which Joel Spolsky has written a good article about.
If the client wants enhancements to the UI, they can always put that as a requirement for the next iteration.
Regarding communication with clients I think that your scetch should be slightly adjusted. Talking in scrum terms your "focal point" is called "product owner". Having one person coordinating with the clients is good, as it can take quite a lot of time to get the different stakeholders agree on the needs. However the product owner (or focal point) should be in direct contact with the developer, without going through the project manager. In fact, the product owner and the project manager has quite distinct roles that gain a lot by being split on two people.
The product owner is the stakeholders' voice to the development team. The project manager on the other hand is responsible for the wellbeing of the project team and often keeps track of budget etc. These roles sometimes has opposing agendas, and having them split on two people gives a healthy opportunity for negotiation between conflicting interests. If one person has both roles, that person often tend to favour one of them, automatically reducing the other one. You don't want to work on a team where the project manager always puts the client before the team's needs. On the other hand no customer wants a product owner that always puts the team's needs first, neglegting the customer. Splitting the responsibilities on two people helps to remedy that situation.
I'd agree with Anders answer. My one extra observation is that many clients find it impossible to ignoire the Ugly. They get concerned about presentation rather than function. Hence you may need to bite the bullet and do at least one "Nice" screen to show that you will pay attention to presentation details.
What to, generally, do in the first few iterations if we start from the scratch?
Many teams use an Iteration Zero to:
setup the development infrastructure (source control, development machines, the automated build, a continuous integration process, a testing environment, etc),
educated the customer and agree with him on the methodology,
create an initial list of features, identify the most important and do an initial estimation,
define time of meetings (planning meeting, demo, retrospective), choose the the iteration length.
Iteration Zero is very special because it doesn't deliver any functionality to the customer but focus on what is necessary to run the next iterations in an agile way. But subsequent iterations should start to deliver value to the customer.
Just give it a month of development to code core of the application or start with simple wire-frames with limited pre-coded functionality?
No, don't develop the core of your application during one month. Instead, start delivering vertical slice of the application (from the UI to the database) immediately, not horizontal slices. This doesn't mean that a screen has to be complete (e.g. implement only one search field in a search screen) but it should ideally be representative of the final look & feel (unless you agreed with the customer on an intermediate step). The important part is to build things that provide immediate value to the customer incrementally.
What usually clients want to see? Shiny stuff that doesn't work or ugly stuff that does work?
To my experience, they want to see demonstrable progresses and you want to get feedback as soon as possible.
Is it a good idea to have a Focal Point on client side or is it better to communicate straight with all the clients to prevent miscommunication?
You need one person to represent the clients (who is called the Product Owner in Scrum):
he provides a single authoritative voice
he has a perfect knowledge of the business (i.e. he can answer questions)
he knows how to maximize the ROI (i.e. how to prioritize functionalities)
Agile generally wants to provide the client something valuable, quickly.
So I certainly would not spend "month of development to code core of the application". To me, that smells of the "big up front design" anti-pattern. Also, see YAGNI.
Get as much information from the clients about what they need soonest, and implement that in your first iteration. "Valuable" is in the eye of the client. Thet will know if they want to see slick UI (maybe they want to give a slide show about the product at a trade show, so functionality can be fake) or simple working features (maybe you're developing something that they need to start using ASAP). Business Value is what they say will help them do their job.
I'd make my iterations as short as I can (your 2 weeks could work, I suggest considering 1 week) If you absolutely can't have your dev team and your clients co-located, instead of having a call with the clients, I suggest a meeting. Demo what you've done over the previous iteration and solicit feedback about what should stay, what should change, and what should be added.
As others have said, your "Focal point" sounds like a Product Owner. What worries me about your drawing is if it is meant to imply that devs don't interact with the PO or the clients. One thing that makes Agile work is when there is lots of communication. Having communication to/from the dev team always filtered through the Project Manager is almost certainly bound to result in miscommunication, unnecessary work, and missed details.
I agree with the two answers given but I would just add one thing from personal experience. Are your customers bought in to the change towards quick iterations? As well as providing feedback after each iteration which is going to require the customer performing usability tests on each feature.
Now I don't know what your groups relationship is with your customer but its not unusual for customers to take a "Put request in - get working system out" attitude in that they are enthusiastic when giving requirements but not so forthoming with time when it comes to testing the feature.
Now this may be totally inappropriate to your situation but its always worth considering how your customer workflow will have to change as well as your groups.
Cheers
I am about to start develop a finance/expenses tracking/management/statistics webapplication, somewhat similar to xpenser.com , mint.com (except bank integration), for a college project and I am looking for a name
credit will be given in the documentation if the name will be used
if this turns later into a real-life project the name will be changed
...
unsure if this belongs on stackoverflow, but I figured that since it is a programming project here is a place to ask for ideas
Is your question about programming? - It is related to programming
We prefer questions that can be answered, not just discussed. - there many answers, they don't need discussion
Scrooge
pennypincher
frugality
moolah
dough
bling
inmymattress
Some ideas off the top of my head:
BigSpender
st#tement
Fiscality
My Online Money - It's as safe as Mom!
ManEx - Manage Expenses
you could call it Dave and say that "Dave is your own personal accountant" (Or Doug or any "accountant sounding name")
Ponzi/Madoff etc.
BudgeIT
Dodgy Abbreviations:
F.U.N - Financial Upkeep (unification/utility etc) Notepad
C.A.S.H - Comprehensive Allocations and Spending Hub (or Homepage etc)
S.P.E.N.D - Secure Personal Expense Needs Database
As this is a homework product, I wouldn't worry too much if you infringe on an existing trademark.
you mention XPenser, so why not eXpenserER - The expense tracking application for Economic Reliability. Or, a common mispelling of something in the related field (like XPenser is Expenser).
Whenever naming things for Uni, I tended to try and be humorous and serious at the same time. Whilst the name would be funny, I would then treat it as a normal name and the Branding was normally conservative.
Good Luck1
MyMoney, ISpent, ImBroken... It depends from what are you looking for.
Off the top of my head:
- MoneyWatcher
- MoneyFlow
- The Honest Accountant
Also I am mad for recursive acronyms so something like:
SOFT Online Financial Tracker
On a particular project we're working with a total of 10 team members.
After about a year working on the project (and using Mantis as a bug-/feature-tracker eversince), the bugtracker gets more and more difficult to use, as no standard has been setup that explains how to create new tasks, how to comment tasks etc. This leads to multiple entries for the same bugs, inability to easily find bugs when searching for them etc.
How do you organize your bugtracker? Do you use a lot of (sub)categories for different portions of your application (GUI, Backend etc), do you use tags in the title of tasks (i.e. "[GUI][OptionPage] The error")?
Is anyone in your team allowed to introduce new tasks or is this step channeled through a single "Mantis-master" (who would then know whether a new report is a duplicate or an entirely new entry)?
Always link a version control system commit to an issue and back so that you know which commits were made do solve which issue and why a certain commit was done.
What we did is to introduce a role for approve entries to the bug tracker. This role can be shared by different people. The process is either to approve, to approve with a small edit, or to reject the entry with the request for further editing or clarification.
It is better for the general understanding if the role is not given to people working in the (core) team.
In a "large" mantis system on the open web, I've seen the rules go something like
New: Anyone can enter a bug.
Acknowledged: A select few people can upgrade it to this level. These people have seen every new bug for a while, and thus they'll know if it's a duplicate. Or they can pass it back to the reporter for clarification until they understand it well enough to do this job.
Confirmed: Set by decision makers who basically say "We will be doing this".
I don't actually remember where it was, and more importantly I don't know how well it worked.