launchpad development|
Size: 4137
Comment:
|
Size: 9707
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| Slogan for public consumption: '''''Go go Yellow Jackets!''''' | Slogan for public consumption: '''''Go go Golden Horde!''''' |
| Line 7: | Line 7: |
| Slogan when we feel tired: '''''Go go Yellow Banana Slugs!''''' | Slogan when we feel tired: '''''Go go [[http://en.wikipedia.org/wiki/File:Banana_slug_closeup.jpg|Yellow Banana Slugs]]!''''' |
| Line 9: | Line 9: |
| Current project is [[LEP/BetterBugSubscriptionsAndNotifications]] . | Current projects are [[LEP/ParallelTesting]] and [[LEP/LaunchpadSetupScripts]]. |
| Line 11: | Line 11: |
| Also see UI work at [[yellow/Subscriptions]] . | |
| Line 13: | Line 12: |
| == Next Deliverables == | <<Anchor(daily-call-checklist)>> == Daily call checklist == |
| Line 15: | Line 15: |
| Due 2011-01-28 | Move quickly if possible. :-) |
| Line 17: | Line 17: |
| * Gary: * Updated LEP, with definition of success/completion approved by Jono. * Iterative user testing plan, after discussion with Matthew and Jono. * Report on status of YUI upgrade plan from RobertCollins. * Report on reply from Jono/Robert on scheduling SMM or similar sooner. |
First part: Where are we right now? We move over the kanban board roughly right to left. |
| Line 23: | Line 19: |
| * Brad and Benji: * Establish new testing feature flag that is granted to team:yellow * Replace non-js subscribe link with JS subscribe link. * Have the link pop up an accordion widget, on production. * Next task: Make the widget behave the way we want. * Danilo and Gary: * Filters and subscribers should be joined: demonstrate that the current filter page is gone. * Show that events are now integrated as one of the filters available on structural subscriptions. * Next task: One person takes mail unsubscribe story with Graham; other person joins Brad and Benji on JS/Webservice work. * Graham: * Make bug notification work through the API (in review) * Demo the widget for direct subscriptions, on production. Announce to malone-alpha team (with warning that it might or might not change significantly soon). * Next task: Mail unsubscribe story, with Gary and/or Danilo. |
* Review Done Done cards. For each card... * congratulate * ask the people if collaboration information is recorded correctly on the card. * ask the people who implemented it one or two questions about the implementation experience (e.g., what was the toughest part of getting this card done? how did you solve [that thing I heard about]? did something really work just as you'd hoped when you implemented this card?) Try to keep discussion to no more than a minute or two; move the card to "Weekly review" if there's more to say. * ask the people who implemented it if there is anything we should know about it (e.g., it changes how we do something, it unblocks some cards, etc.) * If it represents a problem, and in particular if it took more than 24 hours in an active lane, move the card to "Weekly review" for us to talk about on Friday. * Otherwise, move the card to "Archive". * Review cards in deployment and QA. Have any of them been in the same place for more than 24 hours? If so, problem solve (e.g., ask for details, ask if collaboration would help, and ask if anything else would help). * Review cards in slack. * Have any of them been active for more than 24 hours? If so, suggest dividing them up. * Are any of them new? If so and pertinent, have we determined who the maintainer will be (Launchpad, yellow, or personal) and started down the proper design path? * Review Active cards in "Multi-branch work" * Have any of them been in the same lane for more than 24 hours? If so, problem solve. If the developers are stuck, consider "convening a panel" * Have any of them been in the same lane for more than 48 hours? If so, strongly encourage collaboration. Pull people off other active cards if necessary. * Review Miscellaneous Done cards. Ask for comments. Afterwards, move all to "Archive," or to "Weekly review" for discussion. * Review Miscellaneous Active cards. Ask for comments. If non-recurring card is sitting for longer than 24 hours, problem solve. * Do any non-done cards on the board have deadlines? If so, review as necessary. * Review all blocked cards everywhere. Are any of them unblocked? Do we need to take action to unblock any of them? * [experimental] Make sure that, if anyone collaborated or communicated externally (according to [[http://codesinger.blogspot.com/2012/07/yellow-squad-weekly-topics-july-6.html|our definitions]]) since the last time we talked, you "entered into the webapp" (sent an email to Gary about it). |
| Line 37: | Line 39: |
| == Problem Solving == | Second part: what are we going to do? |
| Line 39: | Line 41: |
| === 2011-01-21 === | * Review cards waiting to be done. * Do we have any critical cards? * How are we doing on our weekly (high) cards? * Does it at least look like we have cards ready to be started? * Circle around the team. For each person... * Encourage but do not require each person to mention what card they plan to work on for the next 24 hours * Ask the person to mention any items that everyone should know: remind people of reduced availability, request help such as code reviews or pair requests, etc. |
| Line 41: | Line 49: |
| * Landing issues slowing us down. Solution: no short term solution identified. Ask Jono/Robert that SMM or similar be scheduled earlier. * JS painful; example we found was bad. Solution: Ask for early review from Deryck. Rejected solution: ask Deryck for a "blessed" example. * YUI upgrades are painful. Going from dot releases (e.g., 3.2 to 3.3) is a cost like switching major Python releases (e.g., 2.6 to 2.7). Solution: ask RobertCollins to be on top of YUI upgrades like Python upgrades, and to schedule upgrades with significant warning and full knowledge of the cost. * How do we get ongoing stakeholder guidance in an efficient way? * Francis suggests that we use UI testing of the full interface as a way to also get initial stakeholder approval. He feels user testing will frame the conversation productively to encourage direction of our plans rather than bikeshedding. Benji warns that users may not understand that other features they are not tested on will not be present. * Benji wonders (without necessarily advocating) if Elliot might say "build it and people will like it." Gary feels we've tried that before (i.e., without sufficient stakeholder approval) and failed. * Benji suggests that we ought to have a single stakeholder representative. Gary feels that we've seen before that this is insufficient and historically problematic. * We collectively wonder what Jono's approval of the UI and the definition of "done" means in this regard. Is it Jono's responsibility to be the developers' only interface to the stakeholders now? * We talk about whether UI mockups or prototypes or incremental deliveries would be more valuable for getting input. UI mockups are cheaper than development, but incremental deliveries are more efficient if they are on the right track. Gary feels an ideal answer is finding a cheap way of getting ''just enough'' of a stakeholder blessing of a UI, and then using incremental deliveries to steer the rest of the way. Time-boxed mockups, developed iteratively ideally, combined with iterative delivery. * Next task for pursuing solution: Gary needs to contact Matthew (and Jono and/or Francis?) and see how user testing might work and what we need to provide. We do not yet have all parts of the user interface mocked up. We'd like to see if we can find an approved way to do iterative user testing--several tests instead of one big one. Can we make it cheaper/easier? |
=== Panel requests === <<Anchor(unsticking-panel-checklist)>> == Unsticking panel checklist == * Take note of when the panel starts / set an alarm for T+20. * Describe problem avoiding mentioning your own (stuck) solutions and ask for solutions and approaches. * If that fails, describe your own solution and ask for solutions and ideas. * If the panel has taken longer than 20 minutes, stop. Arrange for a pair programming or consultation as necessary. * If no-one has said anything other than filler for three minutes, stop. Arrange for a pair programming or consultation as necessary. Consider rotation. <<Anchor(pair-programmer-observer-checklist)>> == Pair programming observer checklist == * Be actively skeptical. * Watch the other person's back. * Be a planner: actively propose plans to tackle problems * Offer to be a "navigator," keeping the destination in mind while the "driver" handles the details. * When something doesn't make sense, this is a trigger for both parties to check assumptions and step back. <<Anchor(weekly-review-call-checklist)>> == Weekly review call checklist == * Briefly review where we are in project plan. * Review [[#topics-for-next-weekly-review-call|"topics for next"]], below * Any new tricks learned? * Collaboration tricks? * Debugging tricks? * Communication tricks? * Checklists? Processes? * Any nice successes? * Can you attribute your success to anything beyond the innate brilliance of yourself and your coworkers? * Any pain experienced? * Prompts to ask people about: * (benji/gary) get subcommand * Questions to ask: * Are there any cards that are/were taking too long to move? * Are they blocked? * Are we spinning our wheels? * How long is too long? * Are we not delivering value incrementally? * Are we not collaborating? * Did we duplicate any work? * Did we have to redo any work? * Did we misunderstand the technical requirements, the goal, or a process? * Was the ordering of tasks that we chose broken? * Can we learn from it? * Checklist? * Experiment? * Another process change? * Other topics * Weekly feedback loop for collaboration? <<Anchor(topics-for-next-weekly-review-call)>> === Topics for next === == Writing a LEP checklist == * Describe the idea to one or more people in the squad to vet and refine it. * Write up the LEP. * Get at least one person in the squad to review it, ''especially if you are tired of it'' :-) . * Announce the LEP for broader review. <<Anchor(starting-a-project-checklist)>> == Starting a project checklist == * Prototype (no tests). Consider competing prototypes. * Have a squad discussion about lessons learned and design decisions. * Review CreatingNewProjects to get everything started properly. Also see [[https://docs.google.com/a/canonical.com/document/d/1A8qTOYZd7p9dhjmlnnEKW46h38ydt9yNbmfgX3yhPGw/edit|jml's document]] for further ideas on what to add to this checklist. * Begin coding with TDD. <<Anchor(depending-on-another-developer-or-team-checklist)>> == Depending on another developer or team checklist--someone new or with past delivery problems == * Doublecheck whether you can't do it yourself somehow, or get someone with proven cross-team delivery ability. * Are you depending on a person or a team? If it is a person, consider trying to escalate it to the manager, to make it a team goal, or at least something with team visibility and managerial approval and encouragement. * If they need something from you, ask what format they want it in in order to be able to process your request as quickly as possible. * A corollary to the previous one: make sure that you are making the smallest request necessary and reasonable. * While it is tempting, and sometimes necessary, to be flexible for interacting with busy people, if the work is worth doing, the sooner it is done, the more value you get from it. The longer you wait, the more likely it is that you will get no value from it. This is "lean" for our squad, and also for the company. Try to communicate this. * Request a delivery date guess. Consider requesting that a call be scheduled on that date, either for handover or for reassessment. If there is a deadline for us, also bring this to the attention of the Launchpad manager (flacoste). * If the delivery doesn't happen on the expected date, (on the scheduled call) ask for three things: a revised delivery date, another associated call, and a fallback plan. The fallback plan should be some reasonable remediation if the second delivery date fails. Also bring this to flacoste's attention, and discuss with him whether official escalation is appropriate. jml also pointed out this checklist from Covey's ''Seven Habits...''. You need to establish these things up-front: 1. Desired results [spend time here, include "when"] 2. Guidelines [what I'd call constraints] 3. Resources available [money, team, people] 4. Accountability [what measures, how often] 5. Consequences [natural ones & incentives] We should also try to incorporate these ideas. <<Anchor(slack-project-checklist)>> == Slack project checklist == * The project should further Canonical in some aspect. Examples include making yourself a more valuable employee to Canonical (i.e., studying a technology that is important to the company), improving processes or tools for our squad or team, or building or improving something for another part of Canonical. * Consider who you expect to maintain the project. * Yourself: Be skeptical of this, but if so, that's fine. * Our squad: discuss design with squad, and/or follow the prototype -> discuss -> code pattern we have for new projects * Our team: make a LEP, consult with team lead (flacoste), and get acceptance from TA (lifeless) and/or any other stakeholders identified * Make a card for the task or tasks in the kanban board. |
Yellow Squad Wiki Home
https://launchpad.net/~yellow/+mugshots
Slogan for public consumption: Go go Golden Horde!
Slogan when we feel tired: Go go Yellow Banana Slugs!
Current projects are LEP/ParallelTesting and LEP/LaunchpadSetupScripts.
Daily call checklist
Move quickly if possible. 
First part: Where are we right now? We move over the kanban board roughly right to left.
- Review Done Done cards. For each card...
- congratulate
- ask the people if collaboration information is recorded correctly on the card.
- ask the people who implemented it one or two questions about the implementation experience (e.g., what was the toughest part of getting this card done? how did you solve [that thing I heard about]? did something really work just as you'd hoped when you implemented this card?) Try to keep discussion to no more than a minute or two; move the card to "Weekly review" if there's more to say.
- ask the people who implemented it if there is anything we should know about it (e.g., it changes how we do something, it unblocks some cards, etc.)
- If it represents a problem, and in particular if it took more than 24 hours in an active lane, move the card to "Weekly review" for us to talk about on Friday.
- Otherwise, move the card to "Archive".
- Review cards in deployment and QA. Have any of them been in the same place for more than 24 hours? If so, problem solve (e.g., ask for details, ask if collaboration would help, and ask if anything else would help).
- Review cards in slack.
- Have any of them been active for more than 24 hours? If so, suggest dividing them up.
- Are any of them new? If so and pertinent, have we determined who the maintainer will be (Launchpad, yellow, or personal) and started down the proper design path?
- Review Active cards in "Multi-branch work"
- Have any of them been in the same lane for more than 24 hours? If so, problem solve. If the developers are stuck, consider "convening a panel"
- Have any of them been in the same lane for more than 48 hours? If so, strongly encourage collaboration. Pull people off other active cards if necessary.
- Review Miscellaneous Done cards. Ask for comments. Afterwards, move all to "Archive," or to "Weekly review" for discussion.
- Review Miscellaneous Active cards. Ask for comments. If non-recurring card is sitting for longer than 24 hours, problem solve.
- Do any non-done cards on the board have deadlines? If so, review as necessary.
- Review all blocked cards everywhere. Are any of them unblocked? Do we need to take action to unblock any of them?
[experimental] Make sure that, if anyone collaborated or communicated externally (according to our definitions) since the last time we talked, you "entered into the webapp" (sent an email to Gary about it).
Second part: what are we going to do?
- Review cards waiting to be done.
- Do we have any critical cards?
- How are we doing on our weekly (high) cards?
- Does it at least look like we have cards ready to be started?
- Circle around the team. For each person...
- Encourage but do not require each person to mention what card they plan to work on for the next 24 hours
- Ask the person to mention any items that everyone should know: remind people of reduced availability, request help such as code reviews or pair requests, etc.
Panel requests
Unsticking panel checklist
- Take note of when the panel starts / set an alarm for T+20.
- Describe problem avoiding mentioning your own (stuck) solutions and ask for solutions and approaches.
- If that fails, describe your own solution and ask for solutions and ideas.
- If the panel has taken longer than 20 minutes, stop. Arrange for a pair programming or consultation as necessary.
- If no-one has said anything other than filler for three minutes, stop. Arrange for a pair programming or consultation as necessary. Consider rotation.
Pair programming observer checklist
- Be actively skeptical.
- Watch the other person's back.
- Be a planner: actively propose plans to tackle problems
- Offer to be a "navigator," keeping the destination in mind while the "driver" handles the details.
- When something doesn't make sense, this is a trigger for both parties to check assumptions and step back.
Weekly review call checklist
- Briefly review where we are in project plan.
Review "topics for next", below
- Any new tricks learned?
- Collaboration tricks?
- Debugging tricks?
- Communication tricks?
- Checklists? Processes?
- Any nice successes?
- Can you attribute your success to anything beyond the innate brilliance of yourself and your coworkers?
- Any pain experienced?
- Prompts to ask people about:
- (benji/gary) get subcommand
- Questions to ask:
- Are there any cards that are/were taking too long to move?
- Are they blocked?
- Are we spinning our wheels?
- How long is too long?
- Are we not delivering value incrementally?
- Are we not collaborating?
- Did we duplicate any work?
- Did we have to redo any work?
- Did we misunderstand the technical requirements, the goal, or a process?
- Was the ordering of tasks that we chose broken?
- Are there any cards that are/were taking too long to move?
- Can we learn from it?
- Checklist?
- Experiment?
- Another process change?
- Prompts to ask people about:
- Other topics
- Weekly feedback loop for collaboration?
Topics for next
Writing a LEP checklist
- Describe the idea to one or more people in the squad to vet and refine it.
- Write up the LEP.
Get at least one person in the squad to review it, especially if you are tired of it
. - Announce the LEP for broader review.
Starting a project checklist
- Prototype (no tests). Consider competing prototypes.
- Have a squad discussion about lessons learned and design decisions.
Review CreatingNewProjects to get everything started properly. Also see jml's document for further ideas on what to add to this checklist.
- Begin coding with TDD.
Depending on another developer or team checklist--someone new or with past delivery problems
- Doublecheck whether you can't do it yourself somehow, or get someone with proven cross-team delivery ability.
- Are you depending on a person or a team? If it is a person, consider trying to escalate it to the manager, to make it a team goal, or at least something with team visibility and managerial approval and encouragement.
- If they need something from you, ask what format they want it in in order to be able to process your request as quickly as possible.
- A corollary to the previous one: make sure that you are making the smallest request necessary and reasonable.
- While it is tempting, and sometimes necessary, to be flexible for interacting with busy people, if the work is worth doing, the sooner it is done, the more value you get from it. The longer you wait, the more likely it is that you will get no value from it. This is "lean" for our squad, and also for the company. Try to communicate this.
- Request a delivery date guess. Consider requesting that a call be scheduled on that date, either for handover or for reassessment. If there is a deadline for us, also bring this to the attention of the Launchpad manager (flacoste).
- If the delivery doesn't happen on the expected date, (on the scheduled call) ask for three things: a revised delivery date, another associated call, and a fallback plan. The fallback plan should be some reasonable remediation if the second delivery date fails. Also bring this to flacoste's attention, and discuss with him whether official escalation is appropriate.
jml also pointed out this checklist from Covey's Seven Habits.... You need to establish these things up-front:
- Desired results [spend time here, include "when"]
- Guidelines [what I'd call constraints]
- Resources available [money, team, people]
- Accountability [what measures, how often]
Consequences [natural ones & incentives]
We should also try to incorporate these ideas.
Slack project checklist
- The project should further Canonical in some aspect. Examples include making yourself a more valuable employee to Canonical (i.e., studying a technology that is important to the company), improving processes or tools for our squad or team, or building or improving something for another part of Canonical.
- Consider who you expect to maintain the project.
- Yourself: Be skeptical of this, but if so, that's fine.
Our squad: discuss design with squad, and/or follow the prototype -> discuss -> code pattern we have for new projects
- Our team: make a LEP, consult with team lead (flacoste), and get acceptance from TA (lifeless) and/or any other stakeholders identified
- Make a card for the task or tasks in the kanban board.
