diff options
| -rw-r--r-- | spm-slides.tex | 455 |
1 files changed, 383 insertions, 72 deletions
diff --git a/spm-slides.tex b/spm-slides.tex index 3152186..d557119 100644 --- a/spm-slides.tex +++ b/spm-slides.tex @@ -482,6 +482,60 @@ Reasons; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Use Branches to Avoid Bottlenecks} + +Branches are valuable because they turn a scarce resource — working room in the project's code — into an abundant one. + +Branches are cheap to make. + +Copy the castle and add a drawbridge in isolation. + +Make Pull Requests, ask for review, and merge (when all reviewers are happy). + +Isolate and stabalise the release line to the development line. + +Use branches liberally. + +Most branches should merge their changes back into the main line and disappear, as soon as possible. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Pull Requests} + +A \underline{pull request} is a request from a contributor to the +project that a certain change be "pulled" (merged) into the project. + +Once a contribution arrives, it typically goes through a +\underline{review-and-revise} process, involving communication between +the contributor and various members of the project. + +The moment when a code change is merged to the project's master branch +is when it becomes officially part of the project. + +99.9\% of contribution to the project should go through the {\em Pull Request - Review - Revise - Merge process}. + +``\href{https://ben.balter.com/2014/11/06/rules-of-communicating-at-github/}{There’s only one way to change something}'', Pull Request. + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Essential Git Commands} + +git branch + +git checkout -b FIX-README + +git add . + +git commit -m "README.md: Why, What, How?" + +git pull origin master + +git push origin FIX-README + +git checkout FIX-README + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Refactoring Old Code and Building Upon It} @@ -582,6 +636,26 @@ Bad management: \href{https://www.joelonsoftware.com/2006/08/09/the-econ-101-man In the Zone. + +A good manager is a good listener. + +A good manager is involved. + +A good manager participates himself. + +A good manager cares about the quality of the project. + +A good manager never rewards unsatisfactory behavior. + +A good manager is a role model. + + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Micromanagement} +TBD. + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Customers} @@ -602,6 +676,8 @@ Psychology: making people feel better. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Testers} +{\bf Any big program has bugs}. + QA department. Testers are your software's first users. @@ -672,6 +748,12 @@ Get into ``{\bf the zone}''. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Morale} + +TBD. + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Software demo} Software demo is a marketing effort for ``\href{https://www.joelonsoftware.com/2002/02/13/the-iceberg-secret-revealed/}{speculative}'' software. @@ -854,26 +936,29 @@ Customer acquisition. %% %% %{\tiny https://lumos-hello.readthedocs-hosted.com/en/latest/} -%% %% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -%% %% \foilhead{The process} +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{The process} -%% %% Use new and existing processes to move a project forward to success. +Use new and existing processes to move a project forward to success. -%% %% Waterfall +Waterfall -%% %% \begin{center} -%% %% \includegraphics[width=0.80\textwidth]{fig/waterfall_marsic} -%% %% \end{center} +\begin{center} +\includegraphics[width=0.80\textwidth]{fig/waterfall_marsic} +\end{center} -%% %% Prototyping +Prototyping -%% %% The spiral model (Boehm) +The spiral model (Boehm) -%% %% Agile (popular nowadays) +Agile (popular nowadays) + +\begin{center} +\includegraphics[width=0.80\textwidth]{fig/ExtremeProgramming} +\end{center} + +Scrum (seems really widely used nowadays). -%% %% \begin{center} -%% %% \includegraphics[width=0.80\textwidth]{fig/ExtremeProgramming} -%% %% \end{center} %% %% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% %% \foilhead{The project} @@ -1071,6 +1156,8 @@ Write a mission statement, a README. Rearrange the code tree so that it conform Code tree: src/, bin/, lib/, etc/, include/, test/, share/, data/, example/, doc/, README, LICENSE, COPYING, MANUAL, TUTORIAL, FAQ, ... +\href{https://github.com/github/choosealicense.com}{Choose a license}. + Drudgery and no immediate benefit. @@ -1121,6 +1208,9 @@ Provide the basics that can help newcomers to overcome initial obstacle of unfam You should make efforts to lower this energy threshold. +\underline{Friction}: energy that a potential contributor needs to become a real contributor. +% https://ben.balter.com/2013/08/11/friction/ + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Starting a New Project} @@ -1280,7 +1370,7 @@ Oracle DB (1977). Microsoft Word 1.0 (1983). All selling billions of dollars y QQ (1998). -{\underline Lessons:} (i) it takes many years before your software is good enough and serious enough for people to buy it. The Overhype syndrome. (ii) No time to add many wanted features to 1.0 in a short period of time. The Get Big Fast syndrome. (iii) When it is done, it is {\em done}. Additional features are not essential. (iv) ``We’ll Ship It When It’s Ready'' syndrome. +\underline{Lessons}: (i) it takes many years before your software is good enough and serious enough for people to buy it. The Overhype syndrome. (ii) No time to add many wanted features to 1.0 in a short period of time. The Get Big Fast syndrome. (iii) When it is done, it is {\em done}. Additional features are not essential. (iv) ``We’ll Ship It When It’s Ready'' syndrome. Keep 1.0 quiet. @@ -1294,12 +1384,12 @@ Otherwise, someone visits a web site, downloads the software, tries to build it, {\bf Version control and bug tracker access}. -You need a version control repository (e.g., a repo at github, a repo at savannah, a repo on your own server). +You need a version control repository (e.g., a repo at GitHub, a repo at savannah, a repo on your own server). \begin{itemize} -\item Create an account at github. New an empty repo there. +\item Create an account at GitHub. New an empty repo there. \item Clone that empty repo to your local machine. \\ - \texttt{git clone https://github.com/accountname/reponame.git}. + \texttt{git clone https://github.com/account/repo.git}. \item Inside Git Bash, change directory to that local repo. \item After you have added files into that repo, issue the following commands, \texttt{git add .}, \texttt{git commit -m 'message'}, \texttt{git push origin}. \end{itemize} @@ -1308,7 +1398,9 @@ You need a version control repository (e.g., a repo at github, a repo at savanna We also need a bug tracker (visible from the homepage of the project). -For example, Bugzilla. Anyone tried \href{http://www.fogbugz.com/}{FogBugz}? +For example, Bugzilla (started in 1998). + +Anyone tried \href{http://www.fogbugz.com/}{FogBugz}? The {\em higher} the number of bugs in the database, the {\em better} the project looks. @@ -1369,7 +1461,9 @@ index 84e3f68..fd54c16 100644 {\bf Communications channels}. -IRC is good. Try \href{http://lanlab.org/course/2020s/spm/irc-instruction.txt}{IRC}. +IRC is good. + +Try \href{http://lanlab.org/course/2020s/spm/irc-instruction.txt}{IRC}. However, it turns out that IRC in China is not at all popular. Everyone uses QQ or WeChat, intermixing their work with their life. @@ -1563,12 +1657,61 @@ Forget about it and move on. It it OK if someone thinks that a code of conduct is not necessary. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Write Everything Down} + +Writing is great. + +``Reading text is better communication than having meetings.'' -- Zach Holman. + +In a distributed work environment, writing everything down is crucial for effective communication. + +Why? + +People cannot see your face, hear your sound, or read your gesture when you are not not in the same place. + +No problem. We could write. + +Writing is so powerful that we are still able to read people's thoughts after they are dead for centuries. + +For example, books written in 1810, 1859, etc. + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{More Comments than Code} + +Not only code comments. + +But also Pull Request Comments. +% https://ben.balter.com/2017/05/23/seven-ways-to-consistently-ship-great-features/ + + + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Code review} -Do commit review, code review regularly. +Commit review. + +{\em Peer review} in the open source world. -Look at other people's code {\em changes} as they arrive. +Benefits: + +\begin{itemize} +\item Fostering a productive development community. +\item Improving software quality. Catch bugs before they slip in. +\end{itemize} + + +Review other people's {\em fresh} code. + +Let other people review your {\em fresh} code. + +Review means making some timely comments. Ask stupid questions, and ask many. + +Do this regularly. + +Don't do this after six months. Look for bugs and areas of possible improvement. Thing we could catch: memory leaks, off-by-one errors, insufficient comments, @@ -1588,7 +1731,11 @@ Example of insufficient comments: {\bf Important} to have more eyeballs. -This is {\em peer review} in the open source world. +Given enough eyeballs, all bugs are shallow. + +Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. -- Eric Steven Raymond, \href{http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/}{The Cathedral and the Bazaar} + +Look at other people's code {\em changes as they arrive}. Why do we focus on reviewing recent changes? @@ -1602,7 +1749,7 @@ Result - better software quality. The review should be public, so that other people can see it and know that a review has happened, and is expected. -Commit notifications are useful. +Commit Notifications are useful. {\tiny \begin{verbatim} @@ -1657,13 +1804,16 @@ Fix issue, No subject is chosen when uploading \end{verbatim} } -A valuable way to spend time. One could contribute as much to the -project by reviewing others' changes as by writing new code. +A valuable way to spend time. + +One could contribute as much to the project by reviewing others' +changes as by writing new code. Case study. Greg Stein reviewed every line of every single commit that went into the code repository, and never complained about being the single reviewer. + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Technical debt} @@ -1673,10 +1823,32 @@ Like financial debt. It is a debt, and you need to pay it off in the future (wi High technical debt would make the software not maintainable. -FIXME. - https://www.agilealliance.org/introduction-to-the-technical-debt-concept/ + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{FIXME} + +It is a good practice to insert the tag \texttt{FIXME} in your code that needs further attention. + +Why? Easy to grep and easy to search. + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{README} + + +Use this file to convey Why, What and How. + +Treat this file as the project's constitution. + +Use this file to avoid feature creep. + +%https://ben.balter.com/2017/04/14/your-projects-readme-is-your-project-constitution/ +%https://opensource.guide/building-community/#treat-your-README-as-a-constitution + + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Be open from day one} @@ -1721,6 +1893,7 @@ Your daily work is visible to the public. Compatible with being open source. \underline{Your source code is open, but your time is not open.} +Pace of engagement. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Opening a formerly closed project} @@ -1736,34 +1909,43 @@ site-specific configuration information). Solutions: use open-source libraries, start from \underline{``top-skim''} version. -Managerial issues (1) make sure everyone in the team understand that a BIG change is coming. (2) make sure that you understand how it's going to feel from their point of view. +Managerial issues (1) make sure everyone in the team understand that a BIG change is coming. (2) make sure that you understand how it's going to feel from their point of view. Put yourself in their shoes. -- Expose code to strangers. What if someone points out flaws in the code publicly. +- Embarrassment. Expose code to strangers. What if someone points out flaws in the code publicly. -- Strangers don't know the developers so they can make {\bf bold} comments. Criticisms. +- Criticisms. Strangers don't know the developers so they can make {\bf bold} comments. But you cannot criticise them (faceless entities). - Strangers are not aware of business pressures forced on the developers. -- Lots of questions from strangers suggest inadequate documentation. Burden of external communications. +- Lots of questions from strangers suggest inadequate documentation. + +- Burden of external communications. + +Solution: + +- Don't worry. + +- The above discomfort is perfectly normal. + +- Will get better. -Solution: Don't worry. The above discomfort is perfectly normal. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Announcing} Show your \underline{presentable} work to the world. -Put the announcement on the Project Homepage. +Put the announcement on the project home page. Post the announcement in the appropriate forums. One post per forum. General forum: https://news.ycombinator.com/ -https://www.reddit.com/r/ subdirectories: opensource, programming, software. Topic-specific forums: mailing lists. +https://www.reddit.com/r/ subdirectories: opensource, programming, software. -https://freshcode.club/ +Topic-specific forums: mailing lists, web forums. -http://openhub.net/ +Register at: \href{https://freshcode.club/}{fresh(code)}, \href{http://openhub.net/}{Black Duck Open Hub}. Make sure your announcement contain keywords that would help search engines find your project. @@ -1804,25 +1986,28 @@ Your announcement should be short and to the point. Running code provides the best foundation for success. -Without running code? It may also work. Subversion (a design document, core developers), Mozilla. But there has to be something {\bf concrete/tangible} than just good intentions. +Without running code? It may also work. Subversion (a design document, core developers). But there has to be something {\bf concrete/tangible} than just good intentions. You can announce after you made the project open-source. What you should expect: -- No big impact. +- {\bf No big impact}. Keep 1.0 quiet. - Some casual inquires. - A few more people in your mailing list. -Announcing is Seeding. +Announcing is seeding. -Form exponential communications networks. From project to community. +Form exponential communications networks. + +Project $\rightarrow$ Community. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Why open source?} +% https://ben.balter.com/2015/11/23/why-open-source/ How does it compare to open access. Paywall. Europe’s open-access drive escalates as university stand-offs spread. A key driver behind the activity in Europe is the European Commission’s goal that, by 2020, all research will be freely accessible as soon as it is published. @@ -1868,7 +2053,9 @@ Disadvantages: limited customisation, no fine-grained control. If you are not sure you can do better, just use \underline{canned hosting}. -GitHub - https://github.com +GitHub - https://github.com \href{https://ben.balter.com/2014/11/06/rules-of-communicating-at-github/}{15 rules for communicating at GitHub} + +Pull Request, line-by-line commenting. Mailing lists: @@ -2013,6 +2200,7 @@ revert - undo an already-committed change to the software. \foilhead{Choosing a version control system} Git and Github. +% https://ben.balter.com/2014/11/06/rules-of-communicating-at-github/ https://www.mercurial-scm.org @@ -2040,35 +2228,6 @@ Browsability is important because it is a lightweight portal to project data. Browsability also implies canonical URLs for viewing a particular change. -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\foilhead{Use branches to avoid bottlenecks} - -Branches are valuable because they turn a scarce resource — working room in the project's code — into an abundant one. - -Copy the castle and add a drawbridge in isolation. - -Pull requests and merge. - -Isolate and stabalise the release line to the development line. - -Use branches liberally. - -Most branches should merge their changes back into the main line and disappear, as soon as possible. - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\foilhead{Pull requests} - -A \underline{pull request} is a request from a contributor to the -project that a certain change be "pulled" into the project. - -Once a contribution arrives, it typically goes through a -\underline{review-and-revise} process, involving communication between -the contributor and various members of the project. - -The moment when a code change is merged to the project's master branch -is when it becomes officially part of the project. - - % Skipped: Singularity of Information % Skipped: Authorization %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -2093,6 +2252,9 @@ The tracker is as much a public face of the project as the repository, mailing l Other names: issue trackers, \underline{ticket} trackers, defect trackers, artifact trackers, request trackers. +But Triage. + + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % wed start here \foilhead{Ticket life cycle} @@ -2383,8 +2545,6 @@ Peter Kovacs. Apache OpenOffice. Hadoop PMC: \url{http://hadoop.apache.org/who.html} - - Manage their projects independently. Quite autonomous. Lead and oversee the project. Set per-project policies. Vote on product releases. Elect new @@ -2664,6 +2824,9 @@ pile up \end{verbatim} } +Developers who do not follow requirements. Acceptance Criteria. +% https://pm.stackexchange.com/questions/27404/what-to-do-with-developers-who-dont-follow-requirements + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Handling growth} @@ -3084,4 +3247,152 @@ Keep accurate records of who did what (be specific), when. \underline{Initiating a fork}. {\em Most forks do not succeed, and most projects are not happy to be forked}. Take all factors into account in evaluating the potential success of your fork. Line up support privately first, then announce the fork in a non-hostile tone. Granting all committers of the original project commit access to the fork, including even those who openly disagreed with the need for a fork. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{User satisfaction} +TBD. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Master branch gatekeeper} +TBD. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Epics and story points} +Sprints. + +Timeboxes. + +TBD. + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{The Economics of Open Source} + +Software developers must be paid. + +Office space and network bandwidth. + +Proprietary software: monopoly-controlled royalty streams based on per-copy sales. + +Imagine something that everyone needs but no one needs to own. + +For example, a company needs a web server, but it does not want to make money from it. Maintainance is also a burden. + + +- Paid developers: informal subsidy, salaries. + +- Unpaid developers + +In-group and out-group developers. + +Unpaid labor for someone else's benefit. + +- Funding sources + +Money -- hire good programmers -- influence -- voting power -- voting block. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Forces of Chaos} + +A key developer suddenly loses interest. + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Corporate Involvement} + +Sharing the burden. Reduce cost of development incurred on individual companies without sacrificing the benefits. + +Ensuring maintenance of infrastructure. Companies sell services dependent on open source software. + +Establishing a standard. Include the standard into open source software to make it popular. If the standard becomes popular, the company becomes profitable. + +Creating an ecosystem. + +Supporting hardware sales. Hardware is useless without good software, vice versa. + +Undermining a competitor. + +Marketing. Brand marketing. + +Proprietary relicensing. Resell open source software by integrating it to proprietary software. Not a "pure open source play". "Open source is just a way of software development" to "open source is a way of life" spectrum. + +Start the project or join in the project? + +Leadship or just one voice? + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Government Projects} + +Elected officials. + +Publicity events. + +Exposure event. + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Be Asynchronous} + +Wikipedia versus Encyclopedia Britannica. + +Distributed workflows. + +%https://ben.balter.com/2020/03/18/tips-for-working-remotely/ + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{The Zone} + +Do not interrupt a deep worker when they are in The Zone. + +Why? + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{The Kanban Method} + +Taiichi Ohno. + +Introduced in 1940s, 1959??? by Toyota. + +A great view of the status of the project. + +Immediately know who is doing what by just looking at the board. + +Each task is represented by a card. + +Each movable card can be in one of {\em phases}: Backlog, Work in Progress (WIP) and Done. + +Usually, as the work progresses, you shift the card rightward. + +For software development, we could have Backlog (requirements), Develop, Test, Documentation, Done. + +Priority. Order cards in each phase by their importance. + +Start with what you are doing now. + +WIP limit. Don't overwhelm the developer by too many tasks (multitasking). + +Definition of Done or Done Rule. + +Lead time: time between task creation and completion. Visible to customers. + +Cycle time: time between task start and completion. Visible to employees. + + +Burn up diagram (Cumulative Flow Diagram). + +Burn down diagram. + +Pull work instead of Push work. + +One color for each team member. Great! + +Good Kanban software: \href{https://kanboard.org/}{Kanboard}. + \end{document} + + |