Kent Beck, Martin Fowler
A guide to XP leads the developer, project manager, and team leader through the software development planning process, offering real world examples and tips for reacting to changing environments quickly and efficiently.
I work as a lone developer in a very small company. My work is quite chaotic and I'm looking for ways to make it more organized.
One problem is that my projects have practically no management. Rarely anyone asks me what I'm doing, or if I have any problems. At some point there was talk about weekly status meetings, but that's some time ago. Seems that if I'd want something like that, I would have to arrange those myself.. Sometimes I'm a bit lost on what I should do next because I don't have tasks or a clear schedule defined.
From books and articles I have found many things that might be helpful. Like having a good coding standard (there exists only a rough style guide which is somewhat outdated in my opinion), code inspections, TDD, unit testing, bug database... But in a small company it seems there are no resources or time for anything that's not essential. The fact that I work in the embedded domain seems to make things only more complicated.
I feel there's also a custom of cutting corners and doing quick hacks on short notice. This leads to unfinished and unprofessional products and bugs waiting to emerge at a later date. I would imagine they are also a pain to maintain. So, I'm about to inherit a challenging code base, doing new development that requires learning a lot of new things and I guess trying to build a process for it all at the same time. It might be rewarding in the end, but as not too experienced I'm not sure if I can pull it off.
In a small shop like this the environment is far from optimal for programming. There's many other things needed to be done occasionally like customer support, answering the phone, signing parcels, hardware testing, assembly and whatever miscellaneous tasks might appear. So you get the idea about the resources. It's not all bad (sometimes it's enlightening to solve some customer problems) and I believe it can be improved, but it's the other things that I'm really concerned.
Is it possible to have a development process in a place like this?
Would it help to have some sort of management? What kind of?
Is it possible to make quality products with small resources?
How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?
Maybe there's someone working in a similar shop?
Been there, done that.
The book Planning Extreme Programming helped a lot. I used 3x5 cards stuck on a wall. This kept my boss informed of my progress, helped with estimates and planning, and kept me on track. The Planning Game gives good ammo if your boss's expectations are unrealistic.
Unit testing, as others have stated, helps even if you're a sole developer. I find the TDD style valuable.
lod3n is absolutely right about Source Control.
I've gone with XP-style iterations before; you may want to establish a backlog of items (even something simple like a spreadsheet or 3x5 cards) as well.
Avoid deathmarches. Stick to 40 hours in the sense of not working overtime 2 weeks in a row. Spend extra time outside of work learning new skills - not just technologies, but principles and best practices.
I guess a feature could be something like 'Credit card authorization' while a user story may be 'Authorize Credit Card for Paypal'.
So is a User story a subset of a feature ?
According to Kent Beck and Martin Fowler stories and features are synonyms:
A user story is a chunk of functionality (some people use the word feature) that is of value to the customer.
What you call a feature is usually referred to as theme or epic. Themes and epics are used to group user stories to bigger feature sets, that make sense on their own.
From a more semantic point of view: feature is a part of the system you are trying to build, user story is a way to describe that part.
As Pascal has pointed out - I maybe missed the real meaning of "feature" in that citation ("feature" obviously refers to functionality) Apart of this, I still think that one can use these words (feature and user story) as synonyms in a lot of contexts ("I'm working on this story" vs. "I'm working on this feature"), since, as Pascal said, a user story is a way to capture a feature. Which means there is a 1:1 relationship between those two. And, as can be seen from my remark about the semantics, this is how I really understand it.
Background info: More and more of our meetings at work involve my boss/team pondering how to implement more "best practices" around here. ("Here" = a very small application development shop. 4 developers)
The following things are items that my whole team agrees that we need:
I believe that if my shop could simply choose a clear and specific plan or set of rules, then everything else would fall into place. Right now we are stuck in discussions of fuzzy, feel-good ideas and nice-sounding buzzwords.
Please recommend to me your favorite book (or online resource) that contains clear, discrete, sequential steps for implementing a management scheme for guiding a TDD or Agile team/shop.
I realize that there are other paradigms besides TDD and Agile that would also address these concerns, but my own self-interests and biases point toward TDD and Agile so I would love to harness my team's desire for change and "nudge" it in that direction. Or feel free to slap me down if you vehemently disagree with my sentiments! I will take no offense. :)
Thank you all.
my favorite is Planning Extreme Programming
EDIT: it provides a complete replacement for traditional project management geared towards an XP/Agile team
the danger is, adopting modern development methods and then strangling them with archaic project-management and administration practices!
For your needs I recommend Test Driven Development: By Example (Kent Beck). It is clearly-written, more practical than theoretical, and prescribes time-tested recipes to adopt an agile, test-driven approach.
How does one test an architecture? Are there test-related things that can be done while the architecture is still being pounded into shape?
I plan to iterate but I don't want to wait to have an entire architecture done (even if it's very rough) before I start thinking about testing.
Update: I'm using the word architecture the way it's used in Code Complete.
In other words, at this second, my architecture is a pile of paper showing how various blobs interact (e.g. one sheet of paper shows a legacy system that talks to a facade that parses/slices-and-dices, which in turn talks to the main website application).
Later, I'll flesh it out to the point of public classes/methods. And after that, I'll write out private method signatures and poke at algorithms, though I'm already looking into them for high-level things such as classifying text.
If you want to iterate you should only design that much that you need for the iteration. Architecture is mostly seen as one layer higher than design. That means I use a layered MVC architecture for deciding how to design my class structure.
If you are building an overall program structure for the first iterations without adding features and things that can be tested you are doing something wrong. One of the benefits from going forward with an iterative process is that you don't over design that much in directions you don't need it.
Take the program that you want to build and take the three most important features. Think about how to implement them and how to design the class structure for that. Think about the things that are likely to change and make them changeable in your Design. Then start your first iteration. Before starting your first iteration think about the architectural choices, are you using MVC, a client server based architecture, do you have a Database Layer or something comparable. Those are choices that will have influence of your later design choices.
For further reading I suggest http://en.wikipedia.org/wiki/Iterative_and_incremental_development and Planning XP-Programming from Kent Beck.
We need to involve our customer development partners in our development process. We're more or less following Agile methodologies. Some customer partners are remote, others closer. We need to minimize travel costs.
Our customers are in health care and tend to be busy, expensive, and hard to schedule.
What practices and technologies have worked to support customer involvement? We're using phone calls, phone conferences and email. We're curious about leveraging wiki techniques and would love to hear what's worked for others.
I think by most definitions of Agile processes that have high dependence on customer involvement you've already missed "best practice", which would be for an on-site, and preferably "in-team" customer present at all times. So I suppose we're looking for a "next-best practice". :)
There's the possibility of introducing a "proxy customer" on-site. I have to admit to being very sceptical about the value of a proxy customer. I'm concerned about the risk of introducing some sort of second-rate and otherwise unnecessary business analyst function to the mix, with the increased signal-to-noise ratio and potential for garbled messages. It also carries the risk of allowing busy real customers to reduce their involvement in the process, which is likely to lead to dissatisfaction. I wonder if there might be someone with good domain knowledge who has recently retired and might be available to act in this capacity as a consultant?
Communication bandwidth with remote customers is astonishingly lower than face-to-face, something I had not fully realised until I started dealing with users in another country. Even with video the loss is significant.
How long are your iterations? How hard is planning iterations? Might it be easier to go for longer iterations and get more planning done less frequently, or reduce iteration length and go to smaller, but more frequent planning sessions? Are more than one customer involv
Do you have a useable and available build at the end of each iteration? Is there time for involved users to have hands-on time before the next planning session? Keeping users engaged by shipping frequently would seem on the surface to be a Good Idea, which perhaps legislates for small frequent iterations (a week? two weeks?)
The wiki idea might work: have you looked at the FIT Framework? It's a sort of integrated acceptance test/wiki, which might help in getting acceptance tests from remote customers. I think I'd also look to provide some sort of (separate or integrated) "project dashboard", possibly pushed regularly to key customers as well as available on demand. use it as a substitute for things like post-its on whiteboards, Big Visible Charts and the like. There are a number of open-source or low-cost options that may serve - writing your own simple alternative need not be too time-consuming or costly, either.
Above all, remember that "Agile" is a kind-of catch-all label for developments that are carried out with an emphasis on the values and principles espoused in the Agile manifesto. What is considered "best" in one situation may not be so in another. If you understand the principles and regularly review your methods with a critical eye then you're probably going to be close enough to the best practice application to your situation.
I haven't looked at it for some time but with Beck and Fowler on the author list, there should be something useful in Planning Extreme Programming.
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:
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:
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.
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.
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.
We have a small company team and even smaller Development team. The current process is that each Sales Rep (SR) is the actual Project Manager of each web application sold. Developers obtain requirements, functionality and design from the SR directly. Giving the actual head of developers to visibility over the actual work load on the developers. While we get more projects and thus possible more Sales Rep and Developers this process gets not-scalable.
We have thought about having a Technical PM be in the middle between SRs and Developers.
SR1, SR2, SR(n) ---> TPM --> Dev1,Dev2
This seems ok, but our current process allows our Sales Reps/QuasiPM actually get developer time in a very immediate way. And they are actually trying to get aways of this.
The issues we are having with the current process are:
SR1, SR2 --> Dev1, Dev2 (Adhoc)
I will add more information depending on the comments I receive. Thanks for your time as always.
EDIT2: In general there are 3 SR or Product Owners, 3-4 Developers, 1 Technical PM.
For vacations/planning, Kanban is one option. Others include XP and Scrum. IMHO Scrum is more a management philosophy while XP is a development methodology. Planning Extreme Programming is definitely worth reading.
Customers (your SRs) will always try to get around the development process. "Can't you just slip this story in to the middle of an iteration?" You need to get management buy-in and support on whatever methodology you pick. For the SRs, the benefits are (1) they get to prioritize the stories (feature requests) and (2) they'll have a better idea of when their stories will be done.