标签：requirements very will How design PD team works
PD (Product designer) is very important role in software development. They will provide detail requirements specification and business workflow, UI workflow. In traditional software development process, PD will prepare the detail requirement design document before develop team start to make software design. This kind of process will work pretty well if the requirements are clear and relatively stable. Also, there are enough PD resources to make the complex documents. But most of time, we cannot figure out the whole requirements clearly at the start stage. And the scope change is often happen. Another factor is that PD always need to work on more than one product and it is very difficult for them to spend much of time to work out a detail design document. So, what can we do to deal with this kind of issues?
Agile provides a methodology or framework for the team to develop software under the situation of changing scope. By focusing on high value requirement, separating the long lifecycle to be several short iterations and guarantee fully-test in each iteration, it can provide high-quality and expected software to the client. In this kind of framework, how PD works in the team? How they collaborate with others?
To answer this question, the first thing we need to consider is what kind of responsibilities PD will take? From my personal view of point, it is requirements clarification. All of the works of PD actually provide a very detail information to the team about requirements. So, it seems that PD should be better to work with product owner to figure out the scope. The team structure may like this (Figure 1).
Figure 1
In this structure, PD will be the assistants of product owner and help him/her to make the requirements. The product owner will setup product backlog and PD will provide relative design for each user story. The design may include UI, workflow and etc. During the Sprint planning meeting, team will work with PO and PD together to make Sprint backlog. And product designer could show any kind of design to the team to give detail information about the user story. It could be a flash, a MS visio doc, a PPT, a hand-drawing paper, or just write/draw on whiteboard and take a picture. PD can also help to answer any team's questions about requirements during the Sprint implementation.
This kind of process won't ask PD to complete all of the detail design for the whole requirements from the beginning. PD needs to finalize the design for the coming Sprint. That means PD's work will be ahead of team's work at least one Sprint. They can also work with a separate Sprint. The collaboration with Team just like Figure 2 showing.
Figure 2
The benefits of this kind of process are
- Setup very clear responsibilities to each role;
- PD can focus on high priority requirements design;
- Complex design documents are not required and it will enable PD to consider real value things;
- Collaboration between PD and team is smooth and close.
Another very value thing of this process is that, after each Sprint, PD will get a workable software to do the user acceptance test. It will be very efficient way for PD to validate the design. And any issues caused by incorrect design can be found at very early stage. And the issue can be fixed in the following Sprints. This is also very helpful to provide high quality software. :-)
转载于:https://www.cnblogs.com/RelaxTintin/archive/2008/11/20/1337529.html
标签：requirements,very,will,How,design,PD,team,works 来源： https://blog.csdn.net/weixin_34038652/article/details/93306176
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。