There are three key elements to your release process documents: So you'll want to make sure everyone has access to the latest n' greatest – which is exactly what Confluence was built for. These are the documents that streamline your releases and help build a culture of continuous improvement, and are probably constantly evolving as you adopt new practices to improve your process. The other important set of documentation you'll want to create and store in Confluence is your release process and readiness docs. Just like your onboarding content, you'll want to label all your related architectural docs to keep them organized. Use the table tools menu to add and cut columns and rows, merge, and highlight cells. Tables are easy to insert into your page, and flexible. At Atlassian, we put all this information in tables. These documents can be as heavy or light on information as you need. The most important part of your architectural docs is being able to reference diagrams, components, SDKs, APIs and related docs all in one place. We use these tools as well as for simple relational diagrams that you can attach as images. Both these add-ons give you a diagram editor right within Confluence. There are two great add-ons available in the Atlassian Marketplace that are perfect for this: Gliffy and Draw.io. Use diagramming tools to embed architecture diagrams. Include instructions on logging into critical systems and applications, links to important internal resources like company policies, and tasks for meeting members of the team. The new hire task list or 90 day plan should provide direction and useful resources. You can add tasks to any Confluence page from the editor toolbar: Getting new people current is critical to your dev speed as well as the future success of your team. In short order you'll be a lean, mean documentation machine.Ĭheck out three standard technical docs that your team can create in Confluence: 1. Onboarding documentation Confluence helps solve the paradox by making it easy to create and document your standard technical docs so everyone can access and contribute to them. At the same time, you need good docs to help your team build awesome stuff. Of course, you want to spend your time building awesome products and not writing docs. Second, limit the amount of time your team spends searching for answers to technical problems. Try these two tactics: first, speed up the time it takes to onboard new team members. Since you can't just go out and make clones for your developers (yet.), how do you make your team faster? Successful dev teams need to be able to move fast , without sacrificing code quality. By Terrence Caldwell, published August 31st, 2015
0 kommentar(er)
