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

terça-feira, 3 de abril de 2018

BOOK: Enterprise Scrum (Mike Beedle)

Quoting:
"The focus of Enterprise Scrum is on reinventing the company itself, or any part of it, with all of its business units, customer segments, business models, processes, products, and services.

Enterprise Scrum means Scrum applied to the Enterprise as a whole, so it means continuously reinventing, improving and adapting the company and everything it does.

In 2016, the book Enterprise Scrum: An Adaptive Method for Project Success was published."
Co-Author of Agile Manifesto and Creator of Enterprise Scrum Mike Beedle Passed Away

The blog:
http://www.enterprisescrum.com/

The BOOK: Enterprise Scrum: Agile Management for the 21st Century

https://www.amazon.com/exec/obidos/ASIN/0321807847/

Quoting:
"This is today's definitive guide to making Scrum work at all levels of the enterprise, both in software development and in any other knowledge-intensive business process. Legendary agile pioneer Mike Beedle draws on his experience helping thousands of teams and individuals succeed with Scrum in projects of all types, from single-team assignments to those cutting across complex processes or the entire organization.

Beedle begins with a uniquely clear and practical explanation of Scrum: its roles, benefits, interactions, and how it reflects modern insights into complexity science. You'll master these crucial essentials with the help of clear organizational and process diagrams, as well as exceptionally relevant case studies in software development and beyond.

Building on this understanding, Beedle introduces proven enterprise-level Scrum processes for introducing, growing, and managing operations -- including Scrum's role in the Project Management Office (PMO) and in support of executive activities. He concludes with detailed case studies from multiple domains where Enterprise Scrum has delivered superior results.

Throughout, Beedle helps you understand the paradigm shift required to succeed with Scrum in any knowledge-intensive business process -- and how to gain Scrum's proven benefits of productivity, transparency, and performance."

DIGEST: SW Licensing options

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/>.

REPORT: Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch

Project failures, overall, by project size, Agile vs Waterfall and some contributing factors to success (in the opinion of the participants):
Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch

Quoting:

"The 2015 CHAOS Report has recently been released by the Standish Group. The CHAOS Reports have been published every year since 1994 and are a snapshot of the state of the software development industry. This year the report studied 50,000 projects around the world, ranging from tiny enhancements to massive systems re-engineering implementations. This year the report includes an enhanced definition of success looking at some additional factors which were covered in previous surveys.

The results indicate that there is still work to be done around achieving successful outcomes from software development projects. This table summarises the outcomes of projects over the last five years using the new definition of success factors (on time, on budget with a satisfactory result)"
(...)

Listed factors that could help in project success include:

"The definitions for these factors are:
Executive Support: when an executive or group of executives agrees to provide both financial and emotional backing. The executive or executives will encourage and assist in the successful completion of the project.

Emotional maturity is the collection of basic behaviors of how people work together. In any group, organization, or company it is both the sum of their skills and the weakest link that determine the level of emotional maturity.

User Involvement: takes place when users are involved in the project decision-making and information-gathering process. This also includes user feedback, requirements review, basic research, prototyping, and other consensus-building tools.

Optimization is a structured means of improving business effectiveness and optimizing a collection of many small projects or major requirements. Optimization starts with managing scope based on relative business value.

Skilled staff are people who understand both the business and the technology. A skilled staff is highly proficient in the execution of the project’s requirements and deliver of the project or product.

SAME is Standard Architectural Management Environment. The Standish Group defines SAME as a consistent group of integrated practices, services, and products for developing, implementing, and operating software applications.

Agile proficiency means that the agile team and the product owner are skilled in the agile process. Agile proficiency is the difference between good agile outcomes and bad agile outcomes.

Modest execution is having a process with few moving parts, and those parts are automated and streamlined. Modest execution also means using project management tools sparingly and only a very few features.

Project management expertise is the application of knowledge, skills, and techniques to project activities in order to meet or exceed stakeholder expectations and produce value for the organization.

Clear Business Objectives is the understanding of all stakeholders and participants in the business purpose for executing the project. Clear Business Objectives could also mean the project is aligning to the organization’s goals and strategy"

(...)

Success, namely project success is (re)defined as:

"The Standish Group has redefined project success as onTime, onBudget, with a satisfactory result.
Success is hard to define and we had a hard time coming to this conclusion.
Merriam-Webster dictionary defines success as the fact of getting or achieving wealth: respect or fame: the correct or desired result of an attempt; someone or something that is successful: or a person or thing that succeeds.
The Project Management Institute (PMI) has defined success as onTime, onBudget, and onTarget also known as the Triple Constraints and the Iron Triangle. However, we have seen many projects that have met the Triple Constraints and did not return value to the organization or the users and executive sponsor were unsatisfied."

SW Licensing: Licenses Explained in Plain English (TLDRLegal - Software)

A searchable summary (in "plain human-readable" language) of software licensing:
TLDRLegal - Software Licenses Explained in Plain English

Quoting:
"Lookup popular software licenses summarized at-a-glance."

sábado, 31 de março de 2018

SW Development: Agile enters aviation?

https://www.flightglobal.com/news/articles/us-auditor-gives-backstory-of-software-reform-on-f-447143/

Quoting:
"Instead of releasing large quantities of new software-cabled capacities in multi-year blocks, the F-22 programme carved up the development work into smaller slices of capabilities that could be delivered every 12-14 weeks, the audit says.

As each new software update is coded, developers perform integrated testing to tackle bugs in more manageable chunks. Rather than waiting until the end of a multi-year block development to begin integrated testing.

The F-22 programme called the new method the Scaled Agile Framework (SAFe), according to the IG. The approach was once limited limited to the F-22 programme, but the idea began to spread last year.

In September, Vice Adm Mat Winter, the F-35’s programme executive officer, said agile-based software development would be applied to future upgrades of the F-35 and the F-22. He did not mention that the F-35 was following the lead of the F-22, which the IG report reveals had started using the incremental method four years earlier."

quarta-feira, 28 de março de 2018

MAGAZINE: DNC magazine (PDF)

Freely downloadable twice per month (requires subscription):
http://www.dotnetcurry.com/magazine/

Get Ready for CMMI V2.0!

And CMMI V2.0 launches today... Eager to hear the news? Yes and no...

Preparation for Launch – Getting Ready for CMMI V2.0