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.
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.
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.
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:
Your software's working logic must always reflect the real world. You catch fish with fishing rod, not baseball bat; so forget it.
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.
Never mind changing variable names. That's the most written entry in a programmer's diary; so no need to be ashamed.
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.
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.
Modularity is everything. Set modularity your primary goal. Have i said it is everything meanwhile?
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.
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:
Benefits of Scrum/Agile over Waterfall
How can you create better "products" with Scrum/Agile
What are the types of projects better suited for Scrum
Pros and Cons of Scrum
Scrum Rituals and why are they necessary (What advantage do they bring)
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.
发布评论
评论（10）
你似乎是从工作经验的角度来看待这个问题的；如果您希望积累相关经验以便在敏捷项目中找到工作，我可能会更横向思考。
首先，你可以与其他人合作，也许是在一个开源项目上？这将是一个与其他可能有更多经验的人一起尝试敏捷方法的好机会。
其次，您可以考虑使用一些常见的技术或工具，即使只是为了了解这些工具如何工作 - 例如，您可以设置一个持续集成服务器来在签入代码时运行构建和单元测试。如果您自己工作，这样做不会在生产力方面获得太多好处，但您会获得一些技能，并向未来的雇主说一些相关的话，这表明您致力于敏捷风格。
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.
是的，
请查看 PXP 或个人极限编程。
http://portal.acm.org/itation.cfm?id=1593127
论文摘要：
Yes
Check out PXP or Personal Extreme Programming.
http://portal.acm.org/citation.cfm?id=1593127
Summary from the paper:
是的 - 作为个人可以进行许多敏捷实践。
如果您已经知道如何执行这些操作，则可以作为单独的开发人员来执行这些操作：
你自己做不到的事情：
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:
Things you can't do on your own:
这样结对编程会很困难:)
让我们检查一下敏捷原则：
您可以即使在独自从事某些个人项目时也可以做所有这些事情。你也可以在单独工作时使用GTD，你可以通过迭代开发你的产品，你可以采用时间盒，你可以请一些家庭成员或朋友和你一起做可用性测试（这很有效）真的很好）。
总而言之，您确实可以独自获得大量敏捷经验。我强烈建议您先阅读一些书籍，因为有些原则很容易被误解。
Pair programming would be hard this way :)
Let's check Agile Principles:
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.
有些方面可以单独完成：运行产品待办事项列表和使用任务板。了解 secretGeek 正在做什么。
当然有些不能：结对编程、scrums 等......
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:
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.
肯定是的。敏捷在参与多少人方面非常灵活。有些方法，比如 Scrum，主要关注在有限的时间内尽可能多地完成任务，比如两周（冲刺）。这包括您想要的任何内容。如果您的团队需要质量检查，那么这就是其中的一部分。作为一个孤独者，您可以决定要包含的内容。
在 Scrum 冲刺之后，您会考虑可以采取哪些不同的做法来完成更多工作，然后进入下一个冲刺。
其他一些方法更注重在每次迭代中完成功能，例如开发、测试和重构的三个小功能。
正如您所看到的，有很多方法可以将敏捷应用到任何项目中。您决定想要哪些方面。显然，一个不可或缺的部分是以小增量做事。
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.
是的，
XP/TDD 的范围是从 1 到 1000。结对编程是可选的。
Yes
XP/TDD scales from one to one thousand. Pair programming is optional.
是的。
敏捷更多的是一种心态，而不仅仅是像瀑布一样的软件开发方法。
Scrum 是非常流行的敏捷方法之一。您可以详细研究 Scrum 的以下几个方面：
带来）
产品负责人和开发团队）
在充分了解 Scrum 的工作原理及其优点后，尝试创建一个宠物项目。
您必须亲自扮演所有角色。您可以尝试通过为每个角色佩戴不同颜色的帽子来区分您当前扮演的角色。
示例：
产品所有者：从产品的角度思考，产品中应该有哪些功能以及为什么它们对您的用户很重要等。然后继续进行所有 Scrum 实践。
Scrum Master：不断检查您是否以正确的意识和精神遵循所有 Scrum 仪式，以及是否能够从中受益。
会有一些限制，例如你不能召开每日站立会议，显然因为你是项目中唯一的人。但如果你遵循上述要求，你应该能够很好地找到工作并在团队中发挥自己的作用。
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:
bring)
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.