The key to scrum is that a task be identifiable as "done" before it can be classed as done. How does you company assess whether something is done without reviewing documentation and tests?
Perhaps they have an unusual, but valid, way of doing it. Or perhaps they have missed the point of "done tasks". I'd suggest you start by asking them how they measure down and whether it could be improved. Then suggest documentation and testing as the way of improving the process.
Note that neither testing nor documentation are in fact part of Scrum. Scrum is a pure project management approach - the required engineering practices, like the ones you mention, are supposed to "emerge" during the project. And most specifically, they are supposed to be identified during the heartbeat retrospectives that you do at the end of every sprint. Are you doing those? Can you bring up your concerns there - and are they actually the biggest concerns the team has?
Is the issue that they don't have any documentation and tests, or that they aren't implementing the entire Scrum methodology? Those are 2 very different problems in my mind.
I would much prefer an organization that has taken the time and effort to find and fit a development process that matches their development style as opposed to mandating down from on high the one true process. So I would not be concerned at all if they were using a process that they called Scrum but that didn't meet all the "official" guidelines. Try to determine why the process is the way it is. Chances are that if they have taken the time to tailor it, the team will be receptive to your ideas, especially if you have taken the time to determine why things are the way they are. If you simply approach it as "this isn't Scrum and so isn't right", you will probably not make much headway, but by being pragmatic about the benefits you can likely make some substantial improvements.
Alternatively, if they aren't doing testing and don't have any documentation I would consider that a fairly bad sign. And by documentation I am taking the minimalist view here - a list of features, bug tracking, etc. - I would be very concerned by the absence of these items, less concerned by the absence of items higher up the abstraction list. In the absence of support from management, I would suggest you lead by example. Take it on yourself to setup a simple bug tracking system (there are several - in a pinch, simple text lists in a central location work as well). Don't declare your features complete until someone else has tested it. This can be as simple as walking over to another developer and asking them to try it in front of you. If someone claims a feature is complete, take a few minutes to familiarize yourself with it. If you find a bug, politely mention it to the responsible developer. Slowly build an environment where the team can see the benefits of running tests and tracking features and bugs.
Most teams operate in this manner simply because of a mistaken belief that they don't have time to "do it right", or that they will get to it later. Often this will occur when a simple proof-of-concept done by a developer or two as a side-project turns into a full-on development effort. By showing that it can actually save time and effort, and reducing the initial costs to the rest of the team, you will often find that it becomes ingrained as part of the process without ever actually being officially endorsed or accepted.
If you have management support it will make it much easier, but always be careful to make sure that the team is receptive to the changes. This may mean it takes longer than you want, but so be it, without the team's support any mandated process will fail at the first sign of pressure, which is when you need the process the most.
*Disclaimer - On my last project I spearheaded the movement to tailor the SCRUM process to fit our environment. The "official" process was simply untenable for our client, but it was still an invaluable guide in tailoring our process.
"adding user stories specifically for testing and documenting"
While meta-user stories might make sense in some circles, it rarely works out well. Software folks rarely cope well with meta-user stories, they either don't get the idea that they can change their own processes by writing a story, or -- more typically -- they engineer the meta-user story to death.
When you're interviewing users, it feels like they're making the user story up. Certainly, you're making it up as you listen to them and try to capture it.
When an IT organization tries to make up its own user stories about how IT should work, the process falls apart. Until the organization has done the thing (testing, for example) a bunch of times manually, they're not really qualified to write user stories. Then, after they've done it, they don't need software development processes, they'll just automate the important bits a little at a time.
I think change has to come from a less formal direction. Actually balking at calling something "done" that hasn't been tested is a good starting point.
IT doesn't do things unless forced. So, meet the users and find out why they're not requiring testing. Coach them to require testing. Tell them the consequences and the words to use.
A lot can go wrong in an organization to lead to poor processes. It's important to know what's wrong, and create a demand for change. The best possible thing is to have your boss complaining that you're not fixing it, rather than you suggesting that perhaps it would be good to fix it.
[It doesn't feel right when your boss demands you fix the process, but it's about the only way change will happen.]
发布评论
评论（4）
Scrum 的关键是任务在被归类为已完成之前必须先被识别为“已完成”。 贵公司如何评估是否在未审查文档和测试的情况下完成了某项工作？
也许他们有一种不寻常但有效的做法。 或者也许他们没有抓住“已完成的任务”的重点。 我建议你首先询问他们如何衡量以及是否可以改进。 然后建议将文档和测试作为改进流程的方法。
The key to scrum is that a task be identifiable as "done" before it can be classed as done. How does you company assess whether something is done without reviewing documentation and tests?
Perhaps they have an unusual, but valid, way of doing it. Or perhaps they have missed the point of "done tasks". I'd suggest you start by asking them how they measure down and whether it could be improved. Then suggest documentation and testing as the way of improving the process.
请注意，测试和文档实际上都不是 Scrum 的一部分。 Scrum 是一种纯粹的项目管理方法 - 所需的工程实践（如您提到的那些）应该在项目期间“出现”。 最具体地说，它们应该在每次冲刺结束时进行的心跳回顾中被识别出来。 你在做这些吗？ 您能在那里提出您的担忧吗？它们实际上是团队最大的担忧吗？
Note that neither testing nor documentation are in fact part of Scrum. Scrum is a pure project management approach - the required engineering practices, like the ones you mention, are supposed to "emerge" during the project. And most specifically, they are supposed to be identified during the heartbeat retrospectives that you do at the end of every sprint. Are you doing those? Can you bring up your concerns there - and are they actually the biggest concerns the team has?
问题是他们没有任何文档和测试，还是他们没有实施整个 Scrum 方法？ 在我看来，这是两个截然不同的问题。
我更希望组织能够花时间和精力来寻找并适应与其开发风格相匹配的开发流程，而不是从高处强制执行一个真正的流程。 因此，如果他们使用称为 Scrum 但不符合所有“官方”准则的流程，我根本不会担心。 尝试确定为什么该过程是这样的。 如果他们花时间调整它，团队很可能会接受你的想法，特别是如果你花时间确定事情为什么是这样的。 如果您简单地将其视为“这不是 Scrum，因此是不正确的”，您可能不会取得太大进展，但通过务实地对待好处，您可能会做出一些实质性改进。
或者，如果他们没有进行测试并且没有任何文档，我会认为这是一个相当糟糕的迹象。 通过文档，我在这里采取极简主义的观点 - 功能列表、错误跟踪等 - 我会非常担心这些项目的缺失，而不太关心抽象列表上方项目的缺失。 在缺乏管理层支持的情况下，我建议您以身作则。 自己动手设置一个简单的错误跟踪系统（有几个 - 在紧要关头，中央位置的简单文本列表也可以工作）。 在其他人测试过之前，不要声明您的功能已完成。 这可以很简单，只需走到另一位开发人员面前并要求他们在您面前尝试一下即可。 如果有人声称某项功能已完成，请花几分钟时间熟悉一下。 如果您发现错误，请礼貌地向负责的开发人员提及。 慢慢构建一个环境，让团队可以看到运行测试以及跟踪功能和错误的好处。
大多数团队以这种方式运作只是因为错误地认为他们没有时间“把事情做好”，或者他们稍后会做。 当一两个开发人员作为副项目完成的简单概念验证变成全面的开发工作时，通常会发生这种情况。 通过证明它实际上可以节省时间和精力，并降低团队其他成员的初始成本，您经常会发现它作为流程的一部分变得根深蒂固，而从未真正得到正式认可或接受。
如果你有管理层的支持，事情会变得容易得多，但要始终小心确保团队能够接受变革。 这可能意味着它需要的时间比您想要的要长，但就这样吧，如果没有团队的支持，任何强制流程都会在压力出现的第一个迹象时失败，而此时正是您最需要该流程的时候。
*免责声明 - 在我的上一个项目中，我带头进行了定制 SCRUM 流程以适应我们的环境的运动。 “官方”流程对我们的客户来说根本站不住脚，但它仍然是定制流程的宝贵指南。
Is the issue that they don't have any documentation and tests, or that they aren't implementing the entire Scrum methodology? Those are 2 very different problems in my mind.
I would much prefer an organization that has taken the time and effort to find and fit a development process that matches their development style as opposed to mandating down from on high the one true process. So I would not be concerned at all if they were using a process that they called Scrum but that didn't meet all the "official" guidelines. Try to determine why the process is the way it is. Chances are that if they have taken the time to tailor it, the team will be receptive to your ideas, especially if you have taken the time to determine why things are the way they are. If you simply approach it as "this isn't Scrum and so isn't right", you will probably not make much headway, but by being pragmatic about the benefits you can likely make some substantial improvements.
Alternatively, if they aren't doing testing and don't have any documentation I would consider that a fairly bad sign. And by documentation I am taking the minimalist view here - a list of features, bug tracking, etc. - I would be very concerned by the absence of these items, less concerned by the absence of items higher up the abstraction list. In the absence of support from management, I would suggest you lead by example. Take it on yourself to setup a simple bug tracking system (there are several - in a pinch, simple text lists in a central location work as well). Don't declare your features complete until someone else has tested it. This can be as simple as walking over to another developer and asking them to try it in front of you. If someone claims a feature is complete, take a few minutes to familiarize yourself with it. If you find a bug, politely mention it to the responsible developer. Slowly build an environment where the team can see the benefits of running tests and tracking features and bugs.
Most teams operate in this manner simply because of a mistaken belief that they don't have time to "do it right", or that they will get to it later. Often this will occur when a simple proof-of-concept done by a developer or two as a side-project turns into a full-on development effort. By showing that it can actually save time and effort, and reducing the initial costs to the rest of the team, you will often find that it becomes ingrained as part of the process without ever actually being officially endorsed or accepted.
If you have management support it will make it much easier, but always be careful to make sure that the team is receptive to the changes. This may mean it takes longer than you want, but so be it, without the team's support any mandated process will fail at the first sign of pressure, which is when you need the process the most.
*Disclaimer - On my last project I spearheaded the movement to tailor the SCRUM process to fit our environment. The "official" process was simply untenable for our client, but it was still an invaluable guide in tailoring our process.
“添加专门用于测试和记录的用户故事”
虽然元用户故事在某些圈子中可能有意义，但很少能取得良好效果。 软件人员很少能很好地处理元用户故事，他们要么不知道可以通过编写故事来改变自己的流程，要么——更典型的是——他们将元用户故事设计得死。
当你采访用户时，感觉就像他们在编造用户故事。 当然，当你聆听他们并试图捕捉它时，你正在编造它。
当 IT 组织试图编造自己的用户故事来说明 IT 应该如何工作时，整个过程就会崩溃。 在组织手动完成多次操作（例如测试）之前，他们实际上没有资格编写用户故事。 然后，在他们完成之后，他们不需要软件开发过程，他们只会一次一点地自动化重要的部分。
我认为改变必须来自一个不太正式的方向。 实际上，拒绝称尚未测试的事情为“完成”是一个很好的起点。
除非被迫，否则 IT 不会做事。 因此，与用户见面并找出他们不需要测试的原因。 指导他们进行测试。 告诉他们后果和要使用的词语。
组织中可能会出现很多问题，从而导致流程不佳。 了解问题所在并提出变革需求非常重要。 最好的办法是让你的老板抱怨你没有解决它，而不是你建议解决它也许会更好。
[当你的老板要求你修复流程时，你会感觉不太对劲，但这是发生改变的唯一方式。]
"adding user stories specifically for testing and documenting"
While meta-user stories might make sense in some circles, it rarely works out well. Software folks rarely cope well with meta-user stories, they either don't get the idea that they can change their own processes by writing a story, or -- more typically -- they engineer the meta-user story to death.
When you're interviewing users, it feels like they're making the user story up. Certainly, you're making it up as you listen to them and try to capture it.
When an IT organization tries to make up its own user stories about how IT should work, the process falls apart. Until the organization has done the thing (testing, for example) a bunch of times manually, they're not really qualified to write user stories. Then, after they've done it, they don't need software development processes, they'll just automate the important bits a little at a time.
I think change has to come from a less formal direction. Actually balking at calling something "done" that hasn't been tested is a good starting point.
IT doesn't do things unless forced. So, meet the users and find out why they're not requiring testing. Coach them to require testing. Tell them the consequences and the words to use.
A lot can go wrong in an organization to lead to poor processes. It's important to know what's wrong, and create a demand for change. The best possible thing is to have your boss complaining that you're not fixing it, rather than you suggesting that perhaps it would be good to fix it.
[It doesn't feel right when your boss demands you fix the process, but it's about the only way change will happen.]