BUAA SE Work1

[20373080-庞睿加]

SE Work1

20373080 庞睿加

项目	内容
这个作业属于哪个课程	2023北航敏捷软件工程
这个作业的要求在哪里	个人作业-阅读和提问
我在这个课程的目标是	学习现代软件开发模式与流程，提高个人能力与团队写作能力
这个作业在哪个具体方面帮助我实现目标	通过阅读，在理论与方法论上提高我对软件开发的认识

1. “牛仔式编程”

【来源】

4.5 结对编程

在结对编程中，任何一段代码都至少被两双眼睛看过，两个脑袋思考过。代码被不断地复审，这样可以避免牛仔式的编程。

【疑问与自身看法】

在结对编程部分，书中提出结对编程可以通过代码的不断复审避免牛仔式编程。对这部分我产生了两层次的疑问。

首先，什么是牛仔式编程？通过查阅资料，我找到了两种定义，一种说牛仔式编程是指非常规编程，例如一些牛人写出的取巧但有效的程序代码；另一种则说牛仔式编程用来描述那种直接在生产环境服务器上修改代码的行为，例如为了敏捷实现修改需求而直接跨过流程修改代码。不过具体是哪个定义我没有找到来源。

其次，为什么要避免牛仔式编程？无论是哪个定义，我们可以看出牛仔式编程的核心特点是灵活、直接、独特。这其实与我在中学时学习数学竞赛时所追求的一种好的解法类似，在做一些数学题时，我们往往希望找到一种独特的巧妙的解法，不过过往的经验也告诉我此类解法往往有更大的错误的几率。在软件工程项目中不同之处在于稳定与合作，我们需要尽可能减少bug出现的几率，同时也要增强合作性，而可读性就是很重要的一部分。这也许是工程编程与竞赛题目不同的地方，也是要一定程度上避免牛仔式编程的原因。

2. Program Manager 的方向困境

【来源】

第九章 项目经理

【不同意部分】

在书中提到，PM的设置能够帮助更好的把握方向与平衡，但是我认为在一个不够完善成熟的团队中，PM的设置会将团队的不完善性不成熟性放大，可能PM越多越平等越容易导致在方向偏离时难以纠正。

在团队中，Program Manager往往是平等的角色，且会具有多个，这就意味着在PM中也会出现猪、鸡、鹦鹉的不同角色。在一个不够成熟甚至是刚刚组建的团队中，由于沟通不够充分以及其他外力因素，往往会出现方向与实现偏离的情况，这时我认为PM机制反而可能会难以对方向进行很好的纠正。

具体来说，对于一个小团队或者一个团队的一部分功能有时会在方向上产生很大的偏差，有时重构会是最好的解决方法，而PM机制容易导致难以做下这个决定。可能角色“猪”为了结果的好会支持，但是角色“鸡”与“鹦鹉”可能会通过协调自己的规划来通过减少消耗时间来规避损失，进而反对需要花费时间的重构。

所以基于不充分不完善的经验，我个人认为，我们也需要正视不成熟团队中各式各样的特点，并发现适合不成熟团队的机制，或者做出适合的改进。

3. 敏捷原则4：是否需要每天共同工作

【来源】

第六章 敏捷流程

Business people and developers must work together daily throughout the project.”这句话的Business people and developers.

【疑问】

在敏捷原则中，第四条是：“Business people and developers must work together daily throughout the project.”这句话的Business people and developers指的范围是如何？

对于一些程序开发工程师，在高强度开发时可能需要一些独自安静开发的环境。所以对于主语的限定抱有一些疑惑。

4. 学生开发的日常管理

【来源】

11.5　开发阶段的日常管理

【疑问】

在设计和开发部分的“开发阶段的日常管理”部分，提供了很多进行日常管理的方法以及小技巧，但是根据我以往的经验，问题在于学生与专业软件开发工作者的不同。软件开发工作者的工作基本上集中于一个项目的开发，或者说关键注意力是串行的；而学生的工作往往是并行的，同时进行多项任务，甚至可能因为学院的各种要求产生临时工作要求。这就导致了学生之间的工作交流（项目）反而效率不如专业人士，甚至很难找到共同周期工作会议的时间，所以很多方法在使用时需要考虑到这一因素。如何在开发日常管理能够更好的包容学生的这个不同点，这是我的疑问。

我的个人想法在于可能建立一个以文档为核心的日常管理机制，通过共享文档与记录文档，更好的在时间上实现包容。

 5. 学生开发的绩效管理

【来源】

第十七章 人，绩效和职业道德

开发的绩效管理（邹欣老师博客）

【疑问】

在“绩效管理”的博客中，提出了包括 效率、工作量、不可替代性、完成度等各种指标来衡量绩效，此处我也产生了疑问，我们作为一门教授软件工程的课程，与软件开发不同在于学习的成分，所以对于 本身基础不好但努力学习而不拖队伍后腿的队员，应当如何评判其绩效。也就是说，学习程度是否应当作为标准之一？

注：以上问题基于邹欣老师博客提出，在我的课本到货后会加以补充。

[SoftwareTeacher]

本身基础不好但努力学习而不拖队伍后腿的队员，应当如何评判其绩效。

---

1. 在公司里也有这样的人吧？

2. 在学校里， 大家上同样的课数学课（没有实践，只有书面考试），大家的基础都有很大区别， 如果是花同样努力， 那么最后考试的成绩也会有较大的区别吧？ 这是否也是一种绩效呢？ 这样的绩效公平么？

[SoftwareTeacher]

如何在开发日常管理能够更好的包容学生的这个不同点，这是我的疑问。

---

所以我们这个学期只有很短的时间是要求大家都每天聚集，用scrum 的方式来交流和协调进度。

[BrownSearch]

问题4，比较合适的方法硬规矩+软边界，比如冲刺例会需要有一定的次数保证，那么可以规定一些时间必须全员参与，实在参与不了的再考虑请假。在一些大的时间节点（可以是每次例会，也可以是某一周结束等等）需要保证某些核心需求的实现和基本测试。这些重要的节点需要定硬规矩。而对于一些非核心需求，或者详细的测试报告，或者一些文档，则可以定一些软边界，不设置严格时间，只需要满足课程组给的ddl即可，给大家一定的空间。

[GreyZeng]

工作中，也常常不是串行的，以我的工作经验，协助领导做的事情，经常会打断很多项目计划推进的事情，这也是无法避免的。而且，工作常要平衡家庭和加班，学生至少在本阶段可以专注学习这件事。

[GreyZeng]

但是我认为在一个不够完善成熟的团队中，PM的设置会将团队的不完善性不成熟性放大，可能PM越多越平等越容易导致在方向偏离时难以纠正

但是在团队初期，总有需要协调的事情，这些事情如果不委托一个人来做，开发人员会疲于陷入这些事情的漩涡中