读人月神话博客摘录

读人月神话博客摘录
---->项目日志(1)
http://blog.sina.com.cn/s/blog_493a84550100kxh5.html
项目启动会议很重要，而且是需要正式的项目启动会，有高层领导参加。项目启动会议一方面是体现高层的重视，高层给你们授权，同时是乙方项目团队的集体亮相，启动会上你后续工作可能涉及的沟通和协调接口人都会参加，大家相互认识，领导再支持和肯定项目重要性，后续项目工作开展就容易了。

项目进度计划只是项目计划的一部分，项目计划里面一定要明确项目目标和范围，其次是项目应该有哪些产出，项目的验收标准，项目的组织结构和人员，项目的沟通和汇报机制。这些内容缺一不可。

在项目启动前，开始属性整个项目的背景资料，项目建议书，撰写项目计划，项目进度计划，项目启动会议资料。根据这些组建项目团队，确定项目团队成员的分工，和团队成员一起进一步明确项目计划和范围，准备项目各个阶段需要提供的产出物，每个产出物的文档模版提前准备完毕。

任何事情都要有记录和正式的文档输出。会议应该有会议既要，评审应该有评审记录，调研应该有调研报告，需求分析应该有需求文档，沟通汇报应该有周报日报，所有这些输出必不可少。这些一方面是通过正式的沟通方式获取承诺，一方面是作为项目后续验收的重要产出物，还有就是让项目中的任务都有明确的验收准则和结果导向。

在项目启动前根据项目建议书就可以预先识别项目风险，项目的难点究竟在哪里?有哪些前车之鉴可以参考，如何规避风险，风险驱动了哪些活动？风险管理应该完全贯穿整个项目管理过程。今天不识别出风险，明天就转变为了问题。随时都应该提醒自己没有风险的项目不应该失败。


--->从技术走向IT管理
http://blog.sina.com.cn/s/blog_493a84550100hgu2.html
很多时候我们喜欢提未雨绸缪，但是很多时候缺乏真正的实践环境历练又是很困难的事情。技术走向管理那首先还得回顾技术阶段能够锻炼和提升的管理能力，再谈走向管理后的改进。

技术阶段

加强个人自我管理，自己都管理不好如何管理别人，生活和日常工作中处处是管理，细化到策划一个团队活动无处不体现管理特性。管理好自己是管理开始之基础，七个习惯和卓有成效的管理者其实很多内容都在谈管理自己，个人时间管理和GTD就是项目管理之雏形，个人知识管理就是流程和过程管理之雏形，PDCA循环就是所有管理思想之源头，目标管理又是项目管理之根本。

做好新员工的导师，以师带徒是逐步培养管理能力的基础。能够把一个新员工带好，就有了把多个人和团队带好之信心，能够把团队带好就有了把项目带好之信心。带新员工涉及到平时沟通，学习计划的安排，学习进度的跟着，循序渐进学习和实践路线的准备，结果的Review，技能提升的考察等一系列内容。技术骨干更应该重视带新员工的机会，克服单打独斗的习惯，由个人意识向团队意识转移。

多沟通，多交流，多分享，技术人员不能太内向也不能太外向。在熟悉的团队里面应该积极主动地沟通，保持一种开放的心态，沟通能力是走向管理岗位后的重要能力，平时不注意培养是很难短期大幅提升。同时一定要注意多分享经验，多帮助他人，很多时候技术人员的权威就是如此树立起来的，技术人员不要太狂，太狂的人不适合做管理，要懂得谦下的道理，能力不是靠狂妄体现的，有能力又能保持谦虚才容易赢得尊重。

养成多思考，多总结的习惯，不要仅仅停留在问题表明，为了问题而问题，技术阶段要有探究事物本质的专注精神，要多去思考事物的外延，在思考的基础上主动学习和拓展，通过这种方式进一步提升思维能力和独立解决问题的能力。很多技术人员虽然能力不错，但是缺少读书的习惯，思考总结的习惯，凡事不会事后回想进一步深入研究，老在事物外面转导致进一步提升困难。

初入管理阶段

在技术阶段时候不会以管理者的视角看问题，自己升到管理阶段后又不能以程序员的视角来看问题，很多时候完全以自我为中心不是好事情，先学会换位思考是进入管理之基础，而换位思考会真正让你找到管理的重心，技术，团队，项目，培训一系列工作如何展开。

培养目标意识，特别是项目管理要有强烈的目标意识，目标意识简单谈就是计划，实际执行，偏差三要素。发现偏差要及时沟通总结和纠正。随时都要考虑项目是否出现了偏差，考虑引起偏差的原因，考虑问题的根源和后期如何纠正。而目标意识之根本又是计划的习惯，没有计划就谈不上目标和偏差。

培养团队意识，随着提醒自己一个人做好一件事情不算成功，团队共同做好一件事情才是成功。管理者都没有团队意识，团队成员更难有团队意识。平时少用我，多用我们；少贪功，多担责；少指手画脚，多协同战斗。大家分工不同，目标就是项目成功，管理者更多时候就是打杂的，让大家相互之间磨合好，协作好，帮助大家解决各种问题，而不是只抛问题，好发施令。

培养教练意识，管理者更多要承担教练职责，逐步有随时随地的培训的习惯。要知道做事情思维和方法和传导远远重于问题解决本身。把下面人的技能水平提升上来，团队战斗力才能提升，自己才能够更加轻松，有时间思考更加重要的问题。培养人是管理者的一个重要职责，不要因为任何原因而不培养人。通过培养人和当好教练，才能够真正树立自己的威信，个人威信往往又是技术性团队管理很重要的一个要素。

先重视结果，再改进过程。凡事都要有结果，有输出，事情没有结果时间往往就是浪费了，有结果还要检查结果是否满足标准，强调结果后再来谈过程怎么更好，规范如何更好的保证结果。

=====
项目经理思维和意识的转变-软件生命周期
http://blog.sina.com.cn/s/blog_493a84550100grns.html

需求要条目化,条目化的需求即用户故事，是实现业务价值的一个最小单位，是业务目标驱动的需求;
软件项目经理应该更多考虑如何更好的去适应变化，如果让需求变化导致的影响最小。这就涉及到需求优先级和迭代内容划分，架构可扩展性等一系列内容。软件项目经理应该更多考虑如何更好的去适应变化，如果让需求变化导致的影响最小。这就涉及到需求优先级和迭代内容划分，架构可扩展性等一系列内容。

对于架构，一定要注意的就是软件项目经理往往还需要承担部分的架构设计和评审的职责，架构师不适合多人共同进行，架构最好掌握在一个人手中以保证概念完整性，即我们所的即时架构存在一定的问题也可以保证整体上还是一致的而不是五花八门。架构不仅仅是要熟悉纯技术架构，同时还需要熟悉该系统所在的业务领域知识。原来我们谈的系统分析员更应该是业务架构+技术架构。
源代码就是设计，而我们花费了大量时间编写的设计文档，到了最后往往自己都不会再拿出来看一眼。
对于测试而言，在敏捷方法论中对传统的测试V模型有很大的改进。即我们所的每日构建和冒烟测试，以达到敏捷里面谈的持续集成的作用，只有持续集成才谈得上开发进度的可视化。

审是贯彻了软件生命周期模型的重要过程，重点的评审包括计划评审，需求评审，架构评审和代码评审。评审的目的不仅仅是提前发现和纠正缺陷，同时要认识到通过评审是团队共同学习的机会，是团队形成通用词汇表的重要方式。

=========
谈SCRUM敏捷方法论
http://blog.sina.com.cn/s/blog_493a84550100glun.html
我们常谈的RUP的三个核心是用例驱动，架构为核心和增量迭代。

SCRUM的一个核心思想就是基于过程动态学的可能性艺术，它强调人们想事情的时候不应该把注意力集中在“不能做的事情”，而是应该把注意力放在“什么事情可以做或者可能做”，不要被诸多的不确定性因素所困扰，先做可以做的，然后看有什么新的发现，有什么新的思维出现。再简单来讲就是要尽快去做，把复杂事物进行分解，尽早的开始可以做的事情，当可以做的事情完成后你会发现很多原来不可能的事情又变成了可能，一切原来模糊的东西都逐渐变清晰，这是SCRUM的最高指导思想。

以故事为基础的需求条目化，以任务为基础的实现条目化。(Product Backlog,Spring Backlog)
2-4周的短周期迭代，而每天又是一个最小的迭代。(Product Backlog,Spring Backlog)
基于持续集成思想的进度和质量可视化(看板，燃尽图)。

对于第一点借鉴了很多FDD特征驱动开发方法中的思想，故事更加体现实现业务和用户价值，而故事又必须拆分到最小的业务价值单位以方便后续进度和质量跟踪。在这种方法中弱化了架构，架构思考的过程转移到了故事本身的分解和任务的分解过程中，而这些工作在Spring计划会议中就会完成。

对于第二点重点是借鉴RUP增量迭代的思路，注意迭代的真正含义是每个迭代版本都是可以真正向用户交互的版本。每个迭代中都涉及到多个较小的瀑布模型。

对于第三点位了实现可视化项目管理大量借鉴了精益生产中的看板管理的思路，为了使燃尽图真正有价值又要求了故事本身的粒度应该相差不大，通过这种方式将传统项目管理中的挣值管理方法进行简化，真正体现了进度和质量跟踪中的实用性。


========
个人项目管理计划及实施建议
http://blog.sina.com.cn/s/blog_493a84550100g21f.html

一、项目启动（项目开工会）


了解项目干系人及其利害关系。
所有项目组成员是否到位，如到位则拿到项目开发人员的简历，详细了解每个开发人员的情况（可能会组织到客户方面试）。
根据项目需求规格列出项目功能列表，并根据开发人员技术等情况创建WBS。
根据项目时间、资源等情况规划项目初步开发计划（各里程碑时间点的粗略计划，每个时间段投入多少人力等）。
软硬件需求：版本控制服务器、数据库服务器、开发服务器、缺陷管理服务器、开发工具等。

会议目标：让整个项目组的成员相互认识，建立项目的工作关系和沟通关系，让大家明确团队的工作目标和项目当前的工作状态并一起审阅项目计划，找出项目的难点或可能出问题的环节；分配小组和个人的角色与责任，获得小组和个人的承诺。


参与人员:项目经理、项目总监、全体项目组成员、用户方领导、用户方参与人员、其它主要项目干系人。



实施建议：对立项管理过程域产生的所有有价值的文档如《立项建议书》、《立项调查报告》、《立项可行性分析报告》、《立项评审报告》进行配置管理。做好必要的保密工作。 由于每个项目都要占用机构的资金和资源，立项评审一定要严格。建议对机构高层管理人员进行必要的立项管理培训。


输出文档：项目风险管理计划、工作任务分解结构（WBS）、项目进度计划、配置管理计划、质量保证计划、TimeSheet、开发规范文档、测试计划


二、需求分析

需求调研：与客户就其所需要的功能、流程、操作等需要为基础，而且需求决策者必须是项目经理或部门负责人。列一个需求管理（包括详细的沟通计划及要求沟通）计划，考虑需求沟通中的人员、资源、时间的要求。虽然有些因素是客户方造成的，但应该站在其角度上，为其考虑一些存在的客观及主观因素。


注意与项目成员之间的沟通方式及对团队的建设。
把握需求分析的进度及质量是否符合要求。
根据交互设计原型与客户交流需求分析是否达到要求及功能点是否有遗漏。
有哪些文档或数据是由客户提供的，这些数据是否需要在新开发的系统中维护等。

实施建议：

先对项目成员进行培训，让他们掌握必要的需求开发技能。(比如需求开发要做什么，做到什么程度，需要注意哪些问题等)
对需求开发过程域产生的所有有价值的文档进行配置管理。
需求的建模分析有较高的技术难度，项目成员应当根据自身水平进行取舍。
交互设计中应以用户的易用性为前提然后考虑在这样设计的前提下技术上实现是否有难度或者工作量超过前期设计的百分之二十. （多用TAB形式，尽量让客户的某个角色的任务可以在一个页面中完成，一般用上下文菜单，避免用系统的菜单，一个功能块一般只需要一个入口）

输出文档：产品需求分析说明书、数据流程图、系统应用架构图、交互设计原型、需求分析模型(RQM)


三、概要设计

确定影响系统设计的约束因素：本系统应当遵循的标准或规范、软件、硬件环境（包括运行环境和开发环境）的约束、接口/协议的约束、软件质量的约束、隐含约束等。

确定设计策略：扩展策略、复用策略、折衷策略。

系统分解与设计：将系统分解为若干子系统，确定每个子系统的功能以及子系统之间的关系；将子系统分解为若干模块，确定每个模块的功能以及模块之间的关系。

输出文档：产品概要设计说明书、数据概要设计模型(CDM)



四、详细设计

确定功能模块的参与者、数据库表、输入参数说明、前置条件、基本流程、异常流程、日志等信息。
各层次结构的接口定义

数据库设计：逻辑设计—>物理设计－>安全性设计－>优化


实施建议：先对系统设计人员进行“专题”培训，让他们掌握必要的系统设计技能。由于国内绝大多数的大学不开设“用户界面设计课程”，这导致大部分软件开发人员不善于设计用户界面。项目开发小组应当设法邀请用户界面设计专家参与（或指导）本软件的界面设计。

输出文档：产品详细设计说明书、数据物理设计模型(PDM)、自定义数据类型及BO数据类型文件、数据字典、系统测试用例、对象模型(OOM)


五、编码阶段

软件编码，各接口的实现。 单元测试。


实施建议：
1.对开发人员进行“高质量程序设计”培训，让他们掌握编写高质量程序的技能。
2.对开发人员进行“版本控制、代码审查、测试、改错”等方面的培训，提高他们的工作效率。
3.开发小组根据项目的资源、时间等限制因素，可以适当地减少测试的工作量。
4.对实现与测试过程中产生的所有代码和有价值的文档进行配置管理。



输出：单元测试报告、代码评审报告


六、集成测试

1.根据系统测试用例测试系统的功能性需求，保证系统的正常功能处理及异常处理是否正确。
2.用户界面测试，重点是测试软件系统的易用性和视觉效果等。
3.健壮性测试,测试软件系统在异常情况下能否正常运行的能力。(容错能力和恢复能力)
4.安全性测试(这种测试一般能通过建行的fortify 软件评测即可)
5.如果产品需要安装，那么还得经过安装与反安装测试


实施建议：

对系统测试人员进行必要的培训，提高他们的测试效率。
项目经理和测试小组根据项目的资源、时间等限制因素，设法合理地减少测试的工作量，例如减少“冗余或无效”的测试。
系统测试小组根据产品的特征，可以适当地修改本规范的各种文档模板。
对系统测试过程中产生的所有代码和有价值的文档进行配置管理。
为了调动测试者的积极性，建议企业或项目设立奖励机制，例如：根据缺陷的危害程度把奖金分等级，每个新缺陷对应一份奖金，把奖金发给第一个发现该缺陷的人。
输出：系统测试报告、缺陷管理报告、操作手册


七、客户验收

成果审查。验收人员审查开发方应当交付的成果，如代码、文档等等。确保这些成果是完整的并且是正确有效的。验收测试。验收人员对交付的产品进行全面的测试，确保产品功能、质量符合需求。
及时解决客户方发现的问题。


输出：客户验收计划、验收测试用例、客户验收报告、验收操作手册


实施建议：

在客户验收之前，开发方对验收人员进行必要的产品培训。
开发方可以将系统测试用例给验收人员参考，以减少设计测试用例的时间。
开发方人员应当热情地协助验收人员。对验收人员发现的软件缺陷马上予以纠正；对于复杂的问题应当立即请示有关领导，不可拖延。在验收期间不可与客户争吵，给客户留下很好的印象。
对验收过程中产生的所有有价值的文档进行配置管理。

八、项目结项

计划与实际情况对比:产品功能、工作成果、产品质量、投入人员、工作量、成本等
申请结项理由和项目自我评价
对项目进行综合评估，总结经验教训。


有价值的结项管理至少包括三项内容：

对项目的有形资产和无形资产进行清算，既要防止资产流失，又要及时地利用这些资产。
对项目进行综合评估。例如评估项目完成情况、项目质量、投入产出分析、项目的市场价值、项目对企业的贡献等等。该评估报告可以作为考核项目人员业绩的重要依据。
总结经验教训，使整个机构受益。

实施建议:

对结项管理过程域产生的所有有价值的文档进行配置管理。
做好必要的保密工作。
结项评审工作不能简化。
对结项评审委员会进行必要的培训，使他们树立正确的观念，从而严格把关

输出：结项申请书、结项评审报告



九、核心工具运作经验

下面是这些核心工具的运用经验： (稍做整理)

建立源代码的版本控制系统(cvs或svn)，基本代码提交原则(提交功能描述，每日构建)
建立错误追踪系统(Bugzilla,Jira,TD等),使Bugzilla成为测试与开发沟通的桥梁。
实现每日自动编译，每天的半夜开始自动下载代码，自动编译代码，自动打包安装程序
开发人员的第二天，应该到公共区查看编译日志，看看自己的模块是否正常编译，及时更正，看看自己的邮箱有没有Bug报告，及时修改。
管理人员的第二天，在综合项目需求与头天版本进度的上，可以判断产品的发展方向，如果有偏航或理解错误或有新需求时，可以根据当前情况及时调整。这样，通过 cvs => bugzilla => daily-build，就能将程序员与测试员，进行互动，各施其责。减少沟通与人为的麻烦。对于管理层，也能做到心中有数：因为每天都有新版本，随时掌握产品的走向。
=========
快速开发和自适应
http://blog.sina.com.cn/s/blog_493a84550100ft4z.html
迭代的目的一方面是进度可视，进度可视的体现是产出物可视，每次迭代是一个至少内部可以独立发布的版本。

要通过分解找到明确的内容，放入前面的迭代周期先做，而不是由于需求不明确造成我们整个项目计划的不明确。

当你可能做的东西做完后，你会发现不能做的地方已经迎刃而解

==========
印第安人在赶了3天路后，会停下来小憩一天，因为他要等着自己的灵魂跟上来。

敏捷回顾与项目总结会议不同，它并非项目结束之后的盖棺论定，而是在项目过程中，通过回顾会议及时总结上一次迭代中的得与失，以期达到改进项目开发、团队合作等敏捷活动的目的。

回顾会议竖立一个标杆，那就是在项目开发中没有破坏者，没有替罪羊，没有关键人物，只有整个团队的利益。

回顾会议提出的所有批评都应该是“对事不对人”。

==============

需求调研是在需求分析前的一个步骤，其重点不仅仅在于对现状的理解，问题的保留，需求的收集和捕获等。需求调研的重点就是理解现状，发现问题和差异，为后续需求分析和需求挖掘打基础。
========
项目经理思维和意识的转变-风险
http://blog.sina.com.cn/s/blog_493a84550100eqea.html

风险管理是项目目标驱动的，这样的风险管理才有意义。
达成项目的目标究竟还存在管理，技术，支持等各个方面的哪些不确定性？这个不确定性如果不解决对目标影响是否可以接受。
做计划是对项目目标和结果进行预测，但是预测无法100%准确，风险管理目的就是应对计划本身的不确定性。
风险管理的难点在于通过历史经验积累，识别项目的关键风险，只有识别出来才谈得上应对。
项目应该预留合适的时间和资金的缓冲，但是缓冲太大确实灾难，它可能让我们忽视了风险本身，因为即使风险已经转化为了问题也没有影响到最后目标的达成。

从自己和组织的历史中去找寻经验

=========
项目经理思维意识的转变-人和团队
http://blog.sina.com.cn/s/blog_493a84550100eh7u.html

聘到合适的人而不一定是最优秀的人。最合适的人是能够基本胜任现在工作而且有培养前途的人，这就是项目经理需要的识人的重要眼光。

对于招人，一个是态度，一个是能力，或者能力可能是潜在的，需要考察其学习能力来说明潜在能力。态度的考察比较容易的几个方面，一个是对待本次招聘的态度，一个是对待以往工作的态度；对于能力的考察往往并不需要考察你需要的新的工作技能或知识点，最好的方法就是考察面试者最熟悉的知识点，考察其对经常用到知识点的掌握程度和知识外延的熟悉度，这种方式一是考察现有能力，一是考察自我主动学习能力，看看工作时间是否换了了等周期的工作经验，而不是大量工作的重复。

招到合适的人进来的，首要的就是要安排指导老师形成以师带徒的模式，要让新员工时刻的感受到这是一个团队，我有问题是可以问师傅的，我是有人教的，很多时候我们不注意这点，一个是新员工很难快速融入，一个是本身新员工学习不系统技能提升很慢。老员工是否愿意教，新员工是否愿意学很大程度都受到团队气氛的潜在影响。

项目经理进度安排最重要的往往不是WBS分解和活动排序，而是搞清楚我现在团队技能情况和性格特点.

对工作输出的要求，如果一个员工来自己的角色和工作要求都不清楚，又如何可能把一项工作做好呢？所以发展到后面自然就转变成了一种混乱局面。

工作任务的安排更加会强调需要获取员工对完全工作任务的承诺，当员工愿意为工作任务进行承诺的时候，就表明大家对工作的要求和内容达成了一致，一种单向的工作传递变成了一种双向的工作任务沟通和协议达成。

培养人不可避免的有成本，但是在这方面却来不得半点的节约，培养人不仅仅是通过正式的培训，而更多的是需要通过日常的工作，案例分析，故事管理，言传身教都多种方式进行。

项目经理的内在修养将直接影响到团队的管理和人员的培养，项目经理最重要的就是自律，谦虚，开放和包容，以及其它最基本的职业道德。项目经理首先要加强自律，以方便推动纪律和团队规则的执行，团队要逐渐凝聚，刚开始阶段一定是项目经理的能力和个人威望，在团队发展和规模不断壮大后会转变为通过团队文化来达到这种凝聚的效果。项目经理一方面是严格的执行项目管理规程，制定项目计划和分解任务，跟踪任务的执行，但是更重要的还是观察人，沟通，团队活动策划，员工培训，团队纪律等重要内容，这些内容才是项目真正能够有序执行的基础支撑。

==========
如何成为杰出工程师-九个工作策略
http://blog.sina.com.cn/s/blog_493a84550100dyel.html
只有特定的行为才能让别人觉得你主动积极。主动积极的真正意涵是：主动追求超过自己职权范围的更大责任.

善于利用这个联系的人很清楚必须事先和各领域的专家建立可靠的双向联络管道。

杰出的工程师的工作策略在于主动地创造机会，影响工作上的决策，在工作上表现得极端优异，并且开创自己事业发展的方向。这样的态度可以使他们加速累积工作经验和才能，使得他们在公司中的价值增加。

=======
包括PMBOK，CMMI，IPD，ISO,ITIL等无不再强调体系和方法论。

========
目标驱动
http://blog.sina.com.cn/s/blog_493a84550100ds48.html

我们拿要筹备一场国学讲座这个项目来谈目标驱动。对于这个项目我们的目标是什么呢？可能你开始的答案仅仅是成功的举办这次讲座，那我们就从这个目标来展开谈。

怎样才算成功呢？
这个讲座必须要在10.15日当天下午2:00举行(时间要求)，而且邀请的张老师必须能到，参加的听众应该在100人左右。(时限，资源要求)

必须要在2:00准时开始吗？100人听众容许的偏差范围是多少呢？
我们能容许些延迟，只要在2:20前开始我们都算为正常偏差。另外听众的要求应该是一个范围，最少应该是50人，最多不能超过200人。我们预计的会场只有180个座位，200个是最大容量了。否则会影响到讲座的效果。(增加了偏差和控制边界，度量机制)

成功是谁衡量的呢？仅仅是举办方单方面衡量的吗？讲座顺利召开和讲座成功是否可以划等号？
成功应该还要包括参加听众的反馈，我们需要跟踪讲座的效果才能够形成真正的闭环，以方面我们后续改进类似讲座的组织。应该是大多数的员工对讲座都比较满意才能够算成功的讲座。(获取反馈，度量机制)

大多数是多少？比较满意如何衡量？
看来我们需要先界定这些标准，同时根据界定的标准来收集数据。大多数可以界定为80%以上的听众，对于效果评估我们需要制定讲座后的评估意见收集表，可以分为非常满意，比较满意，一般，不满意等几个等级。我们的标准应该是非常满意和比较满意的人数在80%以上。(细化项目范围,度量)

目标是能够达到的吗？哪些因素会影响到目标的达成呢？
当我们量化了目标本身后，发现要达到这个目标还是有一定难度的。关键的风险还是邀请的老师能够按时达到，老师讲座的内容听众都比较感兴趣。至于参加听众人数我不太担心，因为大家对国学这块还是比较感兴趣。(可行性，风险)

老师讲座的内容听众都比较感兴趣，这个如何达到？
张老师现在没有公开讲课的视频，所以现在有的资料我们无法判断能否匹配。看来在我们的策划过程中是需要包括前期的一些准备，我们可能需要看看老师的讲稿，同时需要调研下听众的需求和关注点，看下两者是否真正的匹配。(细化项目范围)

最后总结如下：

目标需要符合SMART原则。(明确，可度量，可接受，可实现，有时限)
目标需要量化，要用数据说话。
在目标的不断明确过程中，我们看到项目范围也在不断的明确。不明确的目录会遗漏项目范围。
不明确的目标是一种差不多心态，是自己给自己的计划执行偏差和延误留借口。

=====
软件开发中如何应用结构化文档开发
http://blog.sina.com.cn/s/blog_493a84550100cykf.html
当我们向客户按阶段交付文档的时候如何处理呢？这个其实在结构化文档开发工具里面已经有了，即可以根据我们的不同配置规则，根据预定的文档生成格式，自动的抽取相应的内容来生成出我们需要的文档。可以看到在整个过程中我们不会再去专门强调文档这个概念，而是更加强调业务功能和用例，特征值和需求管理和跟踪的概念，文档仅仅是我们在各个阶段思考过程的一种记录后的整合，我们随时的思考和实现思路都应该随时的记录，而不是到后面再来补文档。

=========
借助信息化工作空间实现高效的团队自我管理-转载
http://blog.sina.com.cn/s/blog_493a84550100cvqb.html

经理们往往要求团队成员提交和更新各种各样的表格，例如日报、周报、代码量报告、缺陷报告等等，通过各种计划、报告、表格来管理团队。但是这种方法有很多固有的弊病。

首先，数据不准确。例如在日报中，一般要求提交任务完成百分比。这个数字很多时候是团队成员拍脑袋想出来的。任务完成90%后，剩下的10%需要更多的时间完成的情况在很多团队中也屡见不鲜。
其次，数据不及时。除了项目文件，经理们没有办法了解项目的具体运行状况，进度，只有通过日报或者周报。任务分配也不及时，团队内部工作量也不均衡。
再次，衡量标准不恰当。o 用代码量作为衡量Dev生产率的标准本来就是不恰当的。这使团队成员单纯追求代码量而不停的复制拷贝，不关心优秀系统架构所要求的代码简洁，架构清晰。o 用缺陷作为衡量Dev工作效率的标准也是不恰当的。软件开发并不仅仅是编写代码，更重要的是沟通问题。绝大多数缺陷其实是由需求不明确或者是沟通的不充分和不准确导致的。用缺陷率作为标准会导致团员成员之间的矛盾，互相指责，推卸责任。
再次，信息不透明，不直观。报告往往不是团队成员直接可见的，需要登录到网站，或者访问Source Control或者共享文件夹的某个文件（往往是有权限控制的）。这些信息不会直接展示给大家，他们总是需要一路点击过去。
最后，过多的无效工作。团队成员要花费很多时间和精力在更新及维护报告上面，但这些工作并没有业务价值。

怎样在软件开发中实现团队的自我管理？怎样让团队找到自身的问题？怎样实时地反映项目的进度？团队成员怎样知道每天应该做什么？为了解决这些问题，我们的经验是日常开发中建立一个基于拉动式生产方式的信息化工作空间。

息化工作空间的关键是信息，最终目的是使任何人只要进入一个团队的工作区域，就可以立刻了解项目的进度，项目的运行情况，现有的问题，每个人现在的任务，一些团队需要改进的地方等等。大家每天来上班，只要看一下板，立刻就知道自己该做什么。

很多的敏捷方法论（Scrum、XP、Lean）都提倡团队的自我管理。而信息化工作空间则是保证我们团队自我管理的核心实践。


====

而作为一个面试者唯一需要的就是诚信，其它在细节上犯的一个小错误都不足以否定一个人。

往往你笔试会否定掉一个优秀的人。因为一个优秀的开发人员的核心是结构化思维的能力，是通过各种线索和寻找各种资料来解决问题的能力，而不是把每条语句，每个类都记忆等一清二楚的能力。

==========

软件开发中: 实施是很便宜的甚至是免费的
在软件开发中所有的努力都在设计上，因而需要有创造性和才华的人
创造性的过程很难计划，所以可预计性几乎是一个不可能完成的任务
我们要意识到软件工程学与传统工程学的区别，这是一个完全不同的活动，需要一不同的过程。

====
软件开发-敏捷方法论
http://blog.sina.com.cn/s/blog_493a84550100civ0.html

通过客户、开发人员、经理三方共同参加的计划游戏（planning game）来确定开发计划
小版本发布----尽快发布，尽早发布
通过系统隐喻（metaphor)来让每个人了解整个系统
简单设计----为明确的功能进行最优的设计，不考虑未来可能需要的功能。
重构（refactoring）---不断优化系统设计，使之保持简单
单元测试----先写测试，后写代码
结对编程(pair programming)----系统的每一行代码都是2个人用一个键盘完成的。
代码集体拥有--开发队伍中任何人可以修改任何其他人的代码，代码不属于某个个人。
持续集成----至少每天将整个系统集成一次，保持一个能运转的系统。
40小时工作制----保证休息，保持体力
现场客户----客户自己也是软件开发队伍的重要一份子
编码标准----必须有统一的编码规范，确保代码的可读性

=======
主题阅读-敏捷软件开发
http://blog.sina.com.cn/s/blog_493a84550100c5cy.html

敏捷和CMMI:http://www.javaeye.com/topic/218142
我对敏捷开发的一点理解与读书体会:http://www.javaeye.com/topic/202776
敏捷项目实践步骤:http://www.javaeye.com/topic/163772
异地分布式敏捷开发:http://www.javaeye.com/topic/90820
胖子胡说敏捷:http://www.javaeye.com/topic/9535
跟胖子一起学裁缝:http://www.javaeye.com/topic/70690
对于InfoQ中文社区http://www.infoq.com/cn/，是另外一个关注敏捷和实践的社区，里面还有大量及时从国外翻译过来的文章。关注敏捷和软件开发实践的都可以看一下。

敏捷意味着诚实:http://www.infoq.com/cn/news/2008/10/agile-truthfulness
敏捷如何使个人收益:http://www.infoq.com/cn/news/2008/12/Agile-Benefits-Individuals
敏捷可用性:http://www.infoq.com/cn/news/2008/11/agile_usability
通过游戏学习敏捷:http://www.infoq.com/cn/news/2008/10/agile-games
敏捷团队:http://www.infoq.com/cn/news/2008/10/agile-games
敏捷回顾效果提高工具:http://www.infoq.com/cn/news/2008/12/retrospective-tips
敏捷遭遇实效营销:http://www.infoq.com/cn/news/2007/11/agile-pragmatic-marketing
敏捷度量:http://www.infoq.com/cn/news/2007/07/Agile_Measurement
敏捷抄近道的迷思:http://www.infoq.com/cn/news/2008/01/agile-shortcuts
敏捷态度培养:http://www.infoq.com/cn/articles/cultivating-agile-attitude
敏捷和组织文化:http://www.infoq.com/cn/news/2008/04/smith-creating-agile-environment
敏捷和产品开发:http://www.infoq.com/cn/news/2007/11/agile-product
失败的敏捷项目：http://www.infoq.com/cn/news/2008/07/agile_failures
敏捷项目跟踪：http://www.infoq.com/cn/news/2008/06/agile-traceability-matrix
敏捷和看板:http://www.infoq.com/cn/news/2008/02/hiranabe-lean-agile-kanban


========
项目经理技能和意识-摘录
http://blog.sina.com.cn/s/blog_493a84550100al4k.html

紧盯目标（目标驱动）：好的项目经理应当注意使团队成员协同一致，紧盯目标。他可以凭自己在某一特定行业的经验，凭着对于项目目标的准确理解，也可以凭借他一时的灵感。项目经理是否作到了这一点可以从阶段目标完成的情况上作出判断。

从容驾驭(目标和计划)：好的项目经理应当能够娴熟的控制局势，使团队行动目标明确，同时认真对待拖沓现象。他能使团队绕开礁石，即使出现问题也能迅速修正。是否作到了这一点要看项目经理是否有很好的预防性政策以及出现了问题后处理是否得当。

临危不惧(压力管理)：好的项目经理应当能够乐观的面对长期压力，并能够有效的鼓舞士气。是否作到了这一点可以从团队成员的状态上看出来，如果他们感受到的压力太大以至于影响了工作，项目经理的表现就不是十分理想。

团结协同(团队精神)：好的项目经理能够使团队成员团结一致、发挥自己的能力共同致力于实现团队目标。他会照顾到个别成员的特殊情况，但无论如何一定会使整个队伍灵活高效。是否作到了这一点要看队员的状态及感受。如果每个队员都感到团队正紧密协同向目标前进，那么项目经理的工作就收到了成效。

目光远大(全局观)：好的项目经理非常清楚并密切关注整个项目的全局。他会特别注意一些重要的细节以防出现问题，同时又不会迷失在细节中而失去了对全局的把握。项目经理是否作到了这一点要看他是否在项目进程中的每一阶段都能准确判断出工作的优先顺序。

有章有法(团队纪律)：好的项目经理明确项目目标与进度。他能够有效激励团队成员使他们保持斗志。如果团队成员斗志昂扬，项目经理的工作就值得称道。

未雨绸缪（风险管理）：好的项目经理能够深刻体察队员的心理感受。他能敏锐的发现队员情绪低落的迹象，更重要的是他对这种情况已有了预先准备，能够迅速及时的重新调动队员的积极性，使项目回到正轨上来。

======
好的软件人员一生要看的60本书-转载
http://blog.sina.com.cn/s/blog_493a84550100a8pv.html

======
项目管理面试题-修订后
http://blog.sina.com.cn/s/blog_493a845501009v7i.html

=====
项目管理资料整理的知识目录构建
http://blog.sina.com.cn/s/blog_493a845501009i68.html

=====
列出下人员流失对项目影响的关注点
1.引入新的人员招聘成本,工作交接成本,培训成本
2.需要对新员工进行培训,辅导占有老员工的时间,额外增加成本
3.需要增加更多的Review和测试工作量和时间的安排

1.应该或完全有必要花费相应的成本对新员工进行辅导和培训
2.管理者在项目中更多应该充当教练的角色
3.年平均10%的人员流失是正常的,但超过了这个限度就要分析原因
4.团队建设的目标是塑造追求共同目标和远景和团队精神
5.项目团队应该是一个高度自适应的自我学习型团队

====
探究项目管理中的棘轮效应(转贴)
http://blog.sina.com.cn/s/blog_493a8455010005yi.html
有一个开发人员能力水平高或努力工作，提前完成了项目经理分配给他的任务；而另一个开发人员能力水平低或工作偷懒，结果没有按时完成任务。那么，项目经理有可能认为前者的工作量小，需要提高工作量；后者的工作量大，需要减少工作量。这时，“棘轮效应”出现了,作为理性的高水平或努力工作的开发人员，是不会选择继续努力工作的，因为他们清楚，越努力项目经理评价他的业绩标准越高，自身利益损失越大。

评论

1 楼 793059909 2014-11-05  

很好很强大