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
(For those who haven't heard of it, Pivotal Tracker "is a simple, story-based project planning tool that allows teams to collaborate and instantly react to real-world changes. It's based on agile software development methods, but it can be used on a variety of types of projects.")
We're about to ramp up with a workflow based around this outline by Rein Henrichs and were curious for opinions on how to break down product components into projects.
We've experimented some with tagging but it seems that if there are a lot of components to a system (a photo viewer, a video viewer, a news feed, a notification service) a single project can get pretty crowded.
At the same time, for versioning etc, it seems it might make more sense to have it all in one project regardless of the clutter.
Any thoughts? Opinions? Comments? Thanks.
Remember that Tracker is a story-based planning tool, not a task-based planning tool. From the standpoint of the customer, it doesn't matter if the story impacts the photo viewer, the notification service or both. The customer has some stories (high-level requirements) they would like to have implemented, they have estimates about the cost of the stories, and they have the ability to prioritize the stories. Breaking things into components is a task-level problem.
More importantly, breaking stories for the same product into multiple tracker projects would make it difficult for the customer to communicate how they prioritize the stories, or get a good estimate as to when stories might be completed.
We use Tracker to track our stories, and we have our own board were we track tasks. I personally think it would be useful to track both stories and tasks in Tracker, but the tool doesn't support it.
It is probably best to have a single project to contain all your stories. That way, you have a single place for the entire team to see what is going on with the project and what the current priority items are. If you have your stories broken down enough that they can be the features in Rein's process, you're in great shape! At the end of the day, having a prioritized list of features is all any development team truly needs. Use the tags in Tracker for filtering. They work well. In my opinion, breaking a single product down into multiple, dependent projects actually obscures information and makes it harder to get visibility on the true state of the project.
Related
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 3 years ago.
Improve this question
I am starting my deep-dive into agile and had questions on how certain companies promote their releases. I need input on whether the community agrees that monthly release cycles for services is the same, in theory, as waterfall? My reasoning is that if a team bundles up several service changes/features and makes one mass monthly release then it's the same as waterfall. Wouldn't the
"agile way" be to release each change/fix/feature as they are merged?
One of the agile values is responding to change over following a plan.
Note that it doesn't specify that you need to release according to a particular frequency or method. This is because Agile is an approach and is not a framework nor is it a methodology.
One organisation might be able to release monthly and still respond well to change. A lot will depend on the nature of the product and the environment. Another organisations might need to release as soon as a change/fix/feature is ready. Both organisations can still be following the Agile approach.
As an extreme example, imagine a product that is only ever used by its customers at Christmas. There is still value in releasing frequently as the this helps to reduce technical risk, but it might be considered overkill to release every time a new feature is completed.
The original book on Scrum, "Agile Software Development with Scrum," specified monthly sprints. However it and other methods disconnect sprints from releases--that is, development from delivery--by specifying that each sprint creates a "potentially shippable product." The product is supposed to be in a state that could be delivered to customers, but for business reasons the company may not choose to do so. (One reason I have witnessed, by the way, is that the customer only wanted quarterly releases for anything except security patches.)
On the flip side, although this is debated in the Agile community, Continuous Delivery need not be blocked by sprint dates: You could deliver as often as desired, getting acceptance on the fly, and use end-of-sprint ceremonies to show stakeholders everything that was approved and delivered over the sprint.
Speaking as an Agile coach who maintains his waterfall certification (PMP) because waterfall is appropriate for some types of projects, I believe saying Agile is a subset of waterfall is a misperception based on tying deliveries with cycles, which isn't necessary.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
most of the books about Project Management (if not all of them) describe management of one big project. Sometimes they describe how to manage very few projects in the same time. But I have very different situation.
I manage small team (4 people) with very small projects. Usually one engineer works on dedicated project. Some times One engineer work on few projects with different priorities (projects quite often switched to "on hold" state for a several days).
So my specific is:
Small projects with short lifetime (1 week to 2 month in general)
Projects usually are not shared between engineers
Number of projects can be 2-3 times higher then number of people (some projects go "on hold" quite often)
There are 2 longterm projects with lowest priority which can be shared between engineers
Can someone share own experience how to manage projects like this, or if you never had such experience but have an idea how to organize that I'll be glad to read it.
Of course if you know book which can help me - I'll be glad to check it as well.
May be there is ready methodology for thas kind of projects which I never heard.
Thank you.
I suggest looking at Kanban. Here's some links to explore:
Kanban (the book) on Amazon
David Anderson's site
Some Kanban info on InfoQ
The Limited Work In Progress Society
I have a team with this situation. My solution is to run each project with week long iterations and allocate an engineer to that project for a number of weeks, where possible. That way each project is only an average of half a week from being worked on if needed.
If you have higher levels of concurrency an alternative strategy would be to keep the short iterations and to set objectives for each iteration that include aspects of each project that requires attention. Multiple, concurrent burndown charts could be maintained to track the work for each project, but I would suggest these are a little academic if you aren't going to have effort expended on each project at a consistent rate. Using this approach would be unorthodox but would give you quick feedback, regular delivery of working software and progress on all the projects that need it so shouldn't rile the agile evangelists.
If you're stuck with this setup, the other responses give some reasonable ideas for dealing with it.
But this is a bad setup, and I'd advocate trying to change the situation. You have too many simultaneous projects, and a work process that doesn't allow teamwork.
If multiple projects have the same stakeholders, try to get the business to merge the projects. If this can't be done, or if it still results in multiple simultaneous projects, try to get the projects to be prioritized by business value so that you can put the whole team on the most important project, finish and deliver it and then move on to the next most important.
This will almost certainly involve getting people outside your team to make some difficult choices, and may be politically difficult, but there are gains for the business, which might help you with selling the change.
Getting a project out the door and in production more quickly will improve the cash-flow/throughput of your company. See throughput accounting.
Putting the whole team on this one project will reduce the impact of a developer absence (see bus number) and will mean your team is actually working as a team rather than as a bunch of individuals who happen to have the same manager.
If you can't get the business to prioritize down to one project at a time, by all means try for two, but with a team of only four developers, you should be doing one.
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
I've been working on a CodeIgniter project with a friend of mine for almost a year now. We feel that our development process isn't as effective as we wanted to be, and currently we're not employing any software development methodologies. We're 2 man team, looking to have more people to work with us in the future, but we don't have enough people to start on scrum.
Right now, we're both working on this project on the side, would be nice to know which methodologies are best for us, to get our development going faster and more efficient.
Agile and Scrum won't make you faster or more efficient:
Since you tagged this with agile and scrum, I thought I'd mention this: neither agile nor Scrum has as its goal faster or more efficient development as you ask for in your question. In fact, changing to these approaches involves a significant learning curve, but if practiced well contributes toward very low defect rates, software that meets the customer's needs, and a development process that responds to changing requirements. Used long enough, Scrum can provide good data about roughly how much work a specific team can get done in a period of time.
Still, you might benefit from some practices:
All that said, there are a couple practices that may want to try:
Pair Programming and Test Driven Design (TDD)
Continuous Integration
TDD is not easy to learn, especially on your own. See if you can attend a CodeRetreat or similar event.
If you aren't already using a modern software change management tool (SCM) like Mercurial, git, or subversion, get one and learn how to use it.
Get regular feedback from "customer"
If you don't already know (you didn't say in your post), you might ask yourself who you are making the software for. Can you frequently and regularly demo it to that person and get feedback? Find out what they want next and put those items at the top of the backlog.
Try to make your product incrementally useful
Rather than making big product-wide changes, add small useful amounts of functionality. Your design will drift but if you have sufficient automated tests in place you can refactor as needed.
I'm curious why you say you don't have enough to do some form of scrum?
You're both on the team, one of you can own the process and the other or both of you can be the product owner. You do your daily scrum so you can know what each of you are doing - picking the work from the backlog you agreed to do. And as you add members you'll already have an established practice they can integrate into.
You can work in 2-4 week sprints, do sprint planning,review, and retrospective regardless of the number of members.
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 3 years ago.
Improve this question
We are currently starting a bigger project. What're your suggestions for best practices of workflow?
We are planning to rebuild from scratch (the existing product is outdated by years, regarding visual and internal design and programming). While the product functions (a Rails based web project) are already set, the question is: What is your workflow from here on? The most interesting part is: How and when do you do your screen design?
We are planning to do it in the following order:
"Pencil and paper" screen design: Just layout what the screens should look like and visualize the functions and visitor pathes
Hand out the layouts from point 1 to the designers, have a talk to them, and let them work in parallel to programming on the designs
First implementation, simple color-less HTML layout based on point 1 (automated tests, functionality, BDD, TDD)
Integrate the designs with the product prototype
Work out the rough edges together with the designer team to finalize the product
Release a beta product for the customer to test
Do you have similar workflows? Are there suggestions for improvements? But the most important for me: How exactly do you do point 1?
While this is not exactly programming-related I still think this should belong on StackOverflow as this is important for anyone doing bigger projects. From the past we know that good screen design is always a critical and hard point if trying to do that while programming, and even harder to deploy it after the prototype application has been created.
Update: I found Balsamiq Mockups to be a very helpful tool to do the mockups. Still there's an open question how one would best visualize visitor pathes.
Update: We had been successful using Balsamiq Mockups to create a design pleasant to the customer and we managed to successfully integrate this into the existing web content. The customer is so comfortable with the new ideas that he is planning to redesign the complete web site.
I like your workflow. It should lead to a decent result.
A few ideas here:
Let the designers know and understand your presentation model. What pages there are, what information and control elements will they have, what is the role of each of them, what is the purpose of the page and what message should it communicate to the user. If you let the designers work alone then they will design something to reflect their vision of the project and not your design. You'll end up redoing everything or trying to adapt one part to the other.
Users will only see and understand design. They know nothing of implementation. If they see a button they will think the feature is there. if you plan to go agile while cooperating with the users during development, hide out elements that are not implemented yet. Feed them results one step at a time.
If you can have users nearby do screen design together with them in iterations. There is not much work for designers yet, when you are basically deciding on the layout. All those colourful effects and polished buttons should be done after the layout is stable. Otherwise it will be a waste of the designers work.
I really like the model of extreme programming. When dealing with new products user requirements can quickly change over time and this is a proven method which keeps the design "up to date".
Have the users write up functions that they want for the application. And have the designers agree upon a general layout.
Write up a general wire-frame that both you and the user agree upon, I like to do this in smart draw or some sort of rapid gui development platform. (no functionality at this point).
Write the code for the GUI based upon the wire-frame and write sequence diagrams and class diagrams.
Based upon these design start to fill in the functionality behind the GUI
Release betas throughout the process of adding functionality to select users who can help guide future development
The benefit of this design is that at any point in time you can re-work the GUI and incorporate new functionality. The idea is to have a general plan at the beginning that can be adapted as user requirements change.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am going to be starting a new job in a few weeks where I will be responsible for both the maintenance and development of a couple of existing web applications and the development of new web applications.
As I will be the only developer on the project and the previous developer was more of a hobbyist, no formal project management or planning techniques have been followed. Additionally no bug tracking has been used or if anything has been recorded its just been notes on paper.
I would therefore like to introduce a better system to help resolve some of the issues and help ensure things run more smoothly. I intend to develop using an agile process (likely scrum) and would therefore like to know what all-in-one solutions people could recommend for me to look into further. I am looking for something which will provide at minimum:
Project Planning
Defining new features
Time estimating
Ability to organise tasks by priority
Project Management
Tracking active tasks
Reporting
Bug Tracking
I would also like to let other staff easily submit new bugs in the applications which they find or customers report. Additionally support for them to add new stories / high level tasks would be of use so they can note down other new requirments/features and I can then work with them to outline more detailed tasks and estimates.
So far I have looked at a number of systems including:
FogBugz - Seems great for bug reporting but would need something else for project planning / management
Agile Buddy - This is probably the best solution I have found so far
Trac
Smart Sheets
Pivotal Tracker
However, as I have not actually used any of these systems myself I do not know what ones would be best or whether there is a better solution out there??? So any recommendations you can provide would be much appreciated.
Actually, FogBugz does project management as well. It will even try to learn how accurate time estimates for features are from each user, and give you estimated milestone completion times accordingly, with probabilities of finishing at various dates. I've used it for the bug tracking, and really liked it, but I've also read enough about its project management features to know that it has them, and they're pretty good.
FogBugz feature list
When I was working as a solitary developer, I picked up a copy of Planning Extreme Programming and bought a pack of 3x5 cards and a plastic box for them. I used those in the Planning Game and stuck the ones I was working on on my wall. My boss could walk by and see what I was working on. This worked well and cost little.
We're currently using Zen at work - it's a web-based Kanban board for planning. This is nice when your stakeholders aren't co-located or if priorities/requirements change frequently.
You can enter bugs as user stories with either system, or you could use a separate defect-tracking system.
I'd question if Scrum is suitable for a one-developer shop. It's targeted towards project management. I'd rather not have a stand-up meeting with myself. ;) XP (minus pair programming) works fine for a solitary developer.
For a one-man show, you don't need any tools to speak of.
Tools -- generally -- are for coordination.
If it's just you, what -- precisely -- are you coordinating?
If you want to make things visible, a pair of simple internally-focused web pages built from static content will do.
Bugs.
Burndown for Features.
That's about it. Use the simplest tools you can possibly use. I recommend using docutils to generate the HTML from plain, simple text.
Don't go tool-happy until you have a large enough team that simple text doesn't work any more.