Process #89
Comments
|
Firstly: This is amazing <3. Here's some thoughts on the various pages / issues. — Process I love the icebox I am very happy to see “in progress”. Yes it’s self-explanatory, but that way everyone is more aware of what’s going on. — Issues What is an issue? Is it a ticket / piece of work? Often we also use it to catalogue a whole host of information and it’s getting slightly confusing to me. I’ve seen single task / small task tickets. I think issues should have a task with a concrete outcome. If they require further subtasks, one can create those as they are encountered or as they are planned. But they are separate from the information you need in order to get them done. They should link to that information or contain possibly a short paragraph, but that way the information can be rich, expansive, up to date and provide full context, without needing to “fit into an issue”. — Place Which leads me to a place to store this. I personally prefer a wiki rather than anthology. I think if we have a template we stick to in order to record the right information, everything should go in one place. Especially something that can link to everything else, so it’s very easy to see context, see where decisions came from, what the assigned tasks were, who worked on them, and what the outcome ended up being, where and when the code got merged, and so on. PRs, designs, user stories, personas, issues, bug reports, analytics requests all coming together in one system, but each having their “home”. — Personas I know they seem odd, some people even like to call them made up people, but they really help to understand why we do things. I see them as the unit tests of a design. These are people who we are creating the product for, and they should really help to
They would go well with our user stories. — Verifying understanding of design I think one of our goals should also be to be less surprised by the time a ticket lands on our lap. If we include early designs in our weekly standup, so we see how they evolve we have that background knowledge. However, doing a proper run through an almost finalised design is 👍 and definitely something to add. Perhaps we can make this part of our QA period in a sprint? That way design has had the four weeks to prepare the materials for the upcoming sprint. We can review in QA period as mentioned in this section. We can discuss, and they can then be primed for estimation at the beginning of the next sprint? — Estimation I’m down, if anything to determine the velocity so we can get a better grasp of future planning. Eigen will be going through a lot of changes over the next few months, and features will hang together (like onboarding + home screen), so it’d be great to start learning when to expect such epics to be shipped. That way we can notify relevant parties (marketing, copy, visual design for promotion or something, and so forth). I’d love to see a little timeline on the front page of the wiki, so anyone from the company can easily see what’s going on with Eigen and what’s coming up (which should also help avoid the need to clarify what is part of the sprint and what got shipped, like we saw in the product meeting recently). Also, I think every EPIC that’s been assigned to a sprint should have a dev owner (who can ask for help / get others onboard if and when required). — Weekly standup I think it could do with some tie to the overarching goals as well. What’s the progress of the project, how is what we’re doing / designing right now tying back to what we want / need Eigen to be. — Specification I have some thoughts here but am going to defer to Katarina and Brian for now. A selfish request would be that perhaps the text wouldn’t go in the image, so it’s easier to read in one page (rather than zooming in through the image). But this isn’t up to me ^_^. I do want to reiterate as I mentioned to Katarina last week that I think it makes more sense for development to break up a design spec into tasks, as design doesn't necessarily know how we'd approach it (e.g. separate modules like in the Onboarding epic), and that the approach would probably also vary from developer to developer. |
|
Estimation
Issue Classification
Specification
Verifying understanding of design
I think everything I haven't commented on is great! |
Sarah, this observation is 💯 Planning poker would be a great way to mitigate tribal knowledge. @alloy the understanding design page is amazing ✅ I'd add that part of the process should be identifying missing (or ill-defined) user stories. Ultimately, the goal is to give everyone a snapshot of the entire system: in terms of user stories, visual design, and implementation details. That context would be really useful in estimation. |
|
I’ll come back to all your great feedback tomorrow, I just want to clarify a bit more around the use of user-stories. These are stories we (the developers) would write. We do that by sitting down with the person that is responsible for the design and having them give us a walkthrough and us asking questions. Specifically, the right questions, which is where user-stories (as a tool) help out. |
|
Posting my feedback to be discussed tomorrow: Overall response to this is 👍 👍 👍 My takeaway is that there are two major goals here: 1. Provide more context for why we have conceived a particular feature in a certain way and 2. Have more clarity on what needs to be done to implement a certain feature. To address these two things, I think at a high level our process could look something like this...(some of this we already do)
I'm hopeful that these couple of steps will bring us closer to giving more context to our work without introducing too many new processes to how we work today. |
|
I am a fan of engineers being @-ed in wake ^_^ (seeing as it's a process the design team already uses and works for them). |
I’ve done a bit more describing on that in https://github.com/artsy/mobile/wiki/Issues.
I think all information that the engineers collect in order to get a designed feature implemented should go into Issues, at the right level as defined in https://github.com/artsy/mobile/wiki/Issues. I don’t want to have to jump to too many external tools when quickly jumping through issues from e.g. the ZenHub board. On-going design work will be in Wake, after the design walkthrough we will tell the designer in what form we want the feature design to be split up and spec’ed, which then, as said above, I think should go into Issues. The anthology suggestion was only meant as a tool to use while writing down user-stories, not to keep them there. (I can no longer write human-readable text by hand, nor am I fast enough at it 😉)
I don’t think we need a whole lot of that, it should be really clear by now that Eigen is going to focus on collectors. There is definitely a lot of room for improvement/expansion/addition of role definitions on https://github.com/artsy/mobile/wiki/Specification, though.
Good idea https://github.com/artsy/mobile/wiki/Meetings#feature-estimation
Added 👍
I’m not sure. It’s something that needs to be kept in-sync (i.e. I worry about it going stale) and I’m not sure others in the company would really use it, they probably prefer to get their info from the product meetings, which is where @katarinabatina includes such information. For us, getting an up-to-date overview of the queue is a matter of looking at the ‘Backlog’ pipeline of our ZenHub board and filtering by ‘EPIC’.
That should just be taken from the CHANGELOG. /cc @katarinabatina
We’ll have a GMV team meeting and a separate mobile engineering standup: https://github.com/artsy/mobile/wiki/Meetings#gmv-ios-weekly
The definition of what issues should look like and how design should be split up and spec]ed is up to you |
I’ve tried to describe it a bit more in https://github.com/artsy/mobile/wiki/Issues#types, but it might still not be fully clear. In which case I invite you to do a 15 minutes of research into the topic and add a summary that helps you to that wiki.
It won’t be, the stories will be something that we write during the design walkthrough, based on our understanding of the design. https://github.com/artsy/mobile/wiki/Meetings#feature-design-walkthrough, https://github.com/artsy/mobile/wiki/Specification
👍 I’ve added a note to https://github.com/artsy/mobile/wiki/Verifying-understanding-of-design that explains this a bit more. |
Mind adding that to the wiki page? That page is still very rough. |
|
@katarinabatina I have changed the standup page to be about all types of meetings and have now made a distinction between team concerns and engineering banter https://github.com/artsy/mobile/wiki/Meetings. I also added a very rough draft of how your side of the process looks like, it would be great if you could give that a look over and better describe it https://github.com/artsy/mobile/wiki/Design-Process |
I have created several pages on our wiki that describes an initial draft of how I think we should think of our process: https://github.com/artsy/mobile/wiki
I’d like you all to read through all of those pages and provide feedback about what you think should be different and how it should be different.
Some specific things:
Should we change our weekly standup to be on Monday morning? And if so, how late?
@katarinabatina / @briansw How feasible is it for you to start writing down design decisions as user stories as you create the design? https://github.com/artsy/mobile/wiki/Specification
If an automated tool is needed, we can at some point look at Anthology again. Possibly make it possible to export an overview of stories as markdown, which makes it easy to move them to an EPIC ticket.
@ashfurrow and @mennenia I’d like your feedback on what does and does not work with the process described in: https://github.com/artsy/mobile/wiki/Verifying-understanding-of-design
The text was updated successfully, but these errors were encountered: