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.

Impr开发者_开发问答ove this question

Looking for work at the moment, I'm seeing a lot of places asking for Agile experience, but until I get a job with a team that is using Agile, I suspect I'll never get the experience.

Is it possible to adopt Agile methodologies with just one person?

Sort of answering my own question, there's similar questions at :-

• https://stackoverflow.com/questions/1407189/can-agile-scrum-be-used-by-1-or-2-developers

(I guess I should get better at searching.)

---

You seem to be coming at this from a work experience point of view; if you are looking to build relevant experience to get you a job on an agile project I would probably think a little more laterally.

Firstly could you work with others, maybe on an open source project? That would be a good opportunity to try out agile methods with others who may have more experience.

Secondly, you could look at using some of the common techniques or tools, even if it's just to learn how the tools work - e.g. you could set up a continues integration server to run builds and unit tests when you check in code. If you are working on your own you won't gain much in terms of productivity by doing this but you would gain some skills and have something relevant to say to future employers which would indicate you are committed to the agile style.

---

Yes

Check out PXP or Personal Extreme Programming.

http://portal.acm.org/citation.cfm?id=1593127

Summary from the paper:

Personal Extreme Programming (PXP) is a software development process for a single person team. It is based on the values of Extreme Programming (XP) i.e. simplicity, communication, feedback, and courage. It works by keeping the important aspects of XP and refining the values so that they can fit in a lone programmer situation. PXP can still be refined and improved. It is in the tradition of XP practitioners to vary XP to encompass whatever works. We hope that PXP inherits these pragmatic roots, as well. Giving up XP tenets like pair programming is not necessarily a tragedy. We still believe that following XP strictly is a more effective way to pursue multi-person projects. But we are also convinced that many of the XP practices and methods can be applied to individual work. The PXP approach tries to balance between the "too heavy" and the "too light" methodologies. PXP will inject the right amount of rigor for the situation without overburdening the team with unnecessary bureaucracy.

---

Yes - it is possible to do many agile practices as an individual.

If you already know how to do these, you can do them as a sole developer:

• test-driven development - great place to start
• refactoring
• continuous integration
• doing the simplest thing that could possibly work (and evolving it through refactoring)
• automated deployment
• planning meetings (a team of one plus customer)

Things you can't do on your own:

• pair programming
• CRC/RRC workshops (... you'd have to talk to yourself quite a lot)

---

Pair programming would be hard this way :)

Let's check Agile Principles:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

You can do all of those things even while working on some personal project alone. You can use also GTD while working alone, you can develop your product through iterations, you can adopt timeboxing, you can ask some family members or friends to do usability tests with you (and this works really well).

As a conclusion, you can really get tons of Agile experiences alone. I strongly recommend you to read some books first tho, as some of principles can be easily misinterpreted.

---

Some aspects can be done alone: running a product backlog and using a task board come to mind. See what the secretGeek is doing.

Of course some cannot: pair programming, scrums etc...

---

I recently interrupted a big project. It was a medical software project. While working on it, I realized some patterns about solo programming. I want to share my experiences here:

1. Your software's working logic must always reflect the real world. You catch fish with fishing rod, not baseball bat; so forget it.
   
2. Always start building from the project element to which all other elements refer. That makes sense if you think that like the function in a software project which is called at most. That might be database modeling. It would be useless if you model data access layer first, before modeling database.
   
3. Never mind changing variable names. That's the most written entry in a programmer's diary; so no need to be ashamed.
   
4. Methodology changes the world. Make worth of it. Make every single logical process with a function or procedure. When project gets huge you will understand thats the best way.
   
5. If you're not designing a language compiler in assembly do not hesitate using huge procedure call chains in which one calls another and that calls another and so on. Use methods everywhere, nearly resemble every single entity with classes and be modular.
   
6. Modularity is everything. Set modularity your primary goal. Have i said it is everything meanwhile?
   
7. Last word for beginning the project. If you're building an apartment you install main entrance at last. But when using, you enter the building from entrance. Be aware.
   

These are some of my design principles I learned and learning day by day. I hope having been useful. Do your best.

---

While some Agile practices are directly targeted at more than one person teams, they are just practices, they are just a mean, not an end. I mean, Agile is not about doing pair programming, stand up meetings, etc. Agile is about maximizing the customer value while minimizing waste to provide the most optimal ROI. Agile is business oriented, practices are just a way to achieve this goal in a given context. So, back to the initial question, it's definitely possible to adopt Agile practices (that make sense in your context) to maximize the delivered value: continuous planning, limiting Work In Progress, Stop-the-Line culture, time boxing, high quality, just enough specifications, just enough and just in time documentation, etc, etc.

---

Definately. Agile is very flexible in terms of how many people are involved. Some methodologies, like Scrum, focus mostly on doing as much as possible in a limited time, like two weeks (sprints). That includes whatever you want it to. If your team requires QA, then that is part of it. As a loner, you decide what you want to include.

After the scrum sprint, you look at what you could have done differently to get more done, and move to the next one.

Some other methodologies focus more on getting features done in each iteration, say three small features developed, tested and refactored.

As you can see, there are tons of ways to apply agile to any project. You decide which aspects you want. Though obviously one integral part is doing things in small increments.

---

Yes

XP/TDD scales from one to one thousand. Pair programming is optional.

---

YES.

Agile is more of a state of mind than just a methodology of software development like waterfall. Scrum is one of the very popular agile methodologies. You can study below aspects of scrum in detail:

1. Benefits of Scrum/Agile over Waterfall
2. How can you create better "products" with Scrum/Agile
3. What are the types of projects better suited for Scrum
4. Pros and Cons of Scrum
5. Scrum Rituals and why are they necessary (What advantage do they bring)
6. Different roles in scrums and their responsibilities (Scrum Master, Product Owner and Development Team)

After you have good understanding of working of scrum and its benefits, try to create a pet project. You will have to play all the roles yourself. You can try to distinguish between what role you are playing currently by wearing different colored hats for each role.

Example:

Product owner : Think from product perspective, what should be the features in the product and why would they be important for your users etc. Then proceed with all the scrum practices.

Scrum Master: Keep checking if you are following all scrum rituals in the right sense and spirit and are you able to derive benefits out of it.

There will be limitations,example you cannot have Daily stand-up meeting, obviously because you are the only person in the project. But if you follow above, you should be good to secure a job and play your part well in the team.