敏捷开发者

#1 楼

通过测试驱动的开发方式
通过小规模的冲刺开发方式
通过与客户的广泛接触

我记得读过一篇有关牛仔发展的论文，对于单独的开发人员来说，敏捷是必不可少的，但是我不记得在哪里找到它。

#2 楼

除了klez的答案（所有好的建议）之外，我还建议以下内容：



保留产品积压
产品积压基本上是一个清单您打算在此产品的某个阶段完成的所有项目。

维护sprint消耗和产品消耗
sprint消耗从您已决定要完成的所有任务的列表开始在此sprint中（需要在一定时间段内（例如2周）完成的产品积压工作的子集）以及所需工作的估算。标记完成后，将其标记为完成。从而减少（或消耗）该冲刺的剩余工作。
类似地，产品消耗跟踪整个产品积压工作的剩余工作

采用相对估计和速度的概念
/>相对估算是一种以其他任务（或故事）为指导的估算技术。例如，如果您知道任务A比任务B容易，并且任务B的复杂度是任务C的两倍，则可以确保任务A的“要点”相对于这些期望是正确的。
重点不是正确猜测所需的工作量，但要使估算结果彼此保持一致。
速度是衡量您在sprint中完成多少“点”的指标。如果您的相对估计是要确保一致性，则可以使用此速度来估计您在即将完成的sprint中可能完成的任务。请注意，尽管应该不断修改速度。

#3 楼

限制正在进行的工作（除了装箱）。即使您使用迭代方法（而不是看板），也可以说您的速度是每次迭代8点。不要一次开始处理全部8个。通过故事的数量或故事点来限制WIP很好。
对所有用户故事进行自动验收测试。一般而言，要实现尽可能多的自动化。
使用户故事过小的一面。根据经验，最大故事与最小故事的比率应为3：1。如果您低估了Scrum中的一个故事并且发现故事太大，则多个开发人员可以将其聚集起来以使其恢复正常。但是您没有足够的人。
如果在常规规模的团队环境中，您是否犹豫是否要从用户故事中拆分高峰-在单独团队或小型团队的情况下，请在没有犹豫这有助于使故事更小，更易于预测。
回顾在敏捷中通常很重要，因此看板（也就是“个人看板”）在这里得分更高，因为其回顾过程更多地由数据驱动。当您没有足够的人时，很难玩三重镍矿。

这些情况可能适用于单人和小型团队（2或3个开发人员）的情况。

添加：在我写完此答案后的某个时候，我发现了这次会议演讲，并给人留下了深刻的印象：个人看板：优化个人编码器

#4 楼

要么进行定义明确的sprint，要么故意选择看板方法。不要偶然以看板结尾
首先犯错误，然后是功能。
仍然要专注于“价值与功能”膨胀。 （关于镀金的YAGNI）
回顾展同样有价值。同样重要的是，对流程进行小块更改。除非您确实没有提供ATM的外部功能，否则请不要立即决定今天开始使用TDD，Mock和IoC。一次加入一个。

最终，我将敏捷定义为：“对您的团队和客户有意义，并且不遵循旧的做法，因为它们碰巧看起来就像过去一样。 ”

#5 楼

敏捷对于个人和团队一样有效。这是关于找到一个适合您的流程，并让您的项目一旦开始就可以适应不断变化的情况。这也与定期为您的客户提供价值有关，而不管软件是否真正“完成”。

敏捷过程是高度迭代的。工作在简短的TimeBoxes / sprints / cycles / iterations中完成。可能需要先进行一些设计工作，但是当您了解有关系统需要做什么的更多信息时，可以进行重构。单元测试是几乎所有敏捷开发方法的基础，它可以指示您的软件是否正常运行，以及对软件的添加/更改是否会破坏现有的代码库。

BDD / TDD，允许您随风而变，并可以相应地调整功能优先级，如果您构建整个系统并经常运行所有测试，并且在每个sprint末尾交付工作代码，则已经敏捷。

#6 楼

哇。我会尽量让遇到麻烦的朋友打电话给我-讨论编码问题。您知道我的意思...大声地解释问题的举动会在90％的时间内为我带来解决方案。

#7 楼

最近，我写了一个开发人员如何在工作中使用敏捷和其他技术的文章，并将其命名为The solo developers Manifesto，可在此Github Repo上找到。
然后我使用此宣言创建了Free Currency Exchange API。我花了两天的时间来完成，所以我想说这个宣言非常实用
这是完整的宣言：
《 Solo Developers Manifesto》
本指南将帮助单项开发者实现可以实现的目标按上帝的仁慈分队进行比赛
阶段：
每个阶段都应设置时间框
1。计划：

从用户的角度（解决的用户问题，用户想要的东西等）而不是从Devs的角度（其他功能，精美的外观等）定义目标/，还编写基本的用户接受度测试
尽快开始此阶段，以避免超出期限
进行良好的研究，以实现最佳的最简单设计（包括学习新事物）
进行良好的前期设计（避免将来出现阻塞问题）
将此阶段划分为子阶段即研究，设计，估算和时间表各一个
递归地细分工作，直到获得最小的任务单元，这有助于正确估算
故事->功能->任务->子任务
将待办事项中的任务和分组任务添加到有意义的分组中，并按优先级/ MoSCoW（在优先级划分过程中必须，应该拥有，可能拥有和不会使用用户POV）和故事点（再定级/重新估计）对组进行排序/ Redo Dead衬里（如果已将新功能添加到积压中）
时间框每个子任务并保留日常任务列表

1.1设计：

复杂的用户交互/简单需求交互与简单用例设计（draw.io）
具有MS Paint的简单UI设计，已通过测试UI设计模式（例如是否要添加搜索栏？使用Google搜索栏设计）
加标解决方案（小型实验/程序来研究问题的答案）
simplest design (no fancy features etc, don't worry about future requirements)
worse is better, Software that is limited, but simple to use is better, than buggy or complex software with complex features (less features, more quality)
Don't program features until they are actually needed (YAGNI)
Write programs that do one thing and do it well and work with other programs
complete design: The design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.
Use software standards for everything (e.g. semantic versioning etc)

1.2 Estimation:

10-20% buffer time while estimating deadline (E.g. 1-day buffer means, release date 29th-30th) (avoids stress & frustrations)
overestimation-Parkinson's law, underestimation-no work/feature get done
Proper estimation is very important for highest productivity (No time limit/deadline - Low productivity)

2. Implementation:

Make sure I am following the manifesto properly
Start day by observing/tracking yesterday's task and deadline, things TODO today, and any blocking issue to fix it
Track the work daily to meet deadline (Zen Hub-burndown chart, Kanban board) & correct productivity/blocking issue if any and prioritize accordingly
Use pomodoro Timer Technique for Time Management -> work for n tasks for x mins(30-90mins,depending on estimated time), small break(3-5mins) if fewer than n task completed else large break(10-15mins), pomodoro is indivisible and cannot be interrupted, other things should be done after pomodoro or else abandon pomodoro. After task completion any remaining time used for Reviewing the work and also seeing from learning POV (What I learned? What could be done better etc)
Use Test-driven development (TDD) during coding:

Convert software feature/requirement -> test case (concise, note it down for future unit testing),
run test and see it fail,
write code to only pass the test (No refactoring)
run test and see it pass (the code should not break any existing feature) (if it's gotten hard to pass the above code, then revert the above code to avoid excessive debugging) & commit,
refactor the new code and the whole code & commit (deepcode/standardjs --fix)



2.1 Testing:

Unit Test, Total feature test, acceptance test (users POV), stability test(stressing)

2.2 Documentation & PR:

Minimal documentation for users and also about how the code works (for myself & future Devs) (Code comments, unit test cases above function, etc)
PR/Marketing (Write Medium/dev.to/LinkedIn Article, Answering SO, Quora etc, 4P's-Price, Product, Place, Promotion, Market Targeting/Segmentation message with differentiation & positioning) (Refer similar software to make marketing message), use good GFX(pixabay)

3. Measurement:

Measure & document the estimated time vs actual time taken for subtask, to help in future estimation using my historical values (by seeing time taken previous for similar subtask) and also for retrospective to make things better
Google Timer to measure task and then use Google stopwatch to measure extra time taken (This helps in future estimation by comparing estimated time vs actual time)

4. Retrospective:

Happens at end of sprint, involves looking back at how the sprint went
what things I can use? where I can make things better?
See why I am taking more time than estimated time for different task etc
Try Sheets/Excel Charts to analyse my historical data(ZenHub provides great reports)
Plot estimation vs actual time for task on a graph to see your personal time estimate accuracy trend
Learn from mistakes (Unnecessarily complex solutions, being perfectionist, using unstable libraries effects quality/stability)
Learn from customer question/feedback? Why is customer/user asking/saying that, is there a lacking doc/feature

Rules:

Time/Deadline & quality (no compromise)
Scope (features etc, high impact features first), cost (overtime, etc)
Shorter Sprint (1-2 weeks) release product

Things to Remember:

Eliminate waste (partial work, multitasking, task switching, bugs, extra features, relearning, unnecessarily complex solution, unnecessary stress, building wrong feature, rework)
Implement new learnings
Decide as late as possible (so that to know more about problem and not waste time on things that's not required)
Deliver ASAP
During major blocking issue during operations use stop the line technique -> stop everything (Give importance/resources to issue), assess the issue, and resolve the issue, and learn how to prevent it
Don't beg for help, learn & do things yourself
If stuck somewhere, then google search in Stack Overflow (& its sister sites) and GitHub issue
If stuck, Explain the problem out loud to someone (I prefer God)
Consider asking question at Stack Overflow as last resort (Not advisable)
commits on one main branch to avoid merge hell (don't keep multiple feature branch)
When a bug is found, tests are created before the bug is addressed (a bug is not an error in logic; it is a test that was not written)
embrace change (new features etc)
During sprint you might have personal ideas (Urge to Google search something), project related ideas (new features), just write those into personal notes/to-do list to refer it back in personal time. This will reduce stress and help us to be focused (GTD Method)
自动化测试（单元等），CI / CD非常适合需要长期/始终维护的软件，而不适合一次性的GitHub小型业余项目
功能上的高内聚性（仅完成一项简单的任务）和低耦合（对其他功能的依赖性低）
在不再生产/沮丧时，请休息更长的时间（30-60分钟），如果不起作用，请隔天进行工作
分批检查所有内容一次每天（电子邮件，消息，SMS，电话，新闻，站点等）（不要再次检查），并在工作时间结束时将imp电子邮件标记为要回复
耳机（包括mp3耳机）以避免分心

生产力工具：

G Suite（日历，工作表等），代码时间（时间跟踪器指标）
Asana（看板）
Prowritingaid，Hemingwayapp （简化文档/营销信息）
使用ZenHub的GitHub项目（敏捷项目管理）
GitHub动作（CI / CD）
DeepCode（代码审查），StandardJS（一致代码样式）

为什么lo很棒：

谦虚快乐，感谢上帝成为独立开发者，因为您从团队的思想体系中解救了
没有意见分歧
没有返工沟通上的差距
无需炫耀工作给某人
没有状态更新
没有冲突
没有垃圾的办公时间
没有乞求您的权利（叶子等）
无需撒谎
无需向某人鞠躬
无需竞争
您无需制定规则，
无需浪费时间
出色的工作/生活的平衡成为独奏
你的上帝是你的老板

例行公事：
先知穆罕默德（愿上帝的安宁降临在他身上）一直是这一例行公事的榜样。 />因为上帝说：
实际上，在上帝的使者中，您有一个很好的榜样...-古兰经33:21
将您的日常活动分为三个不同的部分

工作时间
个人时间
家庭/社会时间

您应该同等重视每个人。有些人整天工作，却没有时间给自己或家人/其他人。使用此宣言或笔记应用（Google Keep-TODO列表）或看板（Asana）来管理个人和社交时间
工作时间：

这是您的工作时间
/>每天8-9小时
起床后更喜欢工作
每次迭代/冲刺/释放后每天休息1天
醒来6-7小时后小睡15-30分钟（增加生产力）
具有人体工程学设计的电脑椅和桌子，每15分钟休息20秒（休息时要用力，站立并移动并伸展身体）（防止与计算机相关的伤害）

个人时间：

这是您付出的时间，例如看自己的健康，衣服，卫生状况，身份证更新等（例如，破鞋，修理鞋或从鞋匠那里修理或购买新鞋）
每周进行两次锻炼（例如：为保持心脏健康而跳绳10分钟）（星期六，星期二固定日期）
通过做家务来锻炼身体
下班后开始在这里从事工作
>
家庭/社交时间：

这是您送给家人和其他人的时间，例如带家人去买杂货，给妻子，父母等时间，生病时带家人去看医生，帮助做家务等。 />下班后在这里开始处理任务


实现宣言：
免费货币兑换API是由一位开发人员在2天的时间内遵循此宣言而制成的
请参阅《 Solo开发人员宣言》以获取最新的宣言