New Proposed Outline #53
Conversation
|
Retrofitted original outline to sprint loop cycle as originally suggested by @iphilpot in #62. This was just meant to provide example for how some of the original items might fit into this structure. The team was overly in favor of this structure suggested by @iphilpot as it will better lay out the content in narrative format that i had envisioned for the new content. |
There was a problem hiding this comment.
I've added my thoughts on the outline, and would encourage others to do the same as early as possible (before various sections are filled out). If we all agree on various points that should be conveyed in each section (as well as the overall structure) in this outline PR, we'll be set up well for a naturally cohesive agreement on the playbook as a whole once it's fleshed out entirely.
|
@kevinhartman TLDR; I have pushed changes based on the feedback. The lines i removed all basically center around what we intend to recommend for the questions below. I would like to go ahead and work on getting the outline through without these recommendations so we can start adding content.
I am fully aware of your opinion on this. However, the reality is that dates and deadlines apply to most enterprise dev shops. Most are not yet in a position where they have the flexibility to "ship when its done" and base everything on relative estimates. My fear is that if we make the assumption this is what all our consumers either are or should be doing, we immediately alienate some or most of our potential audience. To address this, i think we need to get laser focused on who are intended audience is and then figure out the right recommendation for that audience. Perhaps we need different recommendations for different audience or clarify for what kinds of teams this recommendation works best? |
There was a problem hiding this comment.
I will say overall that I really like the content outlined in the timeline style, from pre-work through "final day of sprint". We likely need to think a bit about where topics that span the entire project lifecycle properly live (maybe I missed it?) but overall this approach will keep the content as grounded, practical, and "reference-able" as possible.
I keep picturing a new lead running through this each AM in advance of the day's activities... "okay, what do I need to do today?" LOL
Obviously not what we want to happen in real life, but I think its an interesting device to keep the content practical.
My only other overarching comment is that I'd like to encourage authors to link to outside sources whenever possible... particularly for things like "unit test guidance for Go/.NET/Python" etc. There's good info in the world and we shouldn't try to write it all from scratch. I suppose there's an argument for distilling "conventional wisdom" down to bite-sized nuggets... that's fine I guess, but I think a light touch there is still warranted.
Overall, great start, well done, and let's start to socialize this more broadly so we can get others on board to use it and contribute! (I will do my part there)
|
Thanks for reviewing @jplane! Definitely noted on trying not to rewrite from scratch. My vision for this content is that which demonstrates our depth/expertise in these technologies/patterns beyond what you find in the typical hello world examples online. Additionally, this content could document general patterns for the things we do on almost every project (i.e. terraform + azure devops for ci/cd infrax). We could then leverage these a guide for learners; for both Microsoft and our partners. Surface-level or beginner guidance (i.e. the 101 guide to unit testing with GO) I would imagine would be a link out to a stable resource as you recommended. |
Why specifically does forcing a story to fit within the extent of a single sprint alleviate concern around firm deadlines? Please explain that.
This sounds like a comment on "velocity" as a metric. I think the part you're missing is that velocity is the key to transforming relative estimates back into concrete time. The velocity should ideally be a constant (that we discover over time for a particular team). We then divide the number of story points by the velocity to get the approximate number of weeks a particular feature will take. To do project planning properly (and finish feature sets before corresponding deadlines), we then prioritize those features to fit. I'm not suggesting that we "finish when we finish", but only that we're honest about how long each and every feature will take to complete. Velocity is a tool that can give us the insight we need to deliver on time with great quality. |
|
Closing this as the work is now being done in a fork |
The following updates contain the new proposed outline for the engineering playbook. The root readme has been updated to include the proposed outline, structure, and example. I have also added new folder structure to represent each of the engineering fundamentals. I have added content template for agile ceremonies section. Lastly, existing articles have also been relocated to appropriate location in new directory structure.
cc @SaraSp