Я витрачаю багато часу, працюючи над проектами, в яких я є єдиним розробником, менеджером проектів, дизайнером, QT людиною (Так, я знаю ... Погано!), А іноді я навіть клієнт.

Я спробував майже все для планування проектів та управління собою, від простого сидіння та роботи фрістайлом до того, як проект буде зроблено скільки завгодно часу, до одномоментної версії scrum, в якій я провів зустріч з прогресом над собою -чоловік спалює діаграму щоранку (не жартує).

Для тих із вас, хто витрачає багато часу, працюючи наодинці, який найкращий спосіб організувати себе, керувати великими (для однієї людини) проектами та підтримувати продуктивність якомога вище?

Ведення чіткого списку своїх цілей є життєво важливим. Повзучість функцій легко перейняти проект, що керується самостійно. Також корисний підхід TDD "робиться, коли працює". Це заважає вам стати перфекціоністом.

Одне, що мені справді допомагає, - це уявити, що сказав би інший інженер чи керівник проекту в будь-якій ситуації. Часто я можу "присоромити себе" від поганого коду або повернутися назад, якщо графік прослідковується.

Ось ви йдете ... http://xp.c2.com/ExtremeProgrammingForOne.html

XP добре зменшує масштаби, оскільки це оптимально для невеликих сфокусованих команд ..

• Ви можете створити електронну таблицю запитів щодо функцій, встановити їх пріоритетність та вибрати найпопулярніший.
• визначте критерії прийняття (як виглядає зроблене) та зашифруйте його у тесті для виконання
• Далі визначте інженерні завдання, щоб приступити до виконання
• Пишіть одиничні тести, робіть найпростішу річ (YAGNI) та рефактор постійно. Мета - зробити зовнішній тест на прийняття
• Таймбокс кожного сеансу. Для ефективного управління часом ви також можете поглянути на техніку Помодоро .
• Використовуйте управління версіями та встановіть сервер CI / пакетний файл, щоб створити інсталяцію або поштовий індекс вашого програмного забезпечення
• Демонструйте часто. Наведіть зворотний зв'язок в оригінальну електронну таблицю та переоформте їх

Єдине, чого ви не могли зробити в команді одного - це PairProgramming.

Якщо ви працюєте сольно. Ось поради:

1. Робіть якомога менше низькорівневих робіт. Використовуйте стільки бібліотеки та інструментів, скільки можливо, включаючи речі, які, на вашу думку, можна легко кодувати (не робіть цього, просто використовуйте бібліотеку).
2. Виконайте підхід зверху вниз. Тільки кодуйте речі, які вам справді потрібні.
3. Коли ви побачите проблему в абстрактному вираженні, шукайте в Google і використовуйте дослідницькі роботи академічної спільноти, що вже було доведено. Вам потрібно лише кодувати їх алгоритм.
4. Створіть свою систему так, щоб ви могли вільно змінювати речі якомога більше. (включаючи копіювання та вставлення деякого коду звідси туди). Мета - заощадити ваш час, коли ви зрозумієте, що помилилися. Постарайтеся мінімізувати обсяг роботи, яку вам доведеться викинути, коли ви помилитесь. Шматок коду, який потрібно викинути (замість копіювати-вставити звідси-сюди) - це еквівалент часу, який ви втратили, написавши цей код.
5. Майте багато автоматизованих тестів, щоб ви могли регулярно робити тести регресії щоразу, коли вносите зміни
6. Розділіть обов'язки своєї конструкції (тобто зменшіть з'єднання). Зробіть речі максимально модульними
7. Використовуйте налагоджувач для налагодження та використовуйте двійковий пошук, щоб знайти дефект.
8. Постійно перефактуруйте свій код, щоб зменшити (явне) з'єднання та опромінення загальнодоступних методів (неявне з'єднання).
9. Нічого насправді. Це тут про всяк випадок, якщо я можу придумати щось нове: P

Код оглядів.

Вони особливо корисні, оскільки ви будете пояснювати код тому, хто не працював над тим самим проектом, щоб у них не було жодних ваших припущень щодо того, як це має працювати.

Вони також матимуть додаткову користь від обміну знаннями про компанію, тому коли комусь іншому належить працювати над проектом (через те, що люди зайняті в іншому місці, не хворіють, звільнилися або звільнилися), їм не доведеться починати з нуля. .

Я розгорнув свою власну версію agile, яка спирається на історії, важку взаємодію з клієнтами, часті випуски та тестові розробки. Я використовую вікі для відстеження історій, залучаю замовника якнайбільше до їх написання та замовчую клієнта працювати зі мною, щоб розставити пріоритети та організувати випуски. Я використовую TDD для керування дизайном та реалізацією. Я налаштував QA-сервер, на якому замовник може випробувати часті випуски (іноді щодня щойно розвиваються нові функції), щоб швидко отримати зворотний зв’язок. Я рідко проходжу більше 3-х повторень без виходу в QA. Клієнт повинен вирішити, коли версія QA має достатньо функцій, щоб перейти в прямому ефірі - а якщо більше списків не потрібно буде розробляти.

У моїй компанії наша група працює над тим самим проектом, але на відносно незалежних фрагментах. Одне, що ми багато робимо тут, - це те, що те, що ти робиш, здається трохи хитромудрим, або ти стоїш на роздоріжжі з більш ніж одним способом щось реалізувати, ти захоплюєш когось іншого і обговорюєш плюси і мінуси раніше ви продовжуєте. Якщо ви зачекаєте, поки ваш код закінчиться, щоб зробити огляд, зазвичай ви вже вклали занадто багато часу для розгляду основних архітектурних змін, хоча, безумовно, в оглядах коду виявлено багато дефектів.

Крім того, я усвідомлюю, що розробляється тестова розробка - це останнім часом трохи насичене мовлення, але це може бути великою підмогою для розробників соло, оскільки він забезпечує перевірку якості, коли ви йдете, і коли тести стануть важкими для написання, ви знаєте, що вам, ймовірно, потрібна якась реструктуризація вашого код. Це також допомагає пізніше обслуговуючим особам випадково не порушити код у важко виявлених способах.

Я пропоную вам наступне:

1. Розробка тесту
2. Легко використовувати "TODO: зверніть увагу" у своєму коді, коли ви побачите щось, чого не можете зробити негайно, і повертайтеся до них, коли у вас є час замість цього залишитися у facebook, чекаючи, коли ваш клієнт передзвонить.
3. Напишіть свій код, оскільки ваш клієнт придбає його, дивлячись на код не лише на результат, уявіть свого клієнта як голову для розгляду коду.
4. Заповніть свій код тверджень

Я хотів би сказати, що я міг практикувати те, що я проповідую 100% часу, але BDD, здається, є гарним підходом у вашій ситуації:

Ось посилання з додатковою інформацією: http://en.wikipedia.org/wiki/Behavior_driven_development

Я в дуже подібному човні. Я намагаюся якомога більше дотримуватися гнучких принципів (так само, як я їх розумію). Я, мабуть, не роблю справи «правильно», але я мав великий успіх у своїх проектах, намагаючись дотримуватися спритних принципів. Це займає величезну кількість дисципліни, оскільки немає команди, яка б переконалася, що ви не просто починаєте робити ярлики.

Я вважаю, що використання інструментів форматування коду, таких як ReSharper, гарантує, що, принаймні візуально, код легко підібрати для інших розробників.

Щодо фактичних методологій, одному розробнику важко дотримуватися будь-якого конкретного. Я консультант, який, як правило, працює один, і мені здається, що найпростіше як для себе, так і для клієнта використовувати спритний процес. Я, як правило, намагаюся змусити своїх клієнтів безпосередньо вводити їхні вимоги в такий інструмент, як Trac (або я буду від їх імені). Це не тільки допомагає іншим розробникам визначити мету коду, але й самі 3 місяці!

філософія: XP / TDD + GTD

загальний контур:

• опитати зацікавлених сторін
• екранні макети, покрокові інструкції, паперові прототипи (за необхідності)
• мозковий штурм для особливостей / сюжетів (із зацікавленими сторонами та без них)
• мозковий штурм тестових випадків (із зацікавленими сторонами та без них)
• загальний час дизайну / архітектури (за необхідності)
• ітераційне планування (із зацікавленими сторонами)
• ітерації
• огляд процесу, навчання, планування обслуговування тощо (за необхідності)

Будь-яка відповідна методика допоможе - незалежно від кількості людей на проекті. Отож, виберіть його одночасно і подивіться, як ви можете застосувати та відобразити карту до свого домену та виміряйте їхній успіх.

Можливо, цікавіше запитати, які методології не викидати, бо над проектом працює лише одна людина.

І головне, що мені виділяється, - це Контроль над джерелами (Так, це інструмент, але це частина вашого потоку роботи, а також процес). Люди можуть спокуситись зробити це пропуском, оскільки їм "не потрібно одночасно підтримувати кілька людей, що редагують код".

Як не дивно, я вважаю, що рішення для управління версіями на зразок GIT краще для людини, ніж щось на зразок SVN.

Якщо викинути код, можливо, ви зможете бути трохи неміцним з методологіями, але все важливе, і я б сказав, що ваш спосіб поводження з ним як командний проект з однією людиною дуже приємний і дисциплінований.

Напишіть свій код, щоб наступний хлопець прочитав, а не ви ... будьте приємні йому / їй. Навіть код «викинути» залишається навколо назавжди.

Спритний

функції, розповіді та тестові приклади набагато більш повчальні, ніж формальна документація, а набір робочих тестів краще демонструвати, як щось використовувати або як щось працює, ніж будь-яка кількість мертвих дерев

Також простіше передавати роботу між ітераціями.

Як мій консультант, я б запропонував вам знайти спосіб, щоб завжди було як мінімум два розробники для будь-якого завдання.

Я погоджуюся з проворністю і про те, щоб залишити спритний слід у історіях і тестах, які можуть наслідувати інші, але я не вірю, що будь-який інший процес чи методологія дотримуватимуться, коли люди працюють в соло.

Я думаю, що огляди кодексу - це гарний початок, але мені подобається, коли це робиться неформальним та веселим, як, наприклад, перегляд коду пари або програмування пари з метою вирішення певної проблеми / проблеми чи певного вдосконалення (наприклад, зміна застарілого коду для задоволення нових стандартів кодування. ). Часом два набори очей краще, ніж один, і це також цікаво, я відчуваю, що обмін і обговорення здається більш відкритим. Ви також можете провести офіційний / неофіційний обід та обговорити сесії, щоб поговорити про те, що ви робили окремо або як група, наприклад, згадати про новий шаблон, який ви використовували, або про нові технології, як вирішувалася проблема?