Straight away, you can take some good practices out of both.
Daily scrum meetings are very effective. Have the whole team meet daily near a whiteboard, not a room, for a 15 minutes stand up. Everybody has to answer three questions:
What have you done yesterday
What will you do today
Is anything standing in your way
This has a direct benefit of making everybody feel part of a team, and letting problems emerge.
Dividing your project into iterations is also very useful. Choose an iteration length, either two weeks or one month.
Have a half day meeting on the first day of the iteration where the team chooses and commits on what to do in the iteration. Write this down and refer to it during the daily meetings. Monitor that you are progressing towards the objective.
Have another half day meeting on the last day of the iteration to do two things. First you want the demo the current state-of-the-art to Business Owners (or Stakeholders). This focuses the team on having something that can be demoed, and keeps pressure off the team by showing constant progress. Second, you want to have a retrospective meeting in which you write down what went wrong, what went right and any exceptional events happened.
Sometimes we use pair programming to build team spirit and to focus on particularly complex issues. Give one item to solve to two people using only one computer.
Speaking of team focus, have the whole team work in the same dedicated room if possible. This is quite important.
Continuous integration, decent source control and unit testing are technical tools that allow your team to be more agile. Set them up!
I also found useful in the past to circulate (and hang a large print-out of) the agile manifesto.
In order to become even more agile, you need your Business Owner to "buy-in" to the methodology. They need to be involved in the planning meetings where the pick and choose which items should be developed in the following iteration. Generally this choice is based on business value: reduce risk by having the most valuable items developed first. If the project runs late you can still close it off early, still having the most important stuff. They also have to accept part of the responsibility of bringing the development to completion. This usually focuses the development on the right things.
I could write a lot more on the full implementation of these methodologies, but as I was saying, your project has already started. In my experience the biggest problem with implementing agile methodologies is that people have difficulty getting what agile means. Some people will tend to act in a non-agile way even during a fully agile development! For this reason I think that you will need some agile training before you can implement a full-blown Scrum, for example.
Task boards are a good idea for letting everyone know what is being done and what is supposed to be done in a sprint. There can be challenges in getting this started but once a team is used to it, it isn't that bad to have as a way to show what is being done, what was done and what is coming up. There is estimating tasks and building a back log and burn down but this can be nice to see at times to show, "Hey, we did get some stuff done!" I'd suggest taking the first few sprints as a period where velocity will not be consistent as there is some working out of the kinks of how much work can be done in a sprint. This is part of Sklivvz's answer in terms of what goes on that whiteboard where you have stand up.
Pair programming is also a great idea for helping to build a homogeneous codebase and to get in some standards that can also be useful.
It's always a problem to start using any methodology after a project has started. However the best I can give you is to use SCRUM.
The reason I put this forward is that SCRUM is known for projects whose specifications change often and to cater for it.
You have the Project Owner, who is the person who you are making the program for, and they own the product backlog. The backlog is basically your spec. Please read up on these terms in greater detail, i'm simplifying here.
You then have your sprint, which is a 1-Month development cycle, in which you decide on the things you are going to get done from the backlog.
Then daily, you have a 5 minute scrum meeting in which you ask what you did the previous day, what you are going to do, and if there are any obstacles in your way.
So basically, you have a spec that can change, and constant communication. This seems to me to be about the most suitable Agile methodology that you can get into a bit later in the game.
What you are talking about, as far as I understand, is basically to subside the effects of the downtime during the vacation period, now taking Vacation Period in our stride, SCRUM methodology gives the right set of tools for handling this kind of situation, reason being,
Each Sprint would deliver a shippable product, so your concern of the downtime not getting utilized would surely be out of the way, as only that much work would be planned during the downtime as much as the team availability.
SCRUM is independent of what technology you are using, be it EntityFramework or any other for that matter.
发布评论
评论（4）
您可以立刻从两者中汲取一些好的做法。
每日 scrum 会议非常有效。让整个团队每天在白板（而不是房间）附近举行 15 分钟的站立会议。每个人都必须回答三个问题：
这有一个直接的好处，可以让每个人都感觉自己是团队的一部分，并让问题自然而然地出现。
将项目划分为迭代也非常有用。选择迭代长度，两周或一个月。
有时我们使用结对编程来建立团队精神并专注于特别复杂的问题。将一项任务交给两个人，仅使用一台计算机来解决。
说到团队焦点，如果可能的话，让整个团队在同一个专用房间里工作。这一点非常重要。
持续集成、良好的源代码控制和单元测试是让您的团队更加敏捷的技术工具。设置它们！
我还发现过去分发（并悬挂大份印刷品）敏捷宣言很有用。
为了变得更加敏捷，您需要您的企业主“接受”该方法。他们需要参与计划会议，在会议上挑选并选择应在后续迭代中开发哪些项目。一般来说，这种选择基于商业价值：通过首先开发最有价值的项目来降低风险。如果项目延迟，您仍然可以提前关闭它，仍然拥有最重要的东西。他们还必须承担完成开发的部分责任。这通常将开发重点放在正确的事情上。
我可以写更多关于这些方法的完整实施的内容，但正如我所说，你的项目已经开始了。根据我的经验，实施敏捷方法的最大问题是人们很难理解敏捷的含义。即使在完全敏捷的开发过程中，有些人也会倾向于以非敏捷的方式行事！出于这个原因，我认为您需要一些敏捷培训，然后才能实施成熟的 Scrum。
希望有帮助！
Straight away, you can take some good practices out of both.
Daily scrum meetings are very effective. Have the whole team meet daily near a whiteboard, not a room, for a 15 minutes stand up. Everybody has to answer three questions:
This has a direct benefit of making everybody feel part of a team, and letting problems emerge.
Dividing your project into iterations is also very useful. Choose an iteration length, either two weeks or one month.
Sometimes we use pair programming to build team spirit and to focus on particularly complex issues. Give one item to solve to two people using only one computer.
Speaking of team focus, have the whole team work in the same dedicated room if possible. This is quite important.
Continuous integration, decent source control and unit testing are technical tools that allow your team to be more agile. Set them up!
I also found useful in the past to circulate (and hang a large print-out of) the agile manifesto.
In order to become even more agile, you need your Business Owner to "buy-in" to the methodology. They need to be involved in the planning meetings where the pick and choose which items should be developed in the following iteration. Generally this choice is based on business value: reduce risk by having the most valuable items developed first. If the project runs late you can still close it off early, still having the most important stuff. They also have to accept part of the responsibility of bringing the development to completion. This usually focuses the development on the right things.
I could write a lot more on the full implementation of these methodologies, but as I was saying, your project has already started. In my experience the biggest problem with implementing agile methodologies is that people have difficulty getting what agile means. Some people will tend to act in a non-agile way even during a fully agile development! For this reason I think that you will need some agile training before you can implement a full-blown Scrum, for example.
Hope it helps!
任务板是这是一个好主意，可以让每个人都知道冲刺中正在做什么以及应该做什么。开始时可能会遇到一些挑战，但一旦团队习惯了它，作为一种方式来展示正在做什么、已经完成了什么以及即将发生什么也不是那么糟糕。有估计任务、建立积压日志和燃尽的过程，但有时看到这可以很好地表明，“嘿，我们确实完成了一些事情！”我建议将前几次冲刺视为速度不一致的时期，因为在冲刺中可以完成多少工作方面存在一些问题。这是 Sklivvz 回答的一部分，涉及到你站起来的白板上的内容。
结对编程也是一个好主意，可以帮助构建同质代码库并纳入一些也有用的标准。
Task boards are a good idea for letting everyone know what is being done and what is supposed to be done in a sprint. There can be challenges in getting this started but once a team is used to it, it isn't that bad to have as a way to show what is being done, what was done and what is coming up. There is estimating tasks and building a back log and burn down but this can be nice to see at times to show, "Hey, we did get some stuff done!" I'd suggest taking the first few sprints as a period where velocity will not be consistent as there is some working out of the kinks of how much work can be done in a sprint. This is part of Sklivvz's answer in terms of what goes on that whiteboard where you have stand up.
Pair programming is also a great idea for helping to build a homogeneous codebase and to get in some standards that can also be useful.
项目开始后开始使用任何方法总是一个问题。然而，我能给你的最好的办法就是使用 SCRUM。
我提出这一点的原因是 SCRUM 因其规范经常变化并适应它的项目而闻名。
您有项目负责人，即您为其制定计划的人，并且他们拥有产品待办事项列表。积压工作基本上就是你的规格。请更详细地阅读这些术语，我在这里进行了简化。
然后你开始冲刺，这是一个为期 1 个月的开发周期，在这个周期中你决定要从待办事项中完成哪些事情。
然后每天举行一次 5 分钟的 scrum 会议，询问前一天做了什么、打算做什么以及前进的道路上是否有任何障碍。
所以基本上，你有一个可以改变的规范，以及持续的沟通。在我看来，这似乎是最合适的敏捷方法论，您可以在游戏后期使用它。
有关 SCRUM 的更多信息
It's always a problem to start using any methodology after a project has started. However the best I can give you is to use SCRUM.
The reason I put this forward is that SCRUM is known for projects whose specifications change often and to cater for it.
You have the Project Owner, who is the person who you are making the program for, and they own the product backlog. The backlog is basically your spec. Please read up on these terms in greater detail, i'm simplifying here.
You then have your sprint, which is a 1-Month development cycle, in which you decide on the things you are going to get done from the backlog.
Then daily, you have a 5 minute scrum meeting in which you ask what you did the previous day, what you are going to do, and if there are any obstacles in your way.
So basically, you have a spec that can change, and constant communication. This seems to me to be about the most suitable Agile methodology that you can get into a bit later in the game.
For more information on SCRUM
据我了解，你所说的基本上是为了减轻假期期间停机的影响，现在我们可以轻松地度过假期，SCRUM 方法论提供了处理这种情况的正确工具集，原因也就是说，
每个 Sprint 都会交付一个可交付的产品，因此您对停机时间未得到利用的担忧肯定不会成为问题，因为在停机期间只会计划与团队可用性一样多的工作。
SCRUM 独立于您使用的技术，无论是 EntityFramework 还是任何其他技术。
What you are talking about, as far as I understand, is basically to subside the effects of the downtime during the vacation period, now taking Vacation Period in our stride, SCRUM methodology gives the right set of tools for handling this kind of situation, reason being,
Each Sprint would deliver a shippable product, so your concern of the downtime not getting utilized would surely be out of the way, as only that much work would be planned during the downtime as much as the team availability.
SCRUM is independent of what technology you are using, be it EntityFramework or any other for that matter.