🌱 Old notes on process circa 2015?

XP - http://www.extremeprogramming.org/rules/overtime.html

Even if there is only one day left in the iteration it is better to get the entire team re-focused on a single completed task than many incomplete ones

Working overtime sucks the spirit and motivation out of your team. When your team becomes tired and demoralized they will get less work done, not more, no matter how many hours are worked. Becoming over worked today steals development progress from the future. You can’t make realistic plans when your team does more work this month and less next month.

… adding more people is also a bad idea when a project is already late. The contribution made by many new people is usually negative. Instead ramp up your development team slowly well in advance, as soon as you predict a release will be too late.

Communication Guidelines

https://github.com/thoughtbot/guides/tree/master/code-review

  • Accept that many decisions are opinions. Discuss tradeoffs, which you prefer, and reach a resolution quickly.
  • Ask questions; don’t make demands. (“What do you think about…?“)
  • Ask for clarification. (“I didn’t understand. Can you clarify?“)
  • Avoid selective ownership. (“mine”, “not mine”, “yours”)
  • Avoid using terms that could be seen as referring to personal traits. (“dumb”, “stupid”). Assume everyone is attractive, intelligent, and well-meaning.
  • Be explicit. Remember people don’t always understand your intentions online.
  • Be humble. (“I’m not sure - let’s look it up.“)
  • Don’t use hyperbole. (“always”, “never”, “endlessly”, “nothing”)
  • Don’t use sarcasm.
  • Keep it real. If emoji, animated gifs, or humor aren’t you, don’t force them. If they are, use them with aplomb.
  • Talk in person if there are too many “I didn’t understand” or “Alternative solution:” comments. Post a follow-up comment summarizing offline discussion.
  • Be grateful for a reviewer’s suggestions. (“Good call. I’ll make that change.“)
  • Don’t take it personally. The review is of the work, not you.
  • Explain why the something exists. (“It’s like that because of these reasons. Would it be more clear if I did…?“)
  • Seek to understand the reviewer’s perspective.
  • Try to respond to every comment.
  • Understand why a change is necessary (fixes a bug, improves the user experience, refactors the existing code).
  • Communicate which ideas you feel strongly about and those you don’t.
  • Identify ways to simplify while still solving the problem.
  • If discussions turn too philosophical or academic, move the discussion offline. In the meantime, let the author make the final decision on alternative implementations.
  • Offer alternative implementations, but assume the author already considered them. (“What do you think about using…here?“)
  • Seek to understand the author’s perspective.
  • Be explicit when something is approved, finished, or ready for the next steps with a :thumbsup: or “Looks good” comment.

If you disagree with a guideline, open an issue to review the guideline. In the meantime, apply the guideline.

We should use an incremental, fast-paced style of software development to reduce the risk of failure. We want to get working software into users’ hands as early as possible to give the design and development team opportunities to adjust based on user feedback about the service.

process
Made by Brandon . If you find this project useful you can donate.