UnitXP: Difference between revisions
No edit summary |
No edit summary |
||
| (36 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
<html> | <html> | ||
<div style="background-color: black; width: 90%";> | <div style="background-color: black; width: 90%";> | ||
<div style="position: relative; top: 10px; left:10px; background-color: white; color: black;"> | <div style="position: relative; top: 10px; left:10px; background-color: white; color: black;" align="justify"> | ||
<blockquote>See discussion page for definition of the term. | <blockquote>See discussion page for definition of the term. Work relations are essentially economic and you can, to the extent these are well formed, appropriate to the development situation, ignore the discipline of software development in an enterprise that is variously dependent on it. For the gap, I've assembled the material below. <b><a href=http://www.processdash.com/functionality-team><font color=navy>Process Dashboard for Teams</font></a></b> is a useful free tool that is antithetical to agile which is a limited reaction to social conditions in the production of software. Once these conditions, as for example in large software development projects, are removed we are back to the general case of software development the earlier literature addresses. In the case of single developers or very small teams and under actually prevailing small shop conditions (2012), however, agile techniques are generally practically the only available ones with failure as a prevailing mode of outcome in varying proportion to the mismatch of resources/values in the project. | ||
</blockquote></div></div></html> | |||
{| | {| | ||
| | | | ||
* <b>[http://agilemanifesto.org Agile]</b> | * <b>[http://agilemanifesto.org Agile]</b> | ||
* <b>[[Cockburn's Paradigm]]</b> | * <b>[[Cockburn's Paradigm|Cockburn]]</b> | ||
| | | | ||
* <b>[[:en: | * <b>[[:en:Capability Immaturity Model|CIMM]]</b> | ||
* <b> | * [[:en:Software Craftsmanship|<b>Craftsmanship</b>]] | ||
| | | | ||
* <b>[[:en:Dynamic systems development method|Dynamic | * <b>[[:en:Dynamic systems development method|Dynamic]]</b> | ||
* <b>[[:en:MoSCoW Method|MosCow]] </b> | * <b>[[:en:MoSCoW Method|MosCow]] </b> | ||
| | | | ||
* [[:en:Pragmatic Programmer|<b>Pragmatism</b>]] | |||
* <b>[[Programmer]]</b> | * <b>[[Programmer]]</b> | ||
| | |||
* <b>[http://programming-motherfucker.com Programming] [[Motherfucker]]</b> | |||
* <b>[[:en:Software development effort estimation|Sizing]]</b> | * <b>[[:en:Software development effort estimation|Sizing]]</b> | ||
| | | | ||
* [[:en:Software development process|<b> | * [[:en:Software development process|<b>Process</b>]] | ||
* <b>[[:en:Team software process|Team | * <b>[[:en:Team software process|Team ]]</b> | ||
| | | | ||
* [[:en:Testing Maturity Model|<b> | * [[:en:Testing Maturity Model|<b> Maturity</b>]] | ||
* <b>[[:en:Personal software process|Unit | * <b>[[:en:Personal software process|Unit ]]</b> | ||
| | | | ||
* [[:en:V-Model (software development)|<b>V | * [[:en:V-Model (software development)|<b>V</b>]] | ||
* [[:en:Extreme Programming|<b>XP</b>]] | * [[:en:Extreme Programming|<b>XP</b>]] | ||
|} | |} | ||
<html><iframe src=/AkStore2/custom/UNITXP.html width=98% height=1750></iframe></html> | <html><iframe src=https://meansofproduction.biz/AkStore2/custom/UNITXP.html width=98% height=1750></iframe></html> | ||
Latest revision as of 16:09, 23 May 2019
See discussion page for definition of the term. Work relations are essentially economic and you can, to the extent these are well formed, appropriate to the development situation, ignore the discipline of software development in an enterprise that is variously dependent on it. For the gap, I've assembled the material below. Process Dashboard for Teams is a useful free tool that is antithetical to agile which is a limited reaction to social conditions in the production of software. Once these conditions, as for example in large software development projects, are removed we are back to the general case of software development the earlier literature addresses. In the case of single developers or very small teams and under actually prevailing small shop conditions (2012), however, agile techniques are generally practically the only available ones with failure as a prevailing mode of outcome in varying proportion to the mismatch of resources/values in the project.
