忘了说 <input id="chbSelect" runat="server" type="checkbox" />这个在Repeater 当中呢。

博主你好， 我现在遇到和这个一样的问题 可是问题还没解决 <asp:Content ID="Content3" runat="server" ContentPlaceHolderID="PageBody"> 下面是选项卡 <cc1:TabOptionWebControls ID="TabOptionWebControls1" runat="server" > <cc1:TabOptionItem ID="TabOptionItem1" runat="server" Tab_Name="图片列表"> 这里是Repeater <asp:Repeater runat="server" ID="repeater1"> 我写类似 Repeater rep = (Repeater)PreviousPage.Master.FindControl("PageBody").FindControl("HeadMenuWebControls1").FindControl("repeater1"); CheckBox cb = (CheckBox)rep.FindControl("chbSelect"); 改来改去还是得不到 博主帮下忙吧 谢谢了、、

非常感谢！

不错,很多情况下我们没有详细设计文档(因为系统流程简单),而有的时候详细设计和实际的程序出入还很大,总体感觉e旋风 的这种管理方式很好,值得学习.
我见过的公司采用的是,一个人写大需求,详细设计由做的人补充的.

厉害，那要是实现文件拖放，然后上传到服务器应该怎么改呢，谢谢指点

不错，困惑了半个小时，甚好有互联网。

十分感谢，为了这个，找了很久！终于解决了！

@movingboy

是的,这个就需要部门总监来进行全局管理了,一个好的部门总监能够让他带领的团队朝正常,团结,高效的方向不断提升的

@e旋风
你提到的这种方式直接引入了两点：

1.公平竞争。竞标的方式提供了一种公平竞争的环境，让大家都有机会去展现自己的能力。不断的锻炼也能提高自己的管理和技术水平
2.合理分配。根据绩效申请积分体现了能者多劳，多劳多得的原则，避免吃大锅饭。此外获得越高的积分是对工作能力的肯定，这又反过来提高了大家的竞争意识

这种方式让大家既有压力又有动力，只要管理层能切实做好管理和协调工作，确实是一种很不错的工作方式，值得借鉴。

不过事物总是有两面的，我觉得这种方式下也要注意避免/控制可能带来的一些负作用，例如可能工作能力强的团队总是能获得优质项目，而其它团队却只能拣剩下的；绩效优异的团队或个人可能会滋生过分的优越感，轻视他人，导致团队间合作出现裂痕；为了提高绩效可能导致经常加班而忽视了健康等

我现在所在的公司软件设计部门也采用到了这种设计参与方式.

不过我们的项目管理更能充分调动团队成员的积极性.

一般是接到一个项目需求,由需求分析师,一般是团队里能力最强,经验最丰富的成员编写出适合高层设计和详细设计人员阅读的文档.

然后通过竞标或者部门总监的指定,由一个人担任此项目的项目小组长.项目小组长有权力挑选小组成员,项目从高层文档的编写到代码发布和相关文档的最终提交,都由项目小组长组织协调. 项目小组长有权力向部门总监申请该项目的积分,(也就是该项目的money^_^),并根据拿到的项目总积分,从中拿出积分用于项目成员的任务酬劳.当然,剩下的积分归项目组长所有.

高层设计和详细设计的文档一般是项目小组全员参与设计,每个成员负责设计的一部分,项目小组长负责协调成员的进度安排和交流讨论.

高层设计到详细设计再到编码的流程中,一个人连续担任其中的角色.也就是说某某设计了高层设计的A部分,就不能再编写详细设计中的A部分了.

当然,部门总监和系统分析师需要确认高层设计和详细设计的最终定稿,以保证设计不出现明显的偏差!

ps.当然,我们从程序员到部门总监,一共11个人

对团队要求很高。

不一定啊，公司小的时候，发现全员设计是可以的，

我感觉，我们公司现在就是全员的设计

全员是个理想

我同意二楼的说法，在项目的设计阶段应该是多个人参设计与讨论，只要的好处有减少风险，大部分人员知道业务有利于开发进度。一个人在牛也是有局限的。

@smalldust
你的考虑非常有道理，在文中的潜在风险部分也提到了。
看来我的思路可能给大家造成一种感觉，就是从一个极端（详细设计由一、两个核心人物撰写）走到了另一个极端（分散为大家一齐来撰写）。那么可否在两者之间进行折中：在项目组中挑选部分同事来分担详细设计工作？或者在小范围内先试行？古人说“兵无常势，水无常形”，本文主要是想给大家一种可借鉴的思路，在此基础上可以灵活运用。全员设计的主要想法是平衡工作量和多人协作来提高设计质量。

思路不错，但是实践起来会有一个问题，就是这样大范围的设计活动，尤其是在一个项目有几十个上百个人参与时，显得很不切实际。尤其是，设计活动需要非常好的沟通，大多数团队里几个人的沟通还成问题，更不用说更多人数的沟通了。

我觉得，在4，5人的小组里这样的设计方式还是很可行的，但是大一点的项目就不大适合了。

不错!