Merge pull request #12092 from lixinyuxx/master

20180319
This commit is contained in:
Vic Yu 2019-01-22 17:17:00 +08:00 committed by GitHub
commit 0df94c4f0e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 59 additions and 60 deletions

View File

@ -1,60 +0,0 @@
translated by lixinyuxx
6 common questions about agile development practices for teams
======
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/collab-team-pair-programming-code-keyboard.png?itok=kBeRTFL1)
"Any questions?"
Youve probably heard a speaker ask this question at the end of their presentation. This is the most important part of the presentation—after all, you didn't attend just to hear a lecture but to participate in a conversation and a community.
Recently I had the opportunity to hear my fellow Red Hatters present a session called "[Agile in Practice][1]" to a group of technical students at a local university. During the session, software engineer Tomas Tomecek and agile practitioners Fernando Colleone and Pavel Najman collaborated to explain the foundations of agile methodology and showcase best practices for day-to-day activities.
### 1\. What is the perfect team size?
Knowing that students attended this session to learn what agile practice is and how to apply it to projects, I wondered how the students' questions would compare to those I hear every day as an agile practitioner at Red Hat. It turns out that the students asked the same questions as my colleagues. These questions drive straight into the core of agile in practice.
Students wanted to know the size of a small team versus a large team. This issue is relevant to anyone who has ever teamed up to work on a project. Based on Tomas's experience as a tech leader, 12 people working on a project would be considered a large team. In the real world, team size is not often directly correlated to productivity. In some cases, a smaller team located in a single location or time zone might be more productive than a larger team that's spread around the world. Ultimately, the presenters suggested that the ideal team size is probably five people (which aligns with scrum 7, +-2).
### 2\. What operational challenges do teams face?
The presenters compared projects supported by local teams (teams with all members in one office or within close proximity to each other) with distributed teams (teams located in different time zones). Engineers prefer local teams when the project requires close cooperation among team members because delays caused by time differences can destroy the "flow" of writing software. At the same time, distributed teams can bring together skill sets that may not be available locally and are great for certain development use cases. Also, there are various best practices to improve cooperation in distributed teams.
### 3\. How much time is needed to groom the backlog?
Because this was an introductory talk targeting students who were new to agile, the speakers focused on [Scrum][2] and [Kanban][3] as ways to make agile specific for them. They used the Scrum framework to illustrate a method of writing software and Kanban for a communication and work planning system. On the question of time needed to groom a project's backlog, the speakers explained that there is no fixed rule. Rather, practice makes perfect: During the early stages of development, when a project is new—and especially if some members of the team are new to agile—grooming can consume several hours per week. Over time and with practice, it becomes more efficient.
### 4\. Is a product owner necessary? What is their role?
Product owners help facilitate scaling; however, what matters is not the job title, but that you have someone on your team who represents the customer's voice and goals. In many teams, especially those that are part of a larger group of engineering teams working on a single output, a lead engineer can serve as the product owner.
### 5\. What agile tools do you suggest using? Is specific software necessary to implement Scrum or Kanban in practice?
Although using proprietary software such as Jira or Trello can be helpful, especially when working with large numbers of contributors working on big enterprise projects, they are not required. Scrum and Kanban can be done with tools as simple as paper cards. The key is to have a clear source of information and strong communication across the entire team. That said, two excellent open source kanban tools are [Taiga][4] and [Wekan][5]. For more information, see [5 open source alternatives to Trello][6] and [Top 7 open source project management tools for agile teams][7].
### 6\. How can students use agile techniques for school projects?
The presenters encouraged students to use kanban to visualize and outline tasks to be completed before the end of the project. The key is to create a common board so the entire team can see the status of the project. By using kanban or a similar high-visibility strategy, students wont get to the end of the project and discover that any particular team member has not been keeping up.
Scrum practices such as sprints and daily standups are also excellent ways to ensure that everyone is making progress and that the various parts of the project will work together at the end. Regular check-ins and information-sharing are also essential. To learn more about Scrum, see [What is scrum?][8].
Remember that Kanban and Scrum are just two of many tools and frameworks that make up agile. They may not be the best approach for every situation.
--------------------------------------------------------------------------------
via: https://opensource.com/article/18/3/agile-mindset
作者:[Dominika Bula][a]
译者:[译者ID](https://github.com/译者ID)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/dominika
[1]:http://zijemeit.cz/sessions/agile-in-practice/
[2]:https://www.scrum.org/resources/what-is-scrum
[3]:https://en.wikipedia.org/wiki/Kanban
[4]:https://taiga.io/
[5]:https://wekan.github.io/
[6]:https://opensource.com/alternatives/trello
[7]:https://opensource.com/article/18/2/agile-project-management-tools
[8]:https://opensource.com/resources/scrum

View File

@ -0,0 +1,59 @@
关于团队敏捷开发实践的6个常见问题
======
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/collab-team-pair-programming-code-keyboard.png?itok=kBeRTFL1)
”有问题么?“
你可能听过演讲者在演讲结束的时候提出这个问题。这是演讲中最重要的部分--毕竟,你不仅仅是听讲座, 而是参加讨论和社群交流。
最近,我有机会听到我的同伴 Red Hatters 给当地一所大学的一群技术型学生做一个名为 “[Agile in Practice][1]” 的讲座。讲座中有软件工程师 Tomas Tomecek 和敏捷开发的从业者 Fernando Colleone 与 Pavel Najman 合作解释敏捷开发方法的基础,并展示最佳实践在日常活动中的应用。
### 1.完美的团队规模是多大?
知道了学生们参加这个课程是为了了解什么是敏捷实践以及如何将其应用于项目,我想知道学生们的问题会与我作为敏捷从业者在 Red Hat 每天听到的问题相比有什么不同。结果学生的疑问和我的同事们如出一辙。这些问题都直指敏捷实践的核心。
学生们想知道一个小团队和一个大团队的规模是多少。这个问题与任何曾经合作过做项目的人都是相关的。根据 Tomas 作为技术领导的经验 12 个人从事的项目被认为是一个大型团队。现实中团队规模通常与生产力没有关系。在有些时候一个小地区或同一个时区的小团队也许会比一个成员分布在满世界的大团队更具有生产力。最终讲座建议理想的团队大小大概是5个人正如 scrum 开发方法的7+-2
### 2\. 团队会面临哪些实际挑战?
演讲者比较了由本地团队组成的项目(团队成员都是一个办公室,或者相邻近的人)与分散型的团队(位于不同时区)。 当项目需要团队成员之间密切合作时,工程师更喜欢本地的团队,因为时间差异造成的延迟可能会破坏软件开发的“流”。同时,分散型团队可以将可能不适用与当地项目但适用于某些开发用例的技能集合在一起。此外,还有各种最佳方法可用于改进分散型团队中的合作方式。
### 3\. 整理堆积的工作需要多少时间?
因为这是一个对于新学习学生的介绍性质的演讲,演讲者关注于用 [Scrum][2] 和 [Kanban][3] 作为介绍敏捷开发的方法。他们使用 Scrum 来作为说明软件编写的方法并且用 Kanban 作为工作规划和沟通的系统。关于需要多少时间来整理项目堆积的工作,演讲者解释说并没有固定的准则,相对的,实践出真知:在开发的早期阶段,当一个崭新的项目—特别如果团队里有新人—每周可能会花费数个小时在整理工作上。随着时间推移和不断地练习,会越来越高效。
### 4\. 产品负责人是否是必要的? 他们扮演什么样的角色?
负责人会帮助团队更方便的拓展,然而,职位并不重要,重要的是你的团队中有人能够传递用户的意愿。在许多团队中,特别是在大型 团队中从事单个任务的团队,首席工程师就可以担任负责人。
### 5\.建议使用哪些敏捷开发的工具?使用 Scrum 或 Kanban 做敏捷开发的时候必须用特定的软件么?
尽管使用一些专业软件例如 Jira 或 Trello 会很有帮助特别是在与大量从事大型企业项目的工作者合作时但它们不是必需的。Scrum 和 Kanban 可以使用像纸卡这样简单的工具完成。关键是在团队中要有一个清晰的信息来源和紧密的交流。也就是说,优秀的两个 kanban 开源工具 [Taiga][4] 和 [Wekan][5] 。更多信息请查看 [5 open source alternatives to Trello][6] 和 [Top 7 open source project management tools for agile teams][7] 。
### 6\. 学生如何在学校项目中使用敏捷开发技术?
演讲者鼓励学生使用 kanban 在项目结束前使用可视化和大纲来完成。关键是要创建一个公共板块,这样整个团队就可以看到项目的状态。通过使用 kanban 或者类似的高可视化策略,学生不会在项目后期才发现个别成员没有跟上进度。
Scrum 实践比如 sprints 和 daily standups 也是确认每个人都在进步的绝佳方法项目的各个部分最终会一起发挥作用。定期检查和信息共享也至关重要。更多关于 Scrum 的信息,访问 [What is scrum?][8] 。
牢记 Kanban 和 Scrum 只是敏捷开发中众多框架和工具中的两个。它们可能不是应对每一种情况的最佳方法。
--------------------------------------------------------------------------------
via: https://opensource.com/article/18/3/agile-mindset
作者:[Dominika Bula][a]
译者:[lixinyuxx](https://github.com/lixinxyuxx)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/dominika
[1]:http://zijemeit.cz/sessions/agile-in-practice/
[2]:https://www.scrum.org/resources/what-is-scrum
[3]:https://en.wikipedia.org/wiki/Kanban
[4]:https://taiga.io/
[5]:https://wekan.github.io/
[6]:https://opensource.com/alternatives/trello
[7]:https://opensource.com/article/18/2/agile-project-management-tools
[8]:https://opensource.com/resources/scrum