A professional should have professional face, professional voice and professional smile. Of course, if you have some professional capabilities, they might help too.
1, You may love the fairy tales of Scrum about “an increase in business and technical risks” (taken from Scrum Primer 2.0), but we should still have to face the sad reality of “No Silver Bullet”.
2, If you do not really trust your development team, you should try to rebuild it.
3, If you can’t build a trustworthy development team by yourself after having tried several times, you should find someone to help you to do it.
4, If you can’t find a trustworthy guy to do it at all, you can go to find a Scrum trainer and pay to him/her to comfort your feelings now.
1, About Project Manager:
The traditional responsibilities of a project manager have been divided up and reassigned among the three Scrum roles, and mostly to the Development Team and the Product Owner, rather than to the Scrum Master. Practicing Scrum with the addition of a project manager indicates a fundamental misunderstanding of Scrum, and typically results in conflicting responsibilities, unclear authority, and sub-optimal results.
2,About the output of Sprint
Scrum emphasizes working product at the end of the Sprint that is really “done”; in the case of software, this means a system that is integrated, fully tested, end-user documented, and potentially shippable.
3, About Story Points
But how do you know which story is a 3 and which is a five. In order to do that each team would have to find a baseline story.
If you really have to track time then don’t use story points at all.
4, About Spike
A time boxed period used to research a concept and/or create a simple prototype. Spikes can either be planned to take place in between sprints or, for larger teams, a spike might be accepted as one of many sprint delivery objectives. Spikes are often introduced before the delivery of large or complex product backlog items in order to secure budget, expand knowledge, and/or produce a proof of concept. The duration and objective(s) of a spike will be agreed between the Product Owner and Delivery Team before the start. Unlike sprint commitments, spikes may or may not deliver tangible, shippable, valuable functionality. For example, the objective of a spike might be to successfully reach a decision on a course of action. The spike is over when the time is up, not necessarily when the objective has been delivered.
5, About Tracer Bullet
The tracer bullet is a spike with the current architecture, current technology set, current set of best practices which results in production quality code. It might just be a very narrow implementation of the functionality but is not throw away code. It is of production quality and the rest of the iterations can build on this code. The name has military origins as ammunition that makes the path of the weapon visible, allowing for corrections. Often these implementations are a ‘quick shot’ through all layers of an application, such as connecting a single form’s input field to the back-end, to prove the layers will connect as expected.
6, About Definition of Done (DoD)
The exit-criteria to determine whether a product backlog item is complete. In many cases the DoD requires that all regression tests should be successful. The definition of “done” may vary from one Scrum team to another, but must be consistent within one team.
7, About Limitations
Hybridization of Scrum is common as Scrum does not cover the whole product development lifecycle; therefore, organizations find the need to add in additional processes to create a more comprehensive implementation. For example, at the start of the project, organizations commonly add process guidance on requirements gathering and prioritization, initial high-level design, and budget and schedule forecasting. However, the Scrum framework does not explicitly allow for extension points of such a kind; consequently, achieving a more comprehensive software life cycle requires extending the framework rather than instantiating it.
- Quoted from Scrum (Software Development) on Wikipedia.
- Major Premise: All unnecessary consumption of resource is a kind of pollution.
- Minor Premise: A contribution which has no value to others is unnecessary and must consume some type of resource.
- Conclusion: A contribution without value is a kind of pollution.
So we can conduct a basic precondition to open-source something:
if it’s a long-term & independent project,
it’s ok to release after having some code.
else if it has been utilised internally by two projects/products,
and it has been revised twice.
it’s ready to be published.
it’s better to keep it as an internal incubating one.
2, the core functions of foolang should make up a closure in meaning of mathematics.
2.0, option-1: to keep the existing relatively complex structure.
2.0, option-2: to reduce it to a simple model.- like lisp?
0, please spell your name
your name: reference, semantics entity?
1, please spell ‘your name’.
‘your name’: quote, syntax entity?
0.0, level-entity: notify the runtime to try the local-replacing as much as possible.
0.1, level-reference: level-entity + save the result to the same reference – it looks like performing an update.
1.0, level-entity-func: (&func …)
1.0.0, (impl this …) => (&impl this …)
1.0.1, (impl stmt …) => (&impl stmt …) – reasonable?
1.0.2, (impl ref …) => (impl ref …)
1.0.3, (&impl ref …) => (&impl ref …)
1.1, level-entity-pkg: (&pkg:method …)
1.1.0, (this:method …) => (&this:method …)
1.1.1, (stmt:method …) => (&stmt:method …) – reasonable?
1.1.2, (ref:method …) => (ref:method …)
1.1.3, (&ref:method …) => (&ref:method …)
1.2, level-reference-func: ($func target) => (decl target (&func target))
1.2.0, ‘target’ must be a reference.
1.3, level-reference-pkg: ($pkg:method …) => (decl pkg (&pkg:method …))
1.3.0, ‘pkg’ must be a reference.
0, all entities are immutable.
1, programmer can give some hint to runtime.
2, runtime makes the final decision if to override/copy/alter an entity.
3, application code should not depend on any assumption about its internal process.