Как подать заявку гибкий к персональным проектам? [закрытый]
Используя F #:
#light
open System.Net; open System.Text.RegularExpressions
printf "%s" ((new WebClient()).DownloadString("http://www.textfiles.com/holiday/12-bugs")
|> (fun x -> (new Regex("Lines: \d+\s+([\s\S]+)--")).Match(x).Groups.[1].Value))
Результаты двенадцатого дня:
For the twelfth bug of Christmas, my manager said to me
Tell them it's a feature
Say it's not supported
Change the documentation
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again. 8 ответов
Я думаю, что Agile определенно не только для командные проекты. Agile отстаивает набор ценностей, которые одинаково хорошо применимы ко многим типам проектов, даже личным. Некоторое время назад я был точно в вашей ситуации, пытался применить гибкую разработку к личному университетскому проекту, и многому научился в процессе. Вот некоторые полезные вещи, которые может дать вам гибкий образ мышления:
Работайте над тем, что увеличивает ценность конечного продукта. Создайте список функций и расставьте приоритеты, как если бы вы были клиентом. Затем приучите себя работать над функциями, исходя из их ценности для продукта, а не того, чем вы хотите заниматься прямо сейчас. Это может избавить вас от большого количества ненужного, чрезмерно продуманного кода, который вы не будете использовать. Если у вас есть крайний срок, это еще более важно.
Имейте эволюционный план: начните с «Простейшая вещь, которая может сработать» и безжалостно рефакторинг.
Отложите решения до последнего ответственного момента.
Ограничьте время спринтами или итерациями (ОЧЕНЬ важно для университетских проектов).
...
Если вы еще раз пройдетесь по некоторым гибким методологиям, я думаю вы найдете множество ценностей и практик, которые можно применить самостоятельно.
Во время написания этого ответа мне пришло как минимум 3 других ответа, которые опередили меня. Я согласен со всеми из них. :)
Make list of tasks and features that you want in your application. Take those tasks and put them on a card wall.
You can't really have a meeting by yourself, but in the morning decide what you will do for the day and what you successfully did yesterday. Take those tasks, do them and then move to the next. Make sure at every point you are delivering continuously integrated, working software and you update your backlog. You might have "bug bash days" where you just fix bugs. That would be a one man scrum. :)
It's hard to truly apply agile coding to one-man projects because many of its benefits are aimed at small teams where you can quickly collaborate on focussed areas.
That said, you can adopt some of the techniques:
- Release often
- Focus on your users' needs
- Feel free to deviate from major version plans - you can change direction whenever you feel the need
- Spend less time in setting up major frameworks and get something working as soon as possible. Then go back and refactor to accomplish your original needs (if they still apply)
Например, не бойтесь рефакторинга собственного кода, даже если он работает, если результат более гибкий и надежный.
Можно использовать Scrum для проектов одного человека.
- Создать бэклог
- Оптимальное время для одного спринта - полдня
В пятницу создайте план на следующую неделю и каждые полдня обновите сгорание для каждого проекта.
Несколько мыслей по этому поводу:
- Итерации имеют такую длину, какой вы хотите, чтобы они были
- IPM все еще возможны, если вы выбираете, что хотите сделать, в течение этой длины time
- Демонстрации в конце по-прежнему полезны для демонстрации рабочих функций в некоторой степени профессионально, а не в вашей маленькой области отладки, которая может быть не такой чистой или упорядоченной.
- Ретроспективы по-прежнему полезны, чтобы увидеть, что есть, а что нет работая на себя в точке, где вы можете видеть лес за деревьями в некотором смысле
Вполне возможно быть Agile в личном проекте одного человека, IMO.
All of the advice here is good, but there is one important aspects of Agile that usually goes unmentioned: monitoring.
Agile asks you to take a look at what you have done, what you are doing, where you are going, and make appropriate course corrections if needed.
I think Big Visible charts and Burndown/Burnup charts are so useful, I wrote a program, Task Analytics, to make these charts easily. It's perfect for small or one man projects.
Good luck.
Помимо развития пар, вы можете выполнять оставшиеся практики, если хотите играть несколько ролей. Если у вас есть кто-то, кто желает работать с вами, вы также можете заняться парной разработкой.
Сначала вы создадите бэклог продукта. Это будет приоритетный список функций или историй, которые вы хотите разработать. Никакая карточка не должна быть больше, чем работа, которую вы можете выполнить за одну итерацию или спринт. Если ваши спринты рассчитаны на неделю или две, это определит размер функций или карточек историй в вашем приоритетном бэклоге продукта. Как владелец продукта, вы можете изменять приоритет отставания продукта для каждой итерации. Из журнала невыполненных работ вы можете построить свои планы итерации и выпуска.
Поскольку вы играете несколько ролей, вам нужно будет выделить время для создания карты истории. Карточка истории должна содержать набросок графического интерфейса пользователя, описывать первичный и вторичный рабочие процессы и, что наиболее важно, иметь критерии приемки.
После того, как вы подпишете письменную карточку истории, вы можете начать разработку карты. Вы должны использовать TDD (разработка через тестирование), чтобы сначала написать тест, а затем код. Вы будете повторять, пока карта не будет готова. Критерии приемки помогут вам решить, какие модульные тесты писать.
Когда разработка карты будет завершена, вы должны будете написать автоматизированные функциональные тесты. Вы можете использовать Quick Test Pro, FIT, Cucumber или какой-нибудь другой любимый инструмент автоматического модульного тестирования. Я бы держался подальше от каких-либо функций воспроизведения и записи, поскольку это может привести к переделкам в будущем по мере вашего рефакторинга.
Как только модульный тест завершен и карта пройдена, его можно добавить ко всем другим автоматизированным функциональным тестам и запускать как минимум ежедневно, если не при каждой проверке.
В конце итерации и перед переносом вашего рабочего программного обеспечения в производство вы можете выполнить пользовательское приемочное тестирование .
Как разработчик, вы должны использовать непрерывную интеграцию, автоматические сборки запускаются с каждой частой проверкой вашей системы управления исходным кодом.
После того, как карточка истории была написана и до разработки карточек для итерации. , вы можете дать им задание (т. е. дать оценку каждой из задач, необходимых для разработки карты). Вы можете определить, можно ли выполнить какой-либо необходимый рефакторинг в рамках вашей оценки или вам нужно создать новую карточку истории, которая фиксирует технический долг, который вы определили.
Как видите, вы можете далеко продвинуться с одним участником Agile-команды. Учитывая, что методы гибкого управления помогают сотрудничать и определять, что важно, вы также можете извлечь выгоду из этих методов. Учитывая, что инженерные методы (XP) позволяют коду оставаться здоровым и поддерживать устойчивый темп, ваш код останется гибким, будет содержать надежные модульные и функциональные средства автоматизированного тестирования и позволит вам продолжать разработку в устойчивом темпе на неопределенный срок.