第36节
主要讨论了在项目开始之前的一些准备步骤和流程。作者强调了需求识别的重要性,并提出需求是与用户共同完成的“发现”过程,而不仅仅是收集他们的意见。需求在某种程度上应该保持抽象,因为需求不等同于架构或设计。作者还提到了一个词汇表的维护,这是为了消除歧义,并确保大家对需求有共同的理解。此外,项目的需求文档应该在内网上公开,这样所有的相关人员都可以访问、查阅,提出他们的意见和建议。
第37节
这一节为我们提供了一个新的思考方式,那就是如果面对一个看似无法解决的问题,我们应该转变思路,尝试去找问题的本质,看看能否通过重新定义需求来使这个问题消失。
第38节
鼓励我们在遇到重复问题时,尽快解决,我们可以通过快速构建原型、迭代,并寻求更好的解决方案。
第39节
关于编写规范的问题,作者警告我们不要对开发者设置过度严格的规定。过于详细的规定可能会限制开发者的创新能力。
第40节
提醒我们要对先前设定的限制有所认识,并努力不让自己被陷入细节,陷入微不足道的部分而无法全面观察问题。也不能盲目地运用所有的技术,而是应该根据实际需求来选择最合适的。
标签:需求,小工,问题,程序员,修炼,开发者,我们 From: https://www.cnblogs.com/xuan-2004/p/17904968.html