On Software Development (or "O Sr. SiIva disse..."): Summary

Mostrar mensagens com a etiqueta Summary. Mostrar todas as mensagens

quarta-feira, 16 de maio de 2018

Kanban Method 5 lines summary

Kanban Method 5 lines summary with more than 5 lines (as usual):

Foundational Principles

Start with what you do now; no roles/responsibilities
Agree pursue evolutionary change
Initially, respect current roles, responsibilities and job titles
Encourage acts of leadership

Core practises:

Visualize; Limit WIP, manage flow; make process policies explicit (create substasks, like definition of done in Scrum), implement feedback loop (e.g. kanban retro); improve collaboratively, evolve experimentally (kanban retro actions).

More info: https://edu.leankanban.com/kanban-method

Also see about David J. Anderson (kanban for the SW industry)

terça-feira, 3 de abril de 2018

An interesting sum-up of some licensing options (http://www.codeproject.com/info/Licenses.aspx) that might be of interest as a first approach to a decision on what license can we apply (or are we obliged to use) when reusing and/or building upon.

Quoting (licenses valid for Code Project):
"

Microsoft Reciprocal License

A Microsoft open license and a free software license . Allows for distribution of derived code so long as the modified source files are included and retain the Ms-RL.

The Code Project Open License (CPOL)

The main points subject to the terms of the License are:

Source Code and Executable Files can be used in commercial applications;
Source Code and Executable Files can be redistributed; and
Source Code can be modified to create derivative works.
No claim of suitability, guarantee, or any warranty whatsoever is provided. The software is provided "as-is".

The Common Development and Distribution License (CDDL)

Based on the Mozilla Public License (MPL) that makes it more applicable for use outside the Mozilla Foundation.

The Microsoft Public License (Ms-PL)

Used by Microsoft. Compiled derived code can be distributed, for both commercial and non-commercial use. If the source code is to be redistributed then a complete copy of this license must be included in the redistribution.

The Mozilla Public License 1.1 (MPL 1.1)

Used by Mozilla and Firefox, among others. The patent clauses are not acceptable to some.

The Common Public License Version 1.0 (CPL)

Derived from the IBM Public License and influenced by the Mozilla Public License, and used by some Microsoft projects on SourceForge.

The Eclipse Public License 1.0

A newer version of the Common Public License that is in some cases more acceptable to business.

The MIT License

A very old license with essentially no restrictions on the use of the code. It also provides very little in the way of protection for authors or users. It is the same as the BSD license without the 'no endorsement' clause.

The BSD License

A very old license with essentially no restrictions on the use of the code. It also provides very little in the way of protection for authors or users. It is the same as the MIT license except that it includes a clause preventing the use of the author's name for endorsement.

The Apache License, Version 2.0

Slightly more restrictive (but still very open) version of the BSD or MIT license that adds patent clauses. Read carefully.

The Creative Commons Attribution-ShareAlike 2.5 License

A license that requires a link be visible on works that use this license. "Share alike" is what it sounds like, you can share this work as long as that work has a license similar to this one.

It is recommended that this license not be used for software.

The zlib/libpng License

A license with an emphasis on freedom of use and re-use, with a few restrictions.

A Public Domain dedication

Not a license, but a dedication to the public domain. All rights are given up and anyone can do anything they wish with the code. Please note this is not a license and provides no guarantees for the user and no indemnities for the author.

The Creative Commons Attribution 3.0 Unported License

This license lets others distribute, remix, tweak, and build upon your work, even commercially, as long as they credit you for the original creation. It is recommendedthat this license not be used for software.

The Creative Commons Attribution-Share Alike 3.0 Unported License

A license that requires a link be visible on works that use this license. "Share alike" is what it sounds like; you can share this work as long as that work has a license similar to this one. It is recommended that this license not be used for software.

The Creative Commons Attribution-NoDerivatives 3.0 Unported

A license which specifies that if you remix, transform, or build upon the material, you may not distribute the modified material. It is recommended that this license not be used for software.

The GNU Lesser General Public License (LGPLv3)

A derivative of the GPL that was intended to allow non-GPL code to work with, and call GPL code. The author of this license asks that you only use this license if you are licensing functionality already commonly available.

Example usage in your code

(Replace 'Foobar' with the name of your product)

This file is part of Foobar.
 
Foobar is free software: you can redistribute it and/or modify
it under the terms of the GNU Lesser Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
 
Foobar is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Lesser Public License for more details.
 
You should have received a copy of the GNU Lesser Public License
along with Foobar.  If not, see <http://www.gnu.org/licenses/>.

The GNU General Public License (GPLv3)

A common but misunderstood license. This allows developers to freely use the software as long as they use the same (or an even less restrictive) license for parts of the program that they wrote themselves. Viral in nature. Read carefully and make sure you understand the implications of using this license. Unacceptable to many.

You can write commercial software using software licensed with the GPL, but you cannot write proprietary software (meaning software for which the code is not freely available). You can sell GPL code, even if it's already being given away, or you can sell services attached to the code such as support contracts.

Any software written using GPL'd code must itself be licensed using the GPL (or less restrictive license) meaning it cannot be proprietary. This means that developers writing commercial software may not be able to use GPL code if they do not wish to provide the code.

One important note (thanks to René Pfeiffer): The GPL doesn't require you to publish the source to the world. Only the recipient of the software needs to have the source. If you have a customer, write GPLed software for a specific purpose and only give the binary to this customer, then only this customer must have access to the source code, not everybody and not the public; just the recipient of the (binary) code. This is in full agreement to the GPL. The main advantage is to play with open cards and not create a "blackmail" situation.

At the Code Project we prefer that developers allow other developers to use their freely given code in whatever way they wish - commercial, proprietary, or free for anyone. Our preference is that our authors do not use a GPL-like license.

Example usage in your code

(Replace 'Foobar' with the name of your product)

This file is part of Foobar.
 
Foobar is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
 
Foobar is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
 
You should have received a copy of the GNU General Public License
along with Foobar.  If not, see <http://www.gnu.org/licenses/>.

quarta-feira, 8 de junho de 2016

BOOK: Actionable Agile Tools - Jeff Campbell

The book Actionable Agile Tools - Practical tips and tools from ten years of Agile
(by Jeff Campbell) presents some ideas / tools for better Agile/Scrum.

Some ideas / tools in the book are summarized below (this is the 5-line summary with more or less 5 lines). The book is free to read online, so if this summary it "too summarized", try to read the book.
Remember, as the author recommends, if it works ok. If not, try anything else (move to the next tool and/or idea).

Better sprint retrospectives

SR is also sometimes called "coffee room whining ceremony"

Talk about everything
It's someone's else fault
Nothing changes

Retrospective:

Talk about one thing
What can we do?
Experiments

Retrospective vs project post-mortem = bad term

symptom
root causes
experiment: Start... ; start...
success criteria: At least 2 bugs prioritized at each sprint (for example)
follow up: In 4 weeks; actionable person (that can delegate to others)

Post-its with names and flowers

Showing recognition (in front of the team) increases team spirit.

Tools for iterations

Who knows what "sprint 15" is or means (a few months after it was done)?
Solution: choose a tasty theme; name sprints alphabetically: apple pie, blueberry pie, chocolate cake, etc.
Eat the thing (really)
Enjoy.

Tool: Bugs for breakfast

A tool for quality: legacy products in bad shape?
Have a ceremony once per week (approx.)
Focus on quality-related things.
Examples:

unnapropriated tool in area X
few tests
fix issues
create test

List anything that contributes to increased quality. And manage actions derived from the meeting.

Tool for data based decisions

Scrum. Board

Ticket for:
planned, critical, support, meetings, admin

Make ticks in the wall per hour spent or per type of activity performed (to count ticks in the end).

Tool for retrospectives: Event log

Board with dates and what happened (for remembering those events easily later on)

Tool: Door calendar

Useful for production releases.

Move post its (as production releases dates change, if they change).
That way everyone sees it (if it is in the door).

Tool: Resilience map

Tool for cross functionality.
SPOF: To be avoided (at all costs)
Build a matrix of skills vs team member name, basic, med., high
That way it is easy to spot the gaps (where is the issue, if smth goes wrong with that system/skill we are blocked)
Show it to managers (the gaps become more evident and the team might be reinforced, or having more training as a result)

Tool: in-line definition of done

A tool for quality (so that no-one forgets checking everything before marking things as done).
US cards can have the checklist printed next to the / in the US card.

story name / DoD (check list, answer could be N/A for this US)
task name / DoD (could be different than the one for US)

Morning meeting protocol

A tool for meeting efficiency.

Boring daily meetings?
Morning meetings should be energizing:
anything to share?
anything today?
does anyone needs our help?
any unplanned tasks?
is JIRA up to date?
is the build up to date? Jenkins?
etc,

WIP tool

A tool for kanban:

who ignores the WIP?
3 rules broken frequently

When blocked what should we do?
Wait? Or start new task?
What to do? Work in this order:

cofee
try to unblock blocked items
see I somone can finish off halted olwork off the mob
use the tech swimlane (technical debt)
have a retro on blocked items (if they are so many and being consistently a problem)

Tool: Not now backlog

A tool for dealing with "junk" (old epics and user stories that are in the PBL for ages).

1st: Convince to throw the huge backlog away

If not successful use this tool:

decide what now means: Q1,1,month
create a "deep backlog"
move all the crap you never going to do and...
forget about it

Tool: Visualized flow - a tool for refinement

The team "commits" to the sprint just to leave the room: Estimate and leave the room (while sometimes asking questions about the US in the process). If so use this tool:

First:
Several lanes: Customer | Team | Bugs | Marketing | Backlog
Move to the last lane IN ORDER
(top items have higher priorities)

Second:
backlog. PO refinement. Team refinement. Ready: Move items to the last lane as they are really ready (in order?)

Third:
Only choose ready items that are ready that fit the sprint

Fourth
Sprint = Todo... Deployed | Closed

Fifth

Show progress in another task board, so that other stakeholders understand and see the progress.
The task board shows the sprint contents in different lanes (so that they know that that MKT feature is being done)

These tools help to Facilitate communication (to other departments in the company)

The bottom line

Don't try to make teams make something that they don't want to do.
Try the approach (to pass the initial resistance): Let's have it a try for 3 weeks and then analyze results. Again, if it works ok. If not try anything else (move to the next tool and/or idea).

Further info at: https://leanpub.com/actionableagiletools

(2016-06-09: typos - kudos R. Azevedo)

quinta-feira, 5 de maio de 2016

Scrum (Agile) main documents and the 5 line summary (or not)

Scrum main documents include:
- The Agile Manifesto: the rationale behind scrum agile methodology.
- The Scrum Official Guide: maintained by the 2 framework authors up until... today (July 2013 version here).

The guide describes in merely 16 pages (!) a "new" ground-breaking framework for [software] product development. I give you the "5 lines" summary (as if it was needed):

Pillars:

Transparency (progress towards the Sprint Goal; definition of Ready is a transparency measure also)
Inspection: several opportunities for inspection (events, etc), but not so many that gets in the way (of reaching the sprint goal)
Adaption: if something is found it shall be fixed (or annotated as technical debt)

Roles:

PO (the owner of the product backlog; one person not a committee); can delegate but is still owner,
SM (the facilitator; ensures scrum is understood; services to the PO, to the Dev. Team and to the Organization),
Development Team (cross-functional, please; self-organizing - SM does not need to tell what's next): 3 to 9.

Events: All time-boxed (fixed max. duration)

The Sprint; fixed duration (fixed team); could be cancelled (if the sprint goal does not make sense anymore); max. 4 weeks.; if cancelled, Done items shall be reviewed all the same (by the PO)
[Sprint] Planning: all team; choose "Ready" items from the PBL to the Sprint BL (after defining and having the Sprint Goal defined; do not choose non-ready items. Leave unplanned buffer (%); use sprint velocity from previous sprints (team DOES not change and is allocated 100%; what to do next sprint and part 2: how to do (technical aspects included); time-boxed to 8h (1 mth sprint), proportionally smaller for smaller sprints.
Daily Meeting: 15 mins, SM and Dev. Team; if SM is not present shall delegate; optional: SM presents team progress (burndown chart) at start; each developer: what I've done, what I'll do today; what is blocking me (to be solved in 1-2 mins or at a tech meeting with relevant stakeholders afterwards); stand-up meeting.
[Sprint] Review: all team; review US definition (including Acc. Criteria) and demonstrate that it is Done. present all "Done" US to the PO. Answer questions, interact with the software, inspect results, answer to questions. Rework could be raised - as new US (even if the story is Accepted - changed to the Closed status by the PO ideally); time-boxed to 4h (1 mth sprint).
Retrospective: All team (w/o PO); think of lessons learned; what to start doing, stop doing (think on people, relationships, process, and tools); raise actions to fix (or study the); provide status of previous actions until closure; remember to plan for those actions to be closed also in Sprint Planning; time-boxed to 3h (1 mth sprint).
NOT AN EVENT: Refinement, Backlog Grooming, Pre-planning meetings: Prepare US to be "Ready" (PO, SM & parts of Team); convert Epics (Themes, high level features) to "Ready" US; use planning poker estimation technique; each and every US shall respect the INVEST model.
Planning poker estimation technique: estimate story points - cards deck or mobile app
Definition of "Done": Transparency; informal: Definition of "Ready". All tasks that should be completed before some US can be stated at that status.
Events sequence for 2 wk sprint: Planning, Daily(ies), Pre-Planning (several meetings, second week), Review (Demo, last 1-2 days); Retro: after Review (friday).

2 Artifacts:

PBL: Contains PBI: Epics / Themes, User Stories (Drafts, Ready), other tasks (setup, documentation, ...): owned by the PO (which can delegate); is an ordered list (by priorities, at least for the items for next sprints)
Sprint BL: Contains Ready US chosen from the PBL to fulfill the Sprint Goal + other tasks (unplanned, research spikes, technical debt, other tasks such as technical documentation tasks - not to be delivered in the increment - , etc.); the potentially shippable product increment contains the "Done" US (only those approved by PO)

AOB:

Research spike; technical debt; pigs and chicken, potentially shippable product increment = increment = something that can be incorporated in the shipped product.
Burndown chart (personal and for the team): Ideal curve; Are we late? How many (hours, US) do we need to do to converge to ideal curve; estimation accuracy; important for self-control. Important to report effort daily.
Taskboard: Ready - In Progress - Done - Closed / Reviewed (use post its on the wall if no IS is available)
Tools to support: dash boards for auto-control; task board; storage for US; issue tracker (for other tasks/actions).

More interesting resources include:
- Scrum Glossary: https://www.scrum.org/Resources/Scrum-Glossary
- Resources: https://www.scrum.org/Resources

(2016-06-06: add. links at end)

quinta-feira, 17 de março de 2016

RESOURCE: CMMI Summary

I've just found a good attempt on making a summary of this complex topic, CMMI:

PDF: http://www.tutorialspoint.com/cmmi/pdf/cmmi_quick_guide.pdf
HTML: http://www.tutorialspoint.com/cmmi/cmmi_quick_guide.htm